''

Why does engineering take time?

designing pieces of a puzzle is not easy. we have to determine size, role, complexity, etc. a simpler piece is easier to work with, is more compatible with the other pieces. a complex piece fits only fits into a complex puzzle. the design of the puzzle changes completely as soon as the stakeholder needs the 2nd feature. the readablity of the puzzle impacts that 2 week, 3 month, and 12 month revisit of that code. that WHO THE HELL WROTE THIS PIECE OF JUNK moment. Works great for the original use-case. Yet, is completely terrible to work with for the new kinds of customers you have, for the new business stakeholder needs. Engineers can build that thing overnight, and you’ll be stoked about it the next day. Then you want one more feature, and they say, oh, ha, about that, i need two weeks. I need to rebuild the original feature in a way that accomodates the new one. Slow and steady momentum. Build slowly, take careful steps. Build simple, reusable pieces that are compatible with teh system. Functions need only one task. Features and systems should generally only have one use-case or stakeholder to satisfy. Otherwise you’ll pull the code in different directions. Changes to one use-case will have amplified affects on multiple others. [the above is for another blog post]

I think the best way to learn anything is to jump into the deep end and flail around until you learn how to swim. When you can tread water, that’s when we’ll talk about stroke and form and what not. [again, probably another post]

it’s much deeper than that. getting the website to “go” is the easy part. powerful, functional things come out of hackathons. We could stay up all night building out the new dashboard, complete with a ‘working’ login screen and Sure there’s value in those working prototypes. but we still call them prototypes.