How to Recognize a Good Programmer 529
KDan writes to share an article he has written about what some of the key factors in recognizing a good programmer. "It's not as easy as it sounds. CV experience is only of limited use here, because great programmers don't always have the 'official' experience to demonstrate that they're great. In fact, a lot of that CV experience can be misleading. Yet there are a number of subtle cues that you can get, even from the CV, to figure out whether someone's a great programmer."
Sweet! (Score:5, Insightful)
Useless article (Score:5, Insightful)
And what is this about startups failing because the business people hire crappy programmers. Has anyone considered that maybe selling pet food over the internet is simply less efficient that the distribution system build by companies like Wal-Mart?
Re:Useless article (Score:5, Insightful)
My definition of a good programmer isn't the worlds most talented codemonkey, but rather the guy that can set the boundaries of the project firmly and manage the expectations of client/boss. Most of the programming nightmares I've seen have nothing to do with programming skills, but mainly because the project went all over the place due to a lack of explicit boundaries.
When people start going "Yeah, that's neat, but if you can put that widget in there, maybe you can put this other widget that Bob in Accounting thought up yesterday afternoon" you know the project is in trouble.
Re:At least get a CS degree (Score:3, Insightful)
They're out there, but scarce.... (Score:5, Insightful)
The Title is Way Off the Mark (Score:5, Insightful)
Re:WTF is a CV? (Score:1, Insightful)
CV is a Latin abbreviation which stands for 'Curriculum Vitae' which means (according to Wikipedia) 'Course of Life'.
Two things (Score:5, Insightful)
However, two things came to mind. The variety part. Yes, its good. I personally am fluent in just about all programming environments known to man, more data storage techs than I can count, too many business types, and things vastly different, like business intelligence and biology (I started as a programmer for R&D biotech softwares).
The catch is, that tends to show that you're too much everywhere. You can take one "enterprise" stack, let say J2EE or
Those are things that makes the difference between a project taking a year, and one taking a month. Once I realised that (and people hiring know this just too well), I specialised in a 2-3 technologies (specialising in just one isn't enough to keep track of the evolution of the field), and I've been a much better developer since then.
You need to have a broad VIEW of the field, but still be specialised, to be efficient at what you do. Knowing 10 technologies equaly well means that you don't know either of them at their peek.
Secondly, the certification thing. We all know certification means crap, I agree, but like the article does state, it helps hiring people to spend less time interviewing you about the obvious. If you say you're Java certified, they can only ask 2-3 questions to make sure you truly are, and forget about testing you on a Java hello world. That way, they can spend more time testing you on the important stuff, like actual development expertise, as opposed to syntax knowledge. Also, having a lot of certifications, if you can prove you didn't brain dump them, can go in the "broad knowledge" and "passionate" part. If you have 12 certifications with 12 technologies, well, it shows you like knowing your stuff (those tests can sometime ask for pretty pointy things...)
Passion != "Spare Time" (Score:5, Insightful)
The idea that not programming in your spare time makes you a poor programmer is abjectly false and amazingly stupid considering the amount of complaints within the industry about working hours, laundry-list job listings, industry only for the young and unmarried, etc.
I've known too many counter examples to debunk this; people who would talk on end on how "great" and wonderful a technology was only to mis-use it to the detriment of the business and the customer. People who had no lives; bragging about what they did at home, what OSS projects they were working on only to get fired for not being able to understand or structure requirements, not having enough domain knowledge of the industry they were working in, or not being able to meet the customer's needs.
Frankly, I work 50+ hours a week and the last thing I want or feel a need to do is look at a f*cking computer when I go home. And this comes from someone who got a Master's in CS while working full time; led implementation of new technologies and languages within the group.
It sure as _hell_ doesn't mean I don't have passion for what I do.
Why do good programmers need strong opinions? (Score:3, Insightful)
Re:At least get a CS degree (Score:5, Insightful)
That said, I don't really know if he's right anyways. Everything
C++'s main advantage is the same as Microsoft's: it's everywhere, there are just so many libs out there and there exist language bindings for just about everything. We don't really know anything about the lifespan of computer languages yet. Just when I thought it's finally dead for good, I heard about a release of a new version of a FOSS Pascal compiler.
And we're waaaay offtopic here...
The problem with recognizing people. (Score:1, Insightful)
`I shouldn't know you again if we did meet,' Humpty Dumpty replied in a discontented tone, giving her one of his fingers to shake: `you're so exactly like other people.'
`The face is what one goes by, generally,' Alice remarked in a thoughtful tone.
`That's just what I complain of,' said Humpty Dumpty. `Your face is the same as everybody has -- the two eyes, so --' (marking their places in the air with his thumb) `nose in the middle, mouth under. It's always the same. Now if you had the two eyes on the same side of the nose, for instance -- or the mouth at the top -- that would be some help.'
`It wouldn't look nice,' Alice objected. But Humpty Dumpty only shut his eyes, and said `Wait till you've tried.'
Re:Hope this makes it. (Score:4, Insightful)
Baloney (Score:5, Insightful)
Negative indicators:
* Programming is a day job
excuse me, I am a really good programmer, did the whole 9 yards growing up as a stereotypical geek (not into sports, into programming way before it was fashionable to do so, from basic, to turbo pascal, to z80 assembly etc.), I lived and breathed programming and computers for many years of my life, however now I am in my late 30s and I try to have a much healthier work-life balance, I don't see why this should be a negative at all.
If I wasn't working at a computer dev job I would probably be coding a bit for fun, but there is no way that nowadays you could get me to talk shop for hours just for the fun of it.
Also
In fact, the great programmer will be the one talking your ear off about a new technology that you haven't even heard of, explaining to you why you must use it in your business, even if none of your staff knows how to use it. Even if it's a technology he doesn't know how to use yet.
gimme a break, for me this would be a huge no-no, it would be the hallmark of somebody going after every possible latest fad, instead of focusing on proven tools for the job. Yes, there ARE cases where the bleeding edge is needed, but they are the exception rather than the rule: if I have a business I want code that is mantainable, and that, if the 'wiz developer' gets hit by a bus, is understandable by others (read, it's not such a niche skill that if I lose that person my business will fold because it's impossible to find a replacement).
Good programmers will have a tendency to talk your ear off about some technical detail of what they're working on (but while clearly believing, sincerely, that what they're talking about is really worth talking about). Some people might see that as maladapted social skills (which it is), but if you want to recognise a good developer, this passion for what they're doing at the expense of social smoothness is a very strong indicator.
this is another totally bogus criteria: in nowaday's workplace soft skills (being able to work as a team expecially) are just as important; gone are the days of the single programmer in his ivory tower producing code that only himself can understand. You need to have a team, and if I have to choose between person A who is, say, a programmer worth 100/100 but has 0 social skills, and person B who is, say, worth 80/100 but gets along with everybody, I will choose person B every time. A gelled team is greater than the sum of its parts, but you can't gel a team full of primadonnas and socially maladapted people.
If you are such a 'smart' programmer you will realize that 'programming' social interactions is as important as programming computers, and you will apply your skills to that as well, making your workplace a lot better and likely improving drastically your career prospects.
If you're hiring for a small business, or you need really smart developers for a crack team that will implement agile development in your enterprise, you should disregard most formal qualifications as noise.
give me a break, being smart and having no formal qualifications is a lot worse than being smart AND having formal qualifications. I have a M.Sc. in Electronic Engineering: have I used anything I learned in university in my career? Not at all. Have those years broadened my horizons, introduced me to a lot of different concepts and methodologies that made me a much, much, much better programmer than I was before? You bet. Your 'crack team in agile programming' will likely end up implementing something O(n^3) (because they have no clue about computational complexity) while your university educated buzzword-averse reliable programmer will give you O(n^2) or even O(n log n) because they've been there and done that many times before in a lot of different other contexts.
THESE to me are the signs of a great programmer, experience, good grasp of architectural con
Re:it's easier than you think: (Score:3, Insightful)
Re:Baloney (Score:3, Insightful)
Rule #1, an ego doesn't make you a good programmer.
Re:it's easier than you think: (Score:5, Insightful)
The best programmers I've worked with are the ones with a diversity of interests, are very capable of interacting with others. Our field demands that we can translate back and forth between business-speak and code. If all I wanted was a code monkey, I'd pick one up from Bangalore.
Re:waste of time (Score:3, Insightful)
I can't agree with all of this (Score:5, Insightful)
He lists as a negative indicator *anyone* who considers programming as a "day job." I know quite a few programmers who consider programming a day job. They come into work at 9, they work for 8 hours, they go home at 5, and then they do something entirely different. But the code that they produce while at work is brilliant. They are extremely bright people who enjoy programming, but don't live and breath it. They would rather do something else while not at work.
He lists as a positive indicator *anyone* who is passionate about technology. Sorry, but I've met a lot of people who are bubbling over with enthusiasm about programming, but can't code worth shit. These are the people dive headfirst into a programming job without any thought of design or architecture, and you end up with an application that uses half a dozen bleeding edge technologies, all bundled together with virtual duct tape, that disintegrates at the first input exception.
Indeed (Score:3, Insightful)
what killed most of the startups in the e-commerce business back in the 90s, it was bad programmers. A lot of those companies were started by business guys who thought the way startups worked was that you had some clever idea and then hired programmers to implement it.
Ummm, if you start a business thinking that simply hiring programmers to implement your clever idea would make a successful business, you've already failed. If you want to start a successful business, the first thing you have to do is actually know how to run a business. Having a clever ideas makes you clever, maybe, but it doesn't mean you know jack about managing a business. Hiring bad programmers is simply the natural conclusion of somebody that didn't know what they were doing in the first place.
Tunnel Vision (Score:2, Insightful)
Re:Useless article (Score:3, Insightful)
Once you've done that you'll be a lot further along at being able to tell for sure if someone is worth working for/with. Of course that assumes they're willing to let you look at these things. But even if you can't actually look at them, it will give you a lot of insight into good questions to ask during an interview. EG: "what's your 5 year plan for funding?" "What is your market?" "Who is your anticipated competition?" If a person can't answer those 3 questions at least, you need to walk away because they haven't thought the idea through enough.
Re:it's easier than you think: (Score:5, Insightful)
However get a couple of really great guys who understand each other then you will get superior code in a fraction of the time.
Code that's worthless because it will have to be thrown away when the requirements change and no-one knows how to patch it.
Re:The Title is Way Off the Mark (Score:2, Insightful)
Updated:
"Fear not the programmer with lots of languages used only at the basic level, but respect the programmer who uses few languages but knows them well."
The Python Paradox by Paul Graham (Score:5, Insightful)
Paul Graham
http://www.paulgraham.com/pypar.html [paulgraham.com]
August 2004
In a recent talk I said something that upset a lot of people: that you could get smarter programmers to work on a Python project than you could to work on a Java project.
I didn't mean by this that Java programmers are dumb. I meant that Python programmers are smart. It's a lot of work to learn a new programming language. And people don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know.
Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I'll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don't learn merely to get a job.
Only a few companies have been smart enough to realize this so far. But there is a kind of selection going on here too: they're exactly the companies programmers would most like to work for. Google, for example. When they advertise Java programming jobs, they also want Python experience.
A friend of mine who knows nearly all the widely used languages uses Python for most of his projects. He says the main reason is that he likes the way source code looks. That may seem a frivolous reason to choose one language over another. But it is not so frivolous as it sounds: when you program, you spend more time reading code than writing it. You push blobs of source code around the way a sculptor does blobs of clay. So a language that makes source code ugly is maddening to an exacting programmer, as clay full of lumps would be to a sculptor.
At the mention of ugly source code, people will of course think of Perl. But the superficial ugliness of Perl is not the sort I mean. Real ugliness is not harsh-looking syntax, but having to build programs out of the wrong concepts. Perl may look like a cartoon character swearing, but there are cases where it surpasses Python conceptually.
So far, anyway. Both languages are of course moving targets. But they share, along with Ruby (and Icon, and Joy, and J, and Lisp, and Smalltalk) the fact that they're created by, and used by, people who really care about programming. And those tend to be the ones who do it well.
Re:The Title is Way Off the Mark (Score:5, Insightful)
Excessive use of computers may imply passion, but it also implies early burn-out for most coders I've met. The ones who last and are also good, by contrast, are just the opposite. They work hard at work, and they leave it alone when they're at home. Of course there are exceptions to all rules, and certainly to anecdotal evidence, but that's been my experience thus far.
Re:Indeed (Score:2, Insightful)
OMG you are kidding right? (Score:5, Insightful)
This comes from experience, I work on multiple networks and have been through more than one web migration. I tell ya, the one thing that bugs me most is short sidedness, these programmers who are very intelligent and write scripts to prove to the world that they are smart. However they forget to document because why should you document something that works? You take those 20 line snippits and after 3 years or so you have about 100 of them in your environment, something breaks and all hell breaks loose for days because your replacement has to grep through all your code while you are unavailable.
Standard, Commented, well structured code is what I look for. You show me code examples that are easy to read and commented well. Also show me a positive attitude and have musical talent and you are hired.
Re:At least get a CS degree (Score:4, Insightful)
You've never used java before, have you?
Re:it's easier than you think: (Score:4, Insightful)
You're fired.
If you aren't writing clear and understandable code, I don't want you on my project.
Re:it's easier than you think: (Score:5, Insightful)
Re:They're out there, but scarce.... (Score:3, Insightful)
Programming languages are languages. If you understand them, and you're not just shoving out snippets, then a programmer is a linguist.
So a programmer is a person that spends a very considerable portion of their day thinking of how to say things to a very, very stupid entity that doesn't understand his native language (a computer). So he has to have fantastic clarity of thought in the language translation department - especially if he's regularly using more than one programming language.
The only notable exception to this is low-level programming - assembly and pure C. That contains so little actual structure in and of itself that it more closely resembles a math construct than a language. So I think you can get pretty good at the low level stuff without affecting your writing capabilities.
Re:it's easier than you think: (Score:3, Insightful)
What truly makes a great team is if you can get a few naturally shy, great programmers to find out that they actually share interests with some and can accomplish great things then. And you're right, intelligent, like minded people working on a common goal are very capable of interacting with each other. Throw in the beautiful office assistant though and you'll see what we're truly made of.
Re:it's easier than you think: (Score:5, Insightful)
He/She says:
Unfortunately, the code you write *must* be understandable by other coders otherwise you're worthless to a development team. Assuming you're really so "good" that you can write inexplicable code that's also so awesome that it's used in the real world with no problems, then why are you applying for a job?
He/She says:
Can I see this 20 line snippet and your proof of its correctness?
He/She says:
Why don't you know the difference between "You're," and "Your?"
He/She says:
So... Given that you "have yet to find someone who can understand" your "truely amazing code," how would you propose we find these other "really great guys who understand each other," (but, apparently, not necessarily each other's code) in order to obtain "superior code in a fraction of the time"?
Ow. Your awesomeness hurts my brain. I submit.
Re:Sweet! (Score:1, Insightful)
Can I find people that fit these bullet items that are good programmers? Sure, but I can also point to some really bad programmers that fit this model in nearly every way also.
Human behavior is not this cut and dry. Of course this is to be expected when you see so many MBAs jumping from fad to fad. After all, while he may not have an MBA, the author is basically a suit now
Re:Hope this makes it. (Score:4, Insightful)
I remember using "ON ERROR RESUME NEXT" in some of the later BASIC variants because the default error handling does a full stop on an application on any form of error, whether it's unrecoverable or safely ignorable. At a certain point, you don't care about failure - just fire and forget.
Re:it's easier than you think: (Score:2, Insightful)
Re:Indeed (Score:2, Insightful)
Re:OMG you are kidding right? (Score:2, Insightful)
To pop the stack, I personally have no idea whether my code meets "best practices" or not. Since I'm totally in control of the software development where I work, there's no one I need satisfy with code statistics nor any reports to write -- but what I do must be accomplished on a timely basis, deployed to end users in a guarded but reasonable pace and not cause clients' displeasure towards the company in the process. This may sound easy, but it's anything but. For one thing, you cannot maintain a large codebase (current main project is about 1/4 million lines) without it being appropriately documented. Or, at least, not with any speed you can't. Though I don't follow any set guidelines per se, I learned very early on that it was much easier to come back to something months later if you left yourself enough breadcrumbs to recapture the thought path that led you to the code in the first place. Some functions have reams of notes, others have almost none. Yet, when I can look over lines written ten (or even 20) years ago and work with it rapidly, that tells me it was documented well enough. Sure, I've seen policies of "comments every N lines" and such, but most of those are a matter of someone opinion (well informed or not) and it's the results that really count. And in the case of user interface design, I use the tried-and-true method of watching end users actually using the system and take note of anything that seems to slow them down or add to their confusion. As a result, there is very little training required as the system just fits the way they need to do things. But, I digress from the point.
To my own observations, those people that proclaim themselves "great programmers" the loudest are the ones least likely to be so. Those that I consider "decent" may not proclaim their virtues, but they are quick to be personally offended when their code is challenged. This shows to me that they are passionate about their work and care enough about it to back it up with their reputation. And that's the kind of person that I want working for me.
Re:it's easier than you think: (Score:1, Insightful)
I have yet to find someone who can understand what it does and how it does it. Its voodoo to everyone.
True brilliance is when everyone else looks at your code and goes, "Damn, why didn't I think of that!" Because it's clear, concise, and after-the-fact obvious.
If you can't do it clearly so everyone can understand what you're doing, you're not as smart as you think. And that truly wouldn't surprise me.
Re:OMG you are kidding right? (Score:3, Insightful)
Comments should tell you WHY code does it.
If a code monkey can't tell WHAT the code does they need a better book.
No book tells you WHY the code is the way it is, for multiple versions of way.
Re:They're out there, but scarce.... (Score:3, Insightful)
- As one of the elite few programmers who does
"Elite few programmers" is ungrammatical and superfluous (an elite is a small group by definition); "Who does" refers to a single person, but the phrase and context make clear that you are speaking about programmers in general, so "As one of the few programmers who do know how to spell" is better.
- Add "I" before "thank you", or write "A thank you
- Add a comma before "I suppose".
- The hyphen after "However" should also be a comma.
- you should put hyphens or commas around "I think".
- Remove the comma before "and" or add one before "but".
- "- at a time
Re:Hope this makes it. (Score:4, Insightful)
>And what do you expect to do with a failure? printf() something to the console?
Just to be annoying: you can exit with a value different from 0, indicating that there was an error.
But in the real world, this is rarely done, should it be?
I don't know..