Of course I speak somewhat tongue-in-cheek as the developer does not necessarily physically walk such a tightrope, but mentally and theoretically the analogy is quite appropriate. A good developer understands the gravity of the situation and the job which lies before them. The tightrope is indeed stretched precariously between the start of the project and the last line of code to be written. If they lean too far towards writing code quickly they risk the danger of falling into the abyss beneath them. If they err to much towards accuracy they’ll slip off the other side. It’s a very real balancing act they must perform in their quest to complete the project successfully.
Let’s explore some of the skills which must be exhibited to cross this chasm successfully and launch a polished, completed project on time.
Speed Under Control
Fast is fun, fast feels like you’re getting somewhere. Fast can be deadly. The trick to being fast is keeping the speed under control. Controlled speed means understanding the decisions you must make and the curves which will come in the road ahead. If you race too quickly you’ll lose control. When a developer works too quickly there are a few things sacrificed.
The quality of their code suffers. They quit making sure each line is properly indented and that they follow all proper code standards. Speed (or deadline panic) makes the developer do things they know are “not the best practices”.
Not only does their code quality suffer but their code documentation disappears. In the rush to complete “on time” (that’s a myth we’ll look at in a second) they will forego writing proper documentation of their code. “If someone looks at my code they should be able to read it and understand.” is a justification and not an acceptable response.
Lastly, speed under control means they have taken the time necessary to plan their route ahead of time. The good developer takes time before rushing ahead. The road is planned and the direction is clear. Then and only then does the good developer put the “pedal to the metal” and race towards completion.
Accuracy With Certainty
The idea of accurate code is simple. Accurate code is in many ways similar to what some would label “correct code” — the difference is subtle but distinct. Correct code means there is “wrong” code as well. Accurate code implies something less black and white. Accurate code is code which has been thought-out, deliberate and created with certainty of purpose. Accurate code may not always be “perfect” code in everyone else’s opinion. But accurate code can always be understood and reasonably followed.
Accuracy is of vital importance. Doing things without accuracy leads to missed goals. Certainty is the result of planning and purpose. The good developer understands the need for accuracy in their code and plans their code so they can complete the project with certainty. Accuracy is exhibited in a variety of areas including code which accomplishes its purpose clearly.
Accuracy also is demonstrated by code which is optimized for performance and future scalability. Accurate code takes time to plan for tomorrow. Not merely today. Accurate code is future-focused.
This feeling of certainty and the resulting accurate code is one of the ultimate achievements for a developer.
An Interesting Phenomena
There’s an interesting phenomena where speed and accuracy naturally balance and the developer’s life becomes much simpler. This strange and extremely rare occurrence happens when the deadline is removed from the equation. When the developer is not feeling the intense pressure of a looming deadline their code assumes a more natural balance between working quickly and accurately.
What does this mean? There are a couple of things which result from this realization. First, this means the developer should plan appropriately in estimating the time involved in completing a project. Of course this is an entirely separate discussion and too much to elaborate on in this post. It is sufficient to say that the art (yes, it’s an art) of properly estimating the time involved is critical to this tightrope stability. Second, this means the developer must be realistic in their skills and abilities.
The good developer does not believe every task in the project will be “a piece of cake” and take “no time at all”.
A realistic understanding of what is involved with each task will help the good developer to set the appropriate milestones and ultimate completion date.
Developer life may not be easy — but it is without a doubt exciting. Take time to plan, to be accurate and demonstrate speed under control. Do this and successfully navigate the developer’s balancing act.