What distinguishes Software Engineers

In conversation with one of my accountant friends who works in insurance, he made me realize “There is no standard for software engineering.” In accounting, certification exams stratify accountants. They gate the industry, raising the standard of professionals. Software Engineering has adopts the free-for-all approach. So long as you can type some instructions into a computer, and have the computer run it, you can categorize yourself a software engineer. Your ability to market your skills, and rise in the social ladder will get you “recognized”. There are some certificates within software engineering, but these are not as enforced as in other industries. How then do we tell good engineers from the lot?

Software Engineering is a people business. People think. People create. People maintain. These are some traits which distinguish good software engineers from the lot.

1. Competence
2. Maximizes Current Value of Work
3. Practical Informed Decision-Making
4. Enabling others to make decisions efficiently
5. Continuous Learning

Competence

Competence is the bedrock of value-generation in any value-system. Competence in software is now everywhere in the interwebs. I call this distributed competence. A good engineer, however has this distributed competence localized. Localized competence allows an engineer move faster with software. This competence revolves primarily around technical coding skills. This competence is must be tool-agnostic. The focus here is on the quality of code written. How performant is it? If given to a 5 year old, can the 5 year old explain the algorithm?

Maximizing current value of work

To explain this, I must posit two hand-wavy lemmas. First, “Creating software costs money.” The value of engineer-time has grown astronomically over the years. Second, “Software is built to be maintained.” Good businesses want repeat customers; not only one-time customers. On these two lemmas, every software change has a long-term economic value. A good software engineer takes this into consideration with every new change.

There’s always a new-cool way to get something done. But is it the best way? Hacks through a system create technical debt. This accrues to slow development down over time. Unfortunately, people are less inclined to clean up technical debt when the opportunity cost is losing some potential new business. The optimal and ideal software engineer creates no technical debt. The optimal and ideal software engineer does not exist. However, a good software engineer minimizes the pain of future software engineers maintaining their work.

Practises informed decision-making

I remember a quote which explained software in a unique light. I do not remember the exact wordings, but paraphrased, it sounds something like…

A software product is a snapshot of the progression of decisions over time on the subject matter by a certain group of people.

While building software products, software professionals must make and change decisions to continually. These decisions serve to align the software product to the domain where it lives and works, in order to maximize profit — in whatever metric profit is defined as. Another type of decisions made in software engineering is trade-offs. Ever heard the phrase “There are many ways to kill a cat”? That’s true in software more than other industries. Take the Javascript community as an example. If you’re looking for a library to do X, there are on average 100+ packages which vend X. How do you choose which one? If we unfreeze the Javascript decision, how do we select which language vends the best tooling to do X? What do we leave behind? These trade-offs happen daily — sometimes unconsciously — in software engineering. A good software engineer sees clearly enough to make decisions with the best trade-offs for the product.

Over time, our decision making gets “trained”. The frame of mind through which we view software freezes into a “comfort zone”. A good software engineer is able to occasionally “break frame” in order to gain new insight when making decisions. A broken frame of mind is better at gathering information. A frozen frame of mind is better at filtering information. Both of these are necessary in decision-making.

Engenders

Up until now, all traits we have seen has focused on the individual. While it’s often to great to be a “10x Engineer”, durable software is often built in teams. A good software engineers knows this and replicates these skills in colleagues.

Engendering includes — but is not limited to — acts pairing, mentoring, supporting, …. Pairing is beneficial both ways. Each part of the pair gets to learn how the other parts does software. Every engineer is unique. Mentoring shares experience and expertise over time. Supporting is often done by more experienced engineers, so less experienced engineers have a safer environment to grow and experiment. These are short explanations to these; but entire volumes can be written about each.

Continuous Learning

No good engineer stays good forever. The industry keeps changing. In order to stay up to date with best practices, engineers must constantly learn. Good engineers maintain a high level of curiosity towards their work. If something does not work, they dive deep into why it doesn’t work. If something works, they dive deeper into why it works. This this continuous learning breeds competence in engineers; and the cycle restarts and continues ad infinitum.

Conclusion

Software Engineering may not have a single examination to filter out professionals. The human-centric nature of the discipline makes it difficult to measure. These five traits should closely approximate the filtering mechanism for distinguishing good engineers from the lot. If you end up abstracting this into some mechanized test, please reach out to me through one of my socials on my homepage — preferably Twitter. Until then, build good software.