9 ms·

Russ Olsen: The Best Programming Advice I Ever Got

214 points by swannodette 14y ago

happywolf 14y ago
To be frank, his advice can be generalized to "Don't step on other people's role", be it code or other tasks. Even though you may be more competent or capable in performing the said role, the resulting repercussion will usually be very ugly, and you won't enjoy going through it. Speaking from my 10 years+ experience from an innocent technical nerd to a multi-region Project Manager.
- tom_b 14y ago
  but that's not his advice? That is the advice he was given (and then chose to ignore later and then to remind himself to listen to others when they spoke about his own code)
thornofmight 14y ago
I don't get it. "Actually it was terrible advice, advice that I've gone out of my way to ignore it in the years since."
- quaunaut 14y ago
  I've gotta agree. I can't tell if he's saying to follow that shitty advice or not. I think he's saying, be part of a team where fixing things is more important than politics, but I have no earthly idea.
- gmrple 14y ago
  He is saying that while he didn't take the advice, the giving of the advice changed him for the better; it changed the way he viewed his and other's code.
- calinet6 14y ago
  It's sort of anti-advice. He's giving an anecdote as an example of what-not-to-do. The moral of this anecdote is in the last line: "the best way to have a future is to be part of a team that values progress over politics, ideas over territory, and initiative over decorum." Simple as that. Granted, he could have taken a less meandering path to that conclusion. Regarding the conclusion itself, I couldn't agree more. I used to work for a company with a lot of internal politics and code-ownership, but now work for a more open company where progress is highly valued and no code is sacred, and the latter is vastly more capable at solving problems and creating great stuff.
- gambler 14y ago
  I don't get what you don't get. The content of the advise was bad, but the overall effect of it on the author was good. It made him conscious of certain tendencies in the companies and allowed him to not be a purveyor of those tendencies.
  - hisyam 14y ago
    "The content of the advise was bad, but the overall effect of it on the author was good." Now I get it. Thanks gambler.
- aidenn0 14y ago
  He's saying that it's important to remember that it is terrible advice. When someone mucks around in your code, remember how shitty it is to be given that advice and try to handle the situation more gracefully. When you are in a shop where that advice is considered good, find a way to leave.
heyrhett 14y ago
This is the real advice at the very end: "But the best way to have a future is to be part of a team that values progress over politics, ideas over territory, and initiative over decorum." The story is cut short though, and he doesn't really provide any evidence to back up that advice. Did the company that favored politics go out of business. Do company that favor ideas over territory consistently work out better? I think, as engineers, we'd like to believe so, but I'm not sure that's what I've seen from my own experience.
- cutie 14y ago
  Network effects and name recognition can work against it for a time. I'm thinking currently about the demise of Kodak, and similar situations where where a dominant player is displaced by new technology. Had Kodak pursued digital early and aggressively things would be different now. I bet politics didn't allow that outcome.
  - btilly 14y ago
    Are you kidding? Kodak invented digital photography. And you know what? They knew better than anyone else that digital photography absolutely sucked relative to film. If you want to know why dominant players get displaced by new technology, I highly recommend reading The Innovator's Dilemma.
    - digisign 14y ago
      So what? Someone else invented lots of things, like smartphones and tablets. Has no bearing on whether they are aggressively pursued for profit. And sucked, past tense. There are any number of better strategies Kodak could have taken besides "waiting to die," as you appear to recommend.
gfodor 14y ago
Like most engineers, he did the coding part right, the political part wrong. The right way to approach this would be to hack together a proof-of-concept, get buy-in (and/or participation) from the key engineers of the original system, and slowly build consensus. Yes, it's frustrating. Yes, it takes 10 times as long as just hacking it out. But, you end up not looking like an ass and also probably will end up with a better solution anyway because even you, Mr. Superstar programmer, might miss some details that the other people who have been working on the project longer will catch. In the situation where you come in after a long weekend and show how you've managed to "fix" other engineers work you end up pissing people off because it makes them feel like you're making them look bad. Make them a part of the solution. The advice of staying out of other people's code is either good or bad depending on what it means to "stay out". Avoid reading others people's code? Avoid trying to come up with alternative solutions to other people's code? Bad idea. Avoid going in and rewriting other people's code without syncing up with them before you demo your improvements to their boss? Yeah, that's probably good advice.
- plinkplonk 14y ago
  "Yes, it's frustrating. Yes, it takes 10 times as long as just hacking it out." Yes, unless you are immortal, life is too short for this kind of crap. Multiply the "takes 10 times as long" with an arbitrary n problems, and you soon end up wasting years on things that should take a few days. One way to make "the best way to have a future is to be part of a team that values progress over politics, ideas over territory, and initiative over decorum." actionable is to change your job if you are working in a company where you have to jump through political hoops and "take 10 times as long" to get engineering improvements done. Imo, being able to play political games is a valuable skill, to be used on the very rare occasion such game playing is really necessary. But you shouldn't have to do it every other day, especially on engineering problems. In this case, it might be better to just change your job, unless you have very very strong reasons for staying on. EDIT: Not taking a position on the OP's situation or actions, fwiw. Just saying if it takes 10x time to make changes because of politics, might be time to move on.
  - gfodor 14y ago
ChuckMcM 14y ago
Its an interesting anecdote. There is a lot to be said for the advice "Don't work where egos are more important than the mission." But what Russ didn't learn was "How to get the mission done in the presence of egos." The thing is that there are lots of people with big egos, people who rightfully or wrongfully work against others who threaten their ego, even when doing so is counter productive to the company. What is worse is that as a manager you know these egocentric people are there but sometimes you really can't do a whole lot about that. However, when you find someone who can get stuff done without rustling the feathers of the prima-donnas, that person should be pretty valuable. A good manager can really appreciate that skill, a poor manager cannot. Allow me to illustrate. Lets use Russ' example because its out there and we won't get into trouble. Jump up to the corner office and look at what is seen: 1) Product is slow 2) Repeated meetings and updates where the slowness has been raised have been deflected with various plans, arguments about direction, finger pointing, and general lack of progress. 3) Junior programmer rewrites a chunk of the system and shows off an order of magnitude improvement. 4) Meetings where senior people are exploiting that demo to make others look foolish, advance agendas, and generally do damage to others. Now consider a different scenario 1) Product is slow 2) Repeated meetings and updates where the slowness has been raised have been deflected with various plans, arguments about direction, finger pointing, and general lack of progress. 3) Engineer figures out the problems and, knowing the solution, starts talking to various other engineers about how they decide to build what they build. Asks questions that talk to the bottleneck (Like they might ask, "I'm thinking about using that kind of socket in my code, but I'm not sure about it, how much performance could I expect?" and "I wrote this bit of test code, it just copies stuff around, and it seems to be waiting on the socket a lot, could you take a look and tell me if I'm doing it right?") Now by planting the questions/seeds around these engineers start to do things a bit differently, the come up with some alternate strategies. The socket gets eliminated and this speeds up the product tremendously. Everyone is excited about how much progress they are making and generally morale improves. 4) Meetings now how have big performance gains, and the product is going to be much better. Congratulations all around. Now in the latter case the environment gets better, the same result is achieved, but most of the company doesn't know they were the one who 'fixed' the problem. That employee's manager should know, and they should be ready to reward that effort. People who can effect the change you want in an organization without disturbing the politics are really good to have around. Things just 'magically' get better. When they leave it is really obvious that things don't work as well.
johngalt 14y ago
Engineers always present this as a false dichotomy. You can work with other people (and their code) without pissing them off. "Stay the hell out of other peoples code" is no better than "Act with impunity". Thankfully there is a middle ground. It's called talking to people. People who are the most passionate about programming are the same people who tend to identify with the code their code! If you say the code is wrong, you are also saying they are wrong. You can mitigate this type of territorial response by convincing them to disassociate their identity from a code block. We aren't a group of rockstars writing hit after hit, we are a team of engineers iterating through possibilities and routing around roadblocks. For dealing with intergroup rivalry you're better off going to the group responsible for that area first to show your results. Get their support before going up the ladder. Let them be part of the success. Otherwise you paint them into a corner when the big boss comes down and says "Why are other teams fixing your problems!?" Now they must attack your solution to justify themselves. edit: I'm seeing a lot of other threads say "Just don't work at places where this is an issue." When you find robot planet let me know, because this is an issue everywhere. With your customers if not with your co-workers.
- abc_lisper 14y ago
  You must be new here :). Hacker news is for the entertainment of highly-intelligent,self-absorbed, millions-deserving kids. You are either with us, or you are just old and suck :)
- MattRogish 14y ago
  "You can mitigate this type of territorial response by convincing them to disassociate their identity from a code block." Absolutely. In some ways, this is my biggest job as "manager". I try and rotate the team so that no one has "ownership" of a particular feature (we're self organizing but I try and coach people appropriately ;)). Sure, Bob may have been the person that originally penned a particular method, but refactoring is a fact of life, and it's likely that, if I've done my job right, over time any member of the team should be able to do a given refactor. What helps is that you explicitly have someone who worked on a particular block of code not fix any bugs related to it. Give it to someone else. They'll figure it out and make any changes. Have people pair on initial design/architecture (or have specs authored/tweaked by the whole team) so it's never solely one person's vision of how feature X should work. I've found the best programmers have a zen-like state of detachment with code they've written. Very good, but not great, programmers seem to tie up too much of their identity with their code; transitioning them from "good to great" almost always inevitably requires detachment.
dredmorbius 14y ago
It's an anti-pattern. If you're working in a team, on a project, or in an organization in which this is the operational mindset, your first goal should be to get the hell out. You're in a Bs hiring Cs situation. And eventually, if someone inside your organization doesn't solve the problem, someone outside (e.g.: your competition) will. That's a Christensenian disruptive innovation situation right there. An alternative goal is to figure out how to do the right thing in such a way that you don't get fired / lose standing over it. Figuring out how to change the culture might be a third alternative, though this calls for very skillful maneuvering to conduct successfully. There are exceptions to the general rule. Sometimes checks or controls are in place to prevent thigns from going seriously haywire. But even here, simplicity and efficiency should prevail. And of course, you should take care not to be guilty of this mindset yourself.
Zenst 14y ago
If somebody left a sticky saying "stay the hell out of my code" I'd reply "code it so nobody ever has the need to even think about it"; Which would be the polite reponse. You learn so much from others code, what to do and what not to do. Remember once doing a lovely JSP COBOL program only to have it butched into something with goto all over the place. Turned out that was the standard, no matter how right or wrong, standards help for consitency. Now if you have wild cards who end up obviscating there code, just to stop people touching it then they need help or you will only end up needing alot more help later on when things go wrong and they will. So politicaly the best way and just winning move is to push the standards and if they don't have any then you instigate them. Always some higher up manager who will easily be be swayed, especialy if you can say it will help to eventualy get some standard like BS5750 or ISO9002 or whatever the flavour of the month is on that front. Remember code motivates the CPU, but what motivates your company managers to do the right things. office politics is alot easier when you get it fighting itself and you can just get on with what you like doing peacfuly.
mephi5t0 14y ago
Misleading title IMHO. Because it wasn't best advise, it was opposite. The bottom line: stay out of the companies/jobs that give you that advise/attitude. Guy did his job, he didn't dig in the code to look others stupid. He had a very crappy task to go into sewage, find problem and fix it. Yes, there were programmers that knew why it was slow and had other priorities. Well, his priority was to fix it. Not to mention he worked on weekend and evenings.
- andreasvc 14y ago
  That's not misleading, that's sarcasm.
  - briandear 14y ago
    Some would even say irony.
adamio 14y ago
The problem is not the author, the code, or the original programmer, the problem is here: "First to my boss and then to my boss's boss and then to his boss and then to a whole assortment of higher ups..." "Many of those boss's boss's bosses were seriously pissed at me...That was when the Biggest Boss of All..." Too many bosses with bosses
- Zenst 14y ago
  Yes, sadly alot of companies do tend to drift towards the upside down pyramid boss structure. Insecure CEO's may be one factor in that. As a rule of sanity If you need the approval of more than 5 different layers of boss's then your better of rolling a dice and then asking as nomatter the outcome you still get your fun that way to offset the sapien-clustering.
- thebigshane 14y ago
  Interesting, what sort of structure should a 1000+ person company have? Would it really avoid any layers greater than 3 deep? Valve is a notoriously (recently) flat company for being as large as it is: <300 people. But it is noteworthy because it is the exception.
  - adamio 14y ago
    I don't see where the article mentions a 1000+ person company. There's lots of answers to the structure question, its a good question. I was referring mostly to boss with a boss - and what the term boss implies vs leader, or enabler.
bluesmoon 14y ago
Reminds me of how the performance team at Yahoo! was asked to stop working on mobile performance research because the mobile team decided that they should own it.
Ingaz 14y ago
The best comment was "The counter-measure is to make sure that no code is 'other people's code', and thus there is no good reason to stay out of it" http://www.informit.com/articles/article.aspx?p=1926692 http://www.informit.com/articles/article.aspx?p=1926692
xfhai 14y ago
Then open source came along. Welcoming everybody to improve the code. But it seems like there some ego issues there too.

214 points by swannodette 14y ago

To be frank, his advice can be generalized to "Don't step on other people's role", be it code or other tasks. Even though you may be more competent or capable in performing the said role, the resulting repercussion will usually be very ugly, and you won't enjoy going through it. Speaking from my 10 years+ experience from an innocent technical nerd to a multi-region Project Manager.

tom_b 14y ago
but that's not his advice? That is the advice he was given (and then chose to ignore later and then to remind himself to listen to others when they spoke about his own code)

thornofmight 14y ago

I don't get it. "Actually it was terrible advice, advice that I've gone out of my way to ignore it in the years since."

quaunaut 14y ago
I've gotta agree. I can't tell if he's saying to follow that shitty advice or not. I think he's saying, be part of a team where fixing things is more important than politics, but I have no earthly idea.
gmrple 14y ago
He is saying that while he didn't take the advice, the giving of the advice changed him for the better; it changed the way he viewed his and other's code.
calinet6 14y ago
It's sort of anti-advice. He's giving an anecdote as an example of what-not-to-do. The moral of this anecdote is in the last line: "the best way to have a future is to be part of a team that values progress over politics, ideas over territory, and initiative over decorum." Simple as that. Granted, he could have taken a less meandering path to that conclusion. Regarding the conclusion itself, I couldn't agree more. I used to work for a company with a lot of internal politics and code-ownership, but now work for a more open company where progress is highly valued and no code is sacred, and the latter is vastly more capable at solving problems and creating great stuff.
gambler 14y ago
I don't get what you don't get. The content of the advise was bad, but the overall effect of it on the author was good. It made him conscious of certain tendencies in the companies and allowed him to not be a purveyor of those tendencies.
- hisyam 14y ago
  "The content of the advise was bad, but the overall effect of it on the author was good." Now I get it. Thanks gambler.
aidenn0 14y ago
He's saying that it's important to remember that it is terrible advice. When someone mucks around in your code, remember how shitty it is to be given that advice and try to handle the situation more gracefully. When you are in a shop where that advice is considered good, find a way to leave.

heyrhett 14y ago

This is the real advice at the very end: "But the best way to have a future is to be part of a team that values progress over politics, ideas over territory, and initiative over decorum." The story is cut short though, and he doesn't really provide any evidence to back up that advice. Did the company that favored politics go out of business. Do company that favor ideas over territory consistently work out better? I think, as engineers, we'd like to believe so, but I'm not sure that's what I've seen from my own experience.

cutie 14y ago
Network effects and name recognition can work against it for a time. I'm thinking currently about the demise of Kodak, and similar situations where where a dominant player is displaced by new technology. Had Kodak pursued digital early and aggressively things would be different now. I bet politics didn't allow that outcome.
- btilly 14y ago
  Are you kidding? Kodak invented digital photography. And you know what? They knew better than anyone else that digital photography absolutely sucked relative to film. If you want to know why dominant players get displaced by new technology, I highly recommend reading The Innovator's Dilemma.
  - digisign 14y ago
    So what? Someone else invented lots of things, like smartphones and tablets. Has no bearing on whether they are aggressively pursued for profit. And sucked, past tense. There are any number of better strategies Kodak could have taken besides "waiting to die," as you appear to recommend.

gfodor 14y ago

Like most engineers, he did the coding part right, the political part wrong. The right way to approach this would be to hack together a proof-of-concept, get buy-in (and/or participation) from the key engineers of the original system, and slowly build consensus. Yes, it's frustrating. Yes, it takes 10 times as long as just hacking it out. But, you end up not looking like an ass and also probably will end up with a better solution anyway because even you, Mr. Superstar programmer, might miss some details that the other people who have been working on the project longer will catch. In the situation where you come in after a long weekend and show how you've managed to "fix" other engineers work you end up pissing people off because it makes them feel like you're making them look bad. Make them a part of the solution. The advice of staying out of other people's code is either good or bad depending on what it means to "stay out". Avoid reading others people's code? Avoid trying to come up with alternative solutions to other people's code? Bad idea. Avoid going in and rewriting other people's code without syncing up with them before you demo your improvements to their boss? Yeah, that's probably good advice.

plinkplonk 14y ago
"Yes, it's frustrating. Yes, it takes 10 times as long as just hacking it out." Yes, unless you are immortal, life is too short for this kind of crap. Multiply the "takes 10 times as long" with an arbitrary n problems, and you soon end up wasting years on things that should take a few days. One way to make "the best way to have a future is to be part of a team that values progress over politics, ideas over territory, and initiative over decorum." actionable is to change your job if you are working in a company where you have to jump through political hoops and "take 10 times as long" to get engineering improvements done. Imo, being able to play political games is a valuable skill, to be used on the very rare occasion such game playing is really necessary. But you shouldn't have to do it every other day, especially on engineering problems. In this case, it might be better to just change your job, unless you have very very strong reasons for staying on. EDIT: Not taking a position on the OP's situation or actions, fwiw. Just saying if it takes 10x time to make changes because of politics, might be time to move on.
- gfodor 14y ago

ChuckMcM 14y ago

Its an interesting anecdote. There is a lot to be said for the advice "Don't work where egos are more important than the mission." But what Russ didn't learn was "How to get the mission done in the presence of egos." The thing is that there are lots of people with big egos, people who rightfully or wrongfully work against others who threaten their ego, even when doing so is counter productive to the company. What is worse is that as a manager you know these egocentric people are there but sometimes you really can't do a whole lot about that. However, when you find someone who can get stuff done without rustling the feathers of the prima-donnas, that person should be pretty valuable. A good manager can really appreciate that skill, a poor manager cannot. Allow me to illustrate. Lets use Russ' example because its out there and we won't get into trouble. Jump up to the corner office and look at what is seen: 1) Product is slow 2) Repeated meetings and updates where the slowness has been raised have been deflected with various plans, arguments about direction, finger pointing, and general lack of progress. 3) Junior programmer rewrites a chunk of the system and shows off an order of magnitude improvement. 4) Meetings where senior people are exploiting that demo to make others look foolish, advance agendas, and generally do damage to others. Now consider a different scenario 1) Product is slow 2) Repeated meetings and updates where the slowness has been raised have been deflected with various plans, arguments about direction, finger pointing, and general lack of progress. 3) Engineer figures out the problems and, knowing the solution, starts talking to various other engineers about how they decide to build what they build. Asks questions that talk to the bottleneck (Like they might ask, "I'm thinking about using that kind of socket in my code, but I'm not sure about it, how much performance could I expect?" and "I wrote this bit of test code, it just copies stuff around, and it seems to be waiting on the socket a lot, could you take a look and tell me if I'm doing it right?") Now by planting the questions/seeds around these engineers start to do things a bit differently, the come up with some alternate strategies. The socket gets eliminated and this speeds up the product tremendously. Everyone is excited about how much progress they are making and generally morale improves. 4) Meetings now how have big performance gains, and the product is going to be much better. Congratulations all around. Now in the latter case the environment gets better, the same result is achieved, but most of the company doesn't know they were the one who 'fixed' the problem. That employee's manager should know, and they should be ready to reward that effort. People who can effect the change you want in an organization without disturbing the politics are really good to have around. Things just 'magically' get better. When they leave it is really obvious that things don't work as well.

johngalt 14y ago

Engineers always present this as a false dichotomy. You can work with other people (and their code) without pissing them off. "Stay the hell out of other peoples code" is no better than "Act with impunity". Thankfully there is a middle ground. It's called talking to people. People who are the most passionate about programming are the same people who tend to identify with the code their code! If you say the code is wrong, you are also saying they are wrong. You can mitigate this type of territorial response by convincing them to disassociate their identity from a code block. We aren't a group of rockstars writing hit after hit, we are a team of engineers iterating through possibilities and routing around roadblocks. For dealing with intergroup rivalry you're better off going to the group responsible for that area first to show your results. Get their support before going up the ladder. Let them be part of the success. Otherwise you paint them into a corner when the big boss comes down and says "Why are other teams fixing your problems!?" Now they must attack your solution to justify themselves. edit: I'm seeing a lot of other threads say "Just don't work at places where this is an issue." When you find robot planet let me know, because this is an issue everywhere. With your customers if not with your co-workers.

abc_lisper 14y ago
You must be new here :). Hacker news is for the entertainment of highly-intelligent,self-absorbed, millions-deserving kids. You are either with us, or you are just old and suck :)
MattRogish 14y ago
"You can mitigate this type of territorial response by convincing them to disassociate their identity from a code block." Absolutely. In some ways, this is my biggest job as "manager". I try and rotate the team so that no one has "ownership" of a particular feature (we're self organizing but I try and coach people appropriately ;)). Sure, Bob may have been the person that originally penned a particular method, but refactoring is a fact of life, and it's likely that, if I've done my job right, over time any member of the team should be able to do a given refactor. What helps is that you explicitly have someone who worked on a particular block of code not fix any bugs related to it. Give it to someone else. They'll figure it out and make any changes. Have people pair on initial design/architecture (or have specs authored/tweaked by the whole team) so it's never solely one person's vision of how feature X should work. I've found the best programmers have a zen-like state of detachment with code they've written. Very good, but not great, programmers seem to tie up too much of their identity with their code; transitioning them from "good to great" almost always inevitably requires detachment.

dredmorbius 14y ago

It's an anti-pattern. If you're working in a team, on a project, or in an organization in which this is the operational mindset, your first goal should be to get the hell out. You're in a Bs hiring Cs situation. And eventually, if someone inside your organization doesn't solve the problem, someone outside (e.g.: your competition) will. That's a Christensenian disruptive innovation situation right there. An alternative goal is to figure out how to do the right thing in such a way that you don't get fired / lose standing over it. Figuring out how to change the culture might be a third alternative, though this calls for very skillful maneuvering to conduct successfully. There are exceptions to the general rule. Sometimes checks or controls are in place to prevent thigns from going seriously haywire. But even here, simplicity and efficiency should prevail. And of course, you should take care not to be guilty of this mindset yourself.

Zenst 14y ago

If somebody left a sticky saying "stay the hell out of my code" I'd reply "code it so nobody ever has the need to even think about it"; Which would be the polite reponse. You learn so much from others code, what to do and what not to do. Remember once doing a lovely JSP COBOL program only to have it butched into something with goto all over the place. Turned out that was the standard, no matter how right or wrong, standards help for consitency. Now if you have wild cards who end up obviscating there code, just to stop people touching it then they need help or you will only end up needing alot more help later on when things go wrong and they will. So politicaly the best way and just winning move is to push the standards and if they don't have any then you instigate them. Always some higher up manager who will easily be be swayed, especialy if you can say it will help to eventualy get some standard like BS5750 or ISO9002 or whatever the flavour of the month is on that front. Remember code motivates the CPU, but what motivates your company managers to do the right things. office politics is alot easier when you get it fighting itself and you can just get on with what you like doing peacfuly.

mephi5t0 14y ago

Misleading title IMHO. Because it wasn't best advise, it was opposite. The bottom line: stay out of the companies/jobs that give you that advise/attitude. Guy did his job, he didn't dig in the code to look others stupid. He had a very crappy task to go into sewage, find problem and fix it. Yes, there were programmers that knew why it was slow and had other priorities. Well, his priority was to fix it. Not to mention he worked on weekend and evenings.

andreasvc 14y ago
That's not misleading, that's sarcasm.
- briandear 14y ago
  Some would even say irony.

adamio 14y ago

The problem is not the author, the code, or the original programmer, the problem is here: "First to my boss and then to my boss's boss and then to his boss and then to a whole assortment of higher ups..." "Many of those boss's boss's bosses were seriously pissed at me...That was when the Biggest Boss of All..." Too many bosses with bosses

Zenst 14y ago
Yes, sadly alot of companies do tend to drift towards the upside down pyramid boss structure. Insecure CEO's may be one factor in that. As a rule of sanity If you need the approval of more than 5 different layers of boss's then your better of rolling a dice and then asking as nomatter the outcome you still get your fun that way to offset the sapien-clustering.
thebigshane 14y ago
Interesting, what sort of structure should a 1000+ person company have? Would it really avoid any layers greater than 3 deep? Valve is a notoriously (recently) flat company for being as large as it is: <300 people. But it is noteworthy because it is the exception.
- adamio 14y ago
  I don't see where the article mentions a 1000+ person company. There's lots of answers to the structure question, its a good question. I was referring mostly to boss with a boss - and what the term boss implies vs leader, or enabler.

bluesmoon 14y ago

Reminds me of how the performance team at Yahoo! was asked to stop working on mobile performance research because the mobile team decided that they should own it.

Ingaz 14y ago

The best comment was "The counter-measure is to make sure that no code is 'other people's code', and thus there is no good reason to stay out of it" http://www.informit.com/articles/article.aspx?p=1926692 http://www.informit.com/articles/article.aspx?p=1926692

xfhai 14y ago

Then open source came along. Welcoming everybody to improve the code. But it seems like there some ego issues there too.