Live data from Hacker News

The Best Programming Advice I Ever Got (2012)

russolsen.com

1–10 of 247 posts

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

#2
The author, Russ Olsen, has written a book, "Eloquent Ruby".

It's probably the best programming book I've ever read. It teaches high-level concepts, hard technical stuff about how Ruby really works, and does so in a conversational voice.

And in all of those points it succeeds spectacularly. He never sounds arrogant, he never feels colloquial to the point of being imprecise. Just… pleasant.

I have cooled down on Ruby and don't have much use for the book nowadays, but if you use Ruby, get this book in preference to all others. Including the "essential" Dave Thomas book.

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

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

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

#5

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

In my experience, the probability of this happening increases proportionally with the size of the company.

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

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

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

#7

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?

This article literally made no sense

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

#8

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?

It was both.

The advice was bad. But it was useful in helping him maintain perspective any time another engineer had comments about how crappy his code was. His instinct was to give them the same advice, but his brain would override reminding him of why that's bad advice to give.

It also helped him understand politics in a company, and how it gets in the way of certain types of progress.

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

#9

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

In my experience, the probability of this happening increases proportionally with the size of the company.

Wouldn't that mean that the probability is always 100% because the company is always 100% of its current proportion?
Post reply on HN