Hacker News new | comments | ask | show | jobs | submit login
Russ Olsen: The Best Programming Advice I Ever Got (informit.com)
214 points by swannodette on Aug 10, 2012 | hide | past | web | favorite | 60 comments



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.


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


> this is my biggest job as "manger"

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


Whoops, fixed; thanks!


There's almost nothing more poison to an engineering organization than an engineer whose identity is tied to their code.


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


> Thankfully there is a middle ground. It's called talking to people.

> You can mitigate this type of territorial response by convincing them to disassociate their identity from a code block.

Do you have any suggestions for scenarios where this doesn't seem possible? Where any suggestion is treated as an attack, by both programmers, and their manager?


Completely agree. One of the quickest ways to burn bridges and ensure you are perceived as caring more about your own ego and "needs" than anything else, is to re-implement something without talking to anyone about it, be they the authors, stakeholders or 3rd-party dependents. This kind of "look at me, manager! look what I did!" behavior is the cancerous seed of a team ruled by self-seeking and ego.

If your needs would benefit the whole and are not a mere excuse for egoism, but are not aligned with the company/team, get another job.

In the end, the author learned a lesson, but the wrong one. It's not that you should listen when voices of dissent shout in your ear, but that you should simply foster a general environment of open communication, and discourage action-without-coordination.


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.


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


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.


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.


So you rewrite everyone's code to make it "better" without their permission. Now who maintains all that code? You do. Life's to short to own all the code in the world.


He didn't replace it, he made a demo. The original owners then had to implement his design.

I've coded up demos as tools for getting my point accross for a particular feature. I don't own or maintain the resulting implementation.

It was a proof of concept. He proved his point.

Though if you make too good a demo, you might end up gettig assigned to do the rest, and that is danger you speak of.


It's not always a political problem.

What happens when the change you've just demoed to the boss breaks an important feature that you didn't know about?

In the case of the absurdly slow client/server architecture, what if this was a defense against a chunk of code prone to locking up or crashing? What do you do when your new, faster program suddenly crashes every five minutes after its deployed to production?


I would say that the other people did 'the political part' wrong. Nowhere else in life have I seen so much ego as with programmers.

I once thought it was because programming was a creative profession, and creators are protective of their creations, but I haven't seen anything like this in other creative media. When a musician composes or teaches me some music, I usually hear "that's just how I do it, you can do anything you want with it!".

It's not just about challenging seniority, either, because when I present a new approach to people with more experience than me, 90% of the time I get "here's why that's not actually better..." (and I learn something), and 10% of the time I get "OK, let's do that". (Or maybe it's 99%/1%.)

The only place I've been that even comes close is university politics. Perhaps that could explain programmer politics, since so many programmers come from there.


When a musician composes or teaches me some music, I usually hear "that's just how I do it, you can do anything you want with it!".

Try suggesting a change to a song a musician is in the middle of composing...


In my experience, graphic designers are the most egoistic, pedantic, territorial of all. Particularly web designers.


Like most engineers, he did the coding part right, the political part wrong. The right way to approach this would be...

This assumes there is a right approach. In reality it is highly probable that there is no such thing as a right approach. So actually the right thing to do is find another job.


If you plan on switching jobs every time rewriting someones code over the weekend and demoing it to their boss results in bad things then you better keep your resume polished.


No, but if people get pissed at you for working overtime to dramatically improve the system, it's a strong sign there's a better place you could be. Could the guy be more tactful? Definitely. Could this be the best place the guy could work? Doubtful, if he could make such an impact. But being ostracized rather than educated indicates an unhealthy work environment.


Or not waste that mental energy, and channel it into passive income/side-business activities. Fulfillment can rarely be found in a day job.


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.


The problem is, I have worked several places where the problem wasn't that nobody understood the problem, but that nobody would solve it. Either because they were busy with other things or because egos were on the line or some other intraoffice drama. Which puts someone in the situation described here in a predicament. He can tell people, who already know what is wrong, how to fix it (in nice ways), and watch as nothing happens. Or he can just do it. I fall into the latter. Just Do It. If your managers are childish enough to use it to attack each other, that is there problem. But I'm at work to make a good product and that is what I will do. I won't gloat about it. I won't call people stupid for implementing it that way or not solving it earlier. It will simply be a ticket I work on that goes out in the next release.


Unfortunately, no one else will see it that way. The person responsible for the bad design will probably raise hell, the project manager might raise hell about changing the architecture without review, and the Management will do everything they can to push you out of the company.

It happened to me because of my Just Do It attitude, and now I need to go check the job listings again. Unemployment insurance is running out.


This has never been the case for me. Perhaps you should be more discriminatory when it comes to choosing a place to work?


If I were any more discriminatory about my work, I'd not be able to find any.


I'm not sure how (3) could go anything like you suggest in your revised scenario. If the young hacker in question had asked about pub-sub architectures being slow after the engineer responsible had already taken a political position on pub-sub then the answer is going to be "of course not!". At this point admitting that pub-sub can be bad would be a big embarrassment.

The way to fix this is to get people to think of stuff like that before they've taken public positions on the issue.


My experience has been that generally, even the most egotistical programmer, will listen to someone. Finding out who that is, and then working your way backward to someone who will listen can be a useful strategy.

The point I was trying to make is that you can make change happen in highly political environments if you're willing to not get all the glory (and sometimes any glory).

"The way to fix this is to get people to think of stuff like that before they've taken public positions on the issue."

Absolutely great advice. The challenge some times is know what they are thinking before changing position would cause them to lose face (respect). In Russ' post he had inherited a system that was broken, it read like those choices had been made long before he got there. I once proposed a RAID device at NetApp which had similar functionality to but a different implementation than the way it had been done. Watching the anti-body reaction on that was particularly enlightening. I wasn't so invested in the idea that I was going off and beat them about the head and shoulders with a fait accompli, and it wasn't something I could build in a couple of months worth of weekends. I decided to move on instead. Life is too short to spend it fighting the system for something which is right but ultimately not your passion.


I once was in a meeting where they had implemented a solution to a problem, but the solution was totally inadequate. I had an easy fix, but they didn't understand the problem correctly. I was treated pretty poorly in the meeting.

Unfortunately, I took it badly and got annoyed. I eventually managed to force in my solution, which saved quite a lot of contracts from falling through. Sadly, this caused me issues later down the line with the remarkably arrogant developers (one in particular!).

In the end, I would have been better not stressing about it and focus on other things. The company was later acquired by a large storage company who managed to throw away the secret sauce and keep the dysfunction, and eventually they sold it to a certain well known virtualisation company who has now dropped the product. So in the end, it probably wasn't worth it!


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.


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.


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


> A little machiavellian, but not wrong.

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


This is one of the best pieces of advice in the thread and should be much higher. Make the fix but never check in the code, and just run it like that on your own machine. Assuming it is a visibly big enough change someone is going to eventually notice.

An extra bonus potential is, who sees the change running first....if it is engineering personnel from the "wrong" camp, one could derive some delicious pleasure watching them squirm once they've seen what you've done and the implications dawn upon them, I can just imagine seeing the gears turning in their head, trying to figure out how to get themselves out of the predicament!


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.


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.


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.


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.


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.


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.


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


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.


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.


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.


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


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.


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.


"The content of the advise was bad, but the overall effect of it on the author was good."

Now I get it. Thanks gambler.


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.


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.


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.


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


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.


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.


That's not misleading, that's sarcasm.


Some would even say irony.


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


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.


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)




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: