Live data from Hacker News

The Best Programming Advice I Ever Got (2012)

russolsen.com

31–40 of 247 posts

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

#31

"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.

This becomes less and less true as the size and complexity of the relevant software projects grows over time. If highly competent developers have anything going for them, it's their skill both in successfully coping with software complexity, and in preventing undue complexity/keeping it under check in the first place. See also The Mythical Man-Month, etc. etc.

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

#34
post #30

Earlier quoted context omitted.

Those who I consider A players don't foster insecurities about their coding abilities in their egos.

Your thesis is pretty circular. You're not making a statement about A players. You are merely defining them to be that way.

It's fair to define them that way if such people actually exist -- which they do. I've worked with some very smart people who don't have these ego problems. Some do, of course, but I wouldn't call them A people.

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

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

[deleted]

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

#37

Since the article sucked, I'll give the 2 best engineering advice I've received from 2 different senior engineers: >Remember when you'd go to eat at a restaurant, and the kids menu has that game where 'What's the difference between these two pictures?' That is Reverse Engineering. You have a part that works, a part that doesn't work. What is different? >"You just kind of figure it out". Not sure how to start/solve a…

Already more interesting than the whole clickbait blogspam i just reread (to make sure i didnt miss something the first time).

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

#38
post #30

Earlier quoted context omitted.

Those who I consider A players don't foster insecurities about their coding abilities in their egos.

Your thesis is pretty circular. You're not making a statement about A players. You are merely defining them to be that way.

People whose behavior revolves around their insecurities in that way have ceased to learn and grow. If those people who are "B" players now continue being open to learning new ideas, they are eventually going to leapfrog those "A" players in skill.

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

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

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

#40

I'm just not piecing it together. The author was told: >In the future, stay the Hell out of other people's code. But then says: >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. So was that advice bad and why? Or did it end up being useful, and why?

Awful article for this reason. Learned nothing.

Really? It doesn't take much to see that he used the opposite of that advice in order to make sure he was attentative to new hires insights and to criticism's about his own code.

Everytime someone comes up and says his code sucks he remembers being a young engineer admonished for making someone's code better, and instead of getting defensive, he listens.

Post reply on HN