3 ms·
Ask HN: When you are programming, do you build the hardest bits first?
I always build the hardest bits first because I can't stand getting to the end of my todo list and finding a small number of hard and time consuming things to do. I like to get to the end of the project and find things getting easier.
What do you do?
- greenyoda 11y agoI try to implement an end-to-end solution (going through all the layers of the stack) for one simple case first. That gives me an overview of how the different pieces of the code will fit together, and allows me to keep the "big picture" in mind as I'm filling in the remaining pieces. In my experience, this approach helps me to find potential flaws in the design earlier. For more on this approach, see: http://www.c2.com/cgi/wiki?SpikeSolution http://www.c2.com/cgi/wiki?SpikeSolution
- sshykes 11y agoCompletely agree with you greenyoda. I'd also like to add that given a choice I've learned to do the portions believed to be "easy" first, that way you'll find out sooner if they actually turn out to be harder than anticipated. This helps reduce the risk of ending up screwed as well as the severity of screwage when the unexpected arises; If you save the "easy" parts until the end, your project will be even further behind schedule.
- hoodoof 11y agoI tend to have a moderate degree of confidence that my initial architecture/design will work, assuming all my underlying technology assumptions are correct. My software architecture skills are definitely better than my coding skills - the coding is something of a plod. I try to minimise coding effort by designing out coding where I can, mainly cause it takes me so long to write the code. So step one is to prove all unknowns around the technology assumptions. One these are proven out then I build the hard bits then the easy bits, in the knowledge that it will all hold together. It annoys me to have a working system implemented "thinly" because I have to go back and context switch into the mindset of each component and then deal with the massive technical debt of properly implementing each component. Don't get me wrong - I really like the idea of the SpikeSolution - makes a great deal of sense.