Don't hire a programmer if they don't code for fun(jdconley.com)
jdconley.com
Don't hire a programmer if they don't code for fun
http://jdconley.com/blog/archive/2009/01/19/dont-hire-a-programmer-if-they-dont-code-for-fun.aspx
14 comments
But in a early stage startup you better off with few of the rockerstars types, then a lot of average coders.
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.
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.
in a early stage startup you better off with few of the rockerstars types
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.
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.
Rands in Repose has a useful take on "Rock Star" programmers; he calls them "Free Electrons."
http://www.randsinrepose.com/archives/2005/03/20/free_electr...
http://www.randsinrepose.com/archives/2005/03/20/free_electr...
I agree with you completely. "Rock Star" programmers, or programmers who at least have that "Rock Star" mentality, are clever enough to realize that doing a shitty job on a project they openly dislike means in the future they won't have to work on projects they dislike.
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.
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.
We just call them rock stars.
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.
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.
I prefer "silly" to "mind-numbingly foolish", but I don't think he does himself any favors by using the term.
Yea, silly works.
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.
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.
Oy... if we're talking image... do you really want to be a "professional programmer"?
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 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.
if I correctly remember that movie it didn't end too well for the professional ;)
I respectfully disagree. He died protecting someone he loved, taking out an evil guy in the process. Thats as good a death as I could ask for.
Dude! Why do you have to post spoilers like that? Yeah it's far from a new release but still!
I haven't seen it yet and it's on my Hulu queue. Thanks!
Argh!
I haven't seen it yet and it's on my Hulu queue. Thanks!
Argh!
It's fifteen years old now. That's probably older than some of the people who post to this board. I'd have more sympathy for the 'spoiler' effect if the end wasn't also as obvious as a nail in the foot, even though its obviousness doesn't detract from the strength of the story.
Who moderated you up here? You give away the ending of a movie and then figuratevely give me the finger with a too-bad-for-you response and you get applauded for it.
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.)
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.)
apologies, I thought it was so old a spoiler alert would not be required. Carelessness on my part for sure, it's just that to me it is like discussing the ending of 'star wars' or 'the french connection'.
Great movie though, The Professional, go see it anyway, in spite of the spoiler and enjoy the music too.
Great movie though, The Professional, go see it anyway, in spite of the spoiler and enjoy the music too.
> The guy that takes a 10 minute set of verbal requirements, extrapolates, and builds a Web 4.0 Whooziwhatsit in a day, before you even know what Web 4.0 is.
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.
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.
I can. The guy who is always listening for chances to jump in and prove how smart he is, instead of actually hearing what the other person is saying.
Why does he have this need to prove that so bad to other people that it trumps everything? Doesn't he know this himself already?
good point
We have both of those guys on our team. But hey, they do usually get stuff done.
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.
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 secretary who doesn't type for fun.
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 a caretaker who doesn't mop floors for fun.
Doesn't actually work, does it? Why are programmers "special"?
because it's mental work, not physical.
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".
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".
the suggested heuristic obviously works only if a measurable segment of people of profession x practice their trade for fun. but, it seems credible to me in the case of writing software (and not so much for mopping floors).
You should never hire a musician who doesn't play for fun.
You should never hire an artist who doesn't paint/draw/whatever for fun.
Seems to work ok for creative professions.
You should never hire an artist who doesn't paint/draw/whatever for fun.
Seems to work ok for creative professions.
Ah, now we know that programming is an art! Nice discovery!
You should never hire a chef who doesn't cook for fun.
Trying to lump all of programming into the types of things you have worked on is a narrow view of the field. Programmers produce everything from high art, to plumbing but it's much closer to engineering than a musician. While some parts of programming is creative as a profession you get the full range from creative work to simple trial and error.
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.
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.
Because you can learn typing without loving it and you can learn mopping without loving it. Not so with programming which is ultimately a creative task. I know plenty of people who went through university and learned the mechanics of programming without really liking it. These people will never be good programmers just like most people who wrote essays in college will never be good writers.
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...
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...
Don't knock secretaries. My mother spent a number of years writing letters for her EdD boss, who was close to functionally illiterate. (He was hardpressed to compose a grammatical sentence, much less a coherent paragraph.)
Not so with programming which is ultimately a creative task.
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.
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.
Well, that depends on your environment ofcourse, but I'd say when you're spending 90% of your time on forms and reports then you're doing something wrong. A smart programmer would probably find or build a framework that allows the consumers of said reports to build their own so he doesn't have to continiously waste his time on that.
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.
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.
There are a lot of great tools for building simple forms that talk to databases and generate reports. At some point when it comes down to the things that separate this from from all other forms already created someone needs to actually build the form. It's a boring few minutes and then it's done, but then they want to change something and someone needs to fix that. And so it goes.
You missed the point. A skilled, creative programmer will write their own utility or framework to generate the boring stuff. Assuming they've done that well, feeding the form specification to your form compiler is all there is to it.
I think your missing the point. We already have form generates so filling out a from specification is what the programmer is doing. At some point there is nothing left to abstract and you need to specify what's happening. Doing that is programming and it's boring. For any complex system it becomes repetitive in novel ways such as: What's the best layout for the form? What data are we willing to take? etc. And once that's done you are always going to need to fine tune it which is boring.
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.)
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.)
Defining the specifications of a form could be considered programming, as is defining formulas in a spreadsheet application. In this thread, I don't believe the definition of programming includes Excel users.
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.
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.
If your using Excel for simple data entry that's one thing, but like most advanced forms of this idea it's got a Turing complete scripting language. Access works the same way. If you know nothing about programming you can quickly create a huge mess that almost works.
"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.
"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.
I think your pizza topping selector example is dead on. Because yes, that's your task as a programmer. You deliver a pizza-topping-selector-configurator that has all the flexibilities built in that the client needs and it will be easier to use than actually writing code.
Your job is also to extend said configurator when the client has new ideas (e.g. a new rebate system) but your job should not be to carve the forms for individual pizza's (which probably change by the season) into code. That's exactly where I would draw the line, thanks for providing this example.
I think you are artificially separating "code" from "data" using the pizza topping selector idea. Edit: http://news.ycombinator.com/item?id=445959
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.
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.
It depends what stage the project you're working on is at. Adding new forms to an enterprise-level CRM might be where a lot of (boring) programming jobs are at, but it doesn't preclude creative programmers: those who create a system from scratch that does something that has never been done before.
All Web 2.0 is is forms and reports.
You think, back in the 60s when it was the latest thing, COBOL programmers called themselves "rockstars"?
You think, back in the 60s when it was the latest thing, COBOL programmers called themselves "rockstars"?
That's nonsense, web programming is not (at least not in the general case) about forms and reports.
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 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.
Do you seriously believe that the Web 2.0 kids invented that? Frameworks, code generators, CASE tools, the whole lot have been around for a long time.
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?
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?
Didn't I just explain that in my previous post?
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.
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.
I think the point is that the construction workers don't get to decide where the doors and windows go. In most cases, programmers aren't the architects.
If you work in a team where there is a difference between the programmers and the architects, GET OUT! In a healthy environments programmers get to help shape the direction of the product and everyone should be able to voice their opinions or concerns so that the best decisions can be made.
That depends on whether or not you have it in you to be an architect (or your own boss for that matter) or are content just to lay the bricks according to someone else's plan.
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.
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.
You're arguing idealism; I'm arguing reality. In most cases, programmers serve a role that is closer to the construction worker than the architect.
Sure, and maybe right now is not the time to find a new job, but being treated like a construction worker should not be acceptable to any competent programmer. I'm not arguing that it doesn't happen, just that it doesn't have to be that way. Anyone stuck in those kind of conditions should know that there are better jobs out there where they can be treated like smart, competent adults instead of code monkeys.
I think with almost every comment here cringing at the terminology, people calling themselves (or others) "rock stars" are in the minority
A secretary who typed for fun or a caretaker who mopped floors for fun would actually probably be more productive than one who didn't. More specifically, someone who IMs all night long is probably a faster typing than someone who avoids a keyboard after clocking out.
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.
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.
If you looked for rockstar janitors who mopped floors for fun, you wouldn't find any.
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.
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.
Don't know about mops, but apparently there are people who broom for fun: http://en.wikipedia.org/wiki/Curling
Canada. I don't understand it either.
Canada. I don't understand it either.
That is a killer national slogan, I'd go there just for the country with enough of a sense of humour to use it.
I guess because hiring a mediocre secretary or janitor will not jeopardize a software company in the same way as hiring a team of mediocre engineers.
You would be surprised. A kick ass secretary will make all the "sticky" points of running a company go smoothly. I have seen 2 great secretaries that if they replaced would have a significant impact to the efficiency of a company.
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.
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.
I'm not putting down the contributions of secretaries or any other non-engineering roles in a company.
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.
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 know, it really is possible to be working on something which is the "fun code" in your life. I try to avoid jobs where I don't have real passion for the thing I'm creating.
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.
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.
"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. :-(
This is the kind of day job one doesn't see here in Bangalore! Hereabouts everything is enterprisey this, soa that. :-(
For what it's worth, you don't see many of those jobs in the midwest either... It's all SOA/six sigma/RUP madness here too.
To top it off, I have to update three timesheets daily.
To top it off, I have to update three timesheets daily.
"To top it off, I have to update three timesheets daily"
Ouch!
Ouch!
This is a good example of an article whose entire worth lies in the headline, and there is no real reason to actually read it.
I think it's the passion for what they do that differentiates a "rock star" from someone who just does it for the pay. You can have passion without being holed up in your bedroom programming 24/7.
What if their idea of fun is taking slime samples from ancient damp caves in Northern California and graphing the mold contents compared with other similar caves in Oregon?I am just joking.
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"
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.
I think that fun is the wrong word. Fun would imply laughing and smiling, I think.
Many works of creativity happen when there's ideas or feelings inside that are dying to get out.
Many works of creativity happen when there's ideas or feelings inside that are dying to get out.
Just like photons, "Rock Stars" emit light but don't have substance. I'd rather have a look at a programmers code samples to see if it's elegant, clean and efficient.
You should read up on photons. (I still upvoted, though.)
absolutely not. The rockstars I know (3 on my life), do really produce a lot of code, and get done things quickly (and two of them had to leave early from work, as they family and children to take care off, yet they could produce almost twice the amount of quality code from other people and that's why they are so impressive.
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.
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.
If a programmer codes for fun, he probably doesn't have a good idea of what real fun is.
Secondly, not all things that need programming are "fun". Some are downright tedious, but nevertheless important.
Secondly, not all things that need programming are "fun". Some are downright tedious, but nevertheless important.
Don't ever work for a place that doesn't have fun things to code?
Just because a programmer codes something for fun on his own time doesn't mean he's going to have fun coding your app too.
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.