Once upon a time, back in High School, we had a substitute teacher for a couple of days, in the Computer Science Lab. While speaking to us about general concepts (to pretty much keep us busy), he casually explained:
Remember: your work as a Computer Scientist is 90% reasoning with pen and paper, and only the last 10% writing code.
I wish I remembered his name, because that idea (to me) was pure enlightenment: I’ve been using that very principle for my entire career, and it turned out to be THE best professional advice I ever received.
I often found fellow developers incapable of thinking even five minutes before writing a bunch of code. Don’t get me wrong: there is a time where you need to get your hands dirty, and transition between theory and practice; but you have to get there prepared, knowing what your are going to do (roughly, at least).
This is so important, and yet so underestimated!
Take a new house, for example: people don’t simply show up and start building it; there is a house plan, blueprints, Gantt charts, permissions, etc. way before even starting clearing the land.
I’m not saying you should have a perfect plan of actions, complete to the last detail, that’s never going to work (on big projects, at least): things are bound to warp in a project lifespan, and ignoring this will bring us back to the horrible spectacle of unmovable monoliths.
It’s more of a Marathon training: you have to plan your sessions, you need a broad, overall view of what your weekly schedule are going to be, your pace improvement targets, your ideal racing time… But then you adapt, week by week, to small injuries, a flu, a busy fortnight at the office… You might not get to the finish line in the time you were hoping for, but you won’t be far off (and sometimes even better than expected!).
To get results, consistency is key, adaptation is unavoidable.
It’s not about how many Lines of Code you can write in a day, it’s about being effective: measure twice, cut once. The whole idea behind Agile Development is not building fast something that barely works (or, if it does, it’s going to break in 2 months time); it’s about building in small, simple, incremental steps, so that you can make sure your product can quickly adapt to the changes in scope you inevitably will have to deal with.
Don’t ever misunderstand movement for progress: the former is pointless, the latter is essential.
So, next time you get an assigment, grab a pencil and open up a notebook (or a blank .txt file, if you really cannot stay away from your computer): think before your ink code 😉
