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

201–210 of 247 posts

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

#201

Post by jondubois »

The problem nowadays is that software engineering is mostly about politics - Especially in big corporations.

Corporations use extremely inefficient tools and processes but because they have a monopoly over some area of the market, they can easily survive in spite of very poor technical decisions.

What happens is that engineers who work for these companies learn a lot of bad habits and tools which slows them down; they become overly focused on risk mitigation instead of productivity.

I'm starting to think that this is intentional; corporations want their engineers to get stuck in a technological rut; that way they can't leave and start working for a startup which will disrupt them later.

Even some corporations which seem innovative, are not actually innovative at all; their entire ecosystem of tools is extremely inefficient once you step back and consider the big picture.

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

#202

Post by leaveyou »

tormeh wrote: post #200
leaveyou wrote: post #198

Earlier quoted context omitted.

Software is not the first industry to deal with systems complexity or large teams management but (in my part of the world at least) it's the first to expect engineering-like results from non-engineering workers and managers. There are developers who have noticed the similarities between creating/assembling/testing components & modules in other industries and software and borrowed practices before software had a name…

What other industries should we learn from? I know big construction projects often suffer from similar problems, and they don't seem to have figured it out.

Auto.

I find it quite strange that you are not aware about how much more reliable & secure is the product of the construction industry compared to software.

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

#203

Post by Asooka »

eranation wrote: post #187

Did anyone really read this till the end? If your conclusion is that the best programming advice the author ever got was to “stay the hell out of other people’s code” please try to read it again... that was exactly the opposite of what he meant. Best advice I ever got: always read things ten times before responding. > “Actually it was terrible advice, advice that I've gone out of my way to ignore in the years since.…

True, but with so many people with reading problems, it would behoove any author to state his thesis simply and plainly in the first paragraph, in straight text, with no sarcasm, allegory or metaphor. Otherwise you run the danger of bringing upon us another Waterfall^1 situation. When giving advice that could be read and acted upon by managers, please try to make your text's meaning resilient against shortening. That is, it should be possible to cut out any amount from the end of the text and end up with either the intended meaning or no meaning.

^1 - The original Waterfall paper describes Waterfall as what NOT to do, but this becomes apparent about halfway through and then goes to suggest something very close to Agile. Unfortunately, if you just read the start of the paper, maybe if you're a pressed for time manager, all you're left with is an impression of how great Waterfall is.

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

#204

Post by Lio »

jondubois wrote: post #201

The problem nowadays is that software engineering is mostly about politics - Especially in big corporations. Corporations use extremely inefficient tools and processes but because they have a monopoly over some area of the market, they can easily survive in spite of very poor technical decisions. What happens is that engineers who work for these companies learn a lot of bad habits and tools which slows them down; the…

I don’t think it is intentional or malicious.

I think it’s more likely that in big bureaucracies management is seen as the most important function of business.

Managers see their work as “important” and not just the admin that supports the real function of the delivering product.

If you’ve ever sat in a meeting where management spent the whole time talking, instead of asking the team that does the work how could we improve our current processes, that’s what’s happening.

You’ve run smack bang into the collective ego of multilayered management.

Small startups succeed in part because the lines of communication are small. The ratio of those “ordering” the work to those “doing” the work is low and feedback is possible.

In big enterprises outsourcing looks like a great idea because value only comes from management and workers are just a cost centre. Cheap is better than expensive if you think everything is a commodity.

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

#205

Post by 0db532a0 »

vezycash wrote: post #180
Xcelerate wrote: post #172

Earlier quoted context omitted.

> most people get defensive when newcomers (especially juniors) come in with suggestions Reminds me of that quote "science progresses one funeral at a one". I had a good boss at a previous company. Shortly after I was hired, he scheduled a meeting with the rest of the team and said, "We want to get your opinion on this thing X we've been working on for over a year. Since you're new, you may have some fresh perspectiv…

"I want your opinion on...." for me is a potential landmine. Such questions can be used to detect potential troublemakers. https://en.wikipedia.org/wiki/Hundred_Flowers_Campaign In college 10 years+ ago, one of my roommates had a laptop with 500MB ram and took a 500MB ram chip from anther room mate's laptop to speed up a game he was playing. He did this without the knowledge or permission of the laptop's owner who wa…

I’ve always been wary of one-to-ones with the manager for the same reason. Is it ever good to talk about problems with a manager, especially regarding other people? It’s like the prisoner’s dilemma. I still don’t know what’s best for me to talk about in this setting.

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

#206

Post by bartread »

gdy wrote: post #192
eranation wrote: post #187

Did anyone really read this till the end? If your conclusion is that the best programming advice the author ever got was to “stay the hell out of other people’s code” please try to read it again... that was exactly the opposite of what he meant. Best advice I ever got: always read things ten times before responding. > “Actually it was terrible advice, advice that I've gone out of my way to ignore in the years since.…

Yep, seeing so many people with reading comprehension problem here at HN is surprising.

I know, and it's not even like it's a long article. They must have got to that sentence and then just rage quit or something.

It amuses me, but I won't say I've never done it myself, particularly when I'm already tired and irritable, and I'm reading a piece by an author who's taken a provocative stance without quickly getting to the point. Tough to make that accusation stick here though.

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

#207

Post by 0db532a0 »

AnAnonyCowherd wrote: post #95

I got hired at a Fortune 250 to rewrite a system, from the ground up, that had been running for 5 years. I rewrote it in about a year and a half. Huge success; 1000 happy users. What I learned over time was that "the" person responsible for the group that was _supposed_ to be writing this sort of software in the company had been trying, for 10 years, to make something like it, with a whole team of contractors. In fac…

What was your strategy in one-to-ones, and what would you have changed?

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

#208

Post by ptx »

Matumio wrote: post #193
jpnelson wrote: post #86

Earlier quoted context omitted.

That's an interesting perspective. I think you're right that we don't have "correct" and standard answers because we don't assume total competency, but I think we don't assume total competency because software development (both the requirements and the practices) change fairly rapidly. I wouldn't be surprised if in 100 years, we're still trying to figure out standards, if the pace keeps up.

Two things about programming: 1. Nobody really knows how to do it. 2. If you have a system for doing it, you're doing the computer's job. (Sadly I cannot find the source of this quote.)

Here, maybe? That's all I could find. https://news.ycombinator.com/item?id=1901693

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

#209

Post by ginko »

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

Considering the fix was about removing a socket connecting two independent processes I would assume the overall architecture was originally chosen to separate the work of independent teams. There would not be one programmer to talk to about this.

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

#210

Post by tormeh »

leaveyou wrote: post #202
tormeh wrote: post #200

Earlier quoted context omitted.

What other industries should we learn from? I know big construction projects often suffer from similar problems, and they don't seem to have figured it out.

Auto. I find it quite strange that you are not aware about how much more reliable & secure is the product of the construction industry compared to software.

One-of-a-kind construction projects are notorious for cost overruns. It's ridiculous, just like enterprise software projects.
Post reply on HN