So you want to be a developer rockstar?(thinkfaster.co)
thinkfaster.co
So you want to be a developer rockstar?
http://thinkfaster.co/2015/02/so-you-want-to-be-a-developer-rockstar
5 comments
This was a tough one for me. I will agree that doing this purely in the name reputation, to seem like the expert, isn't a good idea.
But asking for advice too quickly can be harmful. There have been times where I struggled for a day or two with configuration, and the answer was a few lines of xml.
But the process, checking all of the dozen possible failure points, along with a few possible combinations? It actually did leave me with a much stronger understanding of the system and how it works. It probably was a valuable day and a half.
And my hair did grow back in, eventually.
But asking for advice too quickly can be harmful. There have been times where I struggled for a day or two with configuration, and the answer was a few lines of xml.
But the process, checking all of the dozen possible failure points, along with a few possible combinations? It actually did leave me with a much stronger understanding of the system and how it works. It probably was a valuable day and a half.
And my hair did grow back in, eventually.
Interesting. Because the article accurately describes myself and a number of other folks I work with, all of which are considered "rockstars". It's great advice in my opinion.
I 100% agree with the don't ask for help advice. People need to ACTUALLY LEARN something. I'm sick of people externalizing the costs of their inadequacies.
I 100% agree with the don't ask for help advice. People need to ACTUALLY LEARN something. I'm sick of people externalizing the costs of their inadequacies.
To be perfectly honest that sounds like a surprisingly toxic work environment, and a sadly elitist attitude. What are teams for if not to act as a collaborative support system?
Should it be a crutch? No. But never asking for help as a matter of course is, in my opinion, counterproductive.
Should it be a crutch? No. But never asking for help as a matter of course is, in my opinion, counterproductive.
I would've worded it differently. Do approach people to confirm that you're on the right track, or to find out the (undocumented) motivation for a certain design, NOT to ask them to solve a problem for you.
I constantly repost this comment from jlcfly from an AskHN.
"Teach them to be better than you. That may seem counterproductive. I have a type A personality, and I have decent coding skills. I've been in your situation a number of times. I also know there's these mythical expert developers out there that I can't seem to find (or afford). So, what to do? A few years ago I realized that if I continue down this path, I'll end up with some serious health issues due to the stresses that come along with having a reputation for being a really good developer.
So, I decided that instead of searching for developers better than me, I would teach developers I work with how to BE better. It's taken a lot of patience. And it's taken me quite a bit to LET GO of my way of doing things. I had to take my ego out of the picture. (VERY hard to do.)
Nowadays, I realize that developers don't have to BE better than me. I simply have to ALLOW them to do what they do without being so obsessive about it. Turns out, even junior developers really CAN do good work. They just need a little guidance that only comes with experience, and then they need me to get out of their way."
https://news.ycombinator.com/item?id=8649415
"Teach them to be better than you. That may seem counterproductive. I have a type A personality, and I have decent coding skills. I've been in your situation a number of times. I also know there's these mythical expert developers out there that I can't seem to find (or afford). So, what to do? A few years ago I realized that if I continue down this path, I'll end up with some serious health issues due to the stresses that come along with having a reputation for being a really good developer.
So, I decided that instead of searching for developers better than me, I would teach developers I work with how to BE better. It's taken a lot of patience. And it's taken me quite a bit to LET GO of my way of doing things. I had to take my ego out of the picture. (VERY hard to do.)
Nowadays, I realize that developers don't have to BE better than me. I simply have to ALLOW them to do what they do without being so obsessive about it. Turns out, even junior developers really CAN do good work. They just need a little guidance that only comes with experience, and then they need me to get out of their way."
https://news.ycombinator.com/item?id=8649415
Working as a team is not externalizing inadequacies.
Asking for help does three things.
1. It makes you look junior. 2. It makes you done with your work earlier 3. It deprives you of an opportunity to practice tackling difficult problems on your own
It's something that helps the company in the short term at your own expense.
1. It makes you look junior. 2. It makes you done with your work earlier 3. It deprives you of an opportunity to practice tackling difficult problems on your own
It's something that helps the company in the short term at your own expense.
I suppose it depends on the culture you work in.
Actually that's probably the worst piece of advice I have heard.
My first job programming was with some introverted people who were fairly smart, on a very poorly documented system. It was really difficult to ask anything, and when I did they were not very good at explaining and I felt kind of stupid, and just went back to staring at the code. Nearly got fired from that job for not being productive enough.
Took another job, and decided to learn from my mistakes - I asked a lot of questions, especially in the beginning, and needless to say that one job went a lot better.
My first job programming was with some introverted people who were fairly smart, on a very poorly documented system. It was really difficult to ask anything, and when I did they were not very good at explaining and I felt kind of stupid, and just went back to staring at the code. Nearly got fired from that job for not being productive enough.
Took another job, and decided to learn from my mistakes - I asked a lot of questions, especially in the beginning, and needless to say that one job went a lot better.
As obnoxious as the tone of this article is, I have to say that I agree with the bit about asking for help.
Being an engineer that can always dive to the bottom of the pool and get the penny will make you incredibly valuable to your employer.
The darker side of this is that, for better or worse, in most organizations asking for help is an awfully expensive way to spend your technical reputation capital. It's extremely frustrating, but I've seen pretty poor engineers ride their way up the pay scale by bullshitting at every opportunity.
Unless you have no chance of solving it yourself, try to figure it out.
Being an engineer that can always dive to the bottom of the pool and get the penny will make you incredibly valuable to your employer.
The darker side of this is that, for better or worse, in most organizations asking for help is an awfully expensive way to spend your technical reputation capital. It's extremely frustrating, but I've seen pretty poor engineers ride their way up the pay scale by bullshitting at every opportunity.
Unless you have no chance of solving it yourself, try to figure it out.
As far as hiring and ongoing employee evaluation goes, how do you feel about developers who can hit a really tricky problem, go deep in it and come out with a great solution?
If a solution would have been found more quickly had the developer engaged their colleagues for help or advice, they cost the organization by wasting time trying to be a "rock star" instead of a team player. They would receive coaching to discourage that sort of counterproductive behavior in the future.
Maybe. But then you eat the time of those 1-2 other people by interrupting them, giving them the context of what you're working on, etc.
My guess is it's a net loss for the org in most cases. The exception being if you sit there for days.
My guess is it's a net loss for the org in most cases. The exception being if you sit there for days.
Hah well that was my presumption. Obviously balking the minute you're stymied is silly, too.
My objection is with never asking for help, not trying for a while and then looking for help only after you've put in a reasonable effort.
Seems like common sense but you know how common that is... :)
My objection is with never asking for help, not trying for a while and then looking for help only after you've put in a reasonable effort.
Seems like common sense but you know how common that is... :)
Agreed :).
I agree with most of this and it echos some of my own behavior; except for the never ask for help advice. Absolutes are an "advice smell" because the world is not black and white. I think you should ask for help after you've exhausted your own options, or there is a time crunch.
A few additions:
A rockstar tries to make everyone else into rockstars. they write up documentation, fill in tests, take notes at meetings for others to reference, and are the ones people go to for help.
The write code they write is crystal clear and easy to support, and sets an example in quality.
A few additions:
A rockstar tries to make everyone else into rockstars. they write up documentation, fill in tests, take notes at meetings for others to reference, and are the ones people go to for help.
The write code they write is crystal clear and easy to support, and sets an example in quality.
I don't see why a time crunch is an appropriate reason to ask for help. As a junior, there's little responsibility you have to assume w.r.t. the success of the project. If it fails for some reason that may be related to you, you were probably poorly managed. A competent boss would notice that you struggle and give your task to someone else in order to meet deadlines.
The thing with rockstars is that they typically don't need the help, and can figure things out eventually. It's not because they've got some ideal that they're trying to fit into that says "real rockstars don't ask for help" because that's totally maladaptive. Rockstars get shit done and don't care what they have to do to get there. And sometimes that means asking for help.
Thanks for all the comments. I posted a response about the help issue here: http://thinkfaster.co/2015/02/no-really-dont-ask-for-help
There are 3 kinds of "ask for help".
1) I'm tired with this code mess, please explain what methods I should call to do this task.
2) There are 3 ways to do this, one of them requires 3-d party service with monthly payments, second requires open source library and we need to check license, third is create our own solution and it will take some time. And I need manager's decision what way we can choose.
3) There is not enough data to complete the task, I need your time to give me data and unblock task.
I think only (1) is toxic and should be avoided.
I think only (1) is toxic and should be avoided.
This is a fantastic article. Can confirm. Agree with it 100%. Most people are just lazy, or outright incompetent (outside a very small area of expertise).
A wide range of expertise with the ability to rapidly deep dive wherever needed is what I consider a rockstar.
A wide range of expertise with the ability to rapidly deep dive wherever needed is what I consider a rockstar.
To me, the perfect example is the "never ask for help" advice.
The reality is, spinning your tires silently instead of solving your problem by asking for help, all in the name of preserving or enhancing your reputation, is about the worst advice I could imagine. It's actually a red flag for me as far as hiring and ongoing employee evaluation goes.