Stretch your mind

“The more you know,
the more you realize you know nothing.”
– Socrates

There is a big push on young engineers (and colleges that educate them) to build up a wide variety of popular, currently in-demand skills. More popular technologies, common platforms, more courses and projects give students a better chance to hit every bullet point in job recs. It is favorably considered by recruiters and looks extremely attractive to hiring managers who think they are getting a well-rounded engineer at a recent-graduate salary. In addition, it sounds impressive in casual conversations with peers and professionals alike. 

Unfortunately, breadth often comes at the expense of depth. Mastering depth of understanding fundamentals, theories and concepts that are the foundation of modern technologies takes time, effort and dedication to learning. It also takes a lot of effort to learn to work in technologies that give developer more direct access to underlying systems, and data structures. It takes passion and drive to gain an understanding of how to use any technology well, and to set high standards for one's work.

Those with deeper understanding, and the curiosity to gain that understanding, go on to become better software engineers and architects. While not immediately required by a job rec, knowledge of the underlying concepts is regularly needed to solve tough technical challenges in real life. Familiarity with more difficult concepts and technologies makes it easier to learn the popular and simpler ideas that change many times throughout one's career. It is well-established that ability to learn, to think critically and creatively is trained by pushing the mind out of its comfort zone, studying hard, understanding rather than memorizing.

Popular technologies and skills that are “hot” in the jobs market are designed to be easy to acquire, and to solve a narrow set of common business problems, with the trade off that these technologies may not be well-suited to a wider range of applications. These skills are easy to learn and apply. The difference comes in the speed of learning, the quality of outcomes, and the critical thinking that better engineers bring to the job, together with the technical skills. In a competitive marketplace, those who went through the trouble of gaining the deeper knowledge of computer science fundamentals, software construction, and code craftsmanship will fare better.

Two are better than one

“If you can't explain it to a six year old, 

you don't understand it yourself.”

― Albert Einstein

Pair programming is uncomfortable, exhausting, and un-ergonomic. With pairing it takes two or more people to do a job of one. It is time-consuming to organize, tiring to participate in, and painstakingly slow to observe. The benefits are non-obvious.

Code reviews are nerve-wrecking, aggravating, and painful. They take enormous amounts of time, bring out the worst attitudes, and spur religious wars on code minutiae. Results are often inconsistent, suggestions are petty, and resulting improvement is invisible.

Yet, there is plenty of evidence that teams that manage through the pain and find the time to pair, to review, to swarm, to mob-program, and to work together using any other technique, do significantly better. Pairing and code reviews contribute greatly to the value being delivered in higher product quality, shorter time to release, and in lower maintenance costs.

It comes down to a simple truth, noted a long time ago:

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” - Brian W. Kernighan and P. J. Plauger

 Left to our own devices, we want to be clever. But if we have to explain every turn of logic, every leap of faith, and every tiny assumption to another human, the desire for cleverness retires to the back of our minds, and leaves the center stage for the desire to be understood. This difference alone causes a big improvement in the work that we produce. Readable code has a much better chance of being good code, than code that’s hard to read.

It also means that the person reviewing the code, or being the non-writer in the pair does not have to be a developer, she could be anyone familiar with the product.  Even if that person does not contribute directly to the code, their questions will influence the programmer to write better software.

In the case of two or more developers working together, in addition to producing better code, all involved will be intensely learning from each other. And that’s the best thing that could possibly happen to developers.

[It will also make them tired.  I suggest getting a lot of colorful plastic balls, and investing in the fanciest espresso machine your office can afford.]