Live data from Hacker News

The Best Programming Advice I Ever Got (2012)

russolsen.com

51–60 of 247 posts

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

#51

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…

Sounds like a toxic company. Sorry you couldn't ditch them.

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

#52

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…

I do not understand why you were treated as if you wrote viral code which wiped all networked storage of the company. Did anyone ever say why you were treated like an infectuous disease after doing something good, which would benefit everyone?

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?

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

#53

"But the best way to have a future is to be part of a team that values progress over politics, ideas over territory and initiative over decorum." Recently had to quit my job because of exactly this. People will sabotage things simply because they want the useful idea to be theirs.

Building something that works in a short period of time when a team has failed to do that over several quarters demonstrates little more than the fact that your organization has hired people less competent and productive than you. Unless you want to work where you're the least competent person, this isn't necessarily bad. Hiring highly competent people to build software does not scale as well as hiring (many) more le…

> 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 than a mediocre programmer.

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

#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 progress”.

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

#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 try to let people know it was really you who is responsible.

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

#56
post #52

Earlier quoted context omitted.

I do not understand why you were treated as if you wrote viral code which wiped all networked storage of the company. Did anyone ever say why you were treated like an infectuous disease after doing something good, which would benefit everyone?

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?

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

#57

Earlier quoted context omitted.

Building something that works in a short period of time when a team has failed to do that over several quarters demonstrates little more than the fact that your organization has hired people less competent and productive than you. Unless you want to work where you're the least competent person, this isn't necessarily bad. Hiring highly competent people to build software does not scale as well as hiring (many) more le…

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

You're absolutely right, but what he said is also true: the act of hiring by itself becomes fairly unscalable unless you're lucky and get a constant stream of good candidates (which again won't work in your favor if your company isn't primarily known for its engineering).

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

#58
post #39

On a related note, can someone elaborate on the performance of using sockets. I would assume given that it's on the same machine that there wouldn't be that big of a performance hit. Especially if the data being passed was done in big chunks to avoid the overhead of whatever protocol was being used. I know it's not the point of the article, i am just wondering about it for curiosity's sake.

It depends. Any IP-based socket will still go through some protocol stack (routing and filtering). On the other hand, unix domain sockets are optimized for IPC and should perform well. But any socket will require a copy, and thus be slower than shared memory.

On the other hand, if you are going to exchange json messages, you can stop worrying about socket overhead.

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

#59
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?

"Technical debt from an H1b."

You seem to have jumped to a conclusion rather quickly. Even assuming for a second that the hysteria was because the new function that GP wrote is complex, wouldn't the reaction to that would've been "Can you write it more clearly?" instead of the hysteria and pariah ceremony?

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

#60
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?

That situation would warrant 10 min discussion with lead. Not this.

You version is quite paranoid on itself - junior denied learning and shunned for a single mistake.

Post reply on HN