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

161–170 of 247 posts

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

#161

Post by hueving »

adrianhel wrote: post #124
iratewizard wrote: post #56

Earlier quoted context omitted.

Or maybe more realistic and less paranoid: the code he wrote was more performant but significantly less maintainable. Look at it from a director's perspective. Technical debt from an H1b. Is he trying to maintain job security by being the only one who understands how a critical module works?

In this scenario the lack of performance was significant, so I would say it was necessary. If performance was adequate, different story. For example. We have a redux based content editor that is quite slow. It is however more than performant enough for the use case. I would love it if someone refactored it though...

You don't know how significant the performance difference was. You're just believing the commenter who thought it was without hearing from the company who obviously didn't think it was a priority.

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

#162

Post by busterarm »

steve_taylor wrote: post #113
blowski wrote: post #25

Earlier quoted context omitted.

Your description of Hacker News makes it sound like it's a single person with a uniformly consistent opinion. It isn't.

It’s a mob, reinforced by a system of rewards (upvotes), punishments (downvotes) and the politics of “karma”.

Some of us don't care so much about the karma. Reactions to my posts are either extremely polarized (one way or the other) or basically neutral. I've even gotten the occasional ban threat from dang when I say something particular unpopular. Occasionally there's still some worthwhile discussion that happens here.

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

#163

Post by edw519 »

"Stay the hell out of other people's code."

Great advice if you want a miserable 40 year career as a team player in mind numbing corporate work prevention departments.

Bad advice if you want anything more out of your programming career.

Horrible advice if you want to make a difference by sharing your gifts with those who need them.

You don't get that many chances to do what OP did by jumping in and making dramatic improvements.

The only reason I have ever avoided staying the hell out of legacy code was when opening that can of worms was just the wrong thing to do for everyone.

Otherwise, I got the hell in there.

Sometimes I was thanked.

Sometimes I was reprimanded.

Sometimes I was fired.

Always I learned something, usually the best learning I ever had.

(And as for getting fired, I wouldn't have changed a thing. This is actually a good thing. Better to push the limits, find out who you're dealing with, and move on quickly rather than being miserable for years without ever understanding why.)

The Best Programming Advice I Ever Got? ... Always Do the Right Thing. (Even if it takes a lifetime to figure out what that is.)

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

#164

Post by hueving »

haxorito wrote: post #148
haxorito wrote: post #43

I made same mistake, I saw how old system underperformed and that I could make it better, faster, more stable and bring higher profit. When I presented that my boss, next I know I’m in room with HR, my bosse’s boss and technical lead (who was practically executive director), to my surprise boss started conversation with “your actions concerning me...” they told me to give all the related code, documents and remove ev…

Answering all questions. One thing i left off is the reason why I was in hot water: Everyone in our organization is really “rank-orientated”, I challenge their intellect and their baby they were proud of - it was foundation for our organization to even exist in company. Even though it was outdated, poorly designed system, that produced high percent of outages and heavy on maintenance. But it was not my place or posit…

It's also possible your solution wasn't as elegant, maintainable, or as performant in all cases as you thought.

If you're going to approach upper management with such a hostile attitude, you need to run it by some peers first to have them poke holes in the idea and get onboard.

Why I called your approach hostile: you phrased it as "challenging their intellect". That's not how good engineers pitch changes.

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

#165

Post by hueving »

StavrosK wrote: post #125
jpatokal wrote: post #102

Earlier quoted context omitted.

+1. The fact that HR's involved strongly suggests that OP was messing with something he had no business to touch.

I don't understand this, or the linked article. Can someone explain to me what possible reason there can be for responding with disciplinary action when someone proposes an improvement?

An easy reason that often gets left out of these stories is that someone spent weeks on a rewrite without authorization rather than working on burning priorities.

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

#166

Post by romeisendcoming »

Depends on your model. In a small business where you have a couple experts in different domains it makes perfect sense to talk about individual ownership. It's not toxic: it's forced practicality. In larger environments with close skill parity it doesn't make sense and hurts morale.

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

#167

Post by JimmyAustin »

Aeolun wrote: post #111
jpatokal wrote: post #100

Earlier quoted context omitted.

It's not about the tech, it's about the politics. If everybody agrees Redis is the way to go, sure, go ahead and optimize it. But what if there's a VP who's been arguing that using Redis is a mistake and you should be switching to MongoDB?

You kick the hornets nest.

"If you come at the king, you best not miss."

If you criticize a seniors ideas, and they interpret it as you coming after them, you better destroy their reputation, or they'll destroy you. It's hard to destroy someones reputation within an organization, and most people get defensive when newcomers (especially juniors) come in with suggestions, so it's typically not worth kicking the nest.

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

#168

Post by ThrowMeDown01 »

WilliamEdward wrote: post #133
haxorito wrote: post #43

I made same mistake, I saw how old system underperformed and that I could make it better, faster, more stable and bring higher profit. When I presented that my boss, next I know I’m in room with HR, my bosse’s boss and technical lead (who was practically executive director), to my surprise boss started conversation with “your actions concerning me...” they told me to give all the related code, documents and remove ev…

You're clearly leaving out some important detail, which makes me think this is 100% your fault and you were being stupid, even though you want to play the victim

One argument in favor of such an interpretation is that anytime somebody posts such an anecdote, and in various contexts that happens not infrequently, there is one giant thing all those story tellers forget: That everybody else only sees their side of the story, and that posting something that looks so one-sided "everybody was being stupid but me" is better not posted at all because of how unbelievable it looks, even if it indeed is true. If they had any good level of people-understanding they would in my humble opinion be much wiser to not tell the story here, or at least not make it look so one-sided, or add some disclaimers showing some self-awareness that shows they at least considered that they themselves are a key part of the problem. It reminds me of that joke of the guy who is driving a car on the autobahn and hears a warning on traffic radio about a wrong-way driver right where he is driving. "Only one?" he says to himself, "Hundreds!"

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

#169

Post by throwawaymjabba »

HeyLaughingBoy wrote: post #98
jolmg wrote: post #52

Earlier quoted context omitted.

The fact that he was a foreigner provides a hint. It seems there's a general fear in the US of foreign workers taking the jobs of citizens. I wonder, is it not possible to switch employers when you have a work visa?

there's a general fear in the US of foreign workers taking the jobs of citizens Comments from our idiot president and his ilk aside, there is not. I'm willing to entertain discussions to the contrary, but this is far from my experience either here in the Midwest, or on the East Coast where I previously worked.

I worked for the US counter part of an Indian company in Illinois for a couple of years. We used to have town hall meetings every quarter. On 2 such meetings, I heard two separate American employees questioning the speaker about outsourcing more. He would be talking about how they are planning to spread out a project with 20% in US, 50% in India, remaining in Europe and some other place. In both the occasions, they asked questions that meant why only 20% in US or something similar. He always replied that's what the customer is willing to pay, that the customer has so and so budget, and this is how we are meeting it.

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

#170

Post by phaedrus »

marktangotango wrote: post #155
strken wrote: post #135

Earlier quoted context omitted.

How do you stop mediocre programmers from working on advanced tasks, and is the overhead of doing so greater than the cost of hiring excellent programmers?

Mediocre devs simply can’t do advanced tasks. They’ll spend months with no results. I’ve seen this countless times, especially working with offshore teams. One project was hobbled by terrible database performance. The app simply couldn’t scale. I listened to weekly calls for a year while they floundered. Finally I researched their connection pool and told them setting to control “verify connection before each call” t…

Problem is there is a class of mediocre programmers who do get results - it's just that they are productive building things that appear to work just long enough for them to be able to move on to the next task, but their work either doesn't scale or falls over in production.
Post reply on HN