Russ Olsen: The Best Programming Advice I Ever Got
informit.com
informit.com
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 are either with us, or you are just old and suck :)
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.
I think you chose the wrong word there, but hay.
> 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?
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.
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, 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.
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.
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.
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.
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 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.
Try suggesting a change to a song a musician is in the middle of composing...
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.
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.
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.
The way to fix this is to get people to think of stuff like that before they've taken public positions on the issue.
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.
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!
Ideally it would never come to that.
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.
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 $.
Because if you do Machiavelli correctly, you get to tell the story of who was wrong.
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!
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.
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.
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.
If you want to know why dominant players get displaced by new technology, I highly recommend reading The Innovator's Dilemma.
There are any number of better strategies Kodak could have taken besides "waiting to die," as you appear to recommend.
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.
"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
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.
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.
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.
"Actually it was terrible advice, advice that I've gone out of my way to ignore it in the years since."
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.
Now I get it. Thanks gambler.
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.
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 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)