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

21–30 of 247 posts

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

#21

Post by narag »

EpicDavi wrote: post #18
porphyrogene wrote: post #16

Earlier quoted context omitted.

According to the Wikipedia page for proportionality[1], the values "can also be viewed as a two-variable linear equation with a y-intercept of 0". Direct (as opposed to inverse) proportionality is a type of positive correlation but they are not the same thing. Because we are dealing with probability percentage as a proportion of the company's size either the size is greater than zero and the probability is 100% or bo…

These are the absolutely useless arguments I come to Hacker News for.

Did you read TFA? Stay the hell out of other people's arguments ;)

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

#22

Post by moneytide1 »

EpicDavi wrote: post #18
porphyrogene wrote: post #16

Earlier quoted context omitted.

According to the Wikipedia page for proportionality[1], the values "can also be viewed as a two-variable linear equation with a y-intercept of 0". Direct (as opposed to inverse) proportionality is a type of positive correlation but they are not the same thing. Because we are dealing with probability percentage as a proportion of the company's size either the size is greater than zero and the probability is 100% or bo…

These are the absolutely useless arguments I come to Hacker News for.

Saying many words without really saying anything.

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

#24

Post by darioush »

moneytide1 wrote: post #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.

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 less competent people. It is simply cheaper after the company grows to a certain size.

Process is more repeatable and predictable when programmers are more or less interchangeable mercenary byte plumbers who care about their own career growth compared to when everyone is deeply passionate about quality and competent about technical excellence.

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

#25

Post by blowski »

porphyrogene wrote: post #17

This article is a great reminder of how to work with others but I think it is unlikely to be received well here. Hacker News loves to dump on junior developers and hates literary subtlety. This article uses the latter to admonish the former.

Your description of Hacker News makes it sound like it's a single person with a uniformly consistent opinion. It isn't.

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

#26

Post by mykowebhn »

porphyrogene wrote: post #17

This article is a great reminder of how to work with others but I think it is unlikely to be received well here. Hacker News loves to dump on junior developers and hates literary subtlety. This article uses the latter to admonish the former.

Although I tend to agree with you, I do think one has to keep in mind their audience. I typically don't expect to have to read programming blogs several times in order to catch the literary subtleties, whereas I might expect that reading literature or philosophy.

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

#27

Post by darioush »

BeetleB wrote: post #11
alexashka wrote: post #4

All it reminds me of Steve Jobs saying A players only want to work with A players. B players hire C players, C hire D and before you know it, you have the politics described in this article.

It's convenient to try to squeeze his story into Steve Job's mold, but in my experience, it's the A players who tend to be the most guilty when it comes to these kinds of politics. In my company, I've worked in two departments - one full of highly intelligent folks, and the other full of mediocre ones. In the former, these kinds of politics prevailed. I recall a particular instance where one person was working on a l…

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

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

#28

Post by moneytide1 »

Exuma wrote: post #7
ydnaclementine wrote: post #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?

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 things more efficiently. This could churn office politics, and cause problems that have little to do with the job itself (emotionally compromised workers and shifting hierarchy).

Likewise, it is our responsibility to embrace the skills of fellow workers in order to enhance workflow. There is no such thing as superiority if you're a member of a team. Kill the ego and think about constant improvement for the group

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

#29

Post by mykowebhn »

Tomte wrote: post #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…

I second this. I've mentioned "Eloquent Ruby" several times to Rubyists as one of the best books I've read on Ruby. Russ Olsen makes difficult concepts digestible.

My only guess as to why it's relatively unknown in the Ruby world is that it's quite old. Perhaps a new edition could have fixed that?

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

#30

Post by BeetleB »

darioush wrote: post #27
BeetleB wrote: post #11

Earlier quoted context omitted.

It's convenient to try to squeeze his story into Steve Job's mold, but in my experience, it's the A players who tend to be the most guilty when it comes to these kinds of politics. In my company, I've worked in two departments - one full of highly intelligent folks, and the other full of mediocre ones. In the former, these kinds of politics prevailed. I recall a particular instance where one person was working on a l…

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.
Post reply on HN