Programming Sucks

[[)roi(]]

Article: https://www.stilldrinking.org/programming-sucks

Here's an excerpt; full article is a veritable quagmire of the hellscape of programming.

All code is bad
Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It’s a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world.

This file is Good Code. It has sensible and consistent names for functions and variables. It’s concise. It doesn’t do anything obviously stupid. It has never had to live in the wild, or answer to a sales team. It does exactly one, mundane, specific thing, and it does it well. It was written by a single person, and never touched by another. It reads like poetry written by someone over thirty.

Every programmer starts out writing some perfect little snowflake like this. Then they’re told on Friday they need to have six hundred snowflakes written by Tuesday, so they cheat a bit here and there and maybe copy a few snowflakes and try to stick them together or they have to ask a coworker to work on one who melts it and then all the programmers’ snowflakes get dumped together in some inscrutable shape and somebody leans a Picasso on it because nobody wants to see the cat urine soaking into all your broken snowflakes melting in the light of day. Next week, everybody shovels more snow on it to keep the Picasso from falling over.

There’s a theory that you can cure this by following standards, except there are more “standards” than there are things computers can actually do, and these standards are all variously improved and maligned by the personal preferences of the people coding them, so no collection of code has ever made it into the real world without doing a few dozen identical things a few dozen not even remotely similar ways. The first few weeks of any job are just figuring out how a program works even if you’re familiar with every single language, framework, and standard that’s involved, because standards are unicorns.

 

[Hamster]

Sho, sounds like some developers have a tough life.

 

[cguy]

Sho, sounds like some developers have a tough life.

Agreed. I have certainly seen this in real life before, but only at companies where either crappy coders were being actively hired or good coders weren’t being paid enough to give a sh$t.

 

[[)roi(]]

This is of course is written with "a bit of tongue in the cheek" prose. e.g. cat piss melting snow flakes...

Not many environments are going to mirror this hellscape, however there are aspects of this to be found in every environment; nothing's ever perfect; and all codebases are built on compromises; and if you dial up the pressure; you could easily see cat piss melting snow flakes.

 

[ekske1]

Article: https://www.stilldrinking.org/programming-sucks

Here's an excerpt; full article is a veritable quagmire of the hellscape of programming.

Have some desert: https://deirdre.net/programming-sucks-why-i-quit/

Coding is just fine until you add humans to it. Especially those driving the project from their needs, not the needs of the project / client or simply an inept selling what there isn't coming back demanding a finished product as if standing in a fast food takeaway.

 

[CT_Biker]

I fear I get labeled as a person who makes other developers lives worse, especially going down the self taught route. Writing easy to read, working code is always going to worry me and something I am always going to strive for.

 

[ArtyLoop]

I fear I get labeled as a person who makes other developers lives worse, especially going down the self taught route. Writing easy to read, working code is always going to worry me and something I am always going to strive for.

The day I was allowed into a team, and to work without judgement, or criticism, that was a good day for me. I don't stress too much about code because like our manager says, code is for the now.. in 5 years we will be replacing it with something else or new we've learnt.

 

[cguy]

The day I was allowed into a team, and to work without judgement, or criticism, that was a good day for me. I don't stress too much about code because like our manager says, code is for the now.. in 5 years we will be replacing it with something else or new we've learnt.

It’s business specific of course, but for my last two jobs, unclear, buggy or inefficient code would cost us many millions of dollars. I’ve always had a direct link between code quality and revenue.

 

[-TachyonRSA]

The ending is my favourite.

So no, I’m not required to be able to lift objects weighing up to fifty pounds. I traded that for the opportunity to trim Satan’s pubic hair while he dines out of my open skull so a few bits of the internet will continue to work for a few more days.

 

[Compton_effect]

My favorite piece of work is still running. It was developed in a week, deployed remotely in 1. And still works perfectly - 7 years later - on a number of mines throughout the world. Its a perfect match of function and code, very simple in concept - powerful, and not requiring anything other than SQL and a exchange server. Every morning - it fires off a neat email to recipients in a email list. Unlike the original solution - that involved Crystal Reports, PDF converters, scheduling utilities and a nightmare of other work - this one is elegant, and works. It handles errors gracefully, is easy to configure (if you read the 2 page manual and know xml) and just works.

I won't talk about the rest of my 20 years in IT.

 

[[)roi(]]

It’s business specific of course, but for my last two jobs, unclear, buggy or inefficient code would cost us many millions of dollars. I’ve always had a direct link between code quality and revenue.

Yeah, same goes with us.
Poor code quality is just not worth the maintenance issues.

 

[aleksandar]

The day I was allowed into a team, and to work without judgement, or criticism, that was a good day for me. I don't stress too much about code because like our manager says, code is for the now.. in 5 years we will be replacing it with something else or new we've learnt.

Not sure about team dynamics but "criticism" or peer review is part of the job. It depends how it is done and how you view it. Usually you can learn a lot from it.

Regarding "coding for now" it is very shortsighted.
Redoing same business logic in different technology or language is waste of resources unless there are serious design limitations.

If code base is good and well designed it can be adapted to be relevant for many years.

Just checked release doc, first pilot site released on 01/03/1998 commits to version control started in 1995.
If latest revamp (db framework and port to linux) is successful it can live for another 10 years.

 

[cguy]

Probably 80% of the code I’ve written in my 20 or so year career is active today.

 

[[)roi(]]

The "how long a piece of code can live" philosophy is no longer what it used to be, because neither language or hardware has been a constant. The code I wrote in the 80s / early 90s certainly shouldn't have hung around until today for a few reasons:

• Languages aren't stagnant: in the 80s I was coding in PL/1, RPG, Clipper(dBase) and a bit of C and the majority of those languages are no longer in active use.
• Most of the interesting hardware from the 80s were huge electricity guzzling chunks of metal that filled large computing centres; and we wrote code on big chunky terminals that were hard wired to the mainframe / midrange machines, with keyboards that were far heavier than the average box PC today, and that hardware would easily be supplanted by a very low spec PC today; actually most basic smartphones have way more processing power.
• The turn of the last century and the Y2K debacle caused a lot of faux panic, and a lot of really old code simply was replaced.

Considering those factors alone I think it's highly doubtful any of that code still survives today. Even the C code would not have lived that long, having been written on the early Sun Solaris systems for geology / surveying purposes; all which would have been significantly enhanced by laser distance meters, GPS, etc. So no it very doubtful that stuff survived.

As for today, code simply doesn't have the longevity that it did in the 80s/90s for many reasons, but primary amongst that is the environment is certainly no where as stagnant as the century before; not only are languages constantly evolving to keep up with other languages, but so too the frameworks, dependencies, ... and of course the hardware.

Plus new paradigms have taken off, we for example completely switched (rewrote) all of our codebases over the last decade to the functional paradigm because not only is it more reliable than the previous OOP stuff we wrote; it by in large is far less code to maintain and way easier to reason about, hence easier to test, and bonus points substantially easier to exploit concurrency and parallelization.

So in short: any code that could stick around for a very long time probably wasn't that interesting to begin with.

 

[cguy]

The "how long a piece of code can live" philosophy is no longer what it used to be, because neither language or hardware has been a constant. The code I wrote in the 80s / early 90s certainly shouldn't have hung around until today for a few reasons:

• Languages aren't stagnant: in the 80s I was coding in PL/1, RPG, Clipper(dBase) and a bit of C and the majority of those languages are no longer in active use.
• Most of the interesting hardware from the 80s were huge electricity guzzling chunks of metal that filled large computing centres; and we wrote code on big chunky terminals that were hard wired to the mainframe / midrange machines, with keyboards that were far heavier than the average box PC today, and that hardware would easily be supplanted by a very low spec PC today; actually most basic smartphones have way more processing power.
• The turn of the last century and the Y2K debacle caused a lot of faux panic, and a lot of really old code simply was replaced.

Considering those factors alone I think it's highly doubtful any of that code still survives today. Even the C code would not have lived that long, having been written on the early Sun Solaris systems for geology / surveying purposes; all which would have been significantly enhanced by laser distance meters, GPS, etc. So no it very doubtful that stuff survived.

As for today, code simply doesn't have the longevity that it did in the 80s/90s for many reasons, but primary amongst that is the environment is certainly no where as stagnant as the century before; not only are languages constantly evolving to keep up with other languages, but so too the frameworks, dependencies, ... and of course the hardware.

Plus new paradigms have taken off, we for example completely switched (rewrote) all of our codebases over the last decade to the functional paradigm because not only is it more reliable than the previous OOP stuff we wrote; it by in large is far less code to maintain and way easier to reason about, hence easier to test, and bonus points substantially easier to exploit concurrency and parallelization.

So in short: any code that could stick around for a very long time probably wasn't that interesting to begin with.

Well written high performance algorithms, data structures, number crunching code, simulation code, financial simulations, driver/kernel, ML, etc. code written in C or C++ has typically lasted for decades. I agree that past languages becoming eclipsed, or radical hardware changes, code can quickly become obsolete, but in the C/C++ x86/ARM/Power world there has been a lot of consistency.

 

[[)roi(]]

Well written high performance algorithms, data structures, number crunching code, simulation code, financial simulations, driver/kernel, ML, etc. code written in C or C++ has typically lasted for decades. I agree that past languages becoming eclipsed, or radical hardware changes, code can quickly become obsolete, but in the C/C++ x86/ARM/Power world there has been a lot of consistency.

>= 20 years I doubt, but yeah some bits do live longer than others, most often the stuff behind the scenes, whereas stuff in the scenes e.g. UI is highly volatile.

 

[aleksandar]

>= 20 years I doubt, but yeah some bits do live longer than others, most often the stuff behind the scenes, whereas stuff in the scenes e.g. UI is highly volatile.

Maybe we are lucky but we constantly try to update code or add new language features to new code.
Luckily c++ is modernised as we go along and libraries are better (boost).

Our interface separation between database, middle tier and presentation layer is well defined and as we go we also update thin client with nicer controls and extra features so it looks up to date.

But as noted earlier we are probably oddity, code is bit boring to work on and stuff sometimes takes longer to be done.
How long will it last, who knows, it exceeded original expectations.

 

[[)roi(]]

Maybe we are lucky but we constantly try to update code or add new language features to new code.
Luckily c++ is modernised as we go along and libraries are better (boost).

Our interface separation between database, middle tier and presentation layer is well defined and as we go we also update thin client with nicer controls and extra features so it looks up to date.

But as noted earlier we are probably oddity, code is bit boring to work on and stuff sometimes takes longer to be done.
How long will it last, who knows, it exceeded original expectations.

I've lost count of the number of codebases I've written, reworked and replaced; and I'd hardly ever categorise a rewritten codebase as old code that's still actively used today. Also I go back a decade before your timeline, and even then there's nothing I can put a finger on that gracefully endured over that time; nothing really does. Theorems, algorithms, algebras, ... all endure the test of time... but code... nope not likely.

As for C++ and boost; yeah sure and I mentioned as much: languages have to keep evolving to survive; and who knows maybe in another decade I may even like C++ again ...doubtful but maybe.

Ps. I'd hardly call the new additions to C++ modernised; still it's not an easy job trying to streamline syntax with such an old language.

 

[ekske1]

"Programming Sucks" -

What perpetuates this is developers with a combination of the following, even all of them*:

1. Always right
2. Knows everything
3. Always has the answer
4. Superiority complex
5. Golden boy [also know as the jesus-dev]
6. Literally too smart
7. Lone ranger
8. It has to must be my way
9. Inept as to communication
10. Pacifism turns into deflection

*Yes they actually exist

 

[Magnum]

digitalWrite(D1, HIGH);