How I write code

I want to share how I author code. Not because I’m particularly good or special or anything lame like that. I just wish someone had shared this sort of experience with me back in the day. A sort of sobering up from an illusion.

You see, I always imagined that a professional programmer works like so:

1. Analyze and define the problem
2. Think/discuss/process/whatever to come up with a plan
3. Sit down and write the code
4. ???
5. PROFIT!!!

But the way I always experienced step #3 felt inadequate. Instead of starting, advancing and finishing, I progress slowly and tediously. Write a bit, change a bit. Write some more, change a lot. Rewrite some, then move things around, then rename then review then change some more. Sometimes discovering edge cases would force me to change a lot of what’s written and working. A picture is worth a thousand words:

Applies to many things, including writing code

This bothered me for ages. But time and experience — my own and overseeing others’ work have taught me that I’m actually doing the right thing. Let’s break it down:

Progressing in baby steps is OK

I write very little code and then run it. How little? VERY little: 2–3 lines of code or a tiny function at a time. It seems absurd, given the fact I’ve been doing it for several years already. I wish it would have worked differently. But each time I try writing longer code chunks, I end up less productive and more frustrated.

Moreover, I clearly remember a landmark event from a few years ago. I had written (without any prior intent) a mere page of code — something like 10 small functions/chunks and ran it. AND IT JUST WORKED!

I couldn’t believe it

I was awestruck. And all it took was 20 years of working with computers, 7 of which programming on a daily basis!

So if you find yourself failing to write large working blocks of code, try smaller ones. This, by the way, aligns very well with software development best practices. Things like separation of concerns and writing short functions which do one thing.

The notion that authoring software is a simple line from A to B is false

My disposition was: assuming you know what you are doing (a fallacy in itself, since [a] we write software which never existed before and [b] we keep learning new stuff all the time), let’s observe other professionals. A carpenter crafts without restarting seven times. Also without modifying his/her entire design several times. Even more so, a dentist can’t do that at all, since the work is destructive.

So how is software development different? I learned the answer from Uncle Bob (if you know the exact quote, please share!):

“The primary value of software is its ability to change”

— Uncle Bob Martin

This amazing property is as valid for software authoring, as it is for later lifecycle stages. When programming, I change, adapt and rewrite what I had written moments ago. Sometimes it happens so much that I am forced to rethink my entire approach or the problem domain. This process results in major modifications of what’s already written and working. That’s awesome, because it means my original approach was flawed, which I identified and fixed!

This is a Good Thing™

This resonates with a recent post about Test Driven Development (TDD). One of its points is that TDD’s greatest strength is the code resulting from the process of refining a design and refactoring the implementation when writing good tests — and not the tests themselves. In other words, in proper TDD you refactor as you go — by necessity. The flip side is that developers who don’t refactor during TDD create the exact opposite: tests for bad code, perpetuating a poor design (or API or implementation).

So if you find yourself rewriting the same piece of code over and over again — it’s a good thing. Time to rethink the solution you came up with or even the problem definition. If the the problem is the right one to solve and the solution is too — you’ll write the right code for the job. If it isn’t, you’ll come up with a better alternative.

So what’s my message here?

If your development style feels wrong, inadequate, slow or takes multiple attempts to get to where you aim — you’re probably doing it right.

Now, I realize this may not match your experience. Like everything else in life, there’s various styles and approaches to programming. I’m only sharing what works for me, the process I went through and how it feels today. This too is subject to change :)

Each part of this post was rewritten waaaaay too many times (including this very sentence). I hope time and practice will improve my ability to clearly express thoughts.

Nick Ribal on about.me_Nick is a Front-end engineer in Israel. Hire Nick from their page._about.me