Live data from Hacker News

The Best Programming Advice I Ever Got (2012)

russolsen.com

31–40 of 55 posts

Re: The Best Programming Advice I Ever Got (2012)

#31
What I don't understand about this is how people are able to express their dissatisfaction about someone else making the code faster, when it's so transparent that they are just butt hurt that their way of doing it wasn't so good after all. Of course I get that such people could from then on hold a silent grudge against you, but I can't understand how they can openly complain about this without making it totally obvious that it's just an ego thing.

Re: The Best Programming Advice I Ever Got (2012)

#32

Earlier quoted context omitted.

The point wasn't to stay out of people's code. He used that "advice" as a reminder to not be what those people were/are.

And what are "those" people?

People who get upset if you touch their code. I think in your other comment you missed the fact that there was already an ongoing debate about this particular part of the code, and it wasn't going anywhere. In such a case a demonstration that the other method is faster is more compelling than more fruitless debate. Speculations on other reasons why the code should've used 2 processes is useless, as it is clear from the article that this change made it possible to get things done faster, no need to argue with that.

Re: The Best Programming Advice I Ever Got (2012)

#33

Earlier quoted context omitted.

He made a classic mistake that I think all of us make once: overperformance without proper (managerial or executive) support. Overperformance fucks up more careers than underperformance, because it makes enemies. (No one actually gives a shit about the pittance drawn away by an underperformer on salary, but overperformance puts peoples' reputations on the line and is generally volatile.) You don't want to fall into t…

Totally agree. "Overzealousness worse than fascism" And I don't believe in such idealism, if he was doing it for the sake of performance he should show it to the developers first, and not perform a show for his boss and boss's boss and THE BOSS and who knows who else. So what was the real intention behind this?

I don't think he had an ulterior motive. I think he was young and had never had a negative career experience and therefore didn't realize what office politics were about and that, even if the execs seem like nice people, any information you furnish to them stands a nontrivial chance of being used in a horrible way.

In a collegial, sympathetic R&D type environment, people are happy when others improve their work. However, in an office environment, it's not the same thing, because you can hurt peoples' careers without even trying and unintentionally make enemies.

Re: The Best Programming Advice I Ever Got (2012)

#34
I have been there in that sort of situation where managers twist their eyebrows at an efficient or productivity-enhancing solution. The essence of the java enterprise consulting business is fixing an unnecessary complicated mess with a similar, new buzzword backed mess.

So the interesting thing here is how bureaucracy and efficiency seem like natural enemies; a subject which always reminds Terry Gillian's Brazil movie where the terrorist guy is the one who fixes things.

Re: The Best Programming Advice I Ever Got (2012)

#35

Earlier quoted context omitted.

We are also not taught how to make the decision to GTFO. I've recently had to make such a decision and really had no prior experience to based anything on. It was a completely new experience. Yes I eventually made the decision to GTFO but it's still lingering in the back of my head if I made the right one.

I've done it multiple times now since I've graduated from college. It makes you uneasy each time and shortly afterwards I definitely questioned myself. But today, I don't regret it one bit.

Thanks for that. Only time will really tell but after I made the decision, it was rather freeing.

Re: The Best Programming Advice I Ever Got (2012)

#36

Earlier quoted context omitted.

" Understand the processes you're working on, and the problems that your co-workers are dealing with. " Go further than that. Step back and look at the environment as a whole. It helps to spend time understanding a situation before assuming you have appropriate ideas about changing it (ref. below). https://www.wittenburg.co.uk/Entry.aspx?id=46870dcd-70cb-4ef...

In my opinion I think the author did try to address the big picture. He brought it to his boss, and his boss's boss. If ideas are commodities worth trading then why was the market closed from the top down? This is a lesson in corporate culture which I think the author explains quite well.

> In my opinion I think the author did try to address the big picture.

Sure. But grandparent's point is that he did it backwards: first he made the changes he wanted to see, and then he demoed it up the chain and got himself in hot water. Had he first taken time to develop a thorough understanding of the situation and the environment in which it had origin, he'd have been able accurately to evaluate how best to take action in order to bring about his desired result -- or indeed whether it might instead be best, despite what had originally seemed to him a desperate need for improvement, simply to cultivate the detachment necessary to take no action at all.

Re: The Best Programming Advice I Ever Got (2012)

#37

Earlier quoted context omitted.

If you bail on every company that's dysfunctional and political (that's about 90%, including of startups) you'll probably get stuck with the job-hopper stigma before you find a good company. Employers get away with horrible conditions and general dysfunction because of the job hopper stigma, but unfortunately, one person leaving bad situations immediately (instead of wasting months to years trying to make lemonade ou…

The answer to "job-hopper stigma" and any and all other competence-trigger hurdles is simple. Sell the benefit, not the feature. In other words, change the conversation from "who you are" to "what you can do for them". A track record of accomplishments does a lot more to convince a stake-holder that you know what you're doing than a list of previously-held positions. If all you have is a list of previously-held posit…

Well. Conveying competence is, indeed, a valuable skill. But the most it can do for you is to get you a seat at the table. What will you do once you've got the job, and it comes time to play the game?

And, while we're at it, why assume that the only possible reward for playing the game is the opportunity to keep playing the game? Isn't it possible that, in playing the game with sufficient skill and artistry, you can create for yourself the opportunity to do the work you joined that company to do?

...to be honest, I really don't know the answer to that last question at all. But it sure is an interesting question, don't you think?

Re: The Best Programming Advice I Ever Got (2012)

#38

Earlier quoted context omitted.

I've done it multiple times now since I've graduated from college. It makes you uneasy each time and shortly afterwards I definitely questioned myself. But today, I don't regret it one bit.

Thanks for that. Only time will really tell but after I made the decision, it was rather freeing.

I think that's probably telling in itself. I've GTFO'd twice; one time was by my own choice, while in the other I had to be helped along by the organization a few months after I failed to follow my sensible instinct to resign. Both times, once I was finally out the door at last, I found myself feeling like a weight had come off my shoulders.

I could be wrong, but I don't see any way it's possible for that feeling to come along with a lurking realization that I'd made a mistake. (Certainly it never has in my experience, at least, and I've made plenty of mistakes.)

Re: The Best Programming Advice I Ever Got (2012)

#39
post #21

Earlier quoted context omitted.

That's the opposite of Facebook's mantra that "code wins arguments". Which has worked well for me.

If I understand correctly, that's Facebook saying that decisions are not going to be made politically. They're going to be made on the basis of what is best technically. And that's great... for Facebook. What I was talking about is companies with a different culture, where politics gets into technical decisions. In that culture, you can't just fix the technical problems, precisely because at that company, code does n…

> And that's great... for Facebook.

Really? Because I'll bet you any sum you care to name that Facebook is just as riddled with internal politics as any other organization of its size in the field, Google specifically included. To believe otherwise is to believe that the people who make up Facebook are other than human.

Re: The Best Programming Advice I Ever Got (2012)

#40
post #8

I think that the advice, if taken literally, is a bad advice. But it does point to the fact that the system is not just the technology, but also the people around it I think that a better way to go about it was to comment first with the proper people that you MIGHT be able to make it run faster before doing anything (all though you know that you already did it). And drop the case if they don't want it. I can see that…

> But it does point to the fact that the system is not just the technology, but also the people around it People come and go. They don't die when they are sacked. They are absorbed by other companies to do other possibly more awesome stuff. There is no point of delaying progress of software because that might mildly inconvenience some people. If half of the Adobe got sacked over a shitstorm caused by some rogue progr…

(In the following, we will stipulate that your "rogue programmer disrupts Photoshop, resulting in a better product and getting half of Adobe fired" situation is plausible, for the sake of illustration.)

The half of Adobe you posit getting sacked wouldn't say it was worth it, though, and from a certain perspective -- namely, their own -- they'd be right.

After all, Photoshop is already the unquestioned leader in its field, and the closest competitor isn't even within shouting distance, so what good does it really do Adobe's business if Creative Cloud's Photoshop component sucks 20% less?

(Yes, no one is happy with the change from Creative Suite to Creative Cloud; this I concede. But those who are unhappy with it aren't decamping to the GIMP or some other laughable knockoff; instead, they are buying CS6 licenses, and they aren't going to be convinced to replace those with Creative Cloud subscriptions by a mere 20% improvement in Photoshop.)

Meanwhile, there are a whole lot of people earning livings as part of Adobe Inc., who, in your "rogue programmer disrupts everything" scenario, suddenly won't be.

This, for good and necessary reasons, makes every one of those people a political enemy of your rogue programmer; after all, whether he means to do so or not, the effect of his actions is to critically imperil those people's ability to maintain themselves, their families, and the position in life to which all of same have grown accustomed.

(This might seem to you like a mild inconvenience. If so, I can only assume either that you're not getting paid well, or that you're only so recently getting paid well that you've yet to accustom yourself to it, and in either case that you're also not carrying a meaningful amount of debt. Hell, I'm not paid all that well, and I carry less debt than anyone I know, and I can assure you that my recent layoff was nonetheless far more than a "mild inconvenience".)

Getting back to our illustration: Of course, I'm sure our lovable rogue doesn't intend to get all those people laid off; indeed, given his laserlike focus on the quality of the product for which he considers himself responsible and his evident and total innocence of matters political, it probably never even occurred to him that such a thing could happen. This doesn't matter at all. Whether he intended it or not, he's put a huge chunk of the corporation which employs him in danger of being laid off.

Expecting those people to react in any other way than by attempting to squash him, by whatever means prove necessary and lie within their grasp, would be foolish; when you threaten a man's life, or something which a man regards as vital, i.e., essential to life, it is only basic sense to expect that he will react as strongly as is within his power. Speculate all you like on why this should be the case; regardless, it is a fact of human existence, and to regard it in any other frame of mind save acceptance is to waste your time and mental effort on utopian fantasy.

And half of a company the size of Adobe is a group of people with a very great deal of power, indeed. Even if we scale down from Adobe as a whole to just the Photoshop project team, at least some of those people are perforce going to be in the higher ranks of management. In fact, since our rogue is a Photoshop developer, at least some of those people are going to be in his direct line of command.

No points for guessing what happens to our lovable rogue when, through his innocence of the political realities of any large human organization, he places at risk the jobs of one or more of his direct superiors. Even if, by some impossible miracle, he manages not to lose his own job, then he's certainly not long for the company, because among the people he's managed to alienate are many of his peers. This means he's got more people looking to put knives in his back than he could keep up with, even if he realized he needed to be looking over his shoulder.

Of course, our lovable rogue being not entirely without some sort of rudimentary sense of interpersonal relationships, even if he isn't shuffled aside immediately and laid off as soon as practicable, he'll realize that his only sensible option is to resign, because there is no longer any chance that he'll be able to work productively with his erstwhile colleagues, who now consider him about as safe to be around as old dynamite that's sweating nitroglycerin.

So our rogue will quit his job, lick his wounds, and find somewhere else to work, and odds are the lesson he'll take from his error is, from the perspective of his future prospects and his ability to advance his career, the single worst one he could possibly choose: specifically, that office politics are incomprehensible, deadly, and evil, that anyone who engages in them is therefore necessarily an awful person and best avoided, as are office politics in general, because an honest hacker can't understand the game well enough to play it, and it'll only end in tears.

None of which, of course, is true. But all of it accords perfectly with the default attitude among software engineers toward office politics, and I'm starting to think that might have a lot to do with the way that the default position of software engineers, when it comes to dealing with management, is "screwed".

Post reply on HN