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

131–140 of 247 posts

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

#131

Post by Gibbon1 »

moneytide1 wrote: post #28
Exuma wrote: post #7

Earlier quoted context omitted.

This article literally made no sense

I see how it's counter intuitive - almost seems as if the author is contradicting himself. But it did drive a point home, especially that last sentence. This is what I took away from it: You may be able to come up with better ways to do things, but that often means replacing or voiding the efforts of coworkers or bosses. People have fragile egos, and may feel their job is being threatened since you are arranging thin…

> but that often means replacing or voiding the efforts of coworkers or bosses.

Comment: Having a work environment where people up discard and replace the the work other people have done is really really bad for moral. If you let that stuff happen continually you'll end up with a team where no one cares or takes ownership of anything.

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

#132

Post by swframe2 »

sonnyblarney wrote: post #122
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 diffe…

My advice applies to the worker who has done enough research to feel confident that they've found a vastly better way that is likely to meet with resistance.

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

#133

Post by WilliamEdward »

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

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

#134

Post by Gibbon1 »

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.

I've never worked in a software only organization. But instead in smaller teams of specialists. Usually there is an process where if you have an issue with something you work with the person who's responsible to fix it. You just do not go in and change things. You never go in and change things without telling them.

Friend of mine talking about how he fixes bugs. Most of the time he tries to figure out where the problem is and and then writes that up. Then uses blame to figure out who wrote the code and reassigns the bug to them.

Him: I Eddy, hey think there is a problem with this condition in this function.

15 minutes passes

Eddy: checks in bug fix closes ticket

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

#135

Post by strken »

hutzlibu wrote: post #85
DavidWoof wrote: post #53

Earlier quoted context omitted.

> Hiring highly competent people to build software does not scale as well as hiring (many) more less competent people. I can't imagine an aphorism I disagree more with. I constantly come across companies with similar-sized platforms where one has a development staff 10 times the size of the other (both in cost and size), all due to the complexity and quality of the code. In the long run, few things are more expensive…

"In the long run, few things are more expensive than a mediocre programmer. " Disagree very much. Mediocre programmers are very good for mediocre tasks, of which there are plenty of. The problem is only, if mediocre programmers work on advanced tasks.

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?

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

#136

Post by WilliamEdward »

philipyoo wrote: post #123

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.

It's funny, because I wanted to be a developer for the exact opposite reason: to develop what I wanted, for myself not for a company.

There's few other fields where you can be this creative, where there's infinite potential and infinite niches available. Why waste it all and get tied up in politics? I sincerely thought the ability to do anything was the reason people became developers in the first place.

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

#137

Post by WilliamEdward »

blowski wrote: post #25
porphyrogene wrote: post #17

This article is a great reminder of how to work with others but I think it is unlikely to be received well here. Hacker News loves to dump on junior developers and hates literary subtlety. This article uses the latter to admonish the former.

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

His description makes it sound like a hivemind, which it is.

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

#138

Post by [deleted] »

StavrosK wrote: post #121
dktp wrote: post #108

Earlier quoted context omitted.

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.

[deleted]

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

#139

Post by sanderjd »

crimsonalucard wrote: post #128
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.

It's definitely bad for pride and politics to hinder progress, but a bit of tact often goes a long way.

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

#140

Post by ChristianGeek »

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?

You make someone above you with an ego look bad.
Post reply on HN