Hermit Programmers Are Dead

In summary, hermit programmers who only write code for themselves are dead because:

As they don’t plan, you never know when (or if) they are going to finish a task. As they don’t document, their code is not reusable because nobody knows how it works. As they don’t test, chances are the code they write is full of bugs. As they don’t refactor, the software cannot evolve. As they don’t handle infrastructure, their code has only been executed on their machine, and only God knows what will happen when the code runs in production. As they don’t have good communication skills, they do not know how to sell what they do to the market, which is why they are always behind the competence. As they don’t diversify their skills, powerful AI will take over their workplaces.

I think in the end the author took the attributes of "Bad" programmers and applied them to "Hermit" programmers.

So yeah I agree Bad Programmers are going to have a Bad time in future.

This is such a strange thing to choose to write a derogatory article about. If you are a singular developer that is only writing code to satisfy your needs, then you can do whatever the hell you want. If you have to work in a collaborative environment, then you will likely need to play by the rules of that environment. There's not much else to say about it.

The stuff about automation doesn't even seem to fit in this article... that's a completely different conversation.

Throughout reading this I had a creeping thought: "this person has no idea what they are talking about".

The text seems to imply that people on the "technical track" (only programming) are doing so because of some flaw in their personality. That is absolutely not the case!

This is not a good way to launch "hermit programmer" as a new term. The term is not defined and mentioned only three times in the entire text (once in the title). I suppose most readers have different assumptions on its meaning.

I know a few "hermits" (the way I interpret the term) that are excellent engineers and also excellent communicators. Only that they work via mailing lists and not in person. And that they are not willing to succumb to a manager bossing them around.

Huh. The author would probably consider me a "hermit programmer."

> As they don’t plan, you never know when (or if) they are going to finish a task.

> As they don’t document, their code is not reusable because nobody knows how it works.

> As they don’t test, chances are the code they write is full of bugs.

> As they don’t refactor, the software cannot evolve.

> As they don’t handle infrastructure, their code has only been executed on their machine, and only God knows what will happen when the code runs in production.

> As they don’t have good communication skills, they do not know how to sell what they do to the market, which is why they are always behind the competence.

> As they don’t diversify their skills, powerful AI will take over their workplaces.

I have only one answer to these rather ... interesting ... statements: https://stackoverflow.com/story/chrismarshall

This seems about ten years out of date. Current cloud deployment software is now so powerful that a lone developer can write and deploy entire systems: front end, middle tier micro services, data stores, private network, firewalls, all of it, boom. And it’ll be containers every where so dev and prod will be more in sync than ever.

And communication skills where highly useful in the mid 90s as much as they will always be. And the salaries for developers are so much higher now than before. Yeah sure everyone that knew what CGI was in 1996 got a great job, but that salary was like 25% of what is now.

In the old days, a server was fast enough to do everything, you bought it, installed the parts, and ran it for years, sometimes more than a decade, before being turned off. You didn't need to configure infrastructure, because you had already built it, once, and it just worked.

It was a much simpler way of doing things because the number of users was known, and you didn't need to scale past that.

Also, your users were known, and thus you really didn't have to worry about security, for the most part.

Programming was a matter of finding the right libraries, and doing plumbing, back then, as it is now. Nothing has really changed in that aspect.

What has changed is that productivity has plummeted as a result of having to fragment systems across servers, networks, and client platforms, with many additional leaky layers of abstraction added to attempt to compensate.

I watched as the office network I was hired to support in 1997 became so reliable that by 2013 there was almost nothing for me to do. The tools that can produce code to run in that environment from 1997 only fail because we've switched from 32 to 64 bit environments.

All those layers of plumbing need to be managed, and it's programmers, not some AI that is going to do the job.

This article focuses on 'hermit' programmers as employees, but I think ultimately that type of stereotyped character is now as likely to become a small business owner.

With all of the benefits of efficiency and the cloud mentioned in the article, such lonesome characters can now put together their own SaaS or similar sorts of high margin services/products (such as infoproducts, data, or semi-automated consultancy) and make a reasonable income, and most customers don't care whether it's wired together with tests, refactored properly, or what not.

It does require at least enough business, marketing, and communication skills to sell their work, however, but even this is becoming an easily reproduced or outsourced skill nowadays.

Yet more expectations on programmers without considering our environments. At the same time that programmers are leaving their jobs in droves and we are seeing widespread burnout.

You sub-tier hermit blub code monkey piece of shit how could you forget to document and test well and refactor and stay on top of a 100 tech trends while churning out tickets all day, firefighting production issues, mentoring other programmers and working from home during a pandemic while friends and family around you are getting sick or dying? All of these things are doable if we had 5x more time and training and sane work cultures but we don't.

Fuck off, blame management.

> Don't call yourself just a programmer anymore

This subtitle is almost the same as the title Patrick McKenzie's popular article on salary negotiation and career progression which is almost 10 years old now. So not really anything new and it's a bit disingenuous to present this as a big new change as of 2021.

The article does this switcharoo where it states something in the title, never addresses in the text and then it lists conclusions which aren't related to the main text or to the title. The conclusions make sense on their own - it's a list of useful skills for software developers. But they don't belong to the rest of the article or to its title.

This article reads like it was generated by GPT-3. High on buzzwords, low on coherence. Not sure how "AI" is going to do anything other than create more demand for programmers.

I disagree with the article's summary; the tasks listed at the end (planning, documenting, testing, refactoring) are helpful but:

1. There exist successful projects that don't rely on them.

2. They're not in an exclusive relationship to programming (e.g.: a person that focuses just on programming and that write code for themselves can still refactor their code).

So he conflates "hermit" with "unsociable solo star with no communication skills", i.e. "the bad programmer", apparently.

Should be obvious that being a hermit does not correlate with being professionally unsociable, nor does being an amazing programmer does correlate to being sociable. They are separate things and even if there's some overlap that says nothing about the one thing or the other.

Fairly pointless article, feels like it was written mostly so the guy can advertise himself.

It is very fitting that this article that can predict the future also has a JSON error displaying at the footer:

> An error occurred: JSON.parse: unexpected character at line 1 column 1 of the JSON data.

That to me is the near future of software: people thinking software is somehow solved or easier while failing to execute well on basic things like displaying a static HTML document.

> People that lived by and for their own coding creations, pleasing managers from time to time

What? I don’t think this guy was a programmer in the 90s. Maybe a fetus.

> Thus, writing a bunch of code is not going to be a cool thing to do anymore: thinking about how to assembly existing software pieces to solve problems with computers will.

The vast majority of sw projects are exactly that: connecting pipes.

To me, this is simply a rant against technical qualification - more bluntly, an excuse of the own inproficiency. Something whose significant increase as a trait of software development in this age is in my opinion undeniable. And this is a problem.

> no-code movement will continue its expansion

One of the many examples of false opposites.

A good programmer / software engineer / whatever you name it, is characterized by his ability to move smoothly between very different layers of abstraction vertically as well as the ability to adopt different points of view, technical caused ones and others. This requires different levels of mastery of all of these things. Not always at the same time, but ultimately no one can be avoided.

Regarding the example from above: Dealing with a real programming language becomes unavoidable with certainty at some point. And this isn't simply "glue code", a pretty derogatory term often used by people who just can't program. It is part of real quality.

What a waste of time.

Every single point in the conclusion is wrong.

After reading this article, I have a strong feeling that the author is trying to sell something. The number of platitudes, buzzwords and non-sequiturs is usually a dead giveaway.

I still don't know what's being sold, though.

They've been saying this since the 80s. The magical world where prolog/pascal/java/NPM solves all your problems is eternally 3 years away.

I find it hard to understand why anyone would read past the first few paragraphs of this obvious dreck. Y'all are much more charitable than I.

was this written by GPT-3?

> This was possible in part because the number of available technologies (software + hardware devices) was so limited that, for instance, a C programmer could literally code for any available platform;

Uhhhh…WTF?? On a scale of 0 to WRONG this is WRONG + 1.

Who does the author think is going to write all the SaaS services and low code tools?

I am a hermit programmer AND I do ML(AI). Last time I checked was still breathing, thanks for asking.

Sounds like this person is swallowing and licking up whatever corporate gives them. But as many have or will find out, companies don't love you like that. Lifetime employment at the same company is just about dead too.

When that pay raise doesn't happen, when cuts to the staff come down, when that other or junior person get's chosen or promoted over you, when your job get's outsourced, etc... It's about their profits, not you.

Somehow this person has got themselves so twisted up in the corporate game, they don't know the difference between "hermit programmer" and "bad programmer".

Below is a list of traits of bad programmers. Saying that only an independent or hermit will do one or more is to be blind to reality:

1) they don’t plan 2) never know if they are going to finish a task 3) they don’t document 4) their code is not reusable 5) they don’t test 6) code they write is full of bugs 7) they don’t refactor 8) the software cannot evolve 9) they don’t have good communication skills 10) they don’t diversify their skills 11) powerful AI will take over their workplaces

As for AI, corporate is more likely to use such to eliminate jobs internally, to save themselves a few bucks. In addition, corporate environments and teams don't produce bug-free code and management can lead a project "off a cliff" to where it fails. Just because a team of people think they are doing the right things, doesn't mean they actually are nor is there any guarantee of success. Doing things by committee can also be a source of vicious arguments, resentment, and project stagnation. Every team isn't effective or efficient, so can depend on the situation.

Bad programmers can exist in corporate environments and teams too, because they are able to abuse the power of their position or fool management for a while or prior to them jumping ship unexpectedly to another company.

The author created a 1970s bofh straw man to tare it down. Testing, documentation, and larger scale design (patterns or whatever you want to call it) are things that are so pervasive now that even a lone practitioner is expected to do them in some form.

Again another story “copilot” will do the work for you - it doesn’t, it can make things easier but that is all.

I get

  An error occurred: Unexpected token < in JSON at position 0.

at the bottom of the page.

"The number of programmers is constantly on the rise, but many programmers no longer need to be experts, middle-skilled developers now do what needed an expert before"

Not really. It's more that the balance between breadth and depth has shifted. Applications are so much more complex and do so much more than they did 20 years ago. You definitely need to build a web version, and probably at least two mobile platforms too. Depending on what it is, maybe one or more desktop apps too.

This article has the feel of being written by an AI. If that is the case, then I'm confident that the need for human writers is not dead.

Yet another article on HN where "programming" = webdev

I've been working both as 1-person team for years but also in larger teams for the same amount of time. In my experience the hermit programmer is some sort of a myth. It's true that sometimes tech staff is more separated from more non-tech staff but that is always a management decision because they think it makes people more efficient.

In fact as a 1-person team it's usually necessary to interface much more often with other non-technical people. In larger (scrum) teams that is usually centralized through a PO or PM. Which is in the long-run usually a good thing, pressure can be extreme for 1-person teams since people call the programmer directly. I used to work at places where sometimes for a time frame of 1 hour a day someone tries to make me listen to his or her ideas. Such a waste of time.

I'm a total hermit...

> As they don’t plan, you never know when (or if) they are going to finish a task.

I have the next year and change planned out.

> As they don’t document, their code is not reusable because nobody knows how it works.

I write lots of documentation.

> As they don’t test, chances are the code they write is full of bugs.

I do a healthy amount of testing (specifically on stuff that involves a lot of variability or uncertainty).

> As they don’t refactor, the software cannot evolve.

Refactoring is like church.

> As they don’t handle infrastructure, their code has only been executed on their machine, and only God knows what will happen when the code runs in production.

I built and maintain my own stack on a combination of setups involving bare-metal, Docker, and Kubernetes.

> As they don’t have good communication skills, they do not know how to sell what they do to the market, which is why they are always behind the competence.

I've been told I'm an excellent communicator. Maybe that's because I spend most of my time talking to myself.

> As they don’t diversify their skills, powerful AI will take over their workplaces.

I can design, develop, write, market, speak, and sell.

---

tl;dr; Don't apply lazy generalizations to yourself as they set an artificial ceiling on your potential that makes you easy to control. See: https://podcastnotes.org/kapil-guptas-solo-podcast/kapil-17/

This article could have been written 10, 20 or 30 years ago with only the slightest of adjustments. We work in an industry with the constant need to learn new things and adapt to new ways of working, this will never change.

In the old days, there were no separate "engineer" and "factory worker" jobs, just "craftsman". Or "architect" and "construction worker", just "builder".

Perhaps a similar separation will occur in programming, and perhaps (this is a separate assumption) the lower-skill jobs that involve mostly "plumbing" will be automated, just like "assembly worker" jobs are getting automated.

I doubt very much that the more complex and "creative" tasks could be replaced, not in foreseeable future.

"This was possible in part because the number of available technologies (software + hardware devices) was so limited that, for instance, a C programmer could literally code for any available platform; and we all know how cryptic can easily become a piece of driver code written in C."

At the beginning of the 1990s, one still had minicomputers, notably but not only the VAX. In the workstation market, one had MIPS, SPARC, PA-RISC, Alpha, 88000 platforms. And that's not even addressing IBM world.

People have been prophesying the dawn of no-code since before I was even born, and yet we're yet to see the demise of programmers.

Also:

> if you want more SSD storage or CPU processors, you just need to add them to the basket

I used to say "CPUs are cheaper than developers", until the day I discovered that's not always true, and had to spend several months refactoring the product we were building so that it could actually scale properly. Funnily enough, Terraform doesn't magically solve P=NP.

Another strawman slain.

Good lord, people have been saying crap like this for decades now.

Don't be good at programming, just glue lego bricks together, This Is The Future!

I’m scared to read this. I’m interested in being able to do these things. I think my communication skills might be lacking and I haven’t figured out an approach that works for someone like me… but I definitely know that it’s something that needs improvement.

> In summary, hermit programmers who only write code for themselves are dead because:

> As they don’t plan, you never know when (or if) they are going to finish a task.

>As they don’t document, their code is not reusable because nobody knows how it works.

>As they don’t test, chances are the code they write is full of bugs.

>As they don’t refactor, the software cannot evolve.

>As they don’t handle infrastructure, their code has only been executed on their machine, and only God knows what will happen when the code runs in production.

>As they don’t have good communication skills, they do not know how to sell what they do to the market, which is why they are always behind the competence.

>As they don’t diversify their skills, powerful AI will take over their workplaces.

What does any of this have to do with being a hermit?

I’d also argue that good communication skills are subjective. For instance people in different regions communicate differently, and some skilled people have disabilities affecting how they communicate. In my view it’s important to be open and accepting towards diverse communication styles. There is no “good skill”, that if you don't posses makes you “always behind the competence”

This is just wrong. Imaginary computing (based on language models) and blockchain or other source of truth is the future. As hermit programmers we can rely on AI to make a prediction as to when a task will be done, generate documentation for us, generate tests https://mullikine.github.io/posts/imaginary-reflection/, generate, etc. Any deployment system that doesn't use language models will be fragile as the time to onramp new developers will become exponentially more difficult over time. Hermit programmers are OK if they lean heavily on AI and blockchain. This article is a case for sell-outs, and pessimists

If you are going to write a text pontificating how good programmers should work, at least have the decency of placing a decent toolbar at the top (broken in Safari).

And even the content is not much better.

Offtopic: For some reason I find the articles font hard to read. It's readable, but makes my eyes a little "buggy".

I feel bad saying it but I’m just not willing to read something this long until eventually it comes to the point.

Working with dips like this is dead. I fire people with this kind of inflammatory attitude towards others.

> It’s 2021, and the job market has crashed

Is this actually the case?

Honestly, I thought the term was "cowboy coder," but maybe my vernacular is archaic.

Not to pile-on, but I don't understand the bizarre disparagement of computer science. There are far too many programmers, hermit or otherwise, who don't know what big-O notation is, which data structure(s) to choose in a particular scenario based on requirements, algorithm design, or the Church–Turing conjecture. I would also add variations of software engineering methodologies are obligatory knowledge of a professional programmer for situations like using strict, formalized waterfall development in life-safety systems. Credentialed Professional Engineers supervising and/or implementing critically-important code are also Good Things in such situations too.

I mean, they were never really that great. People tolerated them when we didn’t have good ways of managing technology, but the archetype of the hermit programmer has been confined to academia for decades. Development practices have focused on collaboration, pair programming and code reviews for a long time now.

Concur with the large number of commenters saying this guy seems to have limited experience with which to judge the scale of the problem.