The other day I was trying to add some functionality to a project I was writing some code for. It was a project with many people on it, and it was well under way when I got there. I was told that some of what I was going to be writing had been figured out already by another teammate, so I went to see what I could learn from their work.
Turns out, a lot.
You see, it ended up taking me about a day to ship the feature. But that day of work was built off of the weeks of work that my coworker had spent shaking out all the quirks, holes in documentation, and edge cases already solved when they worked on their part of the project.
They made my job look easy. It was tempting in hindsight to say, “Of course this is the way to do it,” after seeing their code. It wasn’t though. If they hadn’t laid the groundwork before me I’d have spent the same amount of time (or more) than they did just to get to where things were at when I started.
Solving the problem
There is value in solving the problem. Even if it’s in a piece of code or a project that never quite sees the light of day, or if you’re tempted to look back on as primitive or naive, it’s not. It’s only naive in the hindsight of the work you put in to make it.
Iterating on battle-hardened code is way easier. Don’t be discouraged if your code was first but can be improved. You can only focus on one or the other: solving the problem or iterating on a solution. This is why premature optimization is discouraged, the optimization can come later. Even if it’s by someone else, they are still optimizing your solved code.
Monads and semicolons
This is one of the reasons I simply can’t follow along when people start arguing about technicalities before things are solved. All their arguments are predicated off of the code working in the first place, that part can’t be replaced. Being opinionated about code needs to take this into account.
Not done, but complete
Software is never done, but it can be not complete. This is a subtle but important distinction. There is no ‘done’ break point, but there is one for ‘this works now.’ I invite you to give yourself the credit for the latter.
I’m a reactive programmer: I wait for bugs then react to them
--Gar
Get out there and write
So get out there, write your code without fear. Even if it never quite takes off, and someone else comes along and shows you how it could be better. They can’t improve on something that never existed in the first place.