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

121–130 of 247 posts

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

#121

Post by StavrosK »

dktp wrote: post #108
williamdclt wrote: post #75

Office politics or not, you have a problem when people start referring to parts of prod systems as "my code" or "your code". For me, from the point you opened a PR it's the team's code, not your own anymore. Everybody should be able to happily edit this part of the code without even thinking about asking for your permission (though asking for your input would probably a good idea), first to avoid this kind of nonsens…

Say that a bug occurs in the code that I wrote and I'm more familiar with than anyone else on my team. I'll gladly say "I wrote this, I'll fix it". In a perfect world, we'd all understand every part of the project as well as the next coder. But in my world shipping features on time is often more important. I do not consider my work environment toxic at all. Just an agile startup

It's fine if you yourself want to take blame for some code you wrote. It's not fine if someone else wants to blame you for it. You wrote it, but someone else reviewed it, and (probably) still someone else tested it and yet someone else released it. It's a team effort.

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

#122

Post by sonnyblarney »

swframe2 wrote: post #120

I suggested to my engineering director that we pivot our dev effort to avoid what I thought was a pending disaster. He responded that as long as he was director he would never make the change I suggested. Six month later the CEO replaced him and the new director announced he was going to make the pivot I had suggested. The old director resigned but advised the new director that it was not worth keeping me in the org…

Let's also consider that the worker is not always correct, and that managers might face such advice all day long from various sources, often by highly passionate devs who also assume they are right.

In this case, it seemed that the director was 'wrong' but I don't think that there should be any inherent assumptions that an arbitrary engineers advice on pivoting is somehow the 'better' path.

Also, there's a huge difference between being 'wrong' on a technical opportunity, and 'negligence' (i.e. not doing research, observing facts) or 'malfeasance' (i.e. willingly doing the wrong thing for the advancement of self etc.)

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

#123

Post by philipyoo »

Politics makes me sad. My main interest in wanting to become a developer was to have the ability to build improvements. I want the company to do well. I want the team to receive recognition. I want the people around me to be happy and to be working on a product they care about.

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

#124

Post by adrianhel »

iratewizard wrote: post #56
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?

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

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

#125

Post by StavrosK »

jpatokal wrote: post #102
HeyLaughingBoy wrote: post #99

Earlier quoted context omitted.

When you presented what to your boss, exactly? Did you suggest "I can make it better, faster, more stable...?" or did you go ahead and make the change and say "see?" Were you in a position where you should even have been thinking about this system? I wonder what steps in this story you're leaving out?

+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?

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

#126

Post by ape4 »

The change made the program faster but nothing is simple. When the GUI and backend were different progresses there was memory space separation. It was impossible for a stray pointer in one to klobber the other. Also there was a protocol between the two - which could be used over the Internet.

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

#127

Post by gitgud »

ape4 wrote: post #126

The change made the program faster but nothing is simple. When the GUI and backend were different progresses there was memory space separation. It was impossible for a stray pointer in one to klobber the other. Also there was a protocol between the two - which could be used over the Internet.

That's what I first thought too. There's was obviously a decision to separate the processes, but the performance gain of combining them was probably more meaningful in the end...

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

#128

Post by crimsonalucard »

williamdclt wrote: post #75

Office politics or not, you have a problem when people start referring to parts of prod systems as "my code" or "your code". For me, from the point you opened a PR it's the team's code, not your own anymore. Everybody should be able to happily edit this part of the code without even thinking about asking for your permission (though asking for your input would probably a good idea), first to avoid this kind of nonsens…

It's not that simple. People have pride despite what they claim. If I rewrite an entire feature that someone did just because i think my way is better, you gotta be smart in how you think that should be done. Respect other people pride and work or dont expect them to respect yours.

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

#129

Post by adrianhel »

andrewstuart wrote: post #55

The conclusions I completely disagree with. If you discover a way to make the system 100X faster, and the reason is someone else's code, then tell that programmer, and only them, and tell them gently what you found and leave it with them to be the person who implements it, or offer to implement a solution together if they want to. They may or may not take sole credit but it doesn't matter. Definitely do not sneakily…

I do not agree with this. One bit. He was not the sneaky party.

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

#130

Post by rileymat2 »

Silhouette wrote: post #101
williamdclt wrote: post #75

Office politics or not, you have a problem when people start referring to parts of prod systems as "my code" or "your code". For me, from the point you opened a PR it's the team's code, not your own anymore. Everybody should be able to happily edit this part of the code without even thinking about asking for your permission (though asking for your input would probably a good idea), first to avoid this kind of nonsens…

That's an idealised position, but not always a realistic one. Having specialists who understand certain parts of a complicated system better than anyone else is often valuable. Beyond a relatively small size of project, no-one can be an expert on everything, and a "shared code ownership" strategy where all code is communally maintained may leave you with no true expert when you need one. The underlying problem here w…

Don't projects like Linux use a system of module ownership/lieutenants?
Post reply on HN