Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 require major rework and refactoring.

So the people writing the stupid code get promoted and look good, but the people who have to deal with the mess end up looking bad.



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.


The analogy is strained. Software is closer to a food recipe than a building. Trying to make a 3-layer strawberry banana cake with pineapple frosting? You are going to have to bake something and taste it to see if your recipe is any good. Then make some adjustments and bake some more.


Is the argument here that a skilled chef has no better way to make good food than unguided trial and error? That's obviously not true, as the abundance of "random ingredient" cooking challenges will attest.


I mean, you can write the stupid code to get something working, and not submit the code until you've iterated on it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: