This resonates so much with me... i really dislike the way how much my work is depreciated after just months...

I really learned not to invest much time and finesse into those kinds of projects. When i was younger i was thinking "oh, someone may look at the code, keep it clean...". Nearly 10 Years later and dozens of projects later: Only 5% of my code ever got even a second glance or had to be changed...

It's a self-fulfilling prophecy. Technology management has given up on the idea that code can actually be read, so it's write-once. Reading Code is that ghetto where you put untalented people you want to fire, or young/new people you don't know what to do with yet. Otherwise, the idea that people can actually read code has been given up on. That, of course, generates a class of programmers who never improve and write terrible (illegible) code.

If your attitude is that reading code is a lost cause, you'll create a bunch of shitty, illegible code.

People forget that outside of the corporate world, there actually is code that people (a) enjoy reading, and (b) write with the intention of making it comprehensible.

Also, "doing it right" is an illusionary dream when your software interacts with the real world. In my opinion, it is not true that most code complexity comes from being lazy about code structure and simply not caring whether "models know about my views or not". This might happen sometimes but is usually easy to fix. It makes up a small percentage of code complexity.

There is an impedance mismatch between the way computers work and the way the real world works.

Software works in clear conditionals, numbers without any uncertainties, events that flow deterministically based on relatively simple rules.

The real world works in probabilities, half truths, imprecise numbers, special cases, partial information, irrational actors and deliberate rule breakers.

When you start writing a new piece of software, at first you tackle the most common cases of the real world. At this point it is possible to write clean code and well defined abstractions. However, eventually you are going to get users that will find that your software is too simplistic and doesn't take into account common sense exceptions, doesn't give them enough flexibility to deal with partial information and doesn't allow them to act according to unwritten exceptions to the rules. You have two choices. Either refuse to bend your software to the real world to keep code simplicity or start coding in the exceptions that your users desperately want.

Computers don't understand common sense so you have to translate all these exceptions into well defined rules and heuristics even though this does not reflect how things work in reality. Because computers don't think probabilistically, these heuristic tend to be numerous and complexe and difficult to deal with.

The main jobs of programmers in my opinion, is to manage this complexity so that their programs don't become too unpredictable when the thousands of exceptions interact together in unexpected ways. It's quite the balancing act but I think the best developers are those that don't back down and are able to face these types of problems. Sometimes this means refactoring some exceptions out of the system, or moving it somewhere where it doesn't cause unwanted interactions but sometimes it means leaving it in and managing it as best as you can so that your software can deal with the world as ambiguous and fuzzy as it is. A developer that ignores the fuzziness of the world in order to write clean code, is naïve and ineffective in my opinion.

This is the best explanation I have ever seen. I always say that that beautiful code doesn't stand up well against users, and this is why.

It doesn't mean that you should write crapy code, it just means that sometimes you have to in order to meet the exceptions in the wild.

Much like advertising is 90% ineffective, but no one can predict which 90%, it seems very hard to predict which code will live on forever. Deep enterprise back end stuff gets cancelled in 6 months due to reorg / whatever, some crazy CGI written as a shell script lives for decades.

I was lucky enough that the first project I worked on professionally actually shipped. One guy on the team had been a professional developer for 12 years and it was the first product he ever had ship. The web changed that somewhat, I guess, but non-web stuff is probably still like that.

On the other hand, that first product I worked on is still in service, over 15 years later.

LOL - "If you're cranking out another piece of shit marketing website, or even better, anything app or mobile related"

Honest question - can't one take pride in the fact that people are using his/her code and it is making their life better - saving money/ time etc, even if the code is not top class? Then the question is - which is more important? Make something good enough (and quickly enough) that people can start using, or keep working on something until it is "perfect"?

Obviously, this doesn't apply to life saving (or threatening) software like medical, defense, embedded systems etc.

No, not everything one does for a job is fulfilling or worth being proud of, just because someone asked for it. Often it is something useless, maybe not even what they really wanted, sometimes even annoying or harmful. Lots of us work on things which are basically useless that will go away soon. At the end of life, perhaps all you really accomplished was to stay alive in a certain sort of lifestyle.

Making it technically good is a way of making it interesting and something to be proud of. You could also make something that is yours. You could also make something that is really actually important. Without any of those outlets people will just hate their jobs and only live for their time off.

An mobile app can be scrapped in 2 years, but you might use it everyday for these 2 years. You'd want to be proud of something that will be integrated in the everyday life of someone for any time.