
Russ Olsen: The Best Programming Advice I Ever Got - swannodette
http://www.informit.com/articles/article.aspx?p=1926692
======
johngalt
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.

~~~
MattRogish
"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.

~~~
timrichard
> this is my biggest job as "manger"

I think you chose the wrong word there, but hay.

~~~
MattRogish
Whoops, fixed; thanks!

------
gfodor
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
"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
It depends on the organization how long it takes. In a more 'enlightened'
organization it's common courtesy to ping an engineer whose code you are
working on improving, and then you can hack away. In a more stodgy one, yes,
it could take 10x longer to get everyone on the same page if there are some
people whose egos are easily bruised.

Regardless, it's a dick move to rewrite someone's code over the weekend and
then roll in on Monday and start demoing it to PHBs that the original authors
report to.

It sounds like the author had little respect for the original authors and
decided he would swoop in and 'save the day' and not even give them a heads up
with what he was doing. Then, he had the nerve to demo it to their superiors,
and it's probably not hard to imagine him taking this 'opportunity' to explain
why the original authors suck.. I mean, failed to think of this solution. The
"but, but, I'm just making the product _better_ " angle provides cover if he's
called out on keeping the other authors in the dark.

Being a bit of a cowboy and having tact are not mutually exclusive things.
This particular story reeks of someone looking to not just highlight their own
skills but to do so at the expense of others.

~~~
briandear
Maybe it was a dick move for people to waste productivity over turf battles.
Everyone's time was wasted.

A lot of these political fights sound a lot like working with unions. "Oh you
can't do that, it'll save time and we won't get to work as many hours."..and
then a few years later they're wondering why the plant declared bankruptcy.

------
ChuckMcM
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.

~~~
danielweber
One way is to improve the code and run it privately yourself. When other
people see your system flying just shrug until they are begging to know the
answer.

Ideally it would never come to that.

~~~
specialist
Best political advice I ever got was "Never volunteer. Make them ask you to do
it."

Every time I've ever fixed something or made something awesome, I've been
punished.

The times I've played it detached and cool, grudgingly do some seemingly
impossible task (which is actually easy), I get rewarded.

I've said this here before: If you ever do something awesome, tell no one. If
it's awesome enough and the stars line up, convert it into your next startup
and eat your former benefactor's lunch.

~~~
theorique
_I've said this here before: If you ever do something awesome, tell no one. If
it's awesome enough and the stars line up, convert it into your next startup
and eat your former benefactor's lunch._

A little machiavellian, but not wrong.

Unless you're an owner or part-owner, the fruits of all your 'awesome' ideas
are going to accrue to the owners. Is that what you want most? In many cases,
genius coders, professors, and creative people are paid in prestige and
exposure, while investors and founders are paid in $.

~~~
tripzilch
> A little machiavellian, but not wrong.

Because if you do Machiavelli correctly, _you_ get to tell the story of who
was wrong.

------
dredmorbius
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.

------
heyrhett
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
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
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
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.

------
Zenst
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.

------
adamio
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

~~~
thebigshane
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
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.

------
thornofmight
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."

~~~
gambler
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
"The content of the advise was bad, but the overall effect of it on the author
was good."

Now I get it. Thanks gambler.

------
Ingaz
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>

------
bluesmoon
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.

------
mephi5t0
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
That's not misleading, that's sarcasm.

~~~
briandear
Some would even say irony.

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

------
happywolf
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
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)

