Slashdot Mirror
How to Recognize a Good Programmer
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."
Now I know exactly how to manipulate my resume to look like a good programmer.
It's easier than you think:
After sufficient interactions like these with a good programmer you really should be able to recognize him (or her).
(Appropriate apologies to Steve Martin for shameless borrowing of his "How to get a million dollars, and not pay taxes" routine.
How to recognize someone who would give good advice about how to recognize a good programmer ? I think the C.V. can be misleading : the " official " experience at hiring programmers does not necessarily mean the the person would be apt at giving good advice about hiring programmers.
Programmers should have to take and pass the BigInt code writing test that I had to take in AP Computer Science class. BTW, I failed it.
I would be much more interested in an article that tells programmers how to recognize good business people. I don't want to waste five years of my life implementing some POS idea by Joe Random MBA that is never going to make a dime. I am extremely hesitant to go work for any startup unless I personally know the people starting it and know that they have a track record of making good business decisions. From my experience, many business people feel the same way about technical people.
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?
I am with Bjarne on this one.
Bjarne Stroustrup, creator of the C++ programming language, claims that C++ is experiencing a revival and
that there is a backlash against newer programming languages such as Java and C#. "C++ is bigger than ever.
There are more than three million C++ programmers. Everywhere I look there has been an uprising
- more and more projects are using C++. A lot of teaching was going to Java, but more are teaching C++ again.
There has been a backlash.", said Stroustrup.
Am I going to feel real stupid when I see the answer?
tip1: don't let your page get slashdotted after 5 comments :)
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
Cache: http://64.233.183.104/search?q=cache:-PJEtsLZfV8J:www.inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer/+hire+good+progammer+site:inter-sections.net&hl=en&lr=lang_en&client=firefox-a&gl=uk&strip=1
bang goes my karma... again...
If you want a good programmer, if they speak either Hindi or Chinese, go for it.
They obviously can't find a good sysadmin that can project future load on their servers and scale accordingly ;)
Or maybe they can, and the sysadmin can just blame the evil bean counters.
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
If being a good programmer includes knowing what a CV is, then I'm screwed.
Ah, it's the same as a résumé. I'm good now. Thank you, wikipedia.
-Dave
I think this guy's take on things is totally right on. (Disclaimer: I suppose that's because I get top marks on his scoring system)
- The Kessel run is for nerf herders. I can circumnavigate the entire Central Finite Curve in a lot less than 12 parse
After 15 years in IT, I've noticed that programmers as a lot typically cannot spell even the most basic 3-syllable words, so when you find a coder who actually spells properly get out your checkbook. Like it or not, being able to spell is a significant indication of character, especially the propensity for paying attention to detail (a trait you certainly want in a professional coder).
"To err is human, to mod Funny divine."
I think the author of this article is way off the mark. The title should have been "How to recognize a programmer who's likely to work 18 hours for very little pay." Almost all of his points boil down to the fact that he thinks all good programmers are the ones that can pad out their resume with 900 technologies and eat, sleep, and breathe programming. I can't even begin to tell you how many absolutely amazing C++/Java/Python programmers I've met who I can almost guarantee have never even touched Ruby before. Just because a programmer doesn't go out of their way to try out every single new technology that hits the market doesn't diminish their abilities at those they do use. The author of this article is clearly looking for a programming work horse that he can throw unreasonable expectations on and toss new technology buzz words at until their head explodes. Guess that's probably what you need when you plan a startup and only want to hire one guy to do the work of 10...
According to my own self-analysis, I fall into the "Good Programmer" category. Go me!
... there's room for a few more languages in there. And maybe a few technologies along the way. :)
However, I still need to improve in a few areas; namely, my "variety". PHP, C++, Java, C#, BASH, VDS
No MSCE, you say? No thanks! We'll take this trained monkey over someone who actually groks computing systems and associated software.
Ask them if they are a Slashdotter. If they say yes... move on and ask the next guy.
"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?"
By that metric everyone who doesn't have a duplicate of Walmart's setup is a failure. Now you know why everything's headed for China.
"I would be much more interested in an article that tells programmers how to recognize good business people."
When was the last time anyone here interviewed the company they ended up working for? Good resume, right?
The best I've met have degrees in English, Physics, Engineering, or Math. They then focused on the programming aspect as needed to create tools that helped them and their peers to streamline their work. As that focus became more of a primary job function, they honed their skills and methodology around maintainable code, version control, security, documentation, reusable modules, etc.
I'm guilty of being one of these types myself, but have since moved up to project management around security type stuff after having taught those who replaced me the things that I learned through experience.
Ask him if he's a good programmer in klingon
... I am brushing my teeth in the morning in the mirror, grinning back at me, saying what a great programmer I am. :-)
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
That list is very, VERY good in my opinion, if obvious (but not so obvious to HR people).
.NET, and even if you worked with them constantly for the next 10 years, learning something new every day, you'd still have more to find (and by more, I mean significant things). Thats why once, in .NET, I coded some tool, it took let say 50000 lines of code, then learned about some obscure feature that could have reduced it to 500. Yes, 500.
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...)
First, there is razor sharp intellect and subtle, erudite wit. There's the way he has of getting right to the heart of matters, his effortlessly quick and authoritative opinions on an astonishing array of subjects. Of course it is conceivable that some might miss his unconventional but undeniable good looks, although that might stretch the bounds of credibility.
But in a pinch you can go with the way that he often goes about wearing your pants or the fact that he stares back at you from the mirror every morning. That's a dead giveaway.
Of course if that fellow's unavailable, most people end up settling for somebody who, while utterly lacking his extraordinary qualities, nonetheless agree with as many of his opinions has he has cared to express.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
The first category is crap; "passion" is often mis-identified (as in the case of the article) and linked to what people do in their spare time.
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.
I was going to read the article but I didn't because I'm too afraid that there's going to be pictures of what good programmers look like. Let's face it, we're not the chic-est demographic on the planet.
This is a serious question. I totally agree on every point except that a "great programmer is uncomfortable using a technology he doesn't feel is right". Two developers can be great but be completely at odds. Wouldn't the 'better' programmer say, "Perhaps I don't feel right because I don't know enough about it?" Strong opinions about certain technologies, in my experience, signifies a degree of ignorance and imbalance; and they didn't learn it correctly, extensively, or in the right context. In my opinion, a great programmer is more open-minded, allowing a non-biased filter to consider technologies he doesn't "feel is right." Am I right?
The list seems to be lacking one of the more important ways of identifying a good programmer -- the uncanny ability to quote from the entire works of Monty Python.
What is this, Digg? The content of that blogspam is obvious. Good programmers, the revelation goes, are interested and excited by their fields, and intelligent self-starters.
Garsh!
Is there a field where these qualities wouldn't indicate a superior performer? Obviously you want to hire someone engaged by the subject matter on a personal level, obviously it would help if they had some brains to back up their passion, and obviously a demonstrated knack for going above-and-beyond is a good sign.
I'm fairly sure still would apply to engineers, pilots, designers, editors, choreographers equally as well.
These stories are free but worth money.
`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.'
You know, the one I worry most about is in terms of self-evaluation is "Self-teaching and love of learning", at least when in terms of technology for its own sake. Its sort of an unfortunate side-effect of "Hidden experience"; few flavor of the month technology on the server side seems to bring much new to the table, and so the learning curves just annoy me without a good promise of effort/reward ratios.
Sort of like my disinterest in OSes, and PC hardware; I want that stuff to just get out of the way of the interesting interaction work to be done.
---
Also, yeah, I tend to be a lot less worried about finding hidded gems of programmerhood than avoid the good-resume bozos.
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
someone who knows what software security is and how to code securely.
IT is Dead. The industry is Shot Join Others Who Feel Your Pain http://www.internalstrife.com/
Before I started working, ie, while I was in college and was looking for a job post college, I had quite a few little projects going. I had a small application that joined together multiple P2P protocols (BT and DirectConnect, iirc). I had a little game in the style of Escape Velocity (the mac classic). I had my own chat channel bot that could work with any chat protocol you built plugins for.
Then I got a job, and found out my interest in these little projects dwindled off to zero. After 8 hours of programming, and in total a 10 hour day, between lunch and a commute, trying to get some sleep, enjoying other hobbies, and attempting to keep a somewhat active social life there just wasn't time or interest in working on them.
Now I'm living in my own house and theres even more tasks that need to be completed.
How many hours does this guy think there are in a day if he is defining a bad programmer as someone who only programs as a day job? Does he live off cheeto's in his parents basement?
"Give someone a program, frustrate them for a day... Teach someone to program, frustrate them for a lifetime."
In the animation industry animators put together demo reels which show all their best work. I imagine programmers could do sort of the same. They could cut together all their best pieces of code and set it to some techno music.
I have nothing compelling to say
Thank you for using CV all over the summary and failing to define CV in the summary.
"Love heals scars love left." -- Henry Rollins
My experience suggests exactly the opposite. Those programmers seem to be insanely smug and completely infallible in their own minds. At least, if an American programmer makes a mistake, the American programmer will own up to it. Indian/Chinese will just argue incessantly about how the bug couldn't possibly have been theirs - even when it's just faster to fix the bug than it is to argue about it.
from the article, what's the #1 'negative'?
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
-- the cake is a lie
I always thought the Fizz Buzz test was quite interesting, never used it though.
When hiring for web developers, I tend to ask where to put validation code for form input data. I hope to hear:
* on the client before the form is sent (usability)
* on the server (in case the client is fuzzing)
* in the domain rules / check constraints of the db server (in case data comes from somewhere other than your app)
But I never do. It's the candidates who haven't heard of the 3rd validation who don't make, and those who can argue their corner well who do.
I guess the think to do is to develop your own set of questions to elucidate a candidate's strengths and weaknesses without trying to trap them.
I once failed an interview for being unable to remember what the individual letters in ACID mean. I had forgotten what the "I" meant.
They who would give up an essential liberty for temporary security, deserve neither liberty or security - Ben Franklin
Back in the 90s I observed that the best Unix Admins seemed to all like King Crimson, and that most of the good Perl people I knew liked The Who. I doubt if anyone could prove any sort of direct correlation here, but it is a touchstone that has served me well enough for over a decade.
Manipulating your resume is a waste of time: yours and your prospective employer's; people will figure it out when they interview you.
A good programmer will try to refactor the bullshit out of your business processes. If you, Mr. Businessman, *are* the bullshit, you want to stay as far away from good & great programmers as possible.
All ideas^H^H^H^H^Hprocesses in this post are Patent Pending. (as well as the process of patenting all postings)
slasdot'ed = DNS'ed?
With green folding applause.
But no, more seriously...
A good programmer is interested in what makes a feature "neat", a great programmer is interested in what makes a "neat" feature inapplicable to a problem.
Once you have determined that the person in question can program at all... (as in having asked him _once_ to code a very simple algo, with none of the stupid "I asked a stupid question to see if he'd catch it and correct me" interpersonal gamesmanship) you need to determine only three facts:
1) is the programmer faster than his own ability to reason? Plenty of "passable" programmers can write far more code than they themselves can comprehend. You DO NOT want the guy who goes into a zen trance and spews code that he cannot explain or defend or debug.
2) is the programmer capable of communicating his ideas effectively in venues other than code. This isn't _just_ the comment thing, but the comment thing is part of this. If you want the programmer to be of any value, and a "great" programmer is measurable solely by his value, then he has to be able to do more than crawl off into a hole and return with code. Programmers who cannot work and play well with others and who cannot colaborate on a project, limit their applicability and value to "functions only within the bounds of what will fit in the front of their attention span at any one moment."
3) how well can the programmer cope with being wrong, in fact or just in inference? We are all wrong and code is always broken somewhere. A programmer who cannot face being told he is wrong, cannot face being _proven_ wrong. A programmer who cannot be wrong with aplomb and without denial or tantrum, is a worthless programmer, and worthless programmers are both "not good" and "not great." In short, code full of ego is code devoid of merit.
There are exceptions to each of those guidelines, but there are no valid exceptions to all of those guidelines at once that are worth considering as worthwhile.
There are secondary warning signs:
-- Cannot work and play well with non-programmers.
-- Doesn't think there is _any_ value to social norms.
-- Always talks about what _they_ invented, never talks about what someone else invented.
-- Thinks everybody else's code is crap (with the caveat that they think none of theirs is crap)
-- Doesn't keep up with ongoing literature or developments in the field.
-- Can tell you how (language X) sucks but cannot tell you who (language X) is perfect for.
-- Says things like "I only program in C++" (or Java, or PERL, or Python). "I predominately program in C++" (etc) is okay, because specialization is often a sign of advanced experience, but beware it can just as easily be a sign of a one trick pony. This is a tough distinction to catch sometimes.
-- Doesn't read/cant tell you the last book he liked or hated/has no non-computer related stories or experience. Computers model real things, be they accouting practices or particle physics. A programmer who only thinks about programming or computer games will quickly be out of his depth when brought to confront a real problem.
-- Cannot laugh at themselves/too eager to laugh at others. A general symptom of someone who will limit every thing they engage in (not just a computer programmer metric, apply that to everyone.)
-- Cannot unroll a loop. If they cannot explain why "while (X) Y;" is identical to the sequence "if (X) Y; while (X) Y;" and then they cannot explain how to partially unroll a loop so that you get "A; B; while(F) { C; D; A; B;} C; D;" from "while (F) {A; B; C; D; }" then they have never learned the mental and computational "origami" necessary to re-envision or re-evaluate the problem presented into a "better" solution.
-- Isn't interested in what "the new guy straight out of school" has to say about what is happening. Thus they will be unable or unwilling to see when the new guy is making a mistake, and they will be unable and unwilling to entertain
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
What I think some "I would like...[insert profession here]" is that one first must start with a good person and no I don't mean that just in a moral or ethical way (important as that is). Give me a good person and I can build any kind of specialist. Give me a bad person and it will not matter what I put on top.
He can re-program a Tram system with a remote control.
Just crack a can of Red Bull and wave it around. If he starts sniffing the air and looks more awake you've probably got a good one.
Some of the points made in this article are good, but a couple are way off the mark.
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.
Life is like a web application. Sometime you need cookies just to get by.
I started reading the article but when I got to this bit I realized they had nothing useful to say:
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.
This sig has been temporarily disconnected or is no longer in service
For security, the MD5 hash of this message and sig is 09f911029d74e35bd84156c5635688c0.
I divide programmers into 3 groups: hackers, academics, and professionals. Imagine you try to read someone's code, and can't figure it out after a reasonable effort. You complain to the author, and they respond with:
academic - "Take a class."
hacker - "You're stupid."
professional - "I'll clean it up."
I know that's not a bullet-proof division, and of course this being slashdot someone will give me a lesson on "hacker" vs "cracker" and the general beauty of the programming art and whatnot. But I find these divisions tend to hold up a lot at work.
-Jeff
Please learn the difference between a dissenting opinion and a troll before you moderate.
It's Latin
In the interview, on paper without access to a computer, complete this C function without making any additional function calls (i.e. no strlen, no malloc).
/* Reverse the contents of the string buf. E.g. abcde becomes edcba. */
char *reverse (char *buf) {
}
Try it. Sure you know how to do it. Any freshman CS major should know how to do it. But on the spot its harder than you expect. It may not identify you as a good programmer, but its remarkably effective at weeding out the poor ones. Its also pretty good at making them feel foolish for having wasted your time with a bogus resume.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Write simple lists of ways to recognize good programmers?
I disagree with a lot of these points.
Reasonably good indicators
Ability to yammer on about a subject one's audience does not care about is a weak indicator of programming ability and a strong indicator of poor communication skills
OK
NO, NO, NO!
A good programmer has an open mind and makes decisions after thought, study, and understanding the users' needs; not based on some knee-jerk personal prejudice.
There is nothing wrong with taking advantage of company-sponsored courses. Taking advantage of classroom opportunities is just good time management (it can be easier to learn more, faster, in a well-taught course than in self-study).
So what you're looking for is a prima donna who will refuse to work in the environment you ask him to, and is insubordinate out of the gate? No. A good programmer will find the strengths of the technology you've picked and design a strategy that plays to those, rather than just telling you you've made a stupid choice and should have used his pet technology instead.
I don't know if it's ever a good idea to hire someone who "doesn't seem too smart."
That's a stupid criterion. Why someone starting programming is a lot more important than when
Inability to write a complete CV is hardly an indicator of competence. The author is biased in favor of people who started programming at the age of 9, as he did.
Nonsense; depth of knowledge is as important as breadth of knowledge. Ability to justify 50 different buzzwords on one's resume doesn't make someone a good programmer. It is a lot better to talk about the problems the candidate has solved, than the technology used to solve them.
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
I have developed what - I think - is the ultimate real life programming skills evaluation question list:
How many replica lightsabers do you own?
Tattoine has how many suns?
What did Yoda cook for Luke?
A positive outcome on these questions has proven to show a high correlation with programming ability. My staff tends to agree.
The Kai's Semi-Updated Website Thingy
Ya, for families that could afford it. Maybe this is less relevant now, but I didn't have a computer back in the day (nor did my high school, unless you count a paper terminal and connection via dial-up) and had to wait until university to start programming in ernest.
It must have been something you assimilated. . . .
Sorry, but I was not impressed with this article. First off, it was not bad programming that killed off late '90s ecommerce startups. It was flawed business models. In fact, I would say that unless you're selling software or some kind of technology service, it is highly unlikely that even a crap programming team will derail your firm if you have a fundamentally solid business model. So the backdrop for this article is flawed because it assumes that programming talent defines business success. Secondly, this article does not (as the title suggests) tell you HOW to recognize a good programmer. It attempts to define WHAT a good programmer possesses. There's a big difference between WHAT and HOW. If you want to know HOW to spot if someone is intelligent can be significantly more challenging than simply saying "I want someone smart". Furthermore, it misses one of the biggest points for a successful programmer - namely, Communication Skills! If a programmer can not articulate their understanding of the requirements and communicate back issues, concerns, and ideas, then you are taking a major risk. It doesn't matter that they COULD HAVE programmed the next BIG THING.... if they didn't understand the requirements, they will have wasted their time (and someone's money). And what about being able to work with the business and communicate ideas? How about time management and multitasking skills? I would hire a mediocre developer with solid communication skills and a willingness to learn over someone with top 1% programming talent who can't communicate a sentence properly. Ok, I'm done ranting.
The people that should read this won't. That's the sadest part.
We suffer more in our imagination than in reality. - Seneca
That people cannot adequately analyze a job application is not new, nor is it limited to programming. I wonder how long it is going to take people to realize that you cannot measure experience in terms of a duration of exposure to an environment?
/. will realize that the problems with Intellectual Property are not just confined to music and software/business process.
It would be nice if the people involved with hiring would analyze the "fruits of their labours" occasionally, to find out if they are actually working as well as they think they are. I think they would be surprised to find they stink. I think hell will freeze over first. Or,
Congratulations, you have hit on the method to ensure that you work with a bunch of mercenaries, not good programmers. The good programmers will have chosen the company that is working on exciting new stuff, with profit being the secondary motivation.
How to Recognize a Different Types of Programmers From Quite a Long Way Away
1. The C++ Programmer
The kinds of programmers I dislike are the clueless, the know-it-alls, the horders of knowledge, the spaghetti coders and the perfectionists. The real world is imperfect and governed by deadlines, budgets and system limitations. I don't care if someone is an amazing coder if they don't explain or allow anyone else to understand their code. I don't care that if 10 layers of abstraction makes the system perfect if it adds 3 months onto the deadline. I don't care if the code works for release 1 but is so unreadable that it is impossible to maintain. A good programmer makes sure everyone else on the team can understand their code and the rationale behind their design. Anything less and you're not a good programmer.
I think a more useful approach is, "How do you recognize a programmer that's bad for your organization?" It seems counterproductive to try to define a good programmer given the diversity of environments needing programmers. The only universal qualification I can think of is that programmers must adore Linux and have their own Wikipedia page - otherwise they are clueless.
The Python Paradox
Paul Graham
http://www.paulgraham.com/pypar.html
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.
I was about to say 13256278887989457651018865901401704640, but it appears this number is private property.
1. Mod the article "funny". People who work hard, 16+ hours a day, learn every new technology, and jump onto every fad and fashion, have never impressed me.
2. A good programmer is someone who makes it look easy.
Knowing the business helps to avoid having to ask a lot of questions to fill in the unstated requirements, and also avoids making the kinds of huge mistakes that cost huge amounts of of time. Knowing the technologies that are in use in an enterprise, knowing what has already been done, and knowing how/where to look things up, helps to avoid reinventing wheels. Having academic knowledge of things like algorithms and theories helps to select the ones that are needed, and to implement them correctly and reliably. Knowing particular languages and other technologies helps to get things right the first time.
The person who knows all of these things makes the job look easy, and generally goes home by 5.
If they have been inspired to write games, that's a good bet I think.
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.
CS: It is all sink or swim...oh and did I mention there are sharks in that water?
This was asked before in a Slashdot interview of John Carmack (id Software lead programmer). Question 4:
4. justin_saunders asks:
Many people consider you to be one of the best programmers in the game/graphics scene, based on your ability to keep pushing the limits of current PC hardware.
I was wondering what measures you use to gauge the skill of a programmer, and who, if anyone, you look up to and consider to be a "great" programmer.
John Carmack Answers:
Like most things, it is difficult to come up with a single weighted sum of the value of a programmer. I prefer to evaluate multiple axis independently.
Programming is really just the mundane aspect of expressing a solution to a problem. There are talents that are specifically related to actually coding, but the real issue is being able to grasp problems and devise solutions that are detailed enough to actually be coded.
Being able to clearly keep a lot of aspects of a complex system visualized is valuable.
Having a good feel for time and storage that is flexible enough to work over a range of ten orders of magnitude is valuable.
Experience is valuable.
Knowing the literature is valuable.
Being able to integrate methods and knowledge from different fields is valuable.
Being consistent is valuable.
Being creative is valuable.
Focus is extremely important. Being able to maintain focus for the length of a project gets harder and harder as schedules grow longer, but it is critical to doing great work. (Side note - every time "focus" is mentioned now, I think of Vernor Vinge's "A Deepness in the Sky", currently my favorite SF novel)
I certainly respect the abilities of my primary competitors. Back in the DOOM days, Ken Silverman was extremely impressive, and today Tim Sweeny is producing much of value.
I actually had to turn away a developer who was very Java proficient because he couldn't write memcpy in C. Really, it's not hard!
- I voted for Nintendo and against Bush
If I don't put anything here, will anyone recognize me anymore?
laziness, impatience, and hubris.
Resumes tell you very little, talking sometimes tells a tale, but it's an inefficient way to start.
;-).
Best way to start is do a screen based off coding ability (have a set of tests ready against simple problems and ask them to conform their answer to an API). Advantage of this is that it's very objective, and takes little time from your team. Do a screen based off coding ability but with harder problems, too. In both cases, leave just a little ambiguity in the problems to see whether the candidate spots them and asks for clarification, freezes, goes ahead with their assumption without asking. If they're smart enough to ask for clarification, how clearly specifically do they ask?
This will easily filter 90%+.
Next, do a basic knowledge test (never hire a liar). Based on what they put in their resume, ask trivially easy, and maybe a couple medium level obscurity/difficulty questions. If they're dead or really scrambling, don't waste any more time on them. Obviously, the more the knowledge needed on the job meshes with their resume the more this can weigh in a candidates favor.
Finally, try and figure if it's a personality fit. The less scripted this is the better. At the end of as normal a conversation as you can muster (and try to be listening 90% of the time rather than talking), do you have a definite positive feeling that this person would be able to fit in well, fill the gaps you need filled and bring something extra? If no, gotta make that final cut here, too, even if that leaves nobody.
The main problem is that management will tell you this process too picky and making it too hard to find someone.
Remind them, you need someone good, tell them that nothing about this process is actually hard, they just need to up the offered salary to attract the interest of good applicants and not waste your time.
Also, remind them how well you would be able to do on all this as a way of hinting you need a raise
Like "good".
Having worked with some brilliant coders, I have found the best are: ones who will smile and speak casually while talking about problems, solutions, etc.. as opposed to frowny intense confrontation laden interactions. Also, I cannot say how many times decent coders will use "No, can't be done." as an answer to everything.. once that doesn't scare you off, a solution might occur.. a much better question is "How?" Those two simple things are keystones for me.
It would be advisable to look for people with experience in the field of high speed pizza delivery.
Also, keep an eye open for sword-carrying individuals.
There is no sig.
As someone who's interviewed, hired and fired dozens of programmers over the years, I can tell you there is no sure fire way to pick out a good programmer. Here are some very loose guidelines I've found helpful: good: - old timers with a variety of languages / os's in their background. I love to hire old c++/unix guys just looking for a break to try out java / soa. they invariably pick stuff up really fast, work hard, and know how to do basic programming stuff like debug, set up test environments, etc. - in decent shape. you can't say this out loud to anybody, but trim people tend to be be a productive programmers. i am not kidding. probably the same gene that makes people disciplined enough to exercise and eat right, makes them a hard worker who can turn out lots of code. - linux - anyone with linux on their resume, even as a hobby, gets a bump up in my books. you know they love fiddling with technology and can figure stuff out on their own. bad: - "working on my phd / masters / taking a course at night". translation - course work will take precedence over project work, and as soon as I'm done my degree, I'm outa here. - pony tails. I'm gonna catch it for this, but every guy I've ever hired with a pony tail has been a pain in the butt to work with. they're on a different plane of enlightement from you, won't take direction, and in general its beneath them to be working for you. the ugly: - those stupid canned tests with five lines of code asking you what is wrong with the above code fragment. i've had guys bomb these tests who were awesome programmers, and guys ace those tests who couldn't code their way out of a paper bag. completely useless imho.
The best programmers are the ones who are extremely lazy. The ones who don't want to do more than is required and also want to do it in as little time as possible; the one that will search out existing technologies/code to solve a problem rather than write it himself. You'll end up with fewer lines of code that is more maintainable and easier to understand.
Because of the love of learning and toying with new technologies that comes with the package of being a good programmer, its inevitable that any good programmer over the age of 22 will be fluent in a dozen different technologies.
If he's 22, and claims to know so much stuff, I bet he doesn't master any of them.
To ask if they post on any boards such as slashdot, and what their handle is? Yeah they could lie but that would be fairly easy to find out I should think. If you were gonna hire someone you could at least learn in advance if they spend all day on Slashdot and what kind of sense of humor (or not) that they have.
If only they knew how to recognize a good sysadmin.
This may have been mentioned before, and it may be semi-unimportant, but I'm annoyed that the "programmer" in question is always a he. I'm a girl, and meet most of those qualifications and am very proud of that fact. Hopefully it was just for ease of writing...
Present them with a test who's difficulty is measured directly proportional with what it'd be rated in the IOCCC. At least that's the second most popular method behind having 10 years experience with in house software.
God spoke to me.
I've read a few of the comments here and I think the vast majority of people here don't really have a clue what makes a good programmer. Everyone that said, 'Well, I'd have him code up something in XXX language of my choice...' - I think you are wrong.
.Net Developer who doesn't have a single line of code, anywhere, that contains 'memcpy' or 'malloc'?
That might be a fine test to learn if someone is a good XXX programmer. But it has nothing to do with whether or not they are a good programmer. There are great developers out there who have years of experience NOT working with the language of your choice.
I've never touched Java in my life. I've used PERL, in total, about 3 times. Never done PHP, RUBY, PYTHON...heck, I haven't done any C++ since high school.
A good programmer is going to be a good programmer regardless of the tools he is using. The programming language of choice is a tool. I think of myself as a Software Developer, not a '.Net Developer' or a 'C# Developer'...and yes, if you give me a pop-quiz about how to use memcpy I'm going to fail. But why should I know about it? Conceptually, I understand the gist of memory allocation, I've heard of malloc as well - but how is that an accurate reflection of the abilities of a
This is the equivalent of saying, 'To Recognize a good athlete have him attempt a double leg circle on the pommel horse'....but that's really a test to see if someone is a respectible gymnast. You could take an NFL star and, odds are, he cannot perform a basic gymnastics move.
That's a horrible way to test for someone being a good programmer.
In addition, beware of people who spend too much time padding their Resume with lots of committees, interest groups, department liasons, etc. These are the sorts of jobs that the boss gives morons to keep them out of the office.
Have gnu, will travel.
Nerds!!!
AAARGHGHGH!!!!!!!
Do you see the sig? Do you have it in your sights? Why yes, Miss Moneypenny...
I just have to laugh reading through so many of the replies here and below TFA. Many are claiming that the list is close, but not quite "because I am a good programmer and this is how I do things..." Then you have some whining about the list being completely off, because "I am a good programmer and I don't fit into your list at all".
If you feel the need to claim that you are this wonderful programmer, who are you really trying to convince?
http://www.xkcd.com/292/
How to recognise a good grave digger
How do you recognise good grave diggers if you're a business guy?
It's not as easy as it sounds. CV experience is only of limited use here, because great grave diggers 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 grave digger.
I consider myself to be a pretty good grave digger. At the same time, I've spent a fair amount of time on the business side of the fence, filtering technical CVs for projects, interviewing people, etc. Thanks to this, I think I have a bit of experience in recognising good grave diggers, and I want to share it in this article, in the hope that it may help other "business guys" to recognise good grave diggers. And, who knows, perhaps some grave diggers who have the potential to be good but haven't really exploited this can also read this and realise what they need to do to become good (although, as I'll argue, that's definitely not accessible to all grave diggers!).
Ok, that's enough cutting and pasting. Seriously..this article is a bit sickening; it's all about dehumanizing the human being. Mark of a good programmer? Why not apply the phrenology test? Their skulls must have a particular shape in order for them to be "good."
You should get a very good idea of how the programmer ticks by first looking at their design practices. If they're a good object oriented programmer, their objects should make sense and the relationships should be easy to understand, (keeping it simple and stupid). Nothing should be hard-coded, it should be easy for another programmer to take over and change things as needed. They should probably be able to use almost any OOP language. If a database is involved, the objects should carry through into the table design using about the same number of fields/variables as the object for each table. My experience using stored procedures is use only as necessary; it gets messy quick in my opinion when you have stored procedures scattered around the database. Security should be covered almost 100%. They should be up to date on current malicious techniques. It's hard to get even close to 99% when you're trying to be rapid, such as most webapps. Personally I consider myself to be a very 'neat' programmer. One thing that drives me crazy is when people don't follow a naming scheme in the database, and with the object classes. Doing a table join is much cleaner when there's a strict naming scheme in place. Just take a glance at the design and structure of wordpress and tell me you don't wanna just re-write it from scratch. I have an organized set of tools that I use on a regualar basis, such as my php class creator that accepts an insert query as input. Also, my ajax script I wrote from scratch along with all my javascript form utilities. A lot of things make a good programmer. It's funny how I'll always be able to look at the code I did 3 months ago and laugh to/at myself at all the things I could do better.
crap, crap, crap. I hit every one of those points. Self driven learning, always exploring new forms of technology and then applying it to the current business, etc. etc. Maybe if I hadn't been so good, my hands would still work and I wouldn't be living with constant pain up to my elbows. What's ironic is I left my father's rigging business (machinery moving) because I saw so many people around me losing fingers, damaging their limbs and back etc.. and I wanted to go do something where I wouldn't be injured on the job. Since I had been programming in high school, I thought hey, this is not a bad career. You work indoors, you're not covered in grease, you don't breathe toxic chemicals and you aren't going to get injured by heavy machinery falling on you.
Ha.
You rock!
You are going to be a good, if not great, programmer, for a whole heap of reasons:
From where you are, there are two things that will help you in the real world - the best ways to learn more are to program more and to look at other people's code, you will start to see things that you hadn't thought of, you will start asking 'why did he/she do it that way?' and be able to evaluate whether it's something better or worse than what you would have done.
Good luck in your journey, and congratulations :-)
You stand up on your desk and shout "BINGO!"
I lost my sig.
If you're a good programmer you won't be able to help but find trivial little ways to use it to make your life outside of work easier. And that doesn't preclude having a healthy work-life balance. It actually enhances it.
There are zillions of ways that a tiny bit of code can help in some of your daily life, and if they're not rediculously obvious to you in a way that calls out for you to do them, then you either aren't smart enough to be a really good programmer, or you're not passionate enough to be a really good programmer (or a really good worker at all, most likely).
Also, I don't see how listing "programming as a day job" means that he thinks you should be programming for fun. Normal people have personal work to do outside of their jobs. Using a few lines of code to help for those jobs counts too.
Would you rather have your employee wasting their time and your money hacking their way through a project in a technology that they do not understand or would you rather send them on a course to learn the technology from someone who has experience with the technology? From the courses that I have taken I have seen just how hacky my self-learning can be. You would be crazy to not want to reap the benefits of someone else's experience.
A good programmer (who writes about it in a blog) should know that the internet is used by people that aren't in his/her immediate locale and might not know what CV means.
I'm pretty sure it's Curiculam Vitale (or something like that) but c'mon. It's almost as bad as web sites that refer to temperatures in Farenheit or have zip code edit boxes that don't support alpha chars.
I know this much: don't take advice from someone, who misspells the headline to his article where he is giving you the advice.
"How to recognise a good programmer" - I know how to recognize a bad speller.
You can't handle the truth.
I like that, though you left out the guy who explains why he did it that way... and it makes sense.
I've had a few situations where I've had trouble figuring out some code, because I was making a wrong assumption somewhere, and at least once I've cleaned up some code and then gone back and put it back where it started once I figured out what was really going on, learned more about the technology or the problem area, or otherwise educated myself out of a hole.
I suppose you could say this was a matter of bad documentation, the code should have had better comments or something, but it's not always that simple. And, yes, that sounds like a pretty good place to start.
I would give Bjarne more credit if he'd shown a better understanding of C before he started designing C++.
Not to mention... Java vs C++? This is like arguing the merits of Lincolns vs. Fords. The languages are kissing cousins.
But can you be programmed as a good recognizer?
The prima-donna hackers (assuming they actually can walk the talk) will give you the fastest performance and churn out code quickly. But it will be code that only they can support, and in some cases only they can run it. Send them to work for an OS, game or compiler vendor.
The diversified engineers can give you things more valuable than code, like documentation, structure and conformance to requirements and standards. But their code output and the performance of their programs will be slower.
We are the 198 proof..
The author is a good programmer, hire her.
That's why I only date hookers and porn stars. Any girl who isn't doing other guys on the side isn't really interested in sex.
That article is thrown at idiots.
... good advice in here, and not just that pseudo-babble.
KNOWINGLY.
Its for people that does not know shit bout programming, but want to feel comfortable about hiring some "standard nerd" or something.
Hopefully they got to read some
Software engineers might be some of the smartest people on the planet but at the same time some of the least wise. The main
reason for that is ego.
From observation of myself and others, I have come up with "the 5-step developer lifecycle" - it probably also applies to quite a lot of other professions and might apply somewhat to life in general:
1. developer is learning, really curios and asking a lof of more or less stupid questions to other more experienced developers.
2. developer is starting energeticly and randomly to question and object to what the experienced are saying.
3. developer stops listening to what experienced are saying because he assumes that he is always right.
4. developer starts doubting the assumption that he is always right, thinking he might not be Einstein after all, but tries
desperately to defend the assumption to himself an everyone else as best as he can (nobody likes self-doubt or broken illusions).
5. developer realizes that in the grand scheme of things he is just as stupid as all other human beings (and humans are
really stupid in the grand scheme of things). At the same time he comes to peace with himself and is able to laugh of his own
silly mistakes.
Developers in step 2-4 can be extremely counter-productive for an organization. They are usually the most loud-spoken in meetings and might object to any suggestion that they did not come up with themselves. The trick is to hint in the right direction and make them think they came up with the idea.
I don't think this lifecycle applies to all developers - some never leave 1, some are born directly into 5 and some might even
cycle through all of them each day. Been through all 5 myself. The revelation you make at 5 is the most
important insight you'll ever make as a software developer and the step where you finally can start writing good software.
Finally! Someone that understands my value!!!
I've seen so many startups fail because management will turn programmers loose with out having gone through a full cyle of design first - requirements->sign off->high level design->sign off->detail design->review and sign off->testing plan->sign off - before turning the code monkeys loose on the coding phase. They think it takes too much time and costs more money. I've been through the whole life cycle and now mostly architect but it's hard to get management to do the proper cycle, they just want results. The more time you spend designing and testing means less time devoted to fixing and adding features later, and most likely removing stuff the kiddies without an architect to ride herd thought were 'neat' addons. Even when I was coding for some startups I always did the design phase first. At more than one shop it didn't take any longer to get to market with a production ready product then a 'code - run - fix - now make it do this or take this out' iterative style without design docs would. In a couple of shops the first release was the final release and would run error free for several years because of up front design and testing.
Too lazy to create a sig...
You're a clever one but I'm afraid your sig blew your meticulously constructed cover.
Hawaiian shirt (perhaps on inside-out)
shorts
round glasses
greasy hair
likes to fidget with pens
http://www.goldeneye.com/julian/boris.html
What this guy is saying is basically the party line. Find someone who's a "geek's geek." Find someone who's obsessed with technology. Find someone who doesn't have anything compelling in their spare time to do besides write code.
Here's one for you - how about just showing me someone who can deliver the goods? I've known so many people who fit the description in this article, yet who cannot deliver the goods because they're too obsessed with making "the neatest thing possible," or who succumb to scope creep because they don't know how to say "no."
I mean, yes, we all want to make our bosses happy and give everyone what they want. And yes, it is instinctual to want to fit the latest, neatest widget into whatever it is that we're doing. But what about actually delivering code? To do so requires strength and discipline. It requires the ability to properly estimate projects and not over-commit. It requires the ability to say "no" to your boss when he's asking for something impractical. It requires the ability to decide which features must go and which must stay in order to make for a stable, timely release.
Another thing that wasn't mentioned in the article is a sense of elegance, which I think is the key determining factor in what makes someone a good programmer. If someone doesn't have a sense of elegance, they're lost and there's no way to help them. They have to know the difference between a solution and a work-around. They have to know how much complexity is necessary, and how much is too much. They have to know how to write readable, clear code that isn't filled with a bunch of hacks or show-off tricks. Sure, it's impressive when someone loves writing code so much that they taught themselves Ruby or Lisp or Haskell. But I'm more impressed by the guy who, when given a problem, thinks, "there's got to be an elegant way to solve this," and then goes out and learns a new technology not because it's fun, but because it's the cleanest, most logical, most modular way of solving that problem.
I think I agree with Paul Graham here, rather than the author. Business types who dont know anything about programming are going to have trouble picking good programmers.
Here are some nitpicks with the article:
#1
Passion is important, although I disagree with "Good programmers will have a tendency to
talk your ear off about some technical detail of what they're working on".
If asked, a programmer should tell you about things with passion, but having them blather on about an arbitrary thing just means they probably are spending too much time on it in general.
I should mention, hearing good criticisms and bitching about what should be different, I see as good.
"Dammit, why doesn't apple's Cocoa documentation list all of a particular classes APIs in one place somewhere? There's NSString, and AppKit's NSString, ugh" and "Drawing text on OS X is a pain in the ass -- there's at least 5 APIs that all fail in some way or another" would be two examples of what I consider good criticism.
#2
Yes, wanting to learn and self teaching are great qualities. Although:
"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."
This is idiotic. A good programmer should be sensible and reasonable-- not fearing change, but not changing for no good reason (and certainly not for something he doesnt know himself!). And again, talking your ear off about any particular technology is a warning sign. "OH, you just HAVE to use X". BAD.
#4
Yeah I really want to see code that they've created (either for fun or otherwise). That says everything.
#5
I don't think bleeding edge is worth anything. Variety is good, although I must admit the scope of my programming is mostly limited to assembly and C-like languages, so (rationalizing) it isn't everything, as long as you're willing to learn.
Of course, the article misses a key point:
Programming is a medium to accomplish goals. Having someone who understands the goals and vision, and can program worth a shit, is worth more than anything else.
There is a difference between a good programmer and a programmer who is easy to exploit. People who collapse at a young age into a hyperfocussed code-is-my-life every-waking-hour-of-the-day mania are generally engaged in some deep emotional avoidance behaviours.
10,000 highly focused hours rewriting some major OS or application is probably worth more to your career down the road that the same 10,000 hours editing Wikipedia, or leveling-up in WoW. Many of these people wake up and smell the bacon in their early to mid-thirties having given their best energy to a cause that might not even continue to exist. A small percentage (who are wired a bit differently than most of us) thrive in this mode of living indefinitely; just enough to be held up as models to those of us who can't.
EA has been particularly good at spotting talented young programmers who are willing to collapse into a 100-hour per week delivery grind to escape having to deal with life on any other basis, without EA having to fully compensate those hours, leading eventually to a lawsuit.
From an EA perspective, those programmers were the best. Money can't buy you a programmer who is willing to work 100 hours and get paid for 40. You have to spot them yourself.
10K out of 10K+1 bad hiring experiences are caused by psychology majors who find a permanent niche in HR and think they're contributing. My first rule, following the TOTKO principle, is don't hire anyone over 39. They've shot their wad, and all they're really good for is code maintenance, provided they wrote the stuff in the first place. My second rule, don't hire a recent college grad. They don't know squat, so you get gigantic holes in your existing codebase, patched over by tripe that only works 80% of the time. The old stuff only worked 95% before your environment reprioritized everything, for sure, but if you hire a recent grad, either be prepared to whip them through a steep forgetting and relearning curve, or put them on a team far away from design responsibility. My third rule, hire idiosyncratic genius. Communication will be hell for a few months as everyone reaches new consensus on what terms like "embedded" really mean, but the results will be outstanding -- for two years. That's the ENTIRE attention span for anyone who can both plan and execute a project. After the project is over, sign her onto another, different project fast. If you just kick your producing players upstairs or out the door, you will be unable to maintain code (because of the RCG syndrome mentioned above), and your company, or division, or section, will implode, or worse, decay slowly. I.G. can be 40 year old women who took a course after losing a job at a meat packing plant, by the way. Be supple. The exception to my third rule, never ever hire I.G.'s who play dungeons and dragons, or who are exceptionally good at FPS. Automatic asocial disqualifiers.
``Tension, apprehension & dissension have begun!'' - Duffy Wyg&, in Alfred Bester's _The Demolished Man_
I know I'm a great programmer. But I now have social skills too! So nowadays I don't clean my mouse mat by rolling the mouse over it after I used it as a plate to eat my cream cheese sandwich from, while sitting working at the computer - while the others are eating lunch out of the office!
There's some programmer out there that doesn't think s/he is really good?
I think I am good too, of course, but after more than 30 years programming, the more lasting feeling is that we are just artisans, we do what we know, the better we can because we love what we do.
That's all
What's in a sig?
My approach to evaluating people is simple: I give them real problems to solve. If they cannot find a solution, there is no way working with them even if they have a thousand PhDs from the best universities. If they can solve the problems, then I do not care even if they have no papers at all.
Papers are useless. Some people think they can save evaluation time. That's wrong because papers are unreliable. A paper with a bad mark may be given to the best programmer, and a paper with a good mark to the worst programmer. Papers in theory are representations of knowledge, but in reality they are just representations; representations of nothing.
IBM Graduate Recruitment process:
Psychometric testing, followed by group excercise. Group excercise when I went in consisted of:
Seven people are stuck in a cave, the cave is unstable and could collapse at any moment, who do rescue and in what order, you can only rescue most of them:
The CEO of a large textile company
A four year old girl
An eight year old boy
A 16 year old man
An experienced caver but he has a broken leg
I don't remember the rest of the people
This was followed by a pseduo-code test set by IBM R&D which was multiple choice:
This code sets the sequence of an American traffic light which is Red-Green-Yellow-Red, what is the error?
loop
light=red
delay 20s
light=green
light=yellow
delay 2s
light=Red
end loop
What is wrong with the above code? Is it:
(a)Red light will come on straight after yellow light
(b)Yellow light will come on straight after green light
(c)Something else
I'm sure the /. crowd can come up with something more imaginitive to test l33t HaXoR pseudo-coding skillz
Followed by interview but I didn't get that far... :-(
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
A good programmer must listen very well. Not in the sense: I'll take notes and implement everything you say 100% as you said. He should stop you when you ask stupid things of him. He should try to understand what causes you to like a certain feature, definition, algorithm or datastructure. And finally he should be able to give contineus feedback.
...but I also have a good sized vocabulary that is instrumental deciding what to name things. Sometimes I'll even get out a thesaurus.
It's good to know somebody else cares about stuff like this. Just seems obvious to me.
Ask them what language they code in for fun. If they say they don't program in their spare time, they aren't a good programmer. If they say something recherche like Prolog, Erlang, Self or OCaml, they're a good programmer, and possibly also arrogant or trying to impress. If they say Python, Ruby, Lisp or Smalltalk, they're a good programmer. If they say C++, Perl, C# or PHP, they may be a good programmer, but have wierd tastes. If they say anything by Microsoft with the exception of C#, at all costs do not hire them or they will bankrupt your company. If they say SQL, BASIC, Enterprise Java Beans, or mention UML, be very scared.
Ask a few meainingless questions to let the person get warmed up. Then ask the following: 1. Do you read recreationally? If so, what? (I've worked with hundreds of programmers and never met a good one who didn't read for fun.) 2. Do you enjoy programming? Why? (I've never met a good programmer who did not like programming.) 3. Here, here's a computer, please write a function to convert an arbitrary string of characters into an integer. (There's nothing magical about integer conversion, you could ask for many similar simple programs. You'll be amazed how many people make it to the interview and cannot write a simple program in a short period of time when left alone in a room with a development environment and no internet access.) These 2 questions an 1 short 15-minute task will filter out the good programmers. I have contempt for interviewers who like to use cute little Microsoft-style puzzles to try to figure out how you "think." They are fools who should leave figuring out how people think to Psychologists, Neurologists and Philosophers and stick with trying to figure out if you can or cannot write good programs, work well with others, etc...
We keep it easy. Every applicant is given the same requirements, specifications, goals, and time to write a program. We then evaluate their code and the program itself. We benchmark this against what an in-house programmer does in the same time, with the same requirements, whom we rate highly. After that we interview them and find the ones with the appropriate attitude. The failure rate with this method of hiring has been significantly lower than any thing else we have tried. Some interviewees are offended by this process. It is simple, if they do not want to do it, they do not want the job. The benefits that we give people to work for us far outweigh the difficulty of getting the job.
Easy. You look on the CPAN and see what modules they maintain. If they maintain something like DBI or DateTime, they're a good programmer. OTOH if they maintain something like Matt's Script Archive you might want to give them a miss. HTH.HAND.
Cut that out, or I will ship you to Norilsk in a box.
See the subject line... Yes, it was a tad trollish, but look at all three replies. Three people paralyzed with the need to analyze the obviously invalid code material, correcting it by half measures...
Which is all kinds of what "Bad Programming" is all about.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Er, no. The first half of the code was predicate as "identical". The second half wasn't.
Meanwhile, the "code" isn't even close to rational as, if you want to get super literal, it's just a bunch of identifiers so it would be a big steaming no-op or it would be an endless loop of no-ops.
_Clearly_ a real construct offered as a test would have to be... um... real.
Funny thing is, out of three responses to the post, nobody looked at the content of the post but each of you hopped on this half of a sentence about a while loop.
Not very "big picture" on the part of _any_ of the respondents. 8-)
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Well, if you want to get actually literal, you would notice that there are a bunch of identifiers and no actions (no method invocations and no test). In both cases the whole thing is a steaming no-op. 8-)
Clearly, for any form there are exceptions that can fit in the form and break it....
But then again, the idea behind the question, and indeed the idea behind the _entire_ post had nothing much to do with the code segment the three respondents have hopped on.
Which doesn't say much about the ability of the programmers to stay on point or work with others etc...
Which kind of proves my point... 8-)
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
All 19 hijackers were known terrorists 09-10-2001. Lack of FBI intelligence does not justify warrantless wiretaps..
... write good code, excellent programmers steal excellent code.
Do you like programming? Can you take challenges? Would you match yourself with others?
Here is your chance! Grab it!
The Electrical Engineering Students' Hungarian Association and the Károly Simonyi College for Advanced Studies are proud to present the
8th BME International 24-hour Programming Contest!
If you have missed the previous seven occasions, it is now time to join the adventure!
This contest is a real test of creativity, knowledge, endurance and team-work, an EXTREME CHALLENGE! Sponsors and the offered prizes worth 5000 euros contribute to the high standards of the contest. The team which gaines the utmost points can take home the award and the cup.
Those teams which will have finished registration until 17th February 2008, must do their best during the online preliminary quailifier on 24th February 2008. The best performing thirty teams can participate onsite at the Finals in Budapest Hungary, between 2nd and 4th of May 2008. During the 24-hour advanturous round, the contestants will have to solve one, but extremely complicated and interesting task. They will need all of their knowledge in the field of algorythms theory, artificial intelligence and program design, and also well-used team work competence is desired.
The contestants will be allowed to use their own computers. Technical background and catering will be provided. There are no restrictions on the hardware, software and support they use, but communication with the outside world is strictly forbidden.
For further information and for tasks from the previous years please visit the official homepage of the Challenge where future occurrents will also be available for everyone.
If you are not afraid of eXtreme challenges , you do not have anything else to do just to establish a team of 3 members and register at http://www.challenge24.org/ ! Participation is completely free of charge.
Have fun and good luck!
The Organizers
Deadline for registration: 17th February 2008
Website: http://www.challenge24.org/
For further information please check our website, or contact us by email
Do you like programming? Can you take challenges? Would you match yourself with others?
Here is your chance! Grab it!
The Electrical Engineering Students' Hungarian Association and the Károly Simonyi College for Advanced Studies are proud to present the
8th BME International 24-hour Programming Contest!
If you have missed the previous seven occasions, it is now time to join the adventure!
This contest is a real test of creativity, knowledge, endurance and team-work, an EXTREME CHALLENGE! Sponsors and the offered prizes worth 5000 euros contribute to the high standards of the contest. The team which gaines the utmost points can take home the award and the cup.
Those teams which will have finished registration until 17th February 2008, must do their best during the online preliminary quailifier on 24th February 2008. The best performing thirty teams can participate onsite at the Finals in Budapest Hungary, between 2nd and 4th of May 2008. During the 24-hour advanturous round, the contestants will have to solve one, but extremely complicated and interesting task. They will need all of their knowledge in the field of algorythms theory, artificial intelligence and program design, and also well-used team work competence is desired.
The contestants will be allowed to use their own computers. Technical background and catering will be provided. There are no restrictions on the hardware, software and support they use, but communication with the outside world is strictly forbidden.
For further information and for tasks from the previous years please visit the official homepage of the Challenge where future occurrents will also be available for everyone.
If you are not afraid of eXtreme challenges , you do not have anything else to do just to establish a team of 3 members and register at http://www.challenge24.org/ ! Participation is completely free of charge.
Have fun and good luck!
The Organizers
Deadline for registration: 17th February 2008
Website: http://www.challenge24.org/
For further information please check our website, or contact us by email