3 ms·
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 qui
by wilkystyle 3y 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 3y agoAs 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.