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

101–110 of 247 posts

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

#101

Post by Silhouette »

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 wasn't really that someone "owned" that code, but that when someone else did have a useful suggestion to make, politics overrode technical merit. Clearly that had been happening for a long time and resulted in several other potentially useful contributions by others being wasted as well. This seems to be a problem of toxic management culture, not a flaw in the technical processes.

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

#102

Post by jpatokal »

HeyLaughingBoy wrote: post #99
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…

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.

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

#103

Post by eikenberry »

leaveyou wrote: post #90
ken wrote: post #63

There's definitely value in respecting boundaries. Sometimes you have to take a small local inefficiency in order to create a bigger global efficiency. That's life. In my experience, though, this is a much bigger problem in software because nobody really knows what they're doing. There's no industry standard way to do almost anything. You can argue about "use Foo!" or "don't use Foo, use Bar!" and there's no one Corr…

>>There's definitely value in respecting boundaries. Sometimes you have to take a small local inefficiency.. I don't think anyone argues with that. It's just that sometimes some of the biggest impostors hide behind "boundaries". >>This will continue to be a problem for the next 100 years until we figure out the right way to make good software. A lot of people figured it out already.. but those are a minority and the…

Individual "masters craftsmen" have always figured out things like this way before they have become common practice. But I think original poster was meaning "we" as a profession stabilizing on standard good practices that everyone knows and uses, not just a few masters.

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

#105

Post by koala_man »

usawco wrote: post #61

I had a similar experience and similar results. Someone wrote code to perform 1000 queries to pull back 1000 rows in a specific order rather than issue one query and let the Java collection order the results. Amazingly, another person wrote more logic to add a switch to skip this step because it literally took 10 minutes for the app to start when connected over VPN. The fix was trivial and startup time went from 10 m…

I don't know whether to laugh or cry.. You work at a better place now, right?

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

#106

Post by georgebarnett »

avinium wrote: post #96
georgebarnett wrote: post #54

Killing sacred cows in software dev is a crucial part of the overall process if you’re going to keep a product alive long term. Learning HOW to kill a sacred cow without pissing everybody off around you is a crucial part of learning to become a senior leader. Once you know something will work, there’s a HUGE amount of groundwork to get social traction for a change. Without it, you’ll get the change but not the “team…

> Once you know something will work, there’s a HUGE amount of groundwork to get social traction for a change. Without it, you’ll get the change but not the “team progress”. You're not wrong, but equally I'd argue that if you need a huge amount of groundwork to implement change, you're probably in the wrong organization. Good organizations value good ideas, irrespective of who thought of them.

I'm not disputing that and in general I think that holds as a good litmus test. If you're always having to push crazy hard and nobody listens, one party is failing here (its either you or the company, situation dependent).

That said, my experience tells me there's a lot more to it in some cases, org dependent.

For example - all teams (even great ones) go through phases where they can tolerate more change than at other times. Why that's true is itself a huge list of factors ranging from what the org is doing as a whole, all the way down to the team itself and how they're currently working.

It also matters how the idea is spread among a group. If the idea has legs, theres going to be a lot of broken telephone if you haven't correctly setup the context with thought leaders (which may be different people to the managers, who also need to know what's coming). This gets more challenging as the number of people involved gets larger.

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

#107

Post by HillaryBriss »

vubui wrote: post #32
HillaryBriss wrote: post #10

it may not be good advice, but it gives you something to think about

Why is it not a good advice? Care to elaborate?

sorry. i was not clear. i just meant to say that one need not agree or disagree with it in order to gain some value from it.

i mean, it's worth thinking about: "some people might get mad when i make a change to this unfamiliar, problematic, buggy code base. but how mad are they going to be? could my boss become angry with me? will i make any enemies? will i be a hero? will anyone even notice?"

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

#108

Post by dktp »

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

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

#109

Post by kingofhdds »

avinium wrote: post #97
kingofhdds wrote: post #91

It's not a programming advice. Similar counsel is dispensed in various tech, and non-tech fields, because it's about relations with other people which sometimes could be more important than efficiency for one's career, or comfort. However, to discourage from thinking about improving other programmers code, and call it "the best programming advice"? No way.

You didn't read to the end. The author recognizes this as patently bad advice, and was glad to have received it so he was conscious of what not to do.

Yup, my fault. I exploded too quickly, probably because recently had a similar discussion related to my own work.

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

#110

Post by z3t4 »

Communications! Don't stomp on other people to get to the top, instead get them to boost you up! Example: Make the changes to see if it works, but instead of showing it to your or his boss, you tell the one who wrote it that, "hey I got an idea on how to make this 100x faster". Only when he/she says your idea will not work, you say "actually I did test it, see". And you might get valuable information like for example the political status.
Post reply on HN