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

141–150 of 247 posts

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

#141

Post by ChristianGeek »

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.

It’s not the case in Southern California, either.

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

#142

Post by jorgesborges »

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?

I think this quote sums it up best: "I've realized that there were probably a dozen programmers on that ancient project who knew why the system was so slow and how to fix it. They knew, but they kept it to themselves because in that organization, there were some things that were more important than making the system better." The mistake was in assuming that code quality and performance always trumps other considerations. The title is misleading in this respect: it's not really programming advice. Even the phrase repeated in the article, stay the hell out of other people's code, is more about navigating the potential unknowns of a situation, and being in touch with what's happening around the office more generally.

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

#143

Post by ken »

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…

> A lot of people figured it out already..

You'll have to expand on this for me, because I find this claim shocking. Who figured it out, and what did they figure out?

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

#144

Post by haxorito »

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?

Of course I did not just go and implement the change in production. I had put together PoC and documentation how and why it’s better, more error resilient and effective. The reason for just reaction was politics... I put my nose in other people business.

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

#145

Post by baylisscg »

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?

When they've gone on an unauthorised excursion through some code that has say, safety critical or legal, concerns some off the top of my head examples.

Hey guy's I've rewritten:

- The dosage control code for radiotherapy device so we can remove that expensive mechanical interlock! - The data access layer of our patient records system! - How we calculate x in out guidance software we can go to a cheaper CPU now!

especially if said code was rattling in the building around somewhere it might get into the code base.

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

#146

Post by cleandreams »

This is weird info right now because after an acquisition I got a big promotion on the technical ladder so that getting into other people's code and rewriting it is now a big part of my job. It's fun but I would not want to do this without a lot of management support. Also I work hard at relationship maintenance and buy-in.

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

#147

Post by mr_toad »

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…

> the right way to make good software

In software engineering, and in IT generally, there’s a fine line between following best practices and following a cargo cult.

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

#148

Post by haxorito »

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 position to do that.

From now on I moto “not my business”

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

#150

Post by kazinator »

What a bizarre story! Of all the people in the org chart, the "Biggest Boss of All" should be most concerned with the company bottom line, and least with protecting individual developer egos from each other. The wretchedly slow performance of the CAD system could easily have cost that organization customers. Just, wow.
Post reply on HN