Don't hire a programmer if they don't code for fun
jdconley.com
jdconley.com
Every team needs a few "Rock Star" programmers (to use the author’s terminology). When hiring those folks I think his advice is spot on. But the reality of programming a project is that there will be some tedious work that the "Rock Stars" will find boring. In my experience those types of developers actually do pretty mediocre work when forced to write no-brainer code.
So I’ve found the best mix is to have a few of these rock star developers mixed in with folks who enjoy development and are hard workers but who are at a point in their life where they don’t have time for side projects. These are the guys who were probably rock stars in their younger years but now have spouses, kids and all the trappings of that (soccer practice, dance recitals, et al). Since they aren’t looking to work for the majority of their fulfillment they tend to be ok with the tedious stuff and since they are still decent developers they turn in solid code.
You can really do more, with less.
In a early stage there is probably a lot of stuff to do, lots of features to keep the smart people engaged, and with fewer more productive people you have less overhead, less meetings, less political bs.
Sure, but the article should make a point of including this qualifier. Because, of all the teams of programmers in the world -- even if you just count the competent ones! -- a very very small percentage are involved in early-stage startups, despite PG's best efforts. And a lot of those teams benefit from a mix of personalities, ranging from the energetic free electron to the dedicated day worker to the manager who actually kind of enjoys all those tedious meetings where (s)he evangelizes your work to upper management.
http://www.randsinrepose.com/archives/2005/03/20/free_electr...
Due to their "Rock Star" mentality they can rationalize this poor work ethic because they truly believe they are benefiting everyone: "it's far better for me to kick ass with the XYZ project then to do this crappy ABC project"
Trust me, I've been in that position (rock star). There's something more to "rock star" than just passion... they are aware of their rock star status.
IMO, rock star programmers are good if you can handle them. You need to make them believe that what they are working on is of the utmost importance that they specifically were assigned it precisely because of it's importance and because of their capability. That's the best motivation for a rock star.
Otherwise I agree with TomOfTTB: some rock stars, but more drones.
No we don't. We stopped doing that when other folks who were hiring "rock stars" failed to get a product off the ground, and proved their salaries couldn't live up to the livelihood of what a rock star expects to be compensated, thereby making the phrase "rock star" in any sense other than someone who does what Jimmy Buffet did overwhelmingly kitschy, and anyone using the phrase mind-numbingly foolish.
Thanks for playing.
If we really want to give programmers silly names fine I am a "Professional". Aka the movie "the Professional" where you have a problem, you pay me money, I solve the problem. Rock Stars are just another silly name people give out so they don't have to pay you what your time is worth. Look up actual rock stars they tend to end up broke because while it might look like the are making a lot of money most of the time they are getting peanuts.
I think there is _something_ to the rockstar image... namely passion. Accept no bullshit, swear at the suits, light shit on fire to get results passion.
But I agree, "rockstar" A) doesn't cut it as a metaphor and B) is not a word a real developer would use to recruit a real developer
If you want to give my kind of programmer a nickname, save it for your business docs. My fathers already gave me one:
Hacker.
I haven't seen it yet and it's on my Hulu queue. Thanks!
Argh!
Sheesh. Would it kill you and jacquesm to put a courtesy "spoiler alert" notice at the start of your messages?
(This is all incredibly off topic so this'll be my last post on it.)
Great movie though, The Professional, go see it anyway, in spite of the spoiler and enjoy the music too.
I can't think of anything worse in my team than someone that just constantly dives head first into code. Great coders stop and think, discuss, then code. IMHO.
The guy who is not interested in good software design, can't learn or pick things up for their job, who requires constant repetition and babysitting, and finally breaks your software out of ignorance is worse than both of these.
You should never hire a caretaker who doesn't mop floors for fun.
Doesn't actually work, does it? Why are programmers "special"?
You should never hire an artist who doesn't paint/draw/whatever for fun.
Seems to work ok for creative professions.
EX: There are a lot of programmers who spend a lot of time interfacing with buggy API's which is soul sucking work, because the bugs are random.
PS: If you are building a boy band you probably don't are about artistic talent. It might be useful but it's far from the most important trait.
What makes programmers special?
1) There are actually people who program for fun. If you looked for rockstar janitors who mopped floors for fun, you wouldn't find any.
2) There is an order of magnitude or two difference in the productivity of great programmers compared to average programmers, whereas a great janitor or secretary may be something like twice as productive as an average one. It's more important to find a good one.
3) Filtering good programmers is notoriously difficult - it's not like typing where you can give candidates a simple test and get a straightforward, quantitative answer, so every bit of information helps.
In honor of my late grandmother, who devoted about twenty years' worth of Saturdays to cleaning the floors and bathrooms of her local church -- for free -- I must inform you that this isn't true.
Whether or not she was maximally productive is quite a different question. A lot of ritual activity isn't especially intended to be productive.
Canada. I don't understand it either.
Ironically a mediocre programmer really compares better to a secretary than to a great programmer. He may be able to churn out code when given detailed instructions, just like the secretary will type out your letter when you dictate it to her. But the great programmer on the other hand; he decides what letter to write...
90% of programming - sometimes 99% - is forms or reports. Validate and store some data, or retrieve and format some data. No-one does that "for fun". You need professionals who can execute at a high level of competence true, but "creative" is a bit of an exaggeration.
That's btw one of the main differences that I see between great and mediocre programmers. When you give the task of "build a report" to a mediocre programmer then he'll go and build a report that meets to your specs. He'll keep doing that even if he gets the same task every week. A great programmer on the other hand will soon start trying to optimize the process by generalizing and automating. That's where the creativity kicks in. Programmers who love to code will try to get a repetitive, monotone duty out of their way asap, in order to free their time for more interesting problems. Programmers who merely "write code for a living" will rather stick to such tasks despite their inefficiency, because that "one hour per day on boring recurring tasks" is one hour that they don't have to do real work.
PS: The logical next step would be to hand the customer your form generating software and get them to solve their problem, but that just ends up with someone debugging a horrible Access database. (Or whatever system you build.)
In summery: Specifying a specific form specification to collect or show useful information is programming. (Say that 3 times fast.)
Creating an application for building forms (e.g., Wufoo) is programming, building a form with Wufoo is not.
Note, I like the idea of getting non-programmers involved in programming activities. However, just because you work as a programmer and get stuck with things a non-programmer can do doesn't mean programmig is boring, it means you have a boring job.
"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.[2]" (http://en.wikipedia.org/wiki/Greenspun%27s_Tenth_Rule)
I think you get the same then for any significantly advanced Form generating software. At some point you need to link 2 elements and do some math and you end up starting the whole ball rolling again. How would you build the "perfect" form generating software for a Pizza Topping Selector so the client can change any part of the interface in any way they want at any time and have any discount they want for any list of toppings? ... Great now is your form generator simpler than just writing the code?
PS: You can talk about just the GUI but tools like visual studio are already have GUI tools for building GUI's.
Let's say they want the ability to have themes which automatically occur for special events. Now you have the back end (keeping track of the order), GUI (what the user sees), interface builder, script builder (Interface for deciding which themes show up when), topping interface (name, cost, picture), Discount builder (for groups of toppings and groups of pizza's).
But, what is this script builder and what is this interface builder, and discount builder? Well we want scripts that can change the interface and add the holiday special toppings, and change the billing information. And we want a nice interface for changing the look and feel of the website. Great, but who is going to use them and what are they going to be doing?
A: The most flexible interface is always code. It's also to complex for the average user to understand. So we constantly get this pattern n * Developer > Script builder > Script Selector > User. The secret is creating the most useful easy to debug scripting language. You want them to say 2 weeks before Easter and they don't have to worry about when the full moon is.
Lisp is great because it understands this pattern and works well. Viaweb is a great example of this: http://www.paulgraham.com/avg.html, http://lib.store.yahoo.net/lib/paulgraham/bbnexcerpts.txt, and there is also a good essay on their the scripting language they built but I can't find it.
PS: Once you realize your building a scripting language it's a good idea to consider what type of language your building http://www.paulgraham.com/langdes.html because while it might be fastest for your script to be written in the same language you code in your users want something that looks no more complex than BASIC. (See: Excel) However, if they want you to build the script's then you can just use your language / IDE and EVAL the script.
You think, back in the 60s when it was the latest thing, COBOL programmers called themselves "rockstars"?
If forms and database queries eat up a large portion of your time then I'd suggest to look into proper frameworks. In fact, that's what web programming is about these days: Find ways to make the common tasks as easy as possible, without sacrifying performance or flexibility.
You don't want to spend the lion's share of your time on creating forms and views. You want to spend it on making the creation of forms and views so easy that the friction for actual feature development approaches zero.
If web programming isn't all about validating and storing data (the tag is even called <form>), and retrieving and formatting data (into HTML) then what is it?
Ultimately all programming is about "garbage in / garbage out" or, as you put it, input, validate, store, output.
Summing up a specific programming domain like that is a bit like saying "architecting a house is about placing walls, doors and windows".
That statement is ofcourse true but it falls short of describing the real challenge which consists of deciding how and where to place said walls and doors under the premise of what we're trying to build (a train station or a shopping mall?).
Similarly, if you're spending more time on writing forms than on the features backing these forms then you're probably doing something wrong.
Not all programmers were born to be architects, not all architects were born to be programmers either. There is enough special knowledge that goes in to design, engineering and assembly that there is room for specialization.
A really good coder can work just find with a really good 'architect' (systems analyst). "rockstars" tend to work only well with themselves, so they probably aren't part of a team to begin with.
The whole idea of teamwork is to work together but to let each individuals special talents take precedence.
If you are all three disciplines in one person then most likely you'll end up founding some startup.
Given the goal is to make money I know which kind of team I would prefer. I'd definately prefer the one that automates everything out of the way as soon as possible because in an IT-heavy operation that really is one of the most basic dogmas in order to maintain momentum in the long term. If your goal is to cash out fast and close shop in 2 years then fine, spit and glue may be just right for your project. If your goal is to build to last then you'd damn sure better hire people who know what they're doing.
Also an rock star secretary can work smart rather than hard finding ways to remove repetition.
A janitor could be a rockstar if they used methods to clean an office space to extreme detail with utmost efficiency.
Admittedly the more work moves into the physical world, the harder it is to scale with simple mental skill, but programmers are not the only ones that can become "rock stars." Also, WPM is not as relevant a way to measure a secretary's skills any more just as it isn't a way to measure a programmer's skills.
@brl: I know you just wrote a sentence, and this really isn't a reply to directly to you, but more to the elitist us and them content of this forum.
My point is simply that the quality of developer talent at a software company will permanently influence the future of that company in a way that can't be compared by simple analogies.
There are good reasons to be more concerned with hiring the best programmers you can find than hiring the best secretary or the best janitor.
you can't force creativity. of course, not all programmers need to be creative, but some do have to be.
i agree though, it's a bit foolish to expect all your programmers to be "rock stars".
Now, some of my "fun" might be in prototypes or similar concept testing or learning - lately it's been parser combinators - but ultimately it's all applicable to my day job, working on compilers.
This is the kind of day job one doesn't see here in Bangalore! Hereabouts everything is enterprisey this, soa that. :-(
To top it off, I have to update three timesheets daily.
Ouch!
I think any employee that you hire should be questioned regarding what project they have been inspired by. I would ask something like: "Talk about the last 2 or 3 projects you worked on ( personal or work-related ) where you felt 'extremely' to 'incredibly' inspired"
Dr. Egon Spengler: I collect spores, molds, and fungus.
Many works of creativity happen when there's ideas or feelings inside that are dying to get out.
There are people that are all talk, and no game, but then they are people that can really produce code faster than you can think about a feature. Also, some of these people are able to do things that are too complex for any average programmer to even grasp. Things like implementing a very efficient interpreter, parser for a dynamic language, it top of something else, is only domain of people that really know their stuff. Sure, I worked on a interpreter, for a fictional language in CS class in college, but doing it for a production level language, is a totally different ballgame.
As I said, management might be impressed by people that know how to talk, but a good programmer will only be impressed by people that really can code and get done things better then them.
The only way to recognize one, is to work with one.
Secondly, not all things that need programming are "fun". Some are downright tedious, but nevertheless important.