The Best Programming Advice I Ever Got (2012) • Hacker News Board

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

#181

Post by adwn » Sun, Dec 16, 2018, 6:06 AM UTC

ken wrote: post #152

hutzlibu wrote: post #80

Earlier quoted context omitted.

" 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 Correct Answer, so it becomes a political question." When foo and bar both solve the job and equally fast, then yes. But in the example of the article the other version was much faster. So faster (assuming no bugs got introduced) means clearly the correct answer here.

That's not clear at all to me. This system sounds extremely complex (which could be one of the causes of the problem!), so I don't see how we can assume that no bugs got introduced, nor that execution speed is the only metric that matters. Perhaps the existing socket-based solution simply used a bad timeout, and instead of a weekend of work to completely change the architecture of the system, it could have been fixed…

I don't think the single combat warrior is the right analogy for the article. Instead, to me it felt more like a "The Emperor's New Clothes" kind of situation, in which a naive [1] youngster inadvertently exposed the dysfunction of the organisation. Judging by the author's description, nothing that could have solved the performance problem – not even a simple config parameter – would have gone over well in the war between the two factions.

[1] "Naive" as in unaware of the ongoing office politics.

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

#182

Post by gcb0 » Sun, Dec 16, 2018, 6:07 AM UTC

edw519 wrote: post #163

"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 im…

I highly suggest you go back and re-read the text :)

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

#183

Post by dkrikun » Sun, Dec 16, 2018, 6:50 AM UTC

edw519 wrote: post #163

"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 im…

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

This

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

#184

Post by tinkerteller » Sun, Dec 16, 2018, 6:52 AM UTC

This is mind numbing article and probably not worth anyone's time. The so called "best" advice is: Stay the hell out of other people's code*.

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

#185

Post by dkrikun » Sun, Dec 16, 2018, 7:08 AM UTC

Could not disagree more. The author most probably freed the company from its dysfunctional stagnation due to some political issue. It is thanks to his ignorance that he resolved an issue, something that had to be done.

In general, staying out of other people code is a bad idea. It promotes lack of transparency and agenda proliferation. This is because the owners of the code start being a "monopoly", can work less hard, provide exaggerated estimates etc. When people know that others can read there code, maybe hack on it, make something faster or simpler -- well they work harder and tend to be more transparent.

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

#186

Post by wmichelin » Sun, Dec 16, 2018, 7:09 AM UTC

dkrikun wrote: post #185

Could not disagree more. The author most probably freed the company from its dysfunctional stagnation due to some political issue. It is thanks to his ignorance that he resolved an issue, something that had to be done. In general, staying out of other people code is a bad idea. It promotes lack of transparency and agenda proliferation. This is because the owners of the code start being a "monopoly", can work less har…

Sounds like you didn't read the article :)

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

#187

Post by eranation » Sun, Dec 16, 2018, 7:13 AM UTC

Did anyone really read this till the end? If your conclusion is that the best programming advice the author ever got was to “stay the hell out of other people’s code” please try to read it again... that was exactly the opposite of what he meant. Best advice I ever got: always read things ten times before responding.

> “Actually it was terrible advice, advice that I've gone out of my way to ignore in the years since. But those words were valuable nevertheless, and I've gone back to them time and again.

Every time some annoying new-hire comes to me with a dumb idea that is obviously not going to work, Stay the Hell out of other people's code plays back in my head and I listen harder.

Every time some other engineer has an opinion about my code, I remember what I thought of the idea that you should mind your own technical business and I try to disengage my ego.”

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

#188

Post by sbmthakur » Sun, Dec 16, 2018, 7:19 AM UTC

I work in a small team. I occasionally find a thing or wrong in my teammates code. But instead of changing things I simply talk it out with them. Requesting them to try the change also ensures that they've their sense of ownership. It has worked nicely for me till now.

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

#189

Post by sseth » Sun, Dec 16, 2018, 7:25 AM UTC

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.

> Good organizations value good ideas, irrespective of who thought of them.

Ideas with only upside and no downsides may be trivially executed. The problems come with ideas where costs are certain and up-front, while benefits are medium-to-long term, and the transition may carry risks of its own. Big changes and ideas usually are disruptive and the best organizations may still struggle to pull them off.

In my experience even in good organizations people may have different assessment of what's a good idea precisely for these reasons, and getting people aligned behind such changes is what leadership is all about, and does need patient groundwork.

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

#190

Post by Vektorweg » Sun, Dec 16, 2018, 7:26 AM UTC

sbmthakur wrote: post #188

I work in a small team. I occasionally find a thing or wrong in my teammates code. But instead of changing things I simply talk it out with them. Requesting them to try the change also ensures that they've their sense of ownership. It has worked nicely for me till now.

I think, that is a bad argument, but a good practice. Always have the devs fix their own mistakes, so that they can learn from them.