The Anatomy Of A Software Engineer

Software development is a lot more than knowing a couple of programming languages, popular libraries or to be able to traverse a binary tree in a job interview. It's crucial for product managers, team leads, engineering managers, and basically anyone making decision over engineers, to know how to mix and match expertise inside a company to unlock true productivity.

As there is reusable and non-reusable code, I will classify engineering knowledge into reusable and non-reusable categories.

The Non-Reusable Knowledge

Let's start with what I consider "non-reusable" as these categories are all about detail and gotchas. The quirks of Linux won't transfer when you work with IIS (Internet Information Services) of the Windows ecosystem for example. Let's get to the details!

Knowing a Programming Language

I consider the details of a programming language "non-reusable" as the syntax of a language cannot really be used again - unless the other language is almost the same. It's much easier to jump from Java to C# than from JavaScript to Rust. In the latter case you need to relearn keywords, rules, gotchas, and indentation, best practices, anti-patterns... Not to mention package managers and the strengths and weaknesses in the ecosystem (e.g. which input validation library to choose).

???? When moving around engineers for a project, consider that lhe less similar two languages are, the more time they will need to write intelligent code.

For instance ixn JavaScript, the idea that the this keyword of a function is a freely attachable context, and not a pointer to the object containing said function, cannot really be reused in another language; it's a one-time quirk. Once you abandon JavaScript that knowledge will be lost (or you can bore young colleagues in the future about it).

However, the more familiar you become with the deep features of a language, you'll know what to search/ask for when you learn a new language and can get productive a lot quicker as opposed to be a newbie. It took me little time to refactor and low-key optimize the code of data analysts when I had a Python assignment; they knew how to crunch the data, I knew how to avoid typical coding mistakes. See more about this in the next section!

The Ecosystem of a Language

The ecosystem of a language refers to the modules or packages available — like react, express.js, or SQLAlchemy for Python — that are typically accessible through a package management system, such as npm, pip, or NuGet for .NET.

This knowledge accumulates slowly through years of trial and error, getting lucky or getting burnt with someone else's code. In some ecosystems you absolutely should not reinvent the wheel by reimplementing what's out there; in others you might encounter abandoned projects or missing important libraries and you'll have to roll your sleaves up.

Even if you're not changing languages during your career, frameworks change often as well: libraries like Angular or firebase get rewritten with a new design goal, so this type of knowledge also tend to get lost with version changes.

???? Consider the ecosystem when moving people around in a company! This knowledge cannot be externally obtained through search engine queries or asking one of the LLMs.

Going back to my Python assignment, while I was getting their code cleaner, I needed lots of help for all the things that were unique to Python, like setting up pip, the package manager and development environment. The analysts colleagues who had significant amount of experience with the basics were very helpful dealing with this.

Platform-specific Gotchas

Languages and ecosystems do not exist in a vacuum. There is an operating system or sandbox around them (for example, MacOS, Firefox, or a particular Android version). The medium our code runs in dictates how we write things. Here are a few examples of these type of gotchas:

• Some older browsers won't be able to process certain newer UTF encodings and completely drop rendering the page.
• Working on a react-native project chasing mysterious Android crashes, I needed to get familiar using logcat from Android Studio.
• I had horrible, non-reproducible failures for timeout related tests. Turned out that the virtual machine had its internal clock out of sync with real world time. It took me 2 days of bug hunting figuring this out.
• Running two tasks in series with && is the standard on a Mac, but it won't work on Windows; hence the existence of https://github.com/mysticatea/npm-run-all.

These can only be learned by paying the "iron price": struggling through mysteries, scrolling through GitHub issues, and asking for help. You can be stuck debugging these for days from time to time!

Therefore, this experience is a very important part of engineering and crucial for having real productivity! Sadly much of this knowledge starts from zero whenever engineers are reassigned across platforms.

???? Platform-specific knowledge can make or break releases! Make sure you not only have enough engineers but to have experts on the platform you're building for.

The cross-platform framework react-native is a great example to illustrate this point. You can't just grab 5 JavaScript engineers and put them on a react-native project if none of them have mobile development experience.

Having a team member who scores high on platform-specific experience is able to defuse future landmines that others would not even know to look for. It's much cheaper if way before release that expert engineer exclaims in a meeting that something won't work than pulling back an embarassing failure.

Invaluable Product/Domain Knowledge

When working at one company and one product for years engineers get to know the user base, their needs, the problems they face. They would also know the code inside-out.

Some of them can know more parts of the product and customers deeper than the product manager!

Engineers that spend significant amount of time on one product, one aspect, usually become living encyclopedias of both the product and how it works. They become the "go-to" people when someone has a hunch but not unsure.

???? The domain and product knowledge of engineers is crucial for a company if they want real productivity! This local expertise can be easily lost with arbitrary layoffs, denied salary raises or moving team members frequently around.

???? Let me emphasize this a bit more: how your product and codebase works cannot be asked from ChatGPT or from online forums!

There are of course more general and more concrete domain knowledge. For example being familiar with how in the real world devices can lose and regain internet connection during a session can translate to both planning single page applications and mobile apps, while the intricacies of GDPR regulations is not really transferable.

Reusable Knowledge

Now let's focus on the good things: what an engineer can bring from one assignment to another.

Engineering Principles and Instinct

Luckily much of the principles behind popular paradigms are quite reusable: clean coding, the SOLID principles, design patterns and anti-patterns, the test pyramid, and the art of discarding unnecessary layers (in other words: avoiding overengineering). This last term in my opinion is what we can call a pure instinct: you develop your subconscious skills by working with both elegant and terrible codebases, and after a while, you will just see when something is overcomplicated or off.

It is also knowing what to reuse and what not to reuse. It's your ability to smell the code.

To give another personal example, when I had to fix a data engineer's Python code, even as a Python newbie, I immediately searched for a better way to replace variables in a string than positional %s signs that are prone to silly mistakes (like putting address in place of firstName when the amount of data passed changes):

# original version was something like this  
'SELECT %s FROM %s WHERE id = %s' % ('my_table', 13, 'name')  
  
# versus  
  
'SELECT {column_name} FROM {table_name} WHERE id = {id}'  
.format(id=13, table_name='my_table', column_name='name')  
  
# Did you notice that in the first version the order   
# of the arguments passed is wrong? Not likely to happen in  
# the second version - it would look odd immediately  

As it turned out, there was already a syntax for named placeholders, which is superior with its clear indication of what each property means, therefore changing the order of parameters will not have consequences.

This is the most reusable knowledge.

It also helps you with the adoption of a new language: you know what to put into the search bar to find exactly what you need.

???? Tip of the day: Head First Design Patterns is a book seemingly about Java, but in reality, it gives you the why of every pattern and you can learn a lot about principles that are useful in other languages. It's not just for object-oriented programmers!

Problem Solving Skills and Engineering Instinct

One of the distinguishing feature of a truly senior developer is to look holistically at feature requests. It's no longer "just another button in the menu". The experienced eye would look for potential clashes, think about small monitors, mental load of the user, consider UX practices and anti-patterns.

There are also ways of how to approach nasty problems, like tracking down an error without any useful traces by progressively commenting out parts of the codebase. Or engineers can develop an eye of spotting scaling issues like "Well, with a 100 users this is not a problem, but we're going to be stuck when we have 10000!". Or tricks, like inverting the problem statement, brainstorming hacks, and so on.

Finally they would know what requirements to implement to the letter and what requirements need more investigation. Or where and how to look up data to support or disprove assumption.

For example a story can be making a sizable chunk of the knowledge base available for non-registered users. If the task requires significant changes, it might worth looking into the data; if it turns out that 99% of the users are logged in, then maybe you can skip an unnecessary and expensive feature.

This is readily reusable knowledge, and to some extent can be enhanced with special training sessions.

Personal Productivity Management

This ranges from getting the most out of your IDE with the right setup to organizing your day effectively. It also includes knowing when to push through a problem regardless of time versus when to go home when you're done, or when to politely decline meetings to stay in flow. This is also knowing your own limits, understanding the resting requirements of your body, or have rituals to reset your brain.

Growing Lasting Knowledge

I have learnt SQL, HTML and CSS at the university (alongside classics like algorithms, object-oriented programming, design patterns and so on). Later I had to work the trend of the year, for example styled components or certain ORMs, like Prisma or TypeORM. I still use those first three, for almost 20 years, but I no longer work with styled components, Prisma, .NET or Angular.

Either if you plan your own career or you lead a team, you should not take the easy path of relying the latter over the former. Skipping learning SQL because you have an ORM is setting you up for a bitter loss of knowledge in a couple of years.

???? Having only trending tech in a team is a red-flag and vulnerability!

Therefore any reasonable engineer/manager should think about investing into the lasting basics.

Communication Skills and Solving the Problem at the Right Level

Let's not forget soft skills!

A well-versed senior software engineer would have experienced different methodologies, problem solving methods.
Hopefully by this time in their career they become excellent team players: hard stance where it matters, agreeable where it doesn't.

Let's say you are having a heated argument over the way to collect IMEI number from the phone in the application. One way possibly takes 2 weeks to implement. However, someone raises their hand and says: "Hey, let's ask legal team if we can actually collect that information from a user!". This is yet another engineering instinct that comes from being exposed to many facets of a problem.

On the communication side, learning to be context aware, know when and how to explain technical concepts to non-technical people and so on. Or learning that the loudest people are not always right and you have to ask each team member one by one to get the full picture.

Then there's considering the entire team from business owners to data analysts. You can vibe-code refactor the entire codebase in a caffeine fuelled late night sprint, however if the new code completely replaces analytical event names and properties then your data analysts and your business team will get absolutely understandably angry.

Summary

I hope that this article was enjoyable and helpful for managing teams or your own future career in engineering! During my career I have encountered many cases where leadership had very naive expectations over productivity, coming from not knowing how engineering and engineers worked.

I also hope that I nudge existing or prospecting team leads, product managers and CTOs to map out differen types of expertise in their teams and to be strategic about nurturing local knowledge. Check this interview I did with a friend about what happens when someone can never reach a deep expertise while she was always doing what was requested.