Hacker News Reader

Comment by jpfr | Hacker News Reader

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.

View on HN

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.

Maybe "Bad Programmer" is more apt instead of "Hermit programmer" and yeah it is a no brainer that they are "dead"

Maybe "Bad Programmer" is more apt

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...

Oh, it hasn't been the norm, sadly -- but those several times it happened it felt amazing. ^_^

I would not call such a programmer "best", or even "good". Maintainability is almost as important as code actually performing its task.

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...

The programmer's job is to produce code that works and is ready to change. So these real developers did only a half of the job.

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

Actually, I don't think they are dead at all in sub-first-tier environments.

I think they are quite alive.

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.

Reply on news.ycombinator.com