[connor]

I'd take this further and add that you should always be doing something wrong in the pursuit of more than just code. As a novice programmer you can spin your wheels learning every best practice without building much of anything. And HN often compounds this problem - look at every 'You're doing it wrong ...' post. Instead, I think you should make something crappy and make the rookie mistakes. Overtime, simply look to improve bit by bit.

I imagine someone will protest this idea, saying that there's already enough crappy software out there, that the world doesn't need any more technical debt. But this fails to realize that technical debt is a good thing in someways- it's a by-product of learning and crashing through boundaries.

In a way, technical debt is analogous to carbon emissions- yes, by itself it's a bad thing. But in the larger scope, carbon emissions are a by-product of industrialization, a process which has vastly improved our quality of life. Technical debt, like carbon emissions, is a sign of progress.

[bad_user]

I once worked on a project that pivoted the business logic so many times, with one hack after another, that technical debt went through the roof - at which point it became next to impossible to further evolve it. Because of legacy and tight coupling, simple features would take longer and longer to implement. And because the architecture was completely based on assumptions of low traffic that would grow organically (it was a web service), the shit really hit the fan when we started getting tens of thousands of requests per second, again because the architecture was so bad that it seemed as any optimization we did was worthless and actually made matters worse. The web service actually had to be stopped for a while, because as a startup we couldn't afford to rent a thousand frontend servers and even if we did, you're only moving the problem up the chain, which in our case was the data storage and again, because of tight coupling, it was unfeasible to move it to something that scales horizontally.

So the solution was to basically rebuild this web service from scratch. This decision also came with business logic simplifications - as we realized that certain features were unfeasible at that scale, so many features ended up being dropped based on technical considerations. Which IMHO was OK, because the best way to approach problem solving is to build less and sometimes we end up building features instead of solving the problem that we set out to solve in the first place.

I wish I could say that our initial approach allowed us to iterate fast. But it didn't. I was there from the start, I've built the prototypes, I did the pivots, I made all the wrong choices, I managed the team that came after and I could've made all the right choices without sacrificing fast iterations. All it takes is experience and tools that do "the right thing" in regards to your problem, without sacrificing productivity - being able to recognize the best tool for the job, being able to simplify problems, being able to tell the cost of something - now those are traits of good software developers.

The article does have a point though - you can learn all day about tools, best practices, algorithms, paradigms or whatnot, but in the end the goal isn't and shouldn't be to write "beautiful code", but rather to produce artifacts for solving problems that people have.

[einhverfr]

> I wish I could say that our initial approach allowed us to iterate fast. But it didn't. I was there from the start, I've built the prototypes, I did the pivots, I made all the wrong choices, I managed the team that came after and I could've made all the right choices without sacrificing fast iterations.

As long as you learned a lot from it.... We all make architectural errors. One can't learn without making mistakes though.