Signs that you're a good programmer
sites.google.com
sites.google.com
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.
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.
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.
"Today The White House issued a statement..."
This is not:
"Has an active Wikipedia account"
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 think everybody is taking this article both too seriously and too literally. Sadly there is no known cure.
Following a general pattern is still a pattern. Patterns aren't as interesting as anti-patterns.
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.
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.
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.
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.
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.
Especially when it comes to matters they take very seriously.
> * Preference for dismissal over compromise
> * Contempt for delivery dates
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.
There are almost no men that are good programmers and good programmers.
There are many different kinds of programmers.
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.
I feel like hacker is a subset of good programmer.
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 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.
(That said, trusting a developer with a bunch of ThinkGeek toys? Hell no.)
Why not?
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
I could reduce the line count on many files and increase complexity and reduce maintainability.
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.
Wait, does that make me meta-dismissive? How far does this rabbit hole go?
You have a habit of building things that people find useful or valuable (including other coders).
END OF LIST
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.
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 would have said "have a job as a programmer".