

Ask HN: When you are programming, do you build the hardest bits first? - hoodoof

I always build the hardest bits first because I can&#x27;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.<p>What do you do?
======
greenyoda
I 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)

~~~
hoodoof
I 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.

