Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Best Programming Advice I Ever Got (2012)

russolsen.com

Post reply on HN
Print view View original

21–30 of 55 posts

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

#21

Post by bjt »

AnimalMuppet wrote: post #12
chazu wrote: post #9

Earlier quoted context omitted.

That's an important corollary to the author's actual point, if you ask me. Sure you shouldn't make golden calves out of bad old code, but also don't be the guy that mercilessly hacks apart other people's code without allowing them to defend it. Instead have a socratic dialogue about the pros and cons of different approaches to the problem.

If I understood the article, the pros were technical, and the cons were political. And, here's some actual good advice: Never try to solve a political problem by technical means (or vice versa).

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

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

#22

Post by michaelochurch »

baldfat wrote: post #2

Good read, BUT the advice is stay away from Drama and especially work Drama. Seems to me 50% of people are damaged immediately by work Drama and the other half die slowly with maybe one or two sort of winners. I would go work somewhere else and stay happy.

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 that trap. I'm not saying that people should do shoddy work, but if you're going to do more than that you're asked to do, make sure it's behalf on someone powerful enough to clear obstacles and get your back, and who will.

He improved the product and, through no intention of his own, ended up ears deep in office politics. It's a perennial risk. It takes at least one of those, for most of us, before people realize that if you're going to overperform, it should be for something you own. That way, you avoid the risks (you can't get fired from your own side project) and keep the rewards, instead of the reverse.

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

#23

Post by jack9 »

michaelochurch wrote: post #22
baldfat wrote: post #2

Good read, BUT the advice is stay away from Drama and especially work Drama. Seems to me 50% of people are damaged immediately by work Drama and the other half die slowly with maybe one or two sort of winners. I would go work somewhere else and stay happy.

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…

> because it makes enemies

In 20+ years, I've never seen better performance (according to casual metrics) make enemies. But then again, there are some awfully backward people here.

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

#24

Post by michaelochurch »

naterator wrote: post #3
baldfat wrote: post #2

Good read, BUT the advice is stay away from Drama and especially work Drama. Seems to me 50% of people are damaged immediately by work Drama and the other half die slowly with maybe one or two sort of winners. I would go work somewhere else and stay happy.

Yea, the lesson is: If you find yourself in a situation like that, bail out as fast as you can. When we're young we are often not taught—or more importantly we do not have the opportunity—to simply GTFO of the crappy situation we're in (Family, Bullies, etc.). It has tragic consequences both early in life and later on. It's (one of the reasons) why we get school shooters, why people stay at crappy companies when they…

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 out of piss-lemons) is not going to break that stigma. In fact, it's going to lower your value and make you more likely to end up in dysfunctional companies.

A better strategy is to play the game, well, by learning how to do enough in typical, semi-dysfunctional environments to get career credit, while keeping an eye out for better opportunities. This all-or-nothing attitude that many young people have toward corporations ("if they think that way, then I don't want to work for those losers anyway") doesn't pan out in the real world. Even the good companies have plenty of stupid, political people in them.

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

#26

Post by jorgeleo »

DavidBradbury wrote: post #16
jorgeleo wrote: 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…

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?

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

#27

Post by AnimalMuppet »

bjt wrote: post #21
AnimalMuppet wrote: post #12

Earlier quoted context omitted.

If I understood the article, the pros were technical, and the cons were political. And, here's some actual good advice: Never try to solve a political problem by technical means (or vice versa).

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 not win arguments. Politics does.

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

#28

Post by lafar6502 »

michaelochurch wrote: post #22
baldfat wrote: post #2

Good read, BUT the advice is stay away from Drama and especially work Drama. Seems to me 50% of people are damaged immediately by work Drama and the other half die slowly with maybe one or two sort of winners. I would go work somewhere else and stay happy.

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?

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

#29

Post by scotty79 »

jorgeleo wrote: 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 programmer making Photoshop suck 20% less I'd say it was worth it.

The superpowers of companies is that they can die (or get severely crippled) without utterly destroying of what they consist of.

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

#30

Post by vinceguidry »

michaelochurch wrote: post #24
naterator wrote: post #3

Earlier quoted context omitted.

Yea, the lesson is: If you find yourself in a situation like that, bail out as fast as you can. When we're young we are often not taught—or more importantly we do not have the opportunity—to simply GTFO of the crappy situation we're in (Family, Bullies, etc.). It has tragic consequences both early in life and later on. It's (one of the reasons) why we get school shooters, why people stay at crappy companies when they…

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 positions, then sure, if there's more entries on it than years, you'll have a rough go at it. But you don't have to operate this way.

Nobody is unemployable. There are only people who have figured out how to convey competence and people who haven't.

Post reply on HN