3 ms·

If I'm optimizing for my brain, my strengths, and my programming style, bottom up is better. With a particular focus on nailing down the hardest or murkiest par

If I'm optimizing for my brain, my strengths, and my programming style, bottom up is better. With a particular focus on nailing down the hardest or murkiest part, then the next hardest/murkiest, and so on. This phase can be ugly code if that helps ... the point is to uncover unknowns and let points with the fewest degrees of freedom become the first stakes in the ground. When there are no particularly hard/murky parts left, it's top-down from there, and that let's you choose the approach for various portions of the solution (such as, this part will be pure functions, this part will be based around an arena allocation, etc.). Even though I mentioned both bottom-up and top-down, the 10,000 foot summary is bottom-up, because it starts there and the most time is spent in that mode. Whenever I get away from that and go top down too early, I'm likely to run into some area that either gets reworked, or that I compromise on and _wish_ I could justify the time to rework it. (And also with the caveat that some things are simple enough you could do them any way you want, and those are good candidates for top-down, which also seems more comfortable for more junior devs). UPDATE: However, I completely agree with another commentor -- start with the UI first! I don't think that contradicts bottom-up ... it's about fleshing out both the requirements and the _potential_ requirements.

Sakos 4y ago
I have to do the same thing. If I spend too much time on everything else, I procrastinate on the hard stuff until I've wasted too much time. If I start with the hard stuff, I'm a lot more motivated and productive. That doesn't mean I'm not often paying a lot of attention to the overall design of the code and where/how things are being called. I'll often step up and down the layers to refractor and improve the code surrounding what I'm working on, since that code often has a big effect on how I can implement my changes. However, I'm also in a lucky position where I'm not responsible for the UI or any customer facing stuff. My users are internal services that interface with my APIs, which rarely need to be changed.

Sakos 4y ago

I have to do the same thing. If I spend too much time on everything else, I procrastinate on the hard stuff until I've wasted too much time. If I start with the hard stuff, I'm a lot more motivated and productive. That doesn't mean I'm not often paying a lot of attention to the overall design of the code and where/how things are being called. I'll often step up and down the layers to refractor and improve the code surrounding what I'm working on, since that code often has a big effect on how I can implement my changes. However, I'm also in a lucky position where I'm not responsible for the UI or any customer facing stuff. My users are internal services that interface with my APIs, which rarely need to be changed.