Think Twice, Code Once
brunokiafuka.substack.com
brunokiafuka.substack.com
Just don't be afraid to throw away your code. It helps to be quick at typing. It's common to hear "typing speed doesn't matter, I spend much more time thinking than typing", but I find that colleagues who are slow typers are more eager to push on with the first (flawed) attempt.
As always, there is definitely a balance, and I definitely do not want to downplay the importance of critical thinking. You would not do well climbing Mt. Everest by simply starting the climb with the intent of figuring it out and adapting along the way, but you also won't be any good at basketball if you spend all your time reading books and watching videos without stepping onto the court and trying it out.
In my experience, there are two key things that determine whether or not I am successful at this:
1. To develop the ability to rapidly prototype something that is representative of the thing I ultimately want to build, without falling into the trap of all of the optimizations and rigor applicable to the final product I will ultimately deliver.
2. The ability to commit to throwing something away that I have invested time, effort, and learning labor in. At every step of the way, I find myself attached to the thing I'm building, and thus wanting to keep it around and apply all of the optimizations that violate point 1 above.
This has been the biggest struggle of my career. No one ever wants to take the easy route. Everyone thinks they are smarter than everyone else. Everyone thinks their little API is going to be globally popular and needs triple redundant failover zones, 64TB of memory, Kubernetes, scale, scale, scale.
Now, please excuse me while I practice leetcode for my first job out of grad school where if I cannot regurgitate a complex algorithm (which is available in a well maintained library that I should never try to reproduce) I’m an unemployable dumbass.
Been applying to both backend and frontend positions, and to me the market looks like that "fronthand backhand" Key & Peele sketch (just mentally replace with "frontend backend").
I'm only surviving so far because someone I know offered me freelance work, but it probably won't last too long, and nobody else I know is hiring for a remote (or nearby) position.
Maybe, if I lived in either of the 2 cities where 90% of the on-site developer job positions are located, maybe, things would be a bit easier.
I think one issue here is that it is very hard to predict domain-specific problems until you encounter them. If you're working in a domain you are already experienced in, a top-down approach will likely work fine. However, if you are attempting something new, you're bound to run into unforeseeable implementation problems. This is why I believe improving your skills related to iteration speed is just as important as planning.
People often think that the top-down approach is just better than the bottom-up approach, but I think there are lots of cases where the bottom-up approach is just as important as the top-down approach. See the "Top Down versus Bottum Up" section from The Art of UNIX Programming book. [1]
[1]: https://www.arp242.net/the-art-of-unix-programming/#id289955...
The article then launches into recommendations about requirements gathering and writing down your thoughts (functional specs anyone?) which kind-of sounds a little bit like the waterfall method to me. I believe the waterfall method has a bad reputation for overengineered and overcomplicated solutions. We have come full circle, again!
No matter the methodology there seems to be this behavior in the industry that as soon as some code does the job, regardless of how terrible it is, it must not be touched again and we must move on. Whether it was over-engineered because of bloated requirements gathering or because it was hacked into some sprint period the end result is the same.
My recommendation is this: Don't discourage people from refactoring code that already works. Good code will survive refactoring or even rewrites.
That's not really waterfall, it's just normal analysis and design.
The trick is to identify when you have enough domain knowledge that the analysis and design time is valuable/optimal, or to identify that you don't have enough domain knowledge and need to iterate to gain the knowledge.
Conversely, Bob Dylan has, for many years, been telling us, "don't think twice, it's alright."
The writing process itself is an important way of thinking things out, especially when there are too many details and possible confounding factors.
This was a long time ago when computer time was expensive. Now is: don't think, code it, ship it, see if someone complains. (Google, Microsoft and others).