Coding and the illusion of competence

"Walking on water and developing software from a specification are easy if both are frozen" (Edward V. Berard)

I once worked with a C++ developer who was apparently very green as he could not tell me what version of Windows he was on (*). He was able to complete the project he was assigned, but I do not know if the said project was ever deployed as performance was so bad.

The morale of this story is that pretty much anybody can code most real-life specs. It is however a whole other story to develop something that can be easily maintained and offers good, scalable performance when tested in a real-life scenario. There are countless books and methodologies and competing school of thoughts on that matter - and nobody has found the silver bullet.

Coding does not equal competence

It is very easy to assume that, because we have written a program in a given language we now master that language (as well as programming). We have actually mastered the easiest part: the syntax. This part is easy to learn because we get immediate feedback : if we write the wrong thing the program refuses to compile or does not produce the expected result at runtime.

Coding is easy. It's maintaining the software which is hard: making it as easy as possible to debug and evolve even if we haven't looked at the code for a year. Making the software evolve to reflect the ever-changing specs without creating a mess of a code. Making sure the program can scale when tested with real-life scenarios.

(As a side note, I don't know if many universities -if any- focus on the maintenance part. A good course would be to have a multi-year project where students have first to write a Website, but then update it to accommodate multiple specs changes, sometimes 6 months after not touching the project. The whole point being to encourage to refactor the code for better maintainability and to write proper tests)

Maintenance is hard because there is no immediate feedback. And in some cases we may spend years being unaware of our sub-optimal way of doing things (don't hesitate to enter in the comments all the things wrong with the code from the screenshot). Here are however some things which are useful to learn.

Learning the language idiosyncrasies

Most languages look familiar with each other. After all, C++, Java, JavaScript and C# all borrowed their syntax from C, which in turns borrowed it from B. A lot of them however introduce their own unique ways of doing things - it's generally the reason why they were created in the first place.

It is however very easy to ignore these idiosyncrasies, even when they could help us tremendously.

Consider the following: you want to filter a list of strings to only keep the strings that start with "A". In pretty much all (iterative) languages the following approach works:

• Create a new list
• Loop through the old list
• If the string starts with "A" add it to the new list

This works, but may not be the cleanest way depending on the language. Python has list comprehensions for this. C# has LINQ. Java can use streams. JavaScript has the filter() and map() collection methods. But the interesting thing is that you may spend your entire career without realizing this.

Understanding how things work under the hood

The general trend of programming languages is that they mask more and more the hardware complexities, letting us focus on the business logic. This works great... until it doesn't anymore. When Murphy's Law shows up its ugly head, knowing how things work under the hood can come in handy. Whether to troubleshoot why the program is all of a sudden behaving in a seemingly unusual way or to know how to tune your application for better performance.

For instance, most language have a library or framework that wraps database access so we don't have to write SQL: Rails for Ruby, Django for Python, LINQ for C#, CakePHP for PHP, etc. It works great, but works best when one knows what is happening under the hood, like what SQL queries are executed and when. Careless developers may encounter poor performance when they hit the so-called N+1 problem, where displaying a table of N items performs N+1 SQL queries under the hood.

Knowing what is likely to evolve

One factor which hampers software maintenance is when the parts to modify are hard-coded all over the place. Imagine hard-coding the number of wheels in a car maintenance software (stored in variables named wheel1, wheel2, wheel3, wheel4 to make things worse). Modifying the software to work with other vehicles with more than 4 wheels could be tedious.

On the other hand, making sure everything is dynamic would be extremely time-consuming and offer poor performance. Imagine implementing the same software so that it can deal with a potentially unlimited number of steering wheels, engines, tires per wheel, brands per tire, etc. Classes attributes could not be simple types (e.g. string for the model name) but would need to be all collections (e.g. a list of strings - just in case where the vehicle has several model names).

This is where a feel of what is most like to change over time is useful, whether it be common sense, specific to the industry we're working on or something we learn with experience.

Last but not least

There are numerous other skills that help us make a better developer:

• The main language libraries: Popular languages these days come with an extended library, whether it's a standard library that came with it (Java, C#) or from a plethora of third party libraries (all too common for popular open source languages)
• Good programming principle such as DRY and the design patterns that help writing maintainable software
• Scalability Design Patterns and how to performance tune one's software
• How to write proper tests: yes, the days where all the testing is done by QA are pretty much over.
• Cybersecurity fundamentals: this is becoming more and more important as more and more software are targeted by hackers.
• Learning other languages just to see how are things done in other environments can also be useful. For instance, Ruby on Rails great testing tools (Cucumber and RSpec) influenced how I wrote tests for other languages.

I will end up with this quote: "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." (author unknown)

(*) Yes, that happens when there is a talent shortage. Some companies will hire people with barely -if any- programming experience, provide them with quick and dirty training and send them on the field.