These are just rhetorical devices. An active Wikipedia account is just standing in for active participation in sharing knowledge online. S.O. obviously counts, and MDN probably does too (I know nothing about it).
Arduino is standing in for, knowledge of things that aren't directly applicable day-to-day. Hobbyist stuff.
I think it's acceptable to define a good programmer in terms of qualities that aren't beneficial to business. In the real world this is one reason why we have and need management. A big part of management's job is to convey to the rest of staff what the business goals are and how they are to be achieved. It would be nice if all programmers synthesized this without having to be told, but I don't see why that should be considered a necessary prerequisite for being a good programmer.
ThinkGeek toys, obscure stuff are just specific examples of a general pattern of curiosity and playfulness.
Metonymy is the use of a name (usually something specific like a building, or a part) to stand for something else (usually more general, like a government or organisation, or the whole thing), not the use of one example website with lots of others implied (I don't see where they are implied anyway, this is quite explicitly listing having a wikipedia account as an attribute of a good programmer - what a curious idea).
Most of the symptoms are just trivia entirely unrelated to whether someone might be talented at programming like owning a certain brand of toys, and this undermines anything serious the writer might want to say.
I misremembered, but I can't seem to recall the name of the device where you show a specific example from a class to stand in for the whole class. This is remarkably hard to search for. Please be useful and remind me what the proper name of the device is.
I think everybody is taking this article both too seriously and too literally. Sadly there is no known cure.
Signs that you have a general pattern of curiosity and playfulness could also likely include a molecular biologist with a picture of Lil Jon on her wall.
Following a general pattern is still a pattern. Patterns aren't as interesting as anti-patterns.
Or you're more interested in side projects that don't have a hardware or physical component. Or that require much more specialized equipment, like a CAVE system. Or don't use electronics at all, like 3D printing representations of mathematical functions, or building a cabin in the woods. Or restoring linotype machines.
Side projects in this case refers to programming side projects, I'm fairly sure. Personally I'm not interested in side projects with hardware or physical components, but I've still heard of the Arduino. But that really says more about the type of people you know, I guess.
True, but there are plenty of programming side projects that don't require an Arduino, and we often get in our little tech-bubbles and think that the internet is more of a monoculture than it actually is. I've heard (a lot) about the Arduino, so I may not be the best example, but my programming side projects are more likely to use Processing, Cinder, VPT, or some other thing that doesn't necessarily need to interface with that kind of hardware.
If we're talking about the original article, side projects were mentioned in the context of "The instinct to experiment first". There might be some correlation there, but if you limit the focus to programming side projects you've just chosen a slightly bigger box to experiment in.
Many advances in science come by drawing knowledge from a completely different field and applying it to a familiar one. Deep knowledge of programming is necessary but not sufficient for creative programming solutions. Design patterns in software, to take one familiar example, are based on Christopher Alexander's theories about physical architecture. The article itself recommends amusement park rides to foster greater risk-taking. Non-programming hobbies can have great benefits for programmers.
I've never met a good programmer who wasn't passionate about side projects. In fact every bad programmer I've met had no interest in side projects, summer projects, etc.
Sign that you will have a successful career and will get things done: you didn't listen or care what the list was.
Seriously, these lists mean nothing. This list is some guy sitting behind a computer who may or may not even be a good developer (I didn't check though), and telling you how you know if you are a good developer based on some arbitrary lists that are his own opinion. Listen to yourself, constantly improve and have a thirst for knowledge and you will be a good anything, not just developer. And if you are not a great developer, there are tons of developers that make huge amounts of cash that are probably not that great at actually designing and writing code, but they can get the job done. Who cares if some list says you are a good/bad/terrible develop, you do you and you'll be just fine.
Exactly. The author even says he doesn't understand why someone would be fired for teaching a junior everything they know as long as they are a good enough programmer. Career management is completely othorgonal to programming ability, and career progression is surely a function of both, with luck thrown in.
The irony being that you've just provided another alternate list!
I think your comment makes good points though. The OP makes a lot of good pints as well. The bits of humor make it clear to me that it's not supposed to be taken literally. This is just a list of indicators.
"Listen to yourself, constantly improve and have a thirst for knowledge..." is pretty general advice. He explicitly says it's not specific to being a developer. I don't think, "constantly try and better yourself" as an over-arching life motto is any way equivalent to "buying plushies at ThinkGeek."
Side note, I'm pretty sure the author stole half of his various bullet-points from the DSM's diagnostic criteria for autistic spectrum disorder.
The tone of the article was so tongue-in-cheek, that I am surprised by the seriousness and vitriol in the comments.
Obviously, to me and the author at least, this isn't like an actual guide to being a good programmer - this is a semi-autobiographical, kidding essay about the subject.
That's how I read it at least - I expected to agree with some points and not with others, and empathize with a fellow soldier. It tweaks a lot of whiskers because he invariably badmouths something you like or props up something you hate. For me, I was scoffing when he said tabs vs. spaces wasn't important.
I think you'll find that HN, and our profession in general, has a disproportionate amount of people with a strong tendency to take things very literally and overlook the intended humor.
Especially when it comes to matters they take very seriously.
I agree, I laughed a few times while reading. A lot of the points are insightful in some regards and just blatantly wrong in others. Going to thinkgeek doesn't make you a good programmer, it just makes you a nerd.
A lot of what he wrote categorizes people into boxes, we tend to like boxes, but not to be put into them... Some of his points, if abstracted, are very insightful.
This one is so completely backwards it makes me wonder if it is somehow tongue-in-cheek. The best programmers are masters of compromise. In the real world, nothing is perfect.
> * Substantial refactoring on the eve of a deadline
If a team member did this regularly I'd have to recommend their termination.
It is true that we shall not be able to reach perfection, but in our struggle toward it we shall strengthen our characters and give stability to our ideas, so that, whilst ever advancing calmly in the same direction, we shall b e rendered capable of applying the faculties with which we have been gifted to the best possible account - Confucius
Of course, we all do this. The the perfect form exists in all of our minds, even the novice, and we keep this with us as we work. However, the author of the article is advocating reckless behaviour and poor judgement in pursuit of actually achieving it.
A more charitable reading of "Preference for dismissal over compromise" is that you prefer (and respect) that the powers that be picks either your or the other solution instead of crafting a half-assed compromise that satisfies neither party.
There are two kinds of good programmers. The first kind are good programmers to hire; they get the job done and ship a working product on time and budget. The second kind are programmers producing outstanding awe-inspiring code in their spare time after working on it for eons and rewriting it from scratch every time they had an insight how something could be generalized to unify different aspects.
There are almost no men that are good programmers and good programmers.
Totally. A disturbing number of things on the list are cultural or tribal signifiers rather than things that have anything to do with being someone who can get stuff done, get it done well, and get it done in a reasonable amount of time (which is a big part of my own definition of "a good programmer"...maybe that's part of my disconnect with this).
When interviewing people a common pitfall is to subconsciously look for stuff like this, which is really bad because that means you're interviewing for friends rather than coworkers. It also means you're unfairly discriminating against people you can't immediately relate to on a personal level.
For an extreme example of this, look no further than ESR's version of the Jargon File. He basically extends his idea of being a good programmer to political beliefs and all sorts of unrelated things.
In fairness, having similar culture within a company may not be a bad thing. Windows programmers and Unix programmers can both get things done, but put them on a team together, and ... well, I'm skeptical.
"Doesn't become defensive when the boss mentions that they're looking for an off-the-shelf alternative to what they've been writing for the past few years"
Hits so close to home, I might have a bruise. My whole department went through the five/seven stages when we mentioned changing our main platform to another company's product.
After countless presentations of superior software, they went through the stages again. Finally, putting the idea on the shelf for a year, they went through the stages again.
It is truly the "can't see the forest for the trees" sentiment. Cost center programming is a job of fear for most. New hires, new software, new terminology, etc leads to blame and fear to the point of malice. Job security is their biggest fear; but their attitude towards 'new' prevents the business from moving forward and decreases their job security.
I really enjoyed this article. And I will admit that it is because I identified very much. That being said, I am 53 years old, and pretty much in demand as an embedded programmer. I don't have an ardinio, but I have multiple microchip demo boards. The kicker is , I just bought a bottle of silicone oil to attempt making my own silly putty. A few weeks ago I tried a few variations of corn starch modeling clay and wanted to step up my game.
A cubicle or desk populated with toys that came from ThinkGeek
I realize that it's a joke (or is it?), but I disagree with this. In fact, I have hard time to trust people that show any strong sings of group-belonging.
Very thoughtful and provocative comment. My initial reaction was agreement, but then don't we enjoy belonging to this group of hackers? Although you might argue there are no strong signs shown to the outside world.
(That said, trusting a developer with a bunch of ThinkGeek toys? Hell no.)
"At least 10% or more of their commits reduce the line-count of the project without adding new functionality"
It would be great if there was a git command to check that. Now that would be HN worthy. I skimmed the rest of the article and it seems to be typical link bait list
It seems unlikely that you would encounter someone who naturally reduced line counts while making code worse, but once it's being checked whether you're reducing line counts...
I've depressingly found, in recent years, that most programmers I've encountered can't be bothered to fix things that are broken, never mind stuff that isn't. I don't see a lot of people who are taking pride in their work anymore. It's a damn shame.
This list is highly speculative containing dangerous and self serving advice. I think the author lacks both the sources, data, and experience to make such blanket statements.
C. Lawrence Wenham was the lead architect, developer and Director of IT at FragranceNet.com and is currently developing a new personal finance app for the iPhone.
I'm not sure there is much actionable advice to be taken from this list (and I'm not sure it was the goal anyway), but that was entertaining to read.
There's a few obscure references that I got, a ton others that I didn't get, and even more points where I'm not actually sure there was a reference to get.
I don't think this list is what makes a good programmer. Maybe I've grown to look at programming as "problem solving" and "solution providing" to real world problems, and take the actual process of writing code for granted.
Why is an active Wikipedia account better than an active MDN or StackOverflow account?
Why does it matter if someone knows what Arduino is?
What if "eager to fix what isn't broken" means you get caught up in hip and new technologies that cripple your businesses utility?
ThinkGeek toys? Obscure books and songs?
> Has a habit of boring people to tears explaining something tangentially related to the news, such as the cockpit layout of the Airbus 330
No. Just no, please stop.
I'd take "Good interpersonal skills and a disinclination towards generalizing people" over this list any day.