4 ms·

Anything worth coding is worth coding at least twice. Do spend some time thinking about the problem before getting into it, but writing the code is often the qu

Anything worth coding is worth coding at least twice. Do spend some time thinking about the problem before getting into it, but writing the code is often the quickest way to understand which design questions you need to ask yourself. 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.

wilkystyle 2y ago
This is so hard to do well, especially when under all of the usual business pressures, but I 100% agree with you about the understanding gained from pushing quickly to hands-on implementation. Just anecdotally, I have historically done my absolute best work when it is my second attempt at implementing it. 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.
- appplication 2y ago
  As much as I love TDD, it really makes your last point so much more difficult. TDD feels like “do it nice or do it twice”, when you’re describing a more iterative approach. Of course they’re not strictly exclusive of each other, but maybe feel like slightly opposite paradigms in practice.
apantel 2y ago
I agree. The first time you try to make a new type of thing, it takes a lot of trial and error to understand the domain and get things working. But once you’ve done that and understood the domain, you can usually do much much better with a second greenfield attempt, completely from scratch.

wilkystyle 2y ago

This is so hard to do well, especially when under all of the usual business pressures, but I 100% agree with you about the understanding gained from pushing quickly to hands-on implementation. Just anecdotally, I have historically done my absolute best work when it is my second attempt at implementing it. 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.

appplication 2y ago
As much as I love TDD, it really makes your last point so much more difficult. TDD feels like “do it nice or do it twice”, when you’re describing a more iterative approach. Of course they’re not strictly exclusive of each other, but maybe feel like slightly opposite paradigms in practice.

apantel 2y ago

I agree. The first time you try to make a new type of thing, it takes a lot of trial and error to understand the domain and get things working. But once you’ve done that and understood the domain, you can usually do much much better with a second greenfield attempt, completely from scratch.