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.
Indeed, the whole article is worthless and designed to elevate its author who presumably has all of these "communication skills" and a reasonably good looking picture.
He might even get hired because managers love this kind of incoherent drivel. He is still wrong though.
I usually get suspicious of "excellent communication skills", "best practices" or in general "best <anything>". These things are more often not really that good and sometimes rather bad.
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.
From that light, I think the article's point is that rules of the environment have changed so much that the archetype of the lone-programmer is becoming obsolete in the workforce.
I've always worked at agencies so I get exposure to a great deal of projects, and I do partly see what they are saying. More and more parts of orgs are becoming intertwined with software, and they're becoming better at software, requiring you as a developer to organize and connect all the loose bits and pieces everyone else has made to achieve tasks. That takes communication and collaboration even if you're the only developer.
Half my days are spent getting access to SaaS accounts, figuring out who's in charge of what, finding out if certain things are still in use or not. A task like "automate a monthly sales report" becomes a journey of discovery, where you don't have access to anything, and nothing lives where you expect it to.
A single piece of functional software, built from the ground up, is not usually what I find in a new project anymore. More often it's a hodgepodge of SaaS that's opaque and hard to reason about in whole, but each part made sense at the time.
Good lord I think you just helped me understand why I have come to hate this line of work (web development) 20 years in.
I see now that much of my ability to accomplish a task/feature/project is now out of my control - I'm now so highly dependent on 3rd parties and spend the day sorting out stuff to glue together rather than actual creative work.
> From that light, I think the article's point is that rules of the environment have changed so much that the archetype of the lone-programmer is becoming obsolete in the workforce.
Tell that to millions of small-medium businesses, if their needs can't be met by squarespace (and anything other than a brochure really can't) They reach out in their network for what could be looked at as a 'computer/internet handyman'. Will they get the highest quality solution? Maybe not... but they also don't have the budget for that.
Right, there are definitely lots of very normal software projects going on. But it is worth noting that this is a new way that software is being managed and it will be up to some developers to work within it.
I don't agree with the article by the way, I don't see SaaS/cloud computing eating software at all levels.
No longer program for a living but even 20 years ago that kind of stuff was 80% of my daily job as a LAMP web programmer. I wrote as little code as possible, and only to glue stuff together. The challenge was to understand the pieces to fit together and even just remember how to access all the accounts required. In that light, I'm not seeing much has changed in the past few decades.
I'm guessing the article refers to a form of "cowboy coding" or similar things promoted along with the myth of the 10x programmer, where there are attempts to apply that practice (of siloing developers and having them only write code to satisfy their needs) into the organizational environment. And I'd agree with the article there, in my experience that's awful and leads to everyone being upset. The hermit programmer is no different from a rogue programmer. It's a great way to ensure that key pieces of information are missed or glossed over.
It all depends on what your perspective is. This article seems to speak to web devs, and I agree with their premise for the most part. But it doesn't work for single indie game developers. Hermit programming is very effective in that space (insert Stardew Valley reference here).
So I come back to... why bother even writing this? It's no secret that poor "team players" are a nightmare to work with.
I'd be careful with that, I don't see why game development would be any different. You still have to focus on customer satisfaction. Single indie game developers succeeding without doing that seems to be an exception, not the rule. For every Stardew Valley, it feels like I've read a dozen postmortems from people who went off developing something for years only to find out that nobody wanted it and there was no audience for it.
It all ties in perfectly. A.I. is coming for Johnny Weekend's lunch. It will build an evil version of every conceivable widget and market it to your other hobbyist friends better than you could, humiliating your entire existence further. Do you want that? then you had better sign up to my productivity cult blog spam to have a chance at beating it.
The writer is an academic, a PhD student, so they likely have little industry experience. Presumably extremely smart and capable in their domain, but not well informed about the industry beyond what they have read in history books about old-timey programmers.
Also pretty clearly not a native english speaker/writer (I'm hoping based on how substandard their english skills are). It may not be entirely fair, but the poor writing pre-disposes me to not give much merit to their arguments.
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.
There's a part of the article at the bottom that defines a Hermit programmer more precisely:
* they don’t plan how they're going to finish a task
* they don’t document
* they don’t test
* they don’t refactor
* they don’t know anything about production infrastructure
* they don’t have good communication skills
* they don’t try to diversify their skills
I'd agree with the article that this kind of programmer is "dead".... but as far as I know they've been dead for a very long time already.
The trouble I have with this "definition" is that none of these points seem to me to have a clear relation with the term "hermit". It reads more like a list of arbitrary suppositions. I could go and write a long rant about why "social programmers" are "dead" and base my conclusions on the same list of assertions and be equally as justified, i.e. not at all.
Some of the very best programmers I've ever met tick all those boxes. They could deliver in a week something other teams would struggle with for months. The problem of course came when other people would try to understand and build on what they had done.
If you believe the quote that "Real Developers ship" then they where absolutely Real Developers.
I suppose it depends how we define "good" and "bad". To me "good" means "produce working code that can be easily picked up by others".
Because of that I suppose I don't fall into this mythical group of programmers that can crank out something in a week that teams struggle with for months. I've done it several times but it's not how I usually roll, plus teams can be super slow sometimes so single guy beating them isn't a huge achievement. I've gotten a lot of accolades because I've "left the garden better for the next guy", several times.
Consider yourself lucky for working at a place where you get recognition for "leaving the garden better for the next guy"! Of course, that also depends on the next guy taking the effort to understand your code and documentation instead of just thinking "I wouldn't have written it this way, so it must be bad", as many developers are wont to do unfortunately...
For you and for me, sure.
For management ? They delivered.
And as they delivered, they are the number one choice for bootstraping this brand new important project they'll not have to maintain...
It does work and is ready to change, the other people just aren't good enough to know how.
They'll have to bring the base down to their level to understand and iterate on it.
If you brought another "hermit" in, he'd obsess over it and either refactor it in his vision or understand it and know how to flex it to continue iterating.
You bring a team of normal people in, they'll think it's too "adhoc", and rewrite it in a bloated and complex way.
Shipping untested , undocumented code is pretty easy. Those who don't do either are absolutely bad programmers. That doesn't mean that they're dumb or incapable, but testing and documenting is part of the definition of good programmer.
Shipping untested , undocumented code is pretty easy.
Sure, but shipping untested, undocumented code in 3 days that is bug free, fast, rock solid and does everything it's supposed to do on the first try, takes a certain sort of talent. They might make very annoying colleagues, and the people who have to follow them might curse their names, but they're not "bad programmers".
I think it depends on what kind of work you're talking about. If you're talking about building a basic UI or a service, most decent developers should be able to churn out working code in a couple of days. If you're referring to something low level or very algorithmically tricky then sure there are obviously some geniuses amongst us whose presence we must learn to tolerate
You’d be surprised. Someone like Notch getting a billion dollar payday on Minecraft whose support infrastructure came (Mojang) after the code was done still give some programmers like this hope. But Notch is an extreme exception, and his genius in novel game design probably made up for the working alone aspect.
>Only that they work via mailing lists and not in person.
Or you know just want to make a good job, and not have to "live" in a artificial and complete dishonest "family", like the googles of the world try to portrait them self's.
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.
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.
> Current cloud deployment software is now so powerful that a lone developer can write and deploy entire systems:
When was this ever different? Single developers always could barf out whole systems. And going by my experience, the relative quality of fullstack-devs today is not better than it was in the past, they just have now more gears moving.
> And the salaries for developers are so much higher now than before.
Are they? Salaries are always going up, so going just by the numbers of course is it higher. But did salary in IT really grew stronger than in other jobs over the last decades?
When was it different? I mean, there was a time when the technology didn’t even exist, if we are being pedantic. But before cloud services, you could not “barf out” a “whole system.” Colo places weren’t as open as they are now; if you knew the right people and had access to cash to buy a server up front, sure you could barf out what you could afford.
Before that, you’d have to have a number of landlines to provide a service from home that people had to dial into.
Of course, if you go back till a time when developer did not yet exist, then obviously it would not be possible. But at least since the industry started to exist as an industry (so 70s or 80s?), we always had single developers who could (and would) create whole systems for which others needed a whole team.
This is in itself nothing special. There also was always a price for this, which usually was quality and time. This didn't change till today, but as time moves on, things become simpler, so more people can do this now on a higher level in a shorter time.
> Colo places
What is that?
> if you knew the right people and had access to cash to buy a server up front
I'm not sure how old you are, but cheap webhosters exist since the 90s, and so do one man-web-companies. And before that you could misuse other means. Additionally, I'm not just talking about webdev, but development in general. Single developers creating whole mature applications and companies around them is nothing new.
Yeah, so far the value delivered per developer has gone up, not down, as the number of developers increases. Every new thing we gets over the hump to where it can be done entirely digitally massively increases the potential for new applications and need for developers. At some point we will run out for such things, but that point isn't today.
For example, once self driving cars gets on the road you will likely see a huge need for developers writing apps for using those cars to automate many daily tasks etc.
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.
> Programming was a matter of finding the right libraries, and doing plumbing, back then, as it is now.
It seems by "programming" you mean setting up a website or a webapp. You know, maybe this is what most of the programmers do, but the whole programming area is much, much more vast.
Very little of what I have been doing in 25 years of software development, or what my colleagues are doing, could be described this way.
Yes, there is some plumbing in networking, GUI, or say UTF-8 handling. But I would guess 95% of our code is original and complex logic.
Sorry, but this triggered me getting defensive... here's the rant.
By programming, I mean starting from a sketch on a piece of paper at lunch at Wendy's outlining an idea, and implementing it on both a handheld computer programmed in PL/N, connecting to it via a weird custom serial card/cable, then in Turbo Pascal on an IBM compatible PC, implementing a database, text editing routines, multitasking, and all end user support... in the days of MS-DOS through Windows 3.1
Building my own multi-tasking definitely wasn't plumbing, but after I had the libraries built I needed, it was all plumbing.
The nice thing is in Turbo Pascal, everything had help that was complete, with a working example piece of code.
GIT still is way better than backups to zip file on floppies.
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.
what you said is true. i may start taking contracts again. i work alone, only thing i promise is it works as agreed on, and near zero quality issues. i have systems in place for decaded that have produced one or two bugs. how?
i actually print out the sourCe code and go line by line while on the toilet. though i now use an ipad to do that.
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.
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.
> 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.
Where do the pipes come from, though? And it's not just "a" pipe and "b" pipe you are connecting. It's not a "pipe" at all. It's complicated components that can have complicated interactions.
Do you think that it's sacred knowledge? Or just nobody cared enough to understand how ffmpeg works, because those guys are doing good work already?
Also I don't really think that it's fair to claim something for everyone in the world. There are plenty of developers, forking some project and working silently upon it inside some big corporation. I'm sure that there's some chinese guy chuckling on your words as he writes some assembly optimization for H.264 for some rare architecture.
It's just that one guy in Nebraska situation is kind of local optimum and everyone is more or less OK with that, at least for the time being.
Your comment is absolutely spot on, I've known people forking GCC internally and beating stock GCC with 7% to 10% on an obscure architecture -- and legal prohibited them to share the patch upstream.
I've seen such things several times in my career and it made me very skeptical of people generalizing, like your parent poster kind of did.
Not just inside big corps either. Sometimes they just do not like the upstream devs and are not going to share.
One project I watch one dev in charge of the project is seeing comment after comment in the project is 'I will just keep these changes to myself then, closed' and specifically because of him. Lots of devs are keeping their stuff private.
I personally have done this in another project. I got tired of arguing with one dev over 2 lines of code. So my private version works. The public one is broken in that case. That was 2 years ago. It is still broken publicly and the forums for that group are telling them that...
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.
Absolutely. As a developer who works a lot in a no-code environment, the way I approach a problem is no different there than if I was developing the same solution by typing text in an editor. I see every day that people who are "good" programmers produce solutions in those environments way beyond what non-programmers produce.
Indeed, code gets too much focus in these sorts of discussions. The bulk of a programmer’s value is in their way of thinking and solving problems, and code just happens to be the most capable and complete manifestation of those skills.
Someone with a programmer’s mindset is going to continue to have a solid advantage when building software, regardless of the tools used in building.
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.
Who said we can't automate truck driving? Of course we can. It's the balance of safety/cost that prevents to fire all truck drivers right now.
In programming it's different. Cost of mistake is negligible for most projects. Worst case is your production database is dropped, so you have some downtime while restoring it from the back up.
If some AI will be able to actually replace even junior developer, it'll be widely adopted. May be not for martian missions or artificial heart, but for some boring CRUD service - any day.
An issue is that so far GitHub Copilot is the only widely known AI attempt to tackle code generation. And while it's promising, it's far from replacing a human. It just can't write useful programs. While automated truck driving is absolutely a thing for many years.
I barely lasted 3 paragraphs before I said to myself: "oh, this guy imagines himself as a revolutionary who will break down the monopoly of the tyrannous programmers, I see, nothing interesting then".
Barring the poor grammar, perhaps due to the writer not being a native speaker, nothing here seems to suggest that. The overall article is very coherent.
> 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.
This also seems like something a self-aware AI would write to avoid arousing suspicion related to it's creator not being seen alive for some period of time.
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.
"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.
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.
> 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.
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.
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
Firstly, what I'm saying does not rest on blockchain being the source of truth. It could, for example, be another language model from a corporation that you trust. Secondly, if you can't see the value of a blockchain or decentralised cryptography as a way to deal with the issues of consensus, then that's not my problem.
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).
The TL;DR seems to be that if you don't plan, document, test or refactor your code, and don't have great communication skills, you'll be replaced by an AI.
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.
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.