What is it that makes the best software engineers?  I expect this question yields strong opinions and varying answers.   Over the years I have been a part of various processes and tools all created to help make better engineers, but I often wonder how effective these are.   At times it feels like the old saying “you can lead a horse to water, but you can’t make them drink.”  Ultimately I see something more intangible which exists in the best engineers.  The processes & tools then help these engineers work better together, and in some cases raise the bar of others.

Measurement of software engineers can include such metrics as # defects, code maintainability, schedule, cost, performance and usability.  While many books, processes, and classes have emerged over the years to improve each, underlying these are a set of behaviors which are critical for those processes to yield results.  My experience has shown the following intangibles exist in the best software engineers:

Desire to specifically understand what code is actually doing.  I am amazed how often engineers will work within a code base with limited knowledge of what the code “around them” is actually doing.   They rely on what a couple of tests demonstrate or others have told them.   These engineers may be using 3rd party libraries or extending existing code.  The engineer who has the natural interest to understand how it actually works will yield substantially better results.  For example, when one is enhancing existing code (i.e. adding new features) do they “wander” around the code to get a sense of the impact/risk and how the structures and algorithms are actually used?   This wandering may include stepping through a debugger extensive code and building specific test harnesses to observe code behavior.  This knowledge is what helps ensure new code does what is expected with minimized side-effects in the system.

Naturally ensure code is maintainable – even fixing others code.  This includes consistency in formatting, clarity in naming, thorough functional/algorithm comments, consistency with code organization and architecture standards, and refactoring when possible.  This is not something one performs after the fact, so it must be part of how the code is originally written.  Even with the IDE code formatters in use today, I believe how an engineer handles this reflects their approach to writing code.  Software is precise and requires thinkers who are precise and well organized – and expect this from others.  This focus on maintainability is what ensures new and updated code remain maintainable for years to come.

Can decompose a complex problem into simple sub-problems.  Does one naturally notice common code patterns and extract to a reusable block or when doing code reviews do you see evidence of regular copy/paste?  While this can (and is) taught, it is generally something one “gets” and applies or they do not.   Part of the challenge here is being able to identify “almost similar” bits of code and realize they are performing a similar function with some variable modifier.  How the problem is viewed and solved originally will determine how easily it can be enhanced and maintained in the future.

Seek to learn and enhance their programming skills.  How many software engineers actually take some time – say even 1 hour per week – to read and follow any number of very informative web sites.   Folks may be aware of these sites and might even visit them once in a rare while – but which engineers on your team actually take time each week to read and digest something new.   This can be everything from what’s new with relevant technologies to best practices for various programming methodologies.  The key here is someone who desires to advance their abilities on their own.

Understand their own limitations and collaborate around solutions.  Here I have seen examples on both ends of the spectrum – engineers who are like deer in headlights and cannot move without getting input before each step and others who are unable to sense when they have exhausted their own knowledge/experience and need help.   I can see where this attribute can also be heavily influenced by the environment including culture, processes, and past experiences.

There is no mention of languages, operating systems, colleges attended, years of experience, technologies used, size of products and/or teams…   I believe it is more about someone with that natural curiosity to understand how a system works, has the innate attention to detail to build maintainable code the first time, and aptitude to understand large and often complex problems.

Ultimately the question remains – how much of this is natural and how much can be taught effectively?

Advertisements