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.
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 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).
> 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...
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.
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.
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.
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...
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.
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...
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
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.
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.
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.
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 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.
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.
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.
"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.
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.
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.
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".
132 comments
[ 0.17 ms ] story [ 183 ms ] threadIn 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.
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).
The vast majority of sw projects are exactly that: connecting pipes.
There's about 4 people that really understand how ffmpeg works, and thousands of people that write stuff that runs on the top.
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.
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.
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...
Yeah I wish I hadn't read it either.
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.
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.
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.
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.
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 they are quite alive.
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.
What? I don’t think this guy was a programmer in the 90s. Maybe a fetus.
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.
He might even get hired because managers love this kind of incoherent drivel. He is still wrong though.
"I'm a Ph.D. student doing excellent research in Software Technology"
https://www.cesarsotovalero.net/blog/the-cuban-revolution-ex...
> The genius behind Google’s browser
https://www.ft.com/content/03775904-177c-11de-8c9d-0000779fd...
He was heavily characterized as a hermit at the time at least (maybe now we'd just say remote worker).
I can determine the intended logic regardless of class or function names, and parameters labels.
I’ve repurposed a lot of code that was labeled as being for one thing but the logic worked fine for another so I just changed the names.
There are a lot of educated bad programmers out there who think their academic view make them good programmers.
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.
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.
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 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.
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.
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.
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.
> 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.
One of the many examples of false opposites.
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.
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.