Previously I wrote about small changes from the eyes of an Engineer. Building on this I would like to elaborate a bit on my view of what the day of the most experienced and senior engineers I worked with tend to look like, and why it's not always been the engineer focusing on writing the best code.

A small warning: Many of these things requires years of experience, this is meant to be a thought piece and not a step by step guide how to speed up your career. If you are just out of University and start applying some of these things because "you definitely can" you run the risk of making your career short - take a cue for the more senior engineers, follow their lead. This will help you identify a great engineer for a mentor, not a blueprint for how you should act.

System over Code

These engineers and architects have always started with viewing it from a systems perspective. How does the whole tie together? What are the moving parts being affected? What is the trade-offs with different choices, and are those trade-offs for the better for the system?

They are working from a top down perspective. Mentally running through everything in theory before applying anything in practice. This is invaluable when it comes to having a clear, concise, and effective system. When doing this they are making sure that they keep the main goal of the system in mind and avoid patching in functionality that might look good at a quick glance, but when considering the full entirety over the entity they make sure to implement it in a way that doesn't disrupt the whole.

Trade-offs Over Perfection

A good engineer will know when it is time to follow best practice, and when it is time to shoehorn in a solution that enable a functionality, but will result in technical debt. With this I don't mean bad code or introducing security risks, but it means breaking the established pattern with an anti-pattern. In most cases a good engineer will tell you that it is bad to use anti-patterns, and it is bad. It introduces complexities that will make it a lot harder to maintain. However, there is this one in a million time where it might be the preferred way of doing it. And a good engineer can tell you when it is preferred and when it isn't.

One example where a pattern violation happen is on my own web site. I have a clear separation of front-end and back-end, the back-end should only have to deal with the front-end and never generate any html. However, when it comes to dealing with a few exceptions I allow direct contact with the back-end for something externally. These things are the Open Graph (OG), sitemap.xml, and the RSS flow. Why did I elect to break my strictness here? All of those three have one thing in common, the consumer of them are not human. They are html (OG) and XML (sitemap.xml, RSS flow), but they are not intended to be read as is by humans. They are just returning structured markup languages for other software components to read. Putting in the front-end in the loop would actually introduce more complexity by maintaining both a back-end endpoint and a front-end code section than redirecting to the back-end.

Strong Theory

Most high level engineers I've met and worked with know theories and best practices, and they know how to apply them. But they also know when to violate the best practice and when a theory have a trade off. This does not equate to highest academic degree, it maps more to experience and interest. By knowing more than one theory and seeing the best practice from a system perspective they are able to see what will work well together and what will work against each other. In many cases this is hard bought knowledge that have been picked up by painful mistakes that cost them many sleepless nights and much overtime.

Context Over Rules

The most senior and experienced engineers I have worked with have been able to determine when to apply best practices and theory, and when to violate them. A quote I was one told by an engineer I worked with was:

Best practice is for best situation, but reality is rarely best situation

I have been carrying this quote with me for over 10 years, and it have guided me in trying to apply best-practice, but also accepting that it will not always be possible.

Learning the Stakeholder Domain

One of the best engineers I have ever worked with did something I strife to be able to do. He learned the domain the system was supposed to work in, to the brink of knowing the situation better than the stakeholders. This was a very specific domain that was implemented to be doing field research. With this I don't mean that he knew everything about the research field, but the setting that the research was performed in. Armed with this knowledge, he could question requirements to a level that the stakeholders understood why he questioned it and what the implication of their choices would have on the system. This in the end made the system much better, he was the bridge between the stakeholder domain and the system domain.

Knowing When Not to Build

Knowing when to reject requirements outright because it isn't align with the requirements is a highly sought after ability. It requires knowing the domain that the system is meant to impact, and being able to tie together the code, the system, and the stakeholder domain. To do this you need to have extensive knowledge about all of them.

Ownership Beyond Code

When rejecting requirements it isn't enough to just say "no!" and go on with your merry day. It is about analysing the requirement, and take pride in your work. A requirement can be sound, have everything it needs, but it would objectively not be adding value to the end product. It might add superficial value as a requirement, but understanding how usage of the end product and reject things for coding and give suggestions on improvements of the suggested feature - that is taking the ownership beyond just owning the code base. That is stating that you want the best end result as a whole, not just deliver quickly. You collaborate with your stakeholder rather than working for your stakeholder.

Strong Communication

I have seen many bright and exemplary engineers, previous bullet is a case in point, that have known more theory and best practice I thought was around - but they have not been able to explain them to others. This is one of the main things I see setting a strong engineer apart from the best engineers. The ability to take their, extensive and complex, domain knowledge and translate it to non-engineers and engineers alike. This ability does not only strengthen up a relationship between engineer and stakeholder, but it is also invaluable to create a new generation of Senior and Principal engineers.

A practical example here is when I was working as an Agile Coach I asked one of the engineers to explain a mathematical theorem to me, keep in mind here that I have little to no maths knowledge, and this engineer was able to with a whiteboard explain the theorem to me, and I walked out understanding what it actually meant and why it was useful in this system.

The Cost of Change

This usually come across as obtuse pushback when coming from less experience or communicative engineers, but when done right it will come across as obvious. Knowing the system and understanding what impact changes have on it, and being able to clearly communicate that it requires more investigation before committing to the change, and being able to on the spot highlight some issues that might occur when implementing a change is worth a lot, being able to put it in plain speak so stakeholders understand why is golden.

Fostering the Future

The difference that I noticed between a good engineer and a great engineer is the ability to take someone under their wings, without the person under the wings notice it. A very senior engineer I once worked with, I didn't realize had taken me under his wings and protected me from myself without me even noticing it. He treated me as a peer, but hinted me to explain myself away from my own reasoning. Being a good mentor is not about teaching, but it is about making someone evolve. I am very sure that without his guidance early on I would have walked around with a bigger ego than a state deficiet. That would have held me back for many years as being "difficult to work with" or "too opinionated". I am still very much opinionated, but I learned by working with him when the right time to express my oppinion, and when not to. He helped me being my own devils advocate. He fostered the future, in a way that made me learn my own lessons.

No Ego

When I was a junior, one of the things that I found most scaring was to tell a principal that they had made a mistake or misunderstood something. I was very lucky in quickly learning that the true principals are not sitting in an ivory tower doing their best impression of an emperor. Most of had very little ego and quickly acknowledged the error of their ways or was able to explain it to me why that choice was made. As long as I could back my argument up with facts, they were very receptable. They didn't look down on me or was snarky, they welcomed my critique and lifted me up and expanding my knowledge.

Confidence without Hierarchy

I will once again go back to a personal experience, this is the same person that was fostering me. He knew what he could do, he knew how good he was at his job. But he didn't need to assert himself in a loud and boisterous way. When he asked a question or said something people listened, but not because he wore a title, that place literally just had "Software Engineers" with no prefix. And he was comfortable with that, he was approachable and was always up for a good laugh and was more than happy to allow people to take space. He talked the same way to the head of department as he did to Juniors - if anything he was more respectful to Juniors than leadership. What did this do? It made him irreplaceable. He did his job, he took time to review architecture and paradigms, he made sure to help people that were in the weeds, but he also allowed people to fail in a safe place.

Usage of AI

AI is new, but with experience it becomes easier to see how it fits in the day-to-day work. In my eyes it is just another tool for efficiency. For engineers that have been around for a while, the idea of scaffolding is not new. AI agents can be treated in the same way. It is there to remove the tedious tasks that take time and are easy to get wrong for a human. It is not a replacement for reviewing the work, and it is not a replacement for understanding the language and architecture. If anything, it makes those things more important. It is easy to generate something that looks correct. But it takes a good engineer to determine if it actually fits within the system, aligns with the architecture, and does not introduce hidden complexity.

Final thoughts

To close this out. Have I always thought like this? Heck no! When I started I thought I was the best at everything, and that all my ideas was the best ideas. I did stupid recommendations based on my gut feeling from my limited experience pool - which later either came back to bite me, or gave me a lesson from someone with more experience. I will gladly admit that these lessons were learned by mistakes. It is important to make mistakes to be able to learn. In one place where I used to work we had a saying:

You are not a real engineer until you have brought down production at least twice.

At times you need be allowed to make mistakes to gain wisdom, and at times you need to be corrected to get knowledge. A good engineer will know when it is time for the first, and when it is time for the latter.