I do a lot of dev work with non-profits and such. About a year ago I was working on an extremely difficult project as a volunteer where I was insistent that a specific part was vitally important to getting the project to move forward (generalizing tables extraction from scanned OCR docs) and I was spending a lot of time on it. One of the devs I worked with, with 40+ years of experience, basically told me this exact thing. He argued that what I as working on was a waste of time and that I shouldn't work on "code golf" problems, because of the likelihood of failure and that ultimately I should consider the human side of the problem. He said it was best to work on other things instead.

Fast forward a month later, I managed to actually do it, and it worked almost flawlessly, across about 100k scanned PDFs. Multiple long-term projects spawned off from the extracted information, including some projects from the dev who told me to stop.

My point being -- sometimes it seems like that line is used as an excuse to not tackle hard problems if they seem likely to fail. I agree with the line, and it's the exact reason I worked on it as hard as I did, but the dev failed to consider that I understood the social part of the problem, on experienced principle.

> generalizing tables extraction from scanned OCR docs

I would actually categorize this as a human problem. As a society, we scan documents all the time. Data entry is a massive time sink usually involving lots of corrections.

True code golf would be like switching languages/frameworks for no discernable reason or trying to hit an arbitrary code coverage metric because you're unsatisfied with the current one.

It's a permanent balance. I have to "manage" (but I still am a main contributor) a small team in a big investment bank with angry busy trader-users, irrational "global" management in other continent thinking we're all dumbasses in Asia, and people on loaned rotation.

So, like your colleague, I try to strategize delivery. I would never tell a guy not to work on a genius idea that could change the entire paradigm, in fact I let 3 of my guys do just that for the last 3 months, together, sometimes alone. But they either not deliver, or very slowly, or sketchily (not working as well as thought).

So what I do a lot is a compromise. I force them, despite their complaint I don't care enough about the big picture of their non-delivering work, to take smaller issues every week. 1 or 2, give a candy to the user, and do your stuff then.

It worked incredibly well: while they've delivered absolutely nothing of value in their own initiatives yet (but I still think they can, it's just very long term), the users are delighted by a constant stream of little innovations and we've been recently identified as one of the most productive team.

Meanwhile, the team next to us, algo programmers in C++, can take 2 months to enhance an error message. Because they're all revolutionizing the system and have no time for basic human needs. They don't know yet, but they're gone soon. The budget people found there's a new model of delivery that could work, I wonder which one ;)

Good on you for trusting your team and allowing for such experimentation! We need more people in management with this attitude.

As per the blog's opening statement: context is key.

The industry (and really, it's not specific to the industry) is rife with people who take pearls of wisdom out of their context and apply them without the context to serve their own ends.

minuscule anecdote: my most cherished lines of code were an 8 lines vba excel macro to count duplicates for a non tech colleague.

Turned her day from hell to cool (she had to filter duplicates by hand and quadratic formulas over 2000+ lines spreadsheet.

That's what computers are for.

I once spent two hours thinking about how to recursively assemble a tree structure from the database in a way that the JS presentation library wanted the data, then finally I wrote 2 lines of code.

Definitely my most cherished code.

Hah, this is something I've done when trying getting data from a government agency that can't run or write code themselves. It's usually in some awkward meta-adversarial context and they tend to be fearful of macros and such, but it's possible to get around that fear by writing everything in excel functions.

Sometimes those damn excel sheets take hours and hours to make even though it would otherwise take me less than a minute to write in SQL or unix. But it pays off every time and pushes a clear message that they can do better.

> sometimes

Any rule of wisdom, followed blindly, leads to disaster.

Don't substitute rules for good judgement.

Or sometimes you have an approach that is high risk/reward. That's totally fine to take as long as your aware of the risk and have mitigations or offramps at the right points if you find the path isn't viable.

If we take your first statement to be a "rule of wisdom" then it is either false, or all roads lead to disaster anyway.

If you leave off the rest of my post, you're likely to misunderstand it :-)

If you're volunteering, why shouldn't you work on projects that you find interesting? I don't understand the point of view of the older dev.

I've found that volunteer work is _harder_ in terms of getting the human aspect right.

New volunteers sometimes expect the red-carpet treatment as someone volunteering their (pretty expensive presumably!) time and as someone accomplished in their field. Volunteers usually get the opposite treatment since it turns out the other volunteers tend to come from a similar perspective and someone doing the hard human work is often contributing a lot more to the project than an otherwise excellent engineer.

You can of course choose your volunteer activities to be interesting to you. Open source is one such very fun activity but lo-and-behold in projects I've been involved with the human aspect is often very important and requires a similar amount of hard work. This is often truer for bigger projects/organizations than small ones.

Even if you're volunteering you still have to work towards agreed upon objectives. You wouldn't show up on a Habitat for Humanity build site an start modifying the blueprints and working on whatever you found interesting because you are volunteering and are entitled to only work on interesting projects.

Presumably you want to maximize the positive impact your volunteering has on others.

But having people working on potentially extremely useful moonshots that they are interested in for free is a huge win. I think it's really just a case of bad advice, and not all developers with 40+ years of experience are correct. In my opinion, it's better to have a motivated volunteer engaged and working on something with unknown impact that she is interested in, rather than get her to work on boring things with less impact.

of course not, humans are most often wrong about everything. Someone with experience is just that. Our perspective changes.

I started coding at 12 because everyone said it was much to hard for me. Now im old and motivate people by doing the same. At the same time its good to be reminded by others what happens if you drop one thing in favor of the other.

Predicting the future is hard. You were both right. You only have the outcome to judge the decision, not the full probability distribution.

This is so important - it's so hard to gauge what another person's mental model of a scenario is compared to yours.

As in - perhaps OP and 40+ year person had the same, accurate mental model of the probability distribution of success, but OP and 40+ had different attitudes towards risk/reward.

Or perhaps the OP happened to have a much more realistic picture of the probability of success, and 40+ was unnecessarily pessimistic.

So hard to evaluate these things, and to internalise the fact that other people don't have the information you have all the time.

Yep! If I wasn't successful, he would have been right and I can't really blame him too much for thinking it his way. The problem was particularly tricky because it combined bunches of distinctly esoteric domains (OCR, text/vector maps, image processing, fuzzy string matching).. recursively. There were no boundary lines and inconsistently sized black redaction boxes. If I hadn't worked on problems in each domain in separate projects, I doubt I would've been able to do it and he had no way of knowing my experience.

Make an API out of that. There is huge demand for it.

I needed to do this, so happy someone else made it!

A nice FOSS library for it was on HN recently, sharing is caring I guess

https://news.ycombinator.com/item?id=28680136

https://extract-table.com/

https://github.com/vegarsti/extract-table

I'm pretty sure AWS Textract does that already.

https://aws.amazon.com/textract/

I believe such an API already exists: https://pdftables.com/ (no affiliation).

Went to a presentation at a Golang meetup in Amsterdam by the guys behind this company. Seemed to know their stuff. But I have no real world experience using it.

I had a look - from their FAQ [0]:

However, some PDFs are scanned documents, or only contain images. PDFTables doesn't perform Optical Character Recognition (OCR) to turn these images into text.

To process these kinds of documents, you will need to either enable OCR in your scanning software, or run the PDF through specialist OCR software before using PDFTables.

[0] https://pdftables.com/faq

I’m in need of that right now! Would pay for it, especially if the proceeds benefitted that non-profit!

Looks this does it https://www.extracttable.com/

30+ years here, so I'm just a youngster compared to you, but yes, that seems to get lost.

My first mentor in the 80's was a jolly drunken programmer genius who enjoyed getting me to laugh at how bad my code was.

His biggest lesson was that other people need to read and use my code, not just me. It isn't enough to just hack a solution -- "Anyone CAN write code, but not everyone SHOULD write code" was his favorite quote -- but code needs "style" and "heart".

He even had a t-shirt made for me after my internship ended that had those two words and a bunch of my worst code examples printed on it. I still have it: just a bunch of MASM code. I'll Never forgot that guy.

I think this applies to not just software, but engineering in general. See, science is mostly about observing the natural phenomena. On the other hand, there are jobs that are mostly about taking care of people's needs. Engineering sits in the middle. It's a mediator. We have to understand the circumstance of both sides - nature (this could be something like hardware capacity in our case) AND people. Just taking care of one side makes you a bad engineer. You need to be technical and sympathetic at the same time.

It applies to every job not just engineering. I thought this was considered obvious.

To clarify, you're saying that you vire that that being technical and observing natural/physical phenomena are important parts of selling clothing at retail, being a novelist and working as a receptionist?

I think those are important jobs, and completely disagree with you. I'm trying to understand if those are jobs you weren't considering, or if we view each the responsibilities of those jobs very differently.

No. I'm saying that retail, much like being a novelist or a receptionist or a software programmer or indeed any job is, as the OP puts it, a "social service".

That being one of the defining charactetistics of a job.

You're saying you're agreeing with OP, but your statements contradict.

OP calls out 3 categories of jobs. Mainly natural/technical, mainly social, and those which sit in the middle and require both. Finally OP says engineering sits in the middle and requires both.

You said it's not just engineering (that requires both), but all jobs.

Both I and OP disagree with that statement.

So, which jobs are not providing a "social service"?

Car mechanics? Sure, in the end it's "social" in that another human being benefits from it, but the actual "social" aspects of the actual work are handled by someone other than the mechanic.

For many people it definitely is not - some folks get into software engineering because they have the mistaken (albeit not as mistaken as if they were going into another career like medicine!) belief they can avoid people and just deal with machines.

Approching the same experience level and fully agree.

A piece of coding art that doesn't fulfill customer needs, or requires understading of language standard minutia for fellow devs to do maintainance updates is worthless.

Yes, or in some cases even worse than useless - an active problem that requires expensive specialization to not make things an even bigger mess

The biggest mistake people in our industry make is thinking they are somehow exempt from the rules of society and business just because they can use a computer better than most people.

Heads down genius coder everyone steps around ends up fired or stuck in mid level forever, in reality. Guy who makes friends with the Customer Service department and Sales team with mediocre fixes get promoted, and in reality achieves more with his career.

Software is useless without users.

What's the quote? Knowledge can be taught. Wisdom can't be taught or told... it can only be learned through experience?

Edit: Ah, found it.

"Wisdom cannot be imparted. Wisdom that a wise man attempts to impart always sounds like foolishness to someone else ... Knowledge can be communicated, but not wisdom. One can find it, live it, do wonders through it, but one cannot communicate and teach it." - Siddhartha

"Wisdom can't be taught or told... it can only be learned through experience"

I recently had the thought, that good education guides you to certain experiences to really learn the subject and not memorize some definitions.

Problem is that people learn the wrong things from their experiences, not that they lack the experiences.

The way I was told it: "Knowledge is knowing it's a one-way street. Wisdom is learning to look both ways anyway."

Software is whatever you want it to be. I can write software that is not for other humans. That's the most fun part of software engineering to me, when you don't care about the users and just do it just for the fun of doing it.

Almost any advice is useless if you write code purely for your own enjoyment. This is why the context is so important. If you enjoy writing convoluted unmaintainable useless code then who is to stop you? Just understand most advice does not apply to your context.

Most software development advice tacitly assume you want to write code which works and is long-term maintainable (potentially by someone other than yourself) and which fulfills some purpose beyond just the fun of writing the code.

> If you enjoy writing convoluted unmaintainable useless code then who is to stop you?

Does anyone actually do this? I think it's the opposite.

I've spent truly absurd amounts of time thinking about how to do things properly. I read books, read other people's code, read programming language implementations, I just read and learn as much as I possibly can before I even start doing anything. I want my code to be right. I want it to represent the truth of how the world works.

In a professional context where people actually have deadlines, working code is usually enough to satisfy them. How complex and maintainable it is tends to be a lesser concern, to be addressed at a later time or never.

> > If you enjoy writing convoluted unmaintainable useless code then who is to stop you?

> Does anyone actually do this? I think it's the opposite.

Code style, structure, and design are more of an art than a science, so different people will have wildly different opinions (extreme examples notwithstanding).

I don't think anyone deliberate writes unmaintainable code except as a joke. Hard to maintain code happen when some other objective takes priority - performance, abstractions, architectural purity, DRY or whatever else a developer might enjoy focusing on.

The most maintainable code tend to be the least clever. But developers enjoy being clever, so without any outside pressure to deliver maintainable code, developers will tend towards less maintainable code.

And, as the article says, your advice and the GP’s are contextual.

If you’re interested in creating software that makes people happy, solves their problems, gets cherished and recommended - then work hard to not lose sight of that goal in the thick of crafting a massive code edifice.

If you’re interested in pushing the limits of your own creativity, and building a technical structure capable of handling domain complexity with ruthless efficiency - then sure, don’t worry too much about how it looks, how it reads, or how others respond to it.

If you’re lucky, you might get to do both in the same body of code. But not likely.

Even if YOU are the only user, you're still writing software for a human.

Hopefully.

With that argument you could say that everything humans ever did was for humans. So either it is a platitude or it is wrong.

You could say that, but my cat thinks you'd be wrong.

However, I'm yet to see my cat boot up the computer.

Ultimately pets are for humans, whatever you do for your cat you do for humans. The same logic works there.

With cats it's the other way round: the humans for cats.

And from a computers perspective all human work is ultimately for computers. Either making them or feeding them data. The purpose of the cat is to generate cat pictures for the computer etc.

My cat would often turn the computer on or the tv off, and I swear he did it on purpose because that's when he was complaining he didn't got enough attention.

My cat has turned off my computer on me - does that count?

You’re writing software for all of your future selves.

http://www.catb.org/~esr/writings/unix-koans/prodigy.html

Thank you for posting this. I feel understood.

But then we can also go the other way, and forget how crazy and diverse humans are. So you will still, eventually, end up facing the same challenge, framed differently.

Well, you could create software as art. Basically to create it for the fun of creating it, not to use it.

But yeah, the end result is useless then, and can be thrown out.

Or, like some art, of variable degrees of folks caring about it based on other interesting properties - and made for some purpose other than maintainability.

Demoscene, obfuscated coding contests, etc. seem to fall under that category.

Uselessness in the eye of the beholder or something like that.

But in those cases you are creating for other people. The point was made about software that didn't have any use for any people.

In those cases, only the creation itself has a use, not the end result. By definition.

Don't forget to write for future you. They'd appreciate some consideration as well. Mostly along the lines of "wtf does this module do?"

The best one for me was documentation to complicated for me - by me.

You seem to have a complicated relationship with your past self. I foresee further trouble in your future. Its best if you take a torch or you'll be eaten by a grue.

> when you don't care about the users and just do it just for the fun of doing it

Yes!! That makes me so happy.

Or they write it for themself and not _other_ humans.

Your future self can be seen as “other” humans given a long enough time frame.

Anybody who has looked at their own code done more than 5 years ago can surely attest.

5 years is optimistic. A lunch break can be enough.

Can't agree with this enough. Sometimes it is directly for other humans (a GUI), other times it is indirectly related (an ETL job that converts data into a form that can be easily used to drive a recommendation engine which provides recommendations ... to people).

This is tied into asking "why", another one of the author's points. At the end of the day, if you dig deep enough, the why will be related to human happiness.

Bonus! If you keep this in mind, you'll also gain perspective. While you don't want to live at 30k feet all the time, periodically gaining high level perspective of the problem you are solving has been, for me, one of the joys of software development. (Not the only one, but definitely a significant one.) Hopefully it is that way for you too.

> At the end of the day, if you dig deep enough, the why will be related to human happiness.

At one of my jobs, one of my tasks was to take client HR feeds and load them into downstream systems for travel management. On your second day of employment at your company, you should have a profile in our system which was a portal that displayed all travel policies and a profile in whatever booking tool your company used.

We knew who your manager was so approval emails went out automatically. We knew what corporate card was assigned to you, so you never had to deal with that. We knew what preferred vendors your company had agreements with etc

All I was doing was data manipulation and loading on a scheduled or triggered basis. But ultimately it allowed new hires in a new environment to have an easy time booking their trip for mandatory training.

Any time our process failed, you had a traveler stressed out that they wouldn’t be able to book the trip in time or have to outlay money and reimburse later or get stuck at a distant airport.

> Software is a social service. Its for other humans.

I deeply disagree with this Calvinist utilitarian sentiment. Its akin to saying sex is for making babies. Maybe its an academic thing - When I went to grad school for CS, on Day 1 my Algorithms Professor paraphrased Perlis's famous quote on the blackboard - "Shaft the paying customer!"

You can find the whole quote on the first page of SICP[1], or elsewhere[2]. imho its a highly toxic sentiment to think that whatever a programmer does is for other humans. Software as a Social Service...SAAS :)

imho the best software is written to scratch a personal itch. Not to appease this customer. Not for other humans. Not as a social service. In fact all the people I deeply admire in the software world - Arthur Whitney, Kenneth Iverson, Mattis & Kimball, Perlis, Dijkstra, hell even Linus, are generally characterized as egotistical assholes in the public space who really don't give a flying fuck about social service & humans but care deeply about the software they created for their own selfish reasons.

Mattis is quite explicit about this - "You should understand that the GIMP and GTK weren't written to fill holes in the software available under the GPL...GIMP was started because I wanted to make a Web page. GTK was started because I was dissatisfied with Motif...These are purely selfish reasons. That is probably why the projects...eventually succeeded. I find it much more difficult to work on something for selfless reasons."

Perlis - "I hope we don’t become missionaries. Don’t feel as if you’re Bible salesmen. The world has too many of those already. What you know about computing other people will learn."

otoh the people I deeply detest in software (too numerous to name) are generally these do-gooder types who write software to save the world & provide social service, employment to the masses, add "value" insert-marketing-speak-here etc...

I'm ok with the hypocrisy in pretending to care about software as a social service because I need to put food on the table like any other programmer on the market, but deep inside, I write code only for myself. I think a big fraction of developers are like that. There's no harm in saying it out loud.

[1]https://cloudflare-ipfs.com/ipfs/QmQ3C4ooSCmBMuK7mKq4sqVAfGq...

[2]https://www.goodreads.com/quotes/405620-i-think-that-it-s-ex...

> imho the best software is written to scratch a personal itch. Not to appease this customer. Not for other humans.

This statement shows you partially understand, but don't understand the why. You recognize that people working on software for things they truly care about can write better more successful software, but you miss the final step of why that software is more successful.

The reason why Linus can write such great software for software engineers is because he is a software engineer. Fundamentally the software you love is successful for other people, it is for other people and because your idols are one of those people part of that group, they understand it as well as anyone.

Linux was made for passionate hobbyist programmers by a passionate hobbyist programmer. And because it is made for those people, and met their needs perfectly is why it caught on. The reason it met their needs is because Linus understood their needs, because he shared them.

That's the key piece - that great software is written by completely meeting users needs. The easiest way to understand and meet other people's needs is by sharing them. That's the final step of it.

Fundamentally software becomes successful by meeting other people's needs. Anything else that doesn't, you've never heard of.

> imho the best software is written to [...]

What do you mean by "best"? If it is supposed to be judged by the original author of the software alone, your opinion does not matter. If you think your opinion of software written by others matters, then BAM, you've acknowledged what you set out to refute, i.e. Software is written for (or at least its quality can be judged by) other humans. (Unless you're actually a GPT-3 bot in disguise, in which case you win :D)

What you might have shown is that software not written for others can still be great in the eyes of other people, but even that is somewhat nuanced. IIRC one of Linus' egotistical outbursts was triggered by a kernel dev intentionally breaking user-space compatibility. At least in this case Linus' example doesn't support your claims.

I also don't see why "software is written for other humans" necessarily snuffs the fun or interesting aspects out of it. There certainly are large number of un-fun software that serves a commercial purpose, but it doesn't mean that fun software has to be anti-social. Even entries submitted to IOCCC (purposely obfuscated C code written purely for fun) sometimes lead to useful stuff (Fabrice Bellard's work).

> provide social service, employment to the masses,

If I want the computer to do XYZ, and I can provide an XYZ service to other people? They're paying me to do my bug testing, and I get to feel good about it.

If you're providing something that you think is a really good service, but not for people like you, and not for somebody specific you know either, it's probably going to be rubbish.

So if Linus works on Linux for his own selfish reasons, howcome Linux isn't a one-person effort that nobody else is using? And why did they pick the GPL?

It sounds to me like you're describing bad social behavior but generally altruistic motivations with good social behavior but non-altruistic motivations, and you prefer the former over the latter. Sure, thats fine.

I think software is human expression. It can be a social good or a business driver. But it does not have to be. It can have no users, no IO or never run on a computer and still encode deep meaning.

Does it need to be social to be useful? That is a value system.

Many here communicate (beautiful) value systems, and that's great! But ideas and software can transcend those.

35y+ here, i just sent him something along:

"software is communication, made by people, for people"

(which is more or less what you say :)

With all the consequences. Most people, on either side, don't get it. Ever.

you can replace the word "software" with basically any other professional work and that is still the same. I don't know what you can learn from the fact that it's a social service.

I've met a lot of people who are writing code to satisfy requirements and collect a paycheck. They're good people, but just don't automatically think about the end user. They stop when the requirements are met, instead of when the user will be happy.

That's what they're supposed to learn from that, IMO.

> They stop when the requirements are met, instead of when the user will be happy.

that's because they are doing software "for other humans" - aka, their manager and PM, who gave them the requirements.

So the problem is not the software engineer, but the person who creates those requirements to be fulfilled.

I think what the parent may have been complaining about is essentially myopia in interpreting things - ‘well, this technically checks the box of what they ask for’ while willingly avoiding thinking about the larger context of what is being attempted or trying to understand requirements that don’t make much sense.

Don’t get me wrong - it has it’s place, and if everyone always tried to understand everything, there are a lot of organizations and situations it would be crushing - but it’s also very frustrating in many situations for those who want high quality products.

It’s the ‘not my job’ syndrome, essentially.

> I think what the parent may have been complaining about is essentially myopia in interpreting things - ‘well, this technically checks the box of what they ask for’ while willingly avoiding thinking about the larger context of what is being attempted or trying to understand requirements that don’t make much sense.

I think what your post’s parent was pointing out is that in lots of environments, such myopia is just an engineers job definition, for which they will be punished if they stray. Interpreting end-user needs is someone else's job.

I think we just violently agreed, and even repeated the same last line?

I'm not asking that develop to go against the requirements. But it's often possible to satisfy requirements without satisfying the user, even though it's actually possible to do both.

Some organizations are structured such that it is difficult for an engineer to do anything else. An engineer doesn't always have access to the end user, unfortunately.

Well, all economy is human economy, so yeah .. okay.

You can learn from the fact that its a social service by actively NOT resisting the truth of this fact.

Incorporate it into your thinking with every commit you make and you will become a better programmer over time.

(Corollary: those developers who forget this fact, make shitty software...)

Everyone agrees that software is to serve humans. What they disagree about is how to best make software that serves humans.

For example, lets say you write an API that translates text. Should you assume the text the human sent in is correct and return an error? That way you can make better translations when they send the right data. Or should you try to be helpful and automatically fix spelling errors you think you've found in order to make the API more human friendly? Would make it easier but reduce accuracy.

You seem to be in the second camp, reduce power of API and make them easier to use. But lots of people think that the best way to serve humans is to make more powerful and strict API's.

Either option is fine, as long as your user agrees.

You have more than one user. Some of them will want power, other will want ease of use. You can't satisfy everyone without making multiple products.

More than that, there may be a whole stack of software components between your API and your users. In this sense, quite a lot of software is written for computers and not other humans (or, your users are other software devs).

This is to say, "all software is written for humans" is too general to be useful - the important issues are all in the details.

Probably something to do with the computer not caring about that. If you constantly divide your time between someone that’s 100% logical, and someone that generally isn’t, you’re bound to get confused.

Gonna expand on this just a bit. Software isn't a product or a service. It's a tool. No end user cares what your stack looks like, they just want to click a button that solves their problem.

Nothing between "click button" and "problem solved" is your user's problem, they're all yours.

Very few recent programs i've seen were socially useful. Some might find comedy in this but the app my current gig uses:

- is un ergonomic and redundant (typing the same thing over and over, no keyboard shortcut jquery era procedural code)

- the overall design is useless, it produces libreoffice templates that takes ages to be badly filled

- secretaries go faster using fucking paper and filling everything by hand

- the application has all the data at hand but nobody has access to stats or complex queries, people have to also write down stats with stick marks on paper so the hierarchy knows what's going on

alas

What do I do with this, though?

I think I get what it means but how do I act on it?

Always keep the human in mind, whatever software you are righting. Its turtles all the way up to the human.

Is this meant to be "code is for the reader, not the compiler", or "people are the ultimate end users of your software"?

20+ years and I concur.

Improvements in my "soft skills" have carried me further than any technical learning.

A corollary-ish observation of my own:

   * If coders could write useful documentation (starting w/inline comments) they probably wouldn't be coders.

What would they be instead?

Communicators. (Writers, marketers, teachers, ...)

Then they'd make less money.

Why would they choose less money

(Unless of course if they like those other jobs better)

They would be what then?

I fully agree with this.

another 40+ here w0rd!

Isn’t this true of basically any job?

Sure, but that doesn't make it any less useful as a fact - especially when you are working with other developers who choose to try to ignore/avoid it as a maxim.

Please don't tell me you've never met such a developer ..

I am such a developer.

See you in 30+ years! :P

Do you keep your code human readable? Why?

Just playing devil's advocate:

So I or someone else can continue to effectively make the computer do work.

So it's a social act to keep the computer running.

For whom does the computer do work?

Other computers

I see you work in finance. Where the humans are just office decoration.

It may be computers all the way down, but at the bottom there is a human. Somewhere. Poor thing.

Unless it’s consumed by an AI. Which I don’t fully understand but am comfortable assuming that the AI might be able to ‘teach’ itself to consume an API.