Slashdot Mirror
The Truth About Hiring "Rock Star" Developers
snydeq writes "You want the best and the brightest money can buy. Or do you? Andrew Oliver offers six hard truths about 'rock-star' developers, arguing in favor of mixed skill levels with a focus on getting the job done: 'A big, important project has launched — and abruptly crashed to the ground. The horrible spaghetti code is beyond debugging. There are no unit tests, and every change requires a meeting with, like, 40 people. Oh, if only we'd had a team of 10 "rock star" developers working on this project instead! It would have been done in half the time with twice the features and five-nines availability. On the other hand, maybe not. A team of senior developers will often produce a complex design and no code, thanks to the reasons listed below.'"
They need 3 times as long to get the job done.
Rock Star Developers, seriously? None of them are that good.
Be seeing you...
The whole article could be summarized like this: "We have no fucking clue how to manage rockstar developers".
If management or MBAs don't click with devs, the project is ripe for crashing.
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
Article is weak on expertise.
1) No, you don't need 10, idiot, you just need ONE, and about a dozen or so relatively obedeient and competent non-novice developers.
2) Those weren't senior developers.
In my experience, anyone tossing off terminology like "rock star developer" is some kind of a poseur.
it's the lack of a single, piercing intellect who is given the power to do their best. You need SINGLE intelligence to coordinate complex maneuvers, and many minds to search out the plain of solutions like hunters of old. Coding is actually quite holistic, occurring in natural stages. Maybe the problem isn't that there too many or too few people; a good software team should be inspirational, allowing the members to spend time for excellence, even if its not obvious (to you, the hiring boss).
No surprise efficiency is an issue in some places; if one builds a "well oiled" machines for it's consistency of action, trouble us not about these tiny changes (in all honesty) that leave managers hoping humans can be better machines. The art you are looking for, and the people, aren't found where that idea lives.
CS majors know the time/space tradeoff, but they never get taught the 3rd, crucial, tradeoff of the set: comprehension!
"Rock stars" - we called them divas in my company - are notoriously unmanageable: many of them are temperamental, don't work well with others, tend to do what they "know" is right instead of doing what they're told, and have an overinflated sense of ego. It's a high price to pay to exploit their expertise.
At any rate, one diva per project, provided a good supervisor is found to manage them and the project is in early development, is okay and probably does bring added value. A team of them however is sure to bring chaos, as individual personalities will inevitably clash. And forget about getting these guys to work on products that are in the middle of their product lives.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
No-one who identifies himself as a rockstar developer is a rockstar developer, and no good developer would call himself a rockstar. The only thing certain is that in any article about "rockstar developers", a few dozen people will wander in and complain that the only reason the world isn't perfect is because rockstars like them just aren't looked after well enough.
So, for all of you thinking about making this claim: if you're so fucking great, go out and start your own business and rewrite every single software product in your own image. Be the rockstar you think you are, identify everyone's desires, and out-compete every other firm on the planet. Internet capitalism is more meritocratic than most forms of capitalism - if you write a killer operating system or office suite or CRM system or time&billing app or whatever, people will take notice. So team up with as many people as your ego will allow (you're a rockstar so you already have considerable savings) and go get 'em, tiger!
One big problem is that many of these so called "Rockstars" are too interested in the technology rather than getting the job done. Technology to them is like fashion, you have to use the latest simply for bragging rights and ego when a proven more mature solution would be the correct descision to take.
This video is funny but makes a simpliar point, the irony being he's promoting mysql as the solution when mysql itself was in itself once an object of ridicule by peoeple who knew what they where doing:
http://www.youtube.com/watch?v=b2F-DItXtZs
The title should read My 6 opinions on senior developers
Sound far-fetched?
Yes.
10 rock stars are as difficult to manage as 10 idiots, every lead knows that the good development team is a balanced one , 2 idiots , 2 experts , and 6 normal guys, never involve an even number of women!! never!!
'Cause we all just wanna be big rockstars
And live in hilltop houses, drivin' fifteen cars
The girls come easy and the drugs come cheap
We'll all stay skinny 'cause we just won't eat
And we'll hang out in the coolest bars
In the VIP with the movie stars
Every good gold digger's gonna wind up there
Every Playboy bunny with her bleach blond hair
And well, hey, hey, I wanna be a Rockstar
Hey, hey, I wanna be a Rockstar!
i assume they mean guys from with Phds from Stanford and MIT? Sorry but it just sounds like all the self-taught C# losers are just jealous.
Just finished a project. Involved were myself and another senior guy - we are both near our 40s (no, it wasn't cobol, it was in fact HTML5) - whom I consider in the rock star group. There was also a junior involved.
Well, I loved working every minute with the senior rock star. The process had a great flow. Reading each other's mind and just fucking go for it, develop and ship it.
Junior was unreliable, didn't add any insight to the team - just barely contributed the minimal and quite trivial things (due to the time pressure we couln't have done it without him, so still he did contribute some value).
But really, I'd work with non-soloing rock star any day. I can not work with somebody who can't follow my tempo.
And it's the same weather I'm in developer or manager role.
Not all developers can be rock stars all the time. Developer-rockstarism requires a fair bit of ground work ... it's a supersaturated state ...bit of a shake and it's gone!
For projects & companies to succeed you need a good balance between the rock stars & others [ well trained, well read, high IQ, high tenacity, high experience, high business, high spirit etc. ] ... If a company lets you pace your self in between these two then you know u are working for a geek-friendly outfit. That's priceless!
I thought the whole point of hiring a senior developer is that he doesn't behave like a rock star, even if some of them do look like Keith Richards...
Ucenje francuskog jezika u parizu i nici za decu i odrasle. www.emanera.rs
To use 7he GNAA at death's door
Description starts by talking about rockstar developers, then makes assertions about senior developers. These two groups are not even close to equivalent. Seniority (generally) implies experience -- not "rockstar" status.
...No, you don't need 10, idiot,....
That's the attitude and one of the things that made my time as a developer miserable. It wasn't enough that I was under constant pressure to meet unrealistic dealines and spending all my free time keeping up with new tech, I had to put up with that kind of abuse and the constant intellect pissing contests and penis measuring.
The other was the fact that you couldn't say "I don't know. Let me research it." Any sign of ignorance or weakness would get you fired or the very least treated like a moron by one's colleagues.
Last year, I saw the National Geogrphic show on Stress. To make a long story short, the guy who was researching monkeys made some observations about them that reminded me of working in software development.
This sounds like a desperate justification for doing it on the cheap. And the "truths" are badly flawed. First, the term "rockstar" is already pretty bad and way off. A very senior engineer is not a "rockstar". Rockstars are people that crave attention and can generate it.
As to the items:
1. Wrong. If you hire highly competent and professional people, the savings in time, maintenance, etc. will be far higher then the higher salary you have to pay them.
2. Wrong. People in the described situation have trouble seeing the big picture, and will get details wrong as well. Their code will basically barely good enough if you are lucky, but it will be a nightmare of maintenance, architecture and design issues.
3. Wrong. This is confusing "rockstars" with very senior engineers. Very senior (by experience and capability, not age) engineers will know this pitfall (hint: Brooks calls it the "second system effect", a really senior coder will know about that) and will know how to avoid it.
4. Well, yes. But what is the point? If the hiring process is run incompetently, of course you will get bad people. That is in no way the fault of the good people that are out there as well. Seems to me the author needed an excuse to bring it up to 6.
5. Wrong. This is a typical problem of people that may think they are senior when in fact they are not. Also see 3 and 4.
6. And here the truth is revealed. This person does not want senior individuals that actually know what they are doing and may criticize as stupid plan. In fact this person wants no individuals on the team, so everybody can be replaced easily and knows it. Yes-men preferred. Unfortunately that is a sure recipe for disaster.
Bottom line: All there "truths" are wrong or irrelevant and show the real problem: The author of this article has no clue and is a "rockstar" himself. But not one of those that can actually do things right. Just one of those small people that cannot handle others being better at something than he is.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Another lame MBA trying to make excuses for hiring substandard workers. "See I told you so! We should have hired H1Bs instead! I put a few assholes who were full of themselves and they didn't get anything done!" The fact is there are tens of thousands of qualified American candidates for programming and other IT jobs. Do they get hired? No, even though they will work for the same wage nowadays in this lack luster Oconomy. It's because businesses want to be able to pay shit wages AND take the tax deductions for hiring H1Bs. That's why I left the IT industry. A bunch of MBA assholes running the show that don't have a clue about what they are doing to their companies or the country, where they are going, or who they are hiring. It's funny how most MBA's degrees don't mean shit, ooooh ooooh tell me how you took macroeconomics again, and how that makes you better than everyone else.
Now I use my programming skills in another industry, make a ton more money, and don't have to put up with corporate asshole MBAs.
Lay back, shut up, and let Angus pound you back into shape <screeching guitar riff>
I swear to God...I swear to God! That is NOT how you treat your human!
and every really hotshot piece of software I have ever encountered (and I'm talking world-wide success here) has been written by a very small team of highly-motivated developers working very long hours at very odd times of day with no management interference at all. They weren't rock stars before the project or they would have been managed into oblivion. After they had completed the product and it became successful, then they were rock stars. The self-motivation usually came from "fuck you, manager, I'm going to prove that my ideas are correct" One of these projects, where I knew the people well, became one of IBM's top 5 most profitable products world-wide (you've never heard of it), and those guys broke every rule in the book. They worked nights, never went to meetings, smoked cigars at their desks, suppressed all records of how many hours they were really working. By working those hours, the two of them held the entire structure of a big application, its database, and all its interactions with the operating system in their heads, and that mental state enabled them to write vast quantities of simple clear code that contained no serious errors on shipment, and none revealed in the first year. Later people added on to the project for subsequent releases never found any serious errors in the backbone written by the first two guys, nor did they have any problems adding to the code.
Code written during the normal working day, with constant interruptions, will never soar like that.
"Cock Up Your Beaver" does not mean what you think. This sig is intended to clog filters and annoy do-gooders
If you have 40 people writing spaghetti code, then you need _one_ good developer and code reviews, and reject bad code until they learn. Many bad developers are bad because they haven't learned how to do it better. Those that can't learn - sorry, but their productivity is negative, so let them go. What you don't need is a dozen "rock stars". You need developers who can lead by example and let them do it, and who can solve difficult problems that turn up, and you need more people who are reliable, not necessarily bright, who can do all the boring bits - of which there are usually lots.
What I can't understand is how the author talks about smart people making smart designs that don't work. If the design doesn't work, it wasn't smart in the first place. If someone creates a design that isn't smart in the first place, that person wasn't smart. So this seems to be about people who can bamboozle others into thinking they are smart, creating designs that nobody understands.
The characteristic of failed software projects is poor management,
Until organizations realize that, they are doomed to fail, again and again.
Yeah, with good project management, even moderately competant coders can produce good results - the problems reported here are entirely due to poor managers, not poor programmers.
The stars can produce excellent results, but not if the management is doing it's best to derail the project at every turn.
Look at the games industries greatest failures :)
The problem with "Rock Star" developers is, that they might lose focus when the job they're doing is too simple for them. They may like to code on your internet-enabled office-style application for a while, but in the end they long for more interesting, worthwhile and complicated matters that are on the edge of scientific discovery.
So eventually you'll lose them, and you're stuck with the code that they left.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
There's quite a bit of truth to the article allthough I'd say that true rockstar programmers do use the right tool for the job. If a programmer builds a custom Java CMS where Joomla would do, he isn't a rockstar. He's an idiot.
Then again, the best programmer in the world is worth nothing without the environment or the right people around him. That includes higher ups that keep people off his back, maintainers that can handle the pipeline and clear objectives to work against.
If a rockstar doesn't have those, he'll be faster than others in producing workable stuff, but if he gets hit by a bus it will be just as much worth as the other unfinished stuff.
Many programmers I know hat are considered rockstars are quite mediocre. They only were at the right place at the righ time and didn't have any scruples in building a complex key product only they could understand, without docs, concept comments or usecases, as a means of job security.
My last teamlead was a nice guy and a demigod in Perl, but absolutely incapable of any sort of productive or result oriented teamwork-organisation or inter-team communication. In itself not very rockstarish, allthough people did think of him that way when he saved the day on some billing system or something every once in a while.
Bottom line:
Rockstar is always relative. Very relative.
We suffer more in our imagination than in reality. - Seneca
Existing teams where everyone has know each other and worked together for a long time have their own functional relationships, but for new teams you kinda need a hierarchy.
I don't think this matters if its a team of developers putting together an inside sales support system or a team of carpenters putting up a barn. You simply can't have a team of all equals because if you do everything becomes a debate and no actual work gets done. Or even worse everyone needs to shine and get some recognition outside the team and so is pushing for their 'plan' so they can be the hero.
You have to have some social order. Teams are happiest when the guys at the top are their tacitly because of their widely acknowledged talent, and or successful experience. It really helps if those guys are also personable but is not always a requirement. Nobody wants feel someone has arbitrarily stifled their career so that Bob can be tech lead. OOTH some competent but not so senior developers might love working with RockStar Bob on a project. They would feel its an opportunity to learn how Bob does does it, technically or socially, so they can use that knowledge going forward for their own gain.
In the mean time you'd hope Bob is happy that he has some people he can farm out tasks to and after pointing in a general direction, perhaps even taking some feedback, can just leave them to it without having to hold their hand the whole time or worry he is going to get 10KLOC of useless spaghetti as a 'deliverable'.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
... is not rockstar developers it's that making and understanding how software will perform and it's impacts is a hard problem. It's not like engineering where the laws of nature are relatively fixed and known and is a matter of trade offs (time vs cost), ANY change to a program has potential impacts and ripple effects on all other subsystems effectively changing program behavior to some extent. The real issue is the tools for software development and making these things understandable in complex systems is a hard problem. It's a matter of framing problems and solutions in ways that you can actually understand their impacts. Too much software development is undefined and uncharted because of the nature of coding itself. There is a lot of research going on in visualization trying to make these ethereal systems of code easy to grasp and understand in ways that are much easier and more natural for our senses as human beings.
http://www.allosphere.ucsb.edu/
It's a matter of being able to grasp what is that you are trying to do and it's impact. Most developers (even rockstars) have issues with not even knowing where they are headed and what will be needed down the line as projects grow and outstrip human ability to understand them. Software has long since passed the complexity where the human mind has the ability to full grasp all the complex interactions. The real problem now is getting the research and data to make demystify this complexity (i.e. complexity partially being a synonym for not being able to see/understand what a problem and solutions are and it's impacts).
If I think 'Rockstar devs' Todd is the first person who comes to mind. Todd designed the first commercial graphics tablet and had it released by Apple, was an early (and flagship) user of the Video Toaster and released arguably the first interactive album which he helped code for Phillips CDi.
Do we have any other notable examples of people successful as both devs and rock stars? There have to be more than just Todd.
How about hiring COMPETENT developers to begin with? the companies that have those problems have the fault lie with the management. managers that cant actually manage, pay scale for the actual developers is too low, budget for the department or project is too low, and the upper management focus is not on quality, but on profitability.
Yeah, let's lay blame on the guys that are actually doing the work. In reality, every failed project has the person managing it to firmly blame for it's failure.
Do not look at laser with remaining good eye.
I never have mod points when I need them ... Well said.
Religion: The greatest weapon of mass destruction of all time
A slgihtly different definition to the one in the article but the only rockstar developer I can think of off the top of my head is Notch - I don't know when it happened but suddenly everyone knew who he was and he has legions of fans all over the internet. That seems to have died down a bit now but it amused and pleased me to see a developer elevated to the level of rockstars.
Wonder if he got groupies?
We've known about this issue ever since we started to write complex code. The classic reference is 'The Mythical Man-Month'.
The case can be made that one or two really good programmers will do a better job than a team. That seems to contradict TFA.
A truly terrible manager will ruin a project, even if you give him/her the best people.
Rock Stars make great performances not great software.
Ego has little place in software development and in most cases those that consider themselves 'Rock Star Programmers' are suffering from a chronic case of Dunning Kruger syndrome
Great Programmers are masters at listening and comprehension. They are humble, asking questions before offering solutions. They not only accept criticism they solicit it. Their code is simple and elegant, capable of being comprehended by the most junior and appreciated by experts.
You've got it quite backward. In most cases, it's the "divas" and "rockstars" who forcefully suggest the use of certain technologies solely because they're "trendy", rather than out of any technical merit.
So the software product ends up getting built as a web app using Ruby on Rails, NoSQL, and JavaScript. Then it goes live, and it's a complete disaster. The Ruby on Rails code ends up being horribly slow, with all sorts of performance problems. Furthermore, the code is damn near unmaintainable, since the "rockstars" insisted on using techniques like monkey patching. Of course, the NoSQL database is a pain in the ass to query, and the data quickly becomes corrupt thanks to a complete lack of referential integrity and other constraints. Sometimes it just loses data completely. Then there's the front-end JavaScript code. Besides being slow, it also only works correctly on some browsers. The users hate the new web-based UI, because it's less productive than the native apps they were using before.
When a software project with no code goes bad, it's usually because of "architects". When a software project with code goes bad, it's usually because of "rockstars" or "divas".
That's a ho hum salary for programmers with experience. That's less than $50/hour. Ten years ago, I knew Unix people in the financial area ( NYC ) making 50% more than that.
It isn't just the money that makes a programmer work harder. A good working environment ( not the physical ) gets people to be more productive. Things like flex time, tele-commuting and accessible day-care goes a long way towards fostering an effective work force. Trust and respect goes a long way.
Oh, well, not going to happen with all the psychotic managers running the place.
CPT (Chief Programmer Team) had one chief programmer (your "rock star") that could carry out design, but was not necessarily the team leader. The chief programmer would guide other programmers in the task of programming, but the project leader would make sure schedules were kept. Frequently the chief programmer would also be the project leader, but it wasn't a fixed rule.
Well, most tuthes in the article are perceptions of the auther. Not truthes.
The whole article is rather mood anyway. I so far never was in a project where the development team needed managing/management.
The project might need management ... defining what is in scope, what is out of scope and what is done in what timeframe, basically talking to external stakesholders.
But a team? What do you want to manage in a team? Let them define their work alone ... if you have 10 senior developers that should be no issue, if youo have a team with only one it might be difficult. Best teams imho are 50/50.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
He is projecting his own incompetence and poor work ethic onto all senior developers.
Meanwhile rock star MBAs run rampant collecting bonuses by forcing 2 developers to do the job of 10 while working on an ever tightening schedule. To hell with quality of product, it has to ship by yesterday otherwise the investors won't give the C*O his bonus for the quarter. If the company sinks the rock star MBAs just float their parachutes to the next company and rehire everyone at even lower salary.
I am a Mechanical Engineer but I also have a CS degree. It was interesting in school to see how software engineering being a relatively new field is struggling with what other engineering fields have had to deal with for a long time.
Staffing a project is not a linear function. A project with twice the complexity doesn't take twice as many people. It may take 4 times as many because now you have to coordinate those people. This requires project managers and system engineers. This begs the question what is the right project size for a team?
I've been on small teams that have done amazing things in limited time because we were all in one room without distractions. I've also been on large projects that have gone nowhere because nobody knew what to do.
Very occasionally I've been on a large project with a good manager that can break the project down into subsystems with clear requirements small enough for a small team to handle. The manager handles the conflicts with interfaces between these subsystems but otherwise stays out of the way. This is the type of manager I like to work with.
I love Jesus, except for his foreign policy.
A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: "How long will it take to design this system if I assign five programmers to it?"
"It will take one year," said the master promptly.
"But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?"
The master programmer frowned. "In that case, it will take two years."
"And what if I assign a hundred programmers to it?"
The master programmer shrugged. "Then the design will never be completed," he said.
Also, I'd treat anyone calling themselves a "rockstar anything" with suspicion. What they're telling you is that they're flashy, have a huge ego, expect to be treated and paid like royalty, may have a drug habit and might possibly (but not probably) have some actual singing ability.
My personal experience hiring rock star developers led me to believe they're more of pain than they're worth. I'd rather hire the number 2 programmer with a better attitude.
Rock star developers most often work the hardest at feathering their own nest at the expense of everyone else on the project. Trying to become immune to layoffs and working themselves into a position they can demand more money.
Many of them will keep junior programmers from learning enough to be really useful and are ultimately counter-productive to the health of the project.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
Except they/we are rockstars because they get the job done, despite a bunch of MBA's trying to stop them. I agree with him about too many senior developers, they cancel each other out. I've use teams of 3-4 people, usually one rockstar and 3 who are happy to play second fiddle and follow his lead.
When I've done the rockstar roll (before I moved into managing them). The number of times I've had ineffective programmers try to trip me up. A typical pattern is the 'spec says X', I'm well into the spec, X is already written, a programmer on some other platform is falling behind and hasn't gotten to X yet. What do they do? Typically they will start changing the spec, now X is Y and I have to go back and re-implement X as Y.
Do this often enough and I have to WAIT for the slow coach to decide what he's going to implement from the original spec. before I can clone it on my platform.
Then there's the IBM type guys (I think EDS are the same, but I haven't personally had experience of them yet). I couldn't get them to code at all in any way. I'd receive a mountain of design documents for the most trivial of things, and a million excuses why it would take 10 years and more resources than we had. If I simply went ahead and coded their part, they'd send in the 'Rock Star Business Analysts' to claim it's spaghetti code and the distraction of it was the reason they couldn't code their part.
I've seen IBM do a hatchet job on a Danish software producer, so much that the Danish company refused to continue with the project. Yet I never saw an IBM guy deliver a single line of code that tackled a single problem. All they every did was produce meetings explaining what is wrong with the code (which was nothing but a few bugs they were hired to fix but didn't).
That's the other problem superstar programmers face, superstar bullshitters whose real agenda is to delay a project.
I often think there are superstars in every company, and the difference between a Google and a Microsoft is that one company can tell the superstar developer from the superstar bullshitter, the other can't.
You just need a really strong lead but programming itself works better in a mixed team. Too many great minds in the same project might just make the project stale.
How many people on here are taking this to heart and going on the offensive? Brilliant.
well the union job training ideas are needed over say just pure classroom. The tech / trades schools do better but they can use a on the job training / apprenticeship part as well.
These days, sadly, /. is increasingly regurgitating any bullshit article they know is going to get developers/IT staff/geeks 'inflamed' with righteous indignation.
It's perfect because they get all the site traffic without being seen to be agreeing with the opinions of the author.
Feel free to Reply with your righteously indignant refutal of the BS article.
What about TPS reports / poor metrics / rushed time line / high over time.
Stuff like that leads to poor code.
Also how much documentation do you want them to do any ways??
nothing really changes..
Just remember the Golden Ratio: 3 Brogrammers per RockStar (and certainly no more than 2 Ninjas per team).
He considered a bunch of knuckleheads who over engineered because they are bored rockstar developers? Being a star developer includes having common sense. Just because you can punch out code quickly, does not mean you are a star. Being a star includes common sense. This guy does not know the difference.
About junior people writing better code than senior people when the code is simple. Again, that is only the case if the senior person is a knucklehead. People with alot of experience can get stuff done faster. Junior people will still need help and need some reviews. The other issue that junior people have is they may find 1-2 ways to solve a problem, but senior people have seen lots of different things and have more options at their disposal (this does not include making stuff unnecessarily complex).
Mixing Junior/Senior developers is a good idea, so that the junior guys can learn from the senior guys. Smart Rockstar developers will learn from Junior people too because you will never know everything. The smart senior guys are articulate enough to help the junior people out. I do agree that a project is about a team and process. Alot of the success of a project is based on the management and the processes in place. When you have incompetent managers and silly processes, you end up with delays.
A technical person irregardless of skill set (DBA, SA, Tester, whatever) who lacks the common sense to keep things as simple as possible is not and never will be a rockstar. They are just a nuissance.
They didn't have the budget for unit tests, realistic deadlines or an architect. They probably adopted "Agile" and had the project manager set all the deadlines, using the process mostly as a method of flogging the developers. And they probably never had clear requirements. You don't need rockstar developers to insure a project success. You don't even need rockstar managers. You just have to put some thought into the project, and that, sadly, is what's lacking in most of these badly-executed software projects.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
...I would rather hire a classically trained pianist.
I am very small, utmostly microscopic.
They shouldn't be titled "THE truth about..." since they're seldom true, complete, or offer any proof. This one has nothing but a bunch of opinion.
Can we vote down submissions to slashdot so we can start getting less slash and more dot?
and every really hotshot piece of software I have ever encountered (and I'm talking world-wide success here) has been written by a very small team of highly-motivated developers working very long hours at very odd times of day with no management interference at all. They weren't rock stars before the project or they would have been managed into oblivion. After they had completed the product and it became successful, then they were rock stars. The self-motivation usually came from "fuck you, manager, I'm going to prove that my ideas are correct" One of these projects, where I knew the people well, became one of IBM's top 5 most profitable products world-wide (you've never heard of it), and those guys broke every rule in the book. They worked nights, never went to meetings, smoked cigars at their desks, suppressed all records of how many hours they were really working. By working those hours, the two of them held the entire structure of a big application, its database, and all its interactions with the operating system in their heads, and that mental state enabled them to write vast quantities of simple clear code that contained no serious errors on shipment, and none revealed in the first year. Later people added on to the project for subsequent releases never found any serious errors in the backbone written by the first two guys, nor did they have any problems adding to the code.
Code written during the normal working day, with constant interruptions, will never soar like that.
That happens but it is rare. I too have been doing this for a long time, more than 25 years. It has taken me a while to get my head around how to create an environment for the team where success can be replicated. In my experience what was described, what I call coders in a cave, can be extremely successful but it is rarely replicated. While the developers involved can often reflect on what they accomplished they can rarely replicate it again. What you (and I) have experienced is amazing but it is somewhat down to being a huge coincidence of timing with respect to developer/team abilities, market knowledge, energy levels, management attention (or not), etc. It happens, but it is rare. I have also been on very successful projects that were built using processes that are highly interactive with management and basically the opposite of what was described. But, I prefer to find a balance in the middle, one that allows some of the freedoms of coders in a cave but with the feedback and guidance provided by the parts of the company that matter.
For a company that is trying to create an environment for success I would suggest that you need to think about process more than rockstars. Rockstar is a management term BTW, as true rockstars are very humble and most often just consider themselves to have a 'good' way to get things done, not the only way.
For the management types out there:
1. Focus on a 'rockstar' R&D manager, someone who lives to drive the process but understands when to drive and when to get the hell out of the way
2. Make sure your infrastructure is there to guarantee throughput. The larger and more complex the project the more important this is. Pay attention to the little things that keep developers happy, do not cheap out on systems or networks.
3. You need a single architect to be in charge of the overall design even if you have a team of architects as nothing will kill a projects momentum more often than the 'architectural committee'. Even in large scale projects that single architect has to make tough design decisions that can only be made in developer land. Managers please step aside
4. Do not promote your best developers to be managers, hire great managers to be managers if you need them. Pay your top developers more if you want to make them happy. In my experience the best developers are not corporate ladder climbers anyhow except when they think they have to be to improve their lives at home (which never works out) so just pay them more AND/OR
Fucking faggets.
If you're not a rock star manager, you vastly overrate your ability to identify, attract, hire, and retain rockstar developers. You're far more likely to hire people who have massive egos who don't realize their own faults, and who can succeed in pulling the wool over your eyes because you don't know any better.
Except they/we are rockstars because they get the job done
The problem with rockstar developers is they often write code that mere mortals cannot read or maintain.
Sure, they can whip out version 1.0 or impressive enhancements quickly, but if it becomes a maintenance nightmare later, isn't the cost just being shifted from up front to later? Rockstar developers are often more trouble than they're worth.
Good, solid, dependable non-rockstar developers are better, in my experience, because they're more likely to write code that their colleagues can actually maintain later.
FTFY. Also, that's why the developer unemployment rate in CA and NY is 7-8% and why it's 3% in the Midwest.
This.
I think the problem is that very few managers, even people with technical background, have a good idea about what a top developer/software designer should be like. In my interviews I've been asked to demonstrate what design patterns I know, I've been asked about intricacies of programming languages (such as C++ templates), I was asked about all sorts of technical know-how.
Yet I've never had anyone ever ask me about the maintainability of my code (beyond asking about coding guidelines), or clarity and simplicity of design.
All the while IMO this is the very mark of a great developer - the ability to find elegant, maintainable solutions to any problems.
It's actually quite baffling to me why managers don't look for these things - the 'Keep it Simple Stupid' lesson has been in their books for decades now
'Cause we all just wanna be code rock stars
And live in suburb houses, drivin' hybrid cars
Mod points come easy and ideas come late
We'll all stay horny 'cause we just won't mate
And we'll hang out in the coolest threads
About kernel scheduler overheads
Every bitcoin miner's gonna wind up there
Every ESR fanboy with his unwashed hair
And well, hey, hey, I wanna be a rock star
Hey, hey, I wanna be a rock star!
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
Don't forget if you hire Rock Stars you also need to hire those Little Mouse types that can scurry around doing all of the little things like fetching a "Cinnamon Soy Latte with extra whip and a dusting of dark Cacao" and a bunch of BLUE peanut M&Ms.
(and yes this might be a Jug of Double strength Merkat Coffee and Bison jerky (Ghost Pepper flavoured) but ....)
Any person using FTFY or editing my postings agrees to a US$50.00 charge
The problem with Rockstars is that they insist on re-inventing the wheel. Managers do not have the technical expertise to say no or the brows to keep from being brow-beaten into accepting it. It usually turns into a tar pit.
For some historical perspective:
http://en.wikipedia.org/wiki/Union_violence#Labor_unrest_in_1892
For a more recent example:
http://en.wikipedia.org/wiki/Pinochet
If that isn't enough, I can come up with more. An economic system that put control of resources in the hands of a small minority of the wealthy tends to be supported by violence.
USA only of course. Most US citizens couldn't find Canada on a map, less correctly identify it as part of North America.
If your children ever found out how lame you are, they'd murder you in your sleep
Im surprised that nobody has mentioned that Edward Yourdon has written a book or two about what happens when projects go BAD.
In the situation given the best thing to do is send in a Forensics Team to extract what bits can be transplanted and then START OVER.
Any person using FTFY or editing my postings agrees to a US$50.00 charge
For their proclivities, unreliability, flashes of brilliance (when in the view of an adoring audience), and total degeneration (when out of the public eye). Blood-doping notwithstanding, you want a Lance Armstrong to lead your team. He keeps his eyes on the prize, knows what it takes to succeed, and is willing to let others take the lead when necessary for the success of the team.
Indeed, the article is not actually talking about "rock stars" but about poaching senior developers. It is also quite possibly the most perniciously agist thing I have ever read. "People do their best work when their head is barely above water," huh? How about the "truth" that the person who's "slogged through it 100 times before" also knows where the pitfalls are? The entire article reads like a bad stereotype of crotchety old developers too arrogant to follow directions.
I sometimes ask revealing, often ignorant-seeming questions. Maybe they're harder to answer than you think.
A senior developer is more like a great studio musician. The person everyone wants for a recording session because he/she will make the product sound great.
A rock star is the personality who jumps around on stage, grabs his crotch, bites the heads off a few chickens and otherwise puts on a good show for the audience. He or she could be a good musician as well. Or not.
In the development world, rock stars are usually brought onto a project by management to impress the board of directors, customers, etc. Once, they may have done something great. But by the time they have achieved developer rock star status, they are coasting on their past achievments.
OK, give the guy a tambourine. But don't mic it.
Have gnu, will travel.
Funnily enough, the only time I was ever described as a "rock star" developer was by a company that wanted to hire me, but it was quickly obvious that what they actually wanted was "yes men". The CTO literally said in interview "If I tell you what to do, then I will not tolerate any discussion or debate, you just have to do it without question". I'm thinking, why hire someone at that salary level if you just want to bark orders at them (I'm 40, with 17 years in the relevant industry).
(That was only one out of four red flags I got *during interview*. So glad I declined that offer.)
If making a change requires 40 people in a meeting, you don't need to change the developers - you need to fire the buck-passing assclowns in management. Of course, a manager-focused pub like Infoworld certainly isn't going to tell THAT truth...
I'm a porn-star developer!
The best outcome of a project I have ever been a part of was during a project for an unnamed automobile manufacturers website. The project was far behind when we came on and the original development group was let go. :-) We put together a group of a few "Rock Star" developers together with a group of experienced developers that we knew form previous projects would take direction and understood design. It was only because of the urgency of the project and the potential profit that management allowed us to form this group. We placed them in what we used to call the prison. They were not allowed contact with the rest of the project team (Business, Graphic Arts, PMs etc). I had short standup meeting with them every morning. Then the "Rock Stars" rocked away. They implemented an elegant, workable, well executed design. There were 12 of them when normally we would have used more like 25 or 30.
My point being they were real "Rock Stars". They could design and code. They were not above doing the actual work. The idea that there are only two kinds of developers: ivory tower academics who know UML and Patterns but can't code, and spaghetti coders who hack through crap but get it done, is the real problem. We hire everybody who can understand an if then statement as a developer these days. What needs to happen in the development business is that hiring managers need to learn that developers are not all equal and resumes can lie.
No sigs in BETA. Beta SUCKS.
A report authored by lawyer Ian Temby, QC and accountant Dennis Robertson found that $20 million was paid by the HSU without any form of tendering or contract. This included $5 million paid to companies operated by former HSU boss Michael Williamson and his wife. Prime Minister Julia Gillard commented ‘‘It’s clear that there have been real problems at the HSU. That’s distressing I think to everyone who cares about working people.’
4 years and counting since this scandal became public, but no serious action due to protection by union mates:
The former HSU national secretary (and Labor MP) Craig Thomson, faced allegations from 2008[4] that he used an HSU union credit card to pay for escorts, and other financial improprieties with the card. Amid the allegations, the Australian Council of Trade Unions (ACTU) suspended the HSUs' membership.[5] Thompson maintained his innocence, but in May 2012 a report by Fair Work Australia recommended that civil court action be taken against Thomson for what the report says was a "substantial misuse of members' funds".
The worst part about this is that the majority of the Health Services Union members are lowly paid female staff.
Software engineering is definitely plagued by all sorts of "self-taught" idiots who are only doing this because they have heard about all the dollars that can be made in this industry.
If the management talent/scum would only hire people who know the basics (things like algorithms/data structures), there would not be so much crap software and so much abandoned projects around. If "management" weren't Clueless Fucks, they would appoint one of them as the "technical director of project XXX" and give this guy sweeping powers to ensure that all the technical parts fit together nicely. Instead they try to fuck with the details and promote those who can talk nicely but have very few hard skills. But salesmen don't get systems working reliably. All they can do is to sell stuff or to show off nicely in the meeting room.
This industry is full of incompetent people and arguing for mediocrity is plain insanity. If companies would actually hire proper Computer Science people (those who know the difference between a proper Hashtable and the fuck that comes with MFC, for example), their software project would succeed like they do at Google. They only hire the best and brightest.
Rockstar knows how to tune hashtables, when to use tries, how to optmize multi-threaded access to a single harddisk. Rockstar is not a CS bureaucrat and he will code at least every second day. Rockstar is not an expert in Powerpoint and all those blinky-blinky tools. Instead, he queries text and code files using bash, awk, perl, sed, grep, bash.
Overconfidence in a developer is a major flaw.
It makes them arrogant. THAT makes them difficult to work with.
Everytime I see a job request looking for a "rock star" to join a team, I do not bother any further.
If they want a rock star, then they don't want me. I think they don't have a clue and it will just make my life hell. There are better jobs.
It is like the "idea man" who just needs a dev to knock out a week of work for his $500M idea to be achieved. Idiots.
For example, look at the Qt and GTK devs who decide that backwards compatility isn't important. Arrogance. Idiots. They may be fantastic developers, but they shouldn't be allowed to develop code because of these personality flaws.
The key observation is that, in most things in life, the dynamic range between average quality and the best quality is, at most, two-to-one. For example, if you were in New York and compared the best taxi to an average taxi, you might get there 20 percent faster. In terms of computers, the best PC is perhaps 30 percent better than the average PC. There is not that much difference in magnitude. Rarely you find a difference of two-to-one. Pick anything.
But, in the field that I was interested in -- originally, hardware design -- I noticed that the dynamic range between what an average person could accomplish and what the best person could accomplish was 50 or 100 to 1.
Given that, you're well advised to go after the cream of the cream. That's what we've done. You can then build a team that pursues the A+ players. A small team of A+ players can run circles around a giant team of B and C players. That's what I've tried to do.
(Steve Jobs, In the Company of Giants)
http://www.businessweek.com/smallbiz/news/coladvice/book/bk981106.htm
if you act like a rock star, then you had damn well better be a rock star coder.
The Kruger Dunning explains most post on
And I say "I don't know. Let me research it." at least once a week. Sometimes multiple times a day.
I think your employer sucked.
I slightly disagree with you about point #1. The majority of tasks that have to be done for most projects do not need great developers. When I pass off work to junior developers, it is usually because I know they will do it just as fast as me. If we need code to map data between persistent storage and DTOs, I am not going to write that any faster than a fresh college grad. And my company pays them about half as much. They would rather me be working on something where my experience and ability provides them far more than twice the productivity as junior developers.
If you only have "rockstar" developers, you are overspending for much of the work they are doing.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
expensive crack-heads on my development team? http://alcoholism.about.com/od/slang/g/rock_star.htm/
The article reads to me as worse. Infoworld is posting an article that basically suggests senior level developers aren't worth the price tag. It's merely a ripe lump of FUD in an effort to depress salaries.
The best outcome of a project I have ever been a part of was during a project for an unnamed automobile manufacturers website.
It's a web site. Web sites are rather routine jobs by now. For an auto web site, most of the effort should be going into the graphical design and marketing, not the underlying machinery. Some ridiculously fancy sites with interactive 3D models have been built, but they don't sell cars. Read Lutz's "Car Guys vs. Bean Counters".
There are times when you need really good developers. Real-time control. Advanced mobile robotics. Real-time financial trading. Optimizing compilers. Database internals. Digital signal processing. Speech recognition. Image processing. MMORPGs.
Web sites,no. 3-5 years of experience and a string of competently completed jobs.
There are different types of rockstar coders. One type will get shit done under ridiculous deadlines. The other will write great code quickly and meet sane deadlines. Most of the time you want the later. Sometimes, you need to bring in your pinch hitter (the first group) and get stuff done. Most of the really bad spaghetti code can be mitigated by having good requirements and not wasting your rockstars on stupid, simple projects, and of course, strong helpful management.
I think rockstars get a bad wrap precisely because they are called in to fix things when projects are getting over deadline for the exact reason that the requirements suck. You really can't hold them accountable for spaghetti code or not exact solutions when the project requirements were the reason they had to step into the mess in the first place.
"The problem with rockstar developers is they often write code that mere mortals cannot read or maintain."
You need to learn you job if you can't read or maintain code, that's a deficiency in you. Your employer can always just hire another superstar programmer who CAN maintain code.
Do you imagine that the company is run down to the level of it's most incompetent staff? Is that a recipe for competing in the world? Do everything at the level that your most incompetent staff can do it???
A thousand times this.
There's a lot of prima-donna developers in this industry who think they're hot ####. And they think they're rockstars, this all comes back to the time when Silicon Valley marketing wonks wanted to turn the s/w developer professional into some sort of "rock star" capable type person back in 2007--to glamorize the profession? ...that surely crashed and burned, much like TFA.
And is usually takes that one project you successfully worked on to fall into that psychological trap.
TFA talks about these people, not the true Rockstars that are likely generalists and know that this is a business: use case, budget and time is all that matters and get the job done with a team.
I do agree with the OP that creating the educational environment is critical for a successful team though.
Sex and drugs and source control
Is all my brain and body need
Sex and drugs and source control
Are very good indeed
Thank you!
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
You hire a Rockstar developer when you want a Grand Theft Auto game made.
Am am aware of that and I agree with you. (Comment was to the point as much as possible, this is ./, after all.) If these are competent and professional junior developers, you can and should do that and you should have them available just for that. If the junior developers are incompetent or unprofessional, handing off work causes more trouble than doing it yourself.
Let me clarify 1 to say, "competent and professional people, for the specific different levels of experience and skill needed in a project"
I should also say that I view being competent and professional more as an attitude or a goal in life. Sure, junior people will get it wrong more or less often. But the competent and professional ones will realize and try to do better. In particular, they will first invest a reasonable time to figure it out themselves and then ask somebody with more experience. And if the person with more experience is competent and professional, it will realize this is a great opportunity to contribute and spend the time and effort needed to explain what went wrong and how to avoid it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
The people who make complex designs are the show-offs. You don't want those. Good programmers solve the problem with the minimal amount of effort, carefully placing few well designed features at strategic locations to make the problem fold itself.
Then those features can be turned into small amounts of code which is designed to be readable first, and only optimized if it's really necessary.
One of the measures of someone who is good at what they do in a creative job is being able to get shit done, even if it is a difficult or stupid request. It isn't about being "right" it is about making the customer happy.
All the developers that I respect the most (I'm a sysadmin, not a developer) are the ones who are able to solve stupid problems, problems that shouldn't have to be solved, and solve them well. They will call me and bitch about how retarded the client is (I swap 'stupid request' stories with a friend at least once a week) but in the end they make it happen, make it work well, get it done on time, and make the client happy.
If we are going to put a silly label like "rockstar" on it then that is what I define it as. They are the people who can get shit done. It may involve stupid specs, changing specs, and so on they still get it done and don't make a hash of it.
Any programmer should be able to implement something based on well defined, detailed, unchanging specs for a clear and simple problem. It takes a much better programmer to deal with half done, changing specs on something stupid and ill defined.
Often the "Rock Stars" are either programmers who self identify with this and often have some form of seniority; or are blowhards who have the upper management sold on their amazing mad skills. A quick bit of digging will turn out that the database "overhaul" that he did in one weekend that would have taken mere mortals 6 months that resulted in the reports running 20x faster was actually an upgrade of an 8 year old server with an 8 CPU SSD drived, 64GB beasty; so a 20x improvement is actually a bit of a disappointment. Another sign of rockstars is often certifications coming out of the wazoo. I agree with previous posters: Cowboy is probably the better title.
Sometimes the RockStars are stupid but it is even worse when they are really smart. That is when they start coding in assembler knowing that they are creating a dependency on them of mega proportions.
A term I like is rarefied programmers. These programmers are usually quiet and usually leave people scratching their heads; not in confusion; but with puzzlement as to why they didn't see such an easy solution. The code is usually small and understood by all. Often things just get done and all around them benefit. An interesting way to detect these programmers is that they use an odd mix of the old an new. They might be using C++ right along with some NoSQL solution. C++ because they are very good at it and NoSQL because it was the logical tool for the job.
Where these rarefied programmers can get into conflict and "cause trouble" is when they have to deal with the RockStars. Some RockStar with management support will reject unit testing (slows me down) insist on using something (cool) like Go and then need to alter the Linux Kernel as it (I have witnessed this). The rarefied programmer will move on and take the two best programmers with them.
I have noticed quite a few people blaming MBAs for the problems of RockStar programmers; this is due to RockStars providing the MBAs with a good story for sales. "Our guy was the first certified Oracle DBA in the state." "Our guy singlehandedly programmed a NASA Sub system." "Our guy is certified to level 20." "Our guy worked 20 straight days for 16 hours a day to finish a project." MBAs need zest and sizzle or they don't get an obscene bonus. Why do they get the obscene bonus because they golf with the CEO and brag about how they have a RockStar programmer.
The rarefied programmer is usually too boring for the MBAs. "Our guy found an open source product so we canceled my pet project and just used the OS product." "Our guy added unit testing; whatever the hell that is." "Our guy switched the programmer's editor from Eclipse to Sublime Text 2" "Our guy showed the accountants how to make a better macro."
What happens when Ken leaves? The company is well and truly fucked, right?
This is why even the smart guys have to play by the rules. The best ones know that they're good, but that not everybody else is, and this is a job and not a hobby. Frankly, what Ken needs is a manager with the balls to tame him, or fire him.
I'm also glad I'm not working with Synopsis if that's indicative of anything.
Bottom line here, the worst investment in business is in the overqualified. Don't hunt house flies with howitzers.
Fugue for Aaron Swartz
I don't think I can stay in software much longer.
"...something to be desired. I do work in a pretty edge case kind of field though (geospatial analytics), that has a good bit more math than your average business dev work."
"While this is probably true for some people, especially above average people who have only worked at small companies where they are the best developer with no real competition I think there's a second problem that can make good people appear like that:"
"If rock stars programmers work with genuine peers, the diva part of them will be suppressed. It is hard to feel superior when working with people against whom you are just average. Some of them can still lack in social skills(*), but you can often minimize the damages that could cause. Of course as a company you still need to be able to afford top talent and have a project that challenges or otherwise interest them."
Above average. Below average. Senior developer. Junior developer. Rockstar programmer. Cowboy programmer. What do ANY of you know about "average"? What constitutes below average, and what constitutes above average? It's complete and utter subjective nonsense.
Do you want to go by lines of code written? Do you want to go by number of licenses sold? Do you want to go by pay? Do you want to go by your GPA in college (though I'm sure some of these "rockstar programmers" are not computer scientists or even college graduates).
You have no metrics, no basis. So stop using the word average. Software has become egomaniacal and elitist.
The measure of worth for a developer has become so utterly blurred and has been replaced with elitism, egos and exclusivism.
As I go on through my career in software, should it last that long, I will measure my worth by number of successful projects. You all can use whatever you like- pay, lines of code, size of teams, IQ...I don't care.
For this reason I'm looking to get out of software. I've only just begun my career but I already want out. The whole mindset is different in hardware. Because in hardware, it has to work. If it doesn't work, people are at risk. In software, you get angry calls. The mindset is different with hardware engineers and embedded developers- they don't think about rockstars or cowboys...They work together to make things work.
A programmer who always says OK, I can do it and does it? No bugs, no excuses, any domain, only the time it takes to. And then happens to play music like a rock star... Rock star programmer. You need only ONE case to get the general tag and this discussion. But if you follow the idea concept... the rock star programmer is not hired: he is the one hiring, to round corners and chores, but the code and design and idea is his, otherwise there is trouble! But the problem exposed in this discussion is more general: when do technical resources acquire fame? Some actors are simply so... :|
Whenever someone says "Rock Star" programmer, I always picture Keith Richards or Ozzie going in for a development interview...
"So... what you're looking for is a programmer who shows up late, strung out on coke, hungover, and hoping that the roadies (interns) took care of most of the work, who will likely have sex with the girl at the front desk, and will only finish a job if he has a number of people screaming 'ENCORE!' to encourage him on?"
- Holy crap, I've got MOD points! Who thought that was a good idea.
At Microsoft back in the day, we called them HRHs, his or her royal highness or highnesses.. they could not be fired and could do whatever they wanted, get up walk out of meeting, take a smoke break for 3 days, show up whenever, but when they knew they needed to deliver, they would code the best code ever in a 60 hour non-stop marathon. Did the PMs I know like them, hell no, could they fire them? hell no. Did they wish they could, hell yeah! Me? I was a developer on a scale of 1 to 10 like a 12, but these HRHs were code warriors. I loved them and I was non-traditional management and ex-military. An old saying, don't screw with black-ops, and Microsoft's code warriors were definitely trusted warriors. crazy, but true. traditional management and HR could not get a grip on Rock Star programmers. it was not in their play book and it should never be in their playbook. HR is a cost center and idiots at best - remember folks, HR services management, not the other way around. HR cannot bind contracts, Management can.. blah blah blah
Am I a rock star developer. I know plenty of musicians that think they are Rock Stars, but they ain't. If a developer is writting a billion lines of untested code, I would say they are just a Bad Developer. Not like MJ bad, like, you suck bad.