Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go ahead, write the “stupid” code

spikepuppet.io

Post reply on HN
Print view View original

121–130 of 157 posts

Re: Go ahead, write the “stupid” code

#121

Post by xnx »

withinboredom wrote: post #84
tacitusarc wrote: post #55

Earlier quoted context omitted.

I think this is mostly true, but also I’d highlight the necessity of having a mental model, and iterating. I think it is common for a programmer to just start programming without coming up with any model, and just try to solve the problem by adding code on top of code. There are also many programmers who go with their first “working” implementation, and never iterate. These days, I think the pendulum has swung too fa…

My philosophy: 1. Get it working. 2. Get it working well. 3. Get it working fast. This puts the "just get it working" as the first priority. Don't care about quality, just make it. Then, and only once you have something working, do you care about quality first. This is about getting the code into something reasonable that would pass a review (e.g., architectually sound). Finally, do an optimization pass. This is the…

This should be carved in stone on every campus computer science building.

https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

Re: Go ahead, write the “stupid” code

#122

Post by cardanome »

braebo wrote: post #109
balamatom wrote: post #71

Earlier quoted context omitted.

Yeah, no. What you're promoting is a deeply narcissistic worldview, and I hope either the cure or the consequences reach you soon. Though maybe those are going to present as the same thing.

They’re not entirely wrong, and your comment is seemingly unhinged and unprovoked… but there’s a lot of literature on stuff like mindfulness, CBT, and the impact thoughts can have on one’s emotions, especially happiness.

CBT and mindfulness can help with SOME problems. It is great when it does but it also can work less well or even harmful for other problems. Especially people that are prone to rumination don't benefit much from it, they need the opposite of mindfulness.

The unhinged part was to imply that people can just choose to be happy under any circumstance which is obviously magical thinking.

Re: Go ahead, write the “stupid” code

#123

Post by captainkrtek »

withinboredom wrote: post #84
tacitusarc wrote: post #55

Earlier quoted context omitted.

I think this is mostly true, but also I’d highlight the necessity of having a mental model, and iterating. I think it is common for a programmer to just start programming without coming up with any model, and just try to solve the problem by adding code on top of code. There are also many programmers who go with their first “working” implementation, and never iterate. These days, I think the pendulum has swung too fa…

My philosophy: 1. Get it working. 2. Get it working well. 3. Get it working fast. This puts the "just get it working" as the first priority. Don't care about quality, just make it. Then, and only once you have something working, do you care about quality first. This is about getting the code into something reasonable that would pass a review (e.g., architectually sound). Finally, do an optimization pass. This is the…

This is fantastic, but how do you communicate this within your organization to peers, and not allow the pace of the organization to interfere? For example, can see many teams stopping after step 1.

Re: Go ahead, write the “stupid” code

#124

Post by danielbln »

jlarocco wrote: post #120
amatecha wrote: post #50

For sure. I'd argue to write the "stupid" code to get started, get that momentum going. The sooner you are writing code, the sooner you are making your concept real, and finding the flaws in your mental model for what you're solving. I used to try to think ahead, plan ahead and "architect", then I realized simply "getting something on paper" corrects many of the assumptions I had in my head. A colleague pushed me to…

This is why I hate software engineering as a profession. You're going to write the "stupid code" to get things out the door, get promoted and move on to another job, and then some future engineer has to come along and fix the mess you made. But management and the rest of the org won't understand why those future engineers are having such a hard time, why there's so much tech debt, and why any substantial improvements…

Sure, that sucks. You know what else sucks? The engineer who does nothing but foundation building and then is surprised that reality doesn't align with their meticulously laid out assumptions.

Re: Go ahead, write the “stupid” code

#125

Post by palata »

amatecha wrote: post #50

For sure. I'd argue to write the "stupid" code to get started, get that momentum going. The sooner you are writing code, the sooner you are making your concept real, and finding the flaws in your mental model for what you're solving. I used to try to think ahead, plan ahead and "architect", then I realized simply "getting something on paper" corrects many of the assumptions I had in my head. A colleague pushed me to…

> I used to try to think ahead, plan ahead and "architect"

Depends on what you do. If you build a network protocol, you'd better architect it carefully before you start building upon it (and maybe others do, too).

The question is: "if I get this wrong, how much impact does it have?". Getting the API of a core service wrong will have a lot of impact, while writing a small mobile app won't affect anything other than itself.

But the thing is, if you think about that before you start iterating on your small app, then you've already taken an architectural decision :-).

Re: Go ahead, write the “stupid” code

#127

Post by dvcoolarun »

I believe "stupid code" is useful for sticking concepts or quick prototypes together.

But for strategic decisions, having a well-researched document (a PRD or similar) helps as a starting point for iteration, and the approach you take will be influenced by your team's culture.

Re: Go ahead, write the “stupid” code

#128

Post by jasonlotito »

amatecha wrote: post #50

For sure. I'd argue to write the "stupid" code to get started, get that momentum going. The sooner you are writing code, the sooner you are making your concept real, and finding the flaws in your mental model for what you're solving. I used to try to think ahead, plan ahead and "architect", then I realized simply "getting something on paper" corrects many of the assumptions I had in my head. A colleague pushed me to…

This is where experience matters. The more experience you have, more often than not, the less stupid the code is. Not because you aren't testing your concepts as fast, but that your tooling is improved.

Basicaly, do you have a good foundation to build from. With more experience, you can build a better foundation.

Re: Go ahead, write the “stupid” code

#129

Post by AlotOfReading »

danielbln wrote: post #124
jlarocco wrote: post #120

Earlier quoted context omitted.

This is why I hate software engineering as a profession. You're going to write the "stupid code" to get things out the door, get promoted and move on to another job, and then some future engineer has to come along and fix the mess you made. But management and the rest of the org won't understand why those future engineers are having such a hard time, why there's so much tech debt, and why any substantial improvements…

Sure, that sucks. You know what else sucks? The engineer who does nothing but foundation building and then is surprised that reality doesn't align with their meticulously laid out assumptions.

An engineer that does nothing but foundations can still be a damn good geotechnical engineer.

A foundation that isn't useful to build atop is just a shitty foundation. Everyone is taking it for granted that building a good foundation is impossible if you haven't built a shitty foundation for the same building first, but that's not the only way to do things.

Re: Go ahead, write the “stupid” code

#130

Post by godelski »

d-us-vb wrote: post #114
godelski wrote: post #40

Earlier quoted context omitted.

While I generally agree with the conclusion of that, I think it might be a bit too naive. The quantity group has a trivial way to "hack" the metric. I can just sit there snapping photos of everything. I could just set up a camera to automatically snap photos all day and night. To be honest, if I'm not doing this at a stationary wall there's probably a good chance I get a good photo since even a tiny probability can b…

This is an interesting take. It maps decently to the "first to market" mentality of a lot of programming these days. For sure, we'd get better programmers if they were judged by the quantity of code they produced in their personal projects, but if "quantity learners" are simply forced to churn out bad code without any reflection or the time to experiment, then I would agree that it seems pretty naive to think they'll…

Also think about software recently. Is it actually better? IME I face more bugs than ever. Trivial ones to that are clearly being deprioritized but relatively easily solvable.[0]

Do an experiment for me. Write down every bug you face today. Even small. I think you'll be surprised at how many there are and even more at how many are likely simple to solve.

I know it's not just me as so many around me are getting increasingly frustrated with their devices. It's not the big things, it's a thousand paper cuts. But if you just you look at a paper cut in isolation, it isn't meaningful. That's the problem and why they get ignored. But they get created because we care more about speed than direction. I'd argue that's a good way to end up over a cliff

[0] https://news.ycombinator.com/item?id=45363210

Post reply on HN