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: Analyze and define the problem Think/discuss/process/whatever to come up with a plan Sit down and write the code ??? 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? 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. VERY little: 2–3 lines of code or a tiny function at a time. 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 , 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. (a fallacy in itself, since [a] we write software which never existed before and [b] we keep learning new stuff all the time) 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 , because it means my original approach was flawed, which I identified and fixed! awesome This is a Good Thing™ This resonates with a recent about Test Driven Development (TDD). One of its points is that TDD’s greatest strength is the code resulting from the when writing good tests — and . 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). post process of refining a design and refactoring the implementation not the tests themselves 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 is a Front-end engineer in Israel. Hire Nick from their page._about.me Nick Ribal on about.me
