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

151–160 of 247 posts

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

#151

Post by kazinator »

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

A good way to get people to come around to some idea is to sneak it in in such a way that they think it's actually their idea.

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

#152

Post by ken »

hutzlibu wrote: post #80
ken wrote: post #63

There's definitely value in respecting boundaries. Sometimes you have to take a small local inefficiency in order to create a bigger global efficiency. That's life. In my experience, though, this is a much bigger problem in software because nobody really knows what they're doing. There's no industry standard way to do almost anything. You can argue about "use Foo!" or "don't use Foo, use Bar!" and there's no one Corr…

" There's no industry standard way to do almost anything. You can argue about "use Foo!" or "don't use Foo, use Bar!" and there's no one Correct Answer, so it becomes a political question." When foo and bar both solve the job and equally fast, then yes. But in the example of the article the other version was much faster. So faster (assuming no bugs got introduced) means clearly the correct answer here.

That's not clear at all to me. This system sounds extremely complex (which could be one of the causes of the problem!), so I don't see how we can assume that no bugs got introduced, nor that execution speed is the only metric that matters.

Perhaps the existing socket-based solution simply used a bad timeout, and instead of a weekend of work to completely change the architecture of the system, it could have been fixed by changing one number in a configuration file. That would have been much lower risk, and not affected any other functionality, test suites, debugging practices, support procedures, etc.

Software is still a young field that celebrates youth, and single combat warriors, like "Mel". It reminds me of Tom Wolfe's "The Right Stuff", about the U.S. space program back in the 1950's. One person could and did go do crazy heroic things that helped a single flight succeed. Eventually, space flight grew up, and NASA today barely even mentions the names of their contributors and collaborators. They'd never put up with cowboys like that any more. That's not how you achieve successful, repeatable results in complex systems.

Or maybe I'm just getting old.

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

#153

Post by wpietri »

williamdclt wrote: post #75

Office politics or not, you have a problem when people start referring to parts of prod systems as "my code" or "your code". For me, from the point you opened a PR it's the team's code, not your own anymore. Everybody should be able to happily edit this part of the code without even thinking about asking for your permission (though asking for your input would probably a good idea), first to avoid this kind of nonsens…

Agreed. Of all the Agile practices, collective code ownership is possibly my favorite. It requires that one proceed thoughtfully, of course. And I think it requires other practices, like high test coverage. But I think people treating patches of code the same way dogs defending their yards is poisonous. It's hard enough to get good work done without every pull request hinging on politics.

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

#154

Post by mr_toad »

preommr wrote: 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.

Even on the same machine using sockets is going to be much slower than function calls, or shared memory access. One of the criticisms of early X Windows system was its slow performance on local machines.

But the client-server design of X-Windows was quite deliberate. Makes me wonder if this CAD system had a similar pedigree? I think we’re only hearing half the story here.

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

#155

Post by marktangotango »

strken wrote: post #135
hutzlibu wrote: post #85

Earlier quoted context omitted.

"In the long run, few things are more expensive than a mediocre programmer. " Disagree very much. Mediocre programmers are very good for mediocre tasks, of which there are plenty of. The problem is only, if mediocre programmers work on advanced tasks.

How do you stop mediocre programmers from working on advanced tasks, and is the overhead of doing so greater than the cost of hiring excellent programmers?

Mediocre devs simply can’t do advanced tasks. They’ll spend months with no results. I’ve seen this countless times, especially working with offshore teams. One project was hobbled by terrible database performance. The app simply couldn’t scale. I listened to weekly calls for a year while they floundered. Finally I researched their connection pool and told them setting to control “verify connection before each call” to “verify connection every n milliseconds”, and told them how to fix it. I made sure to do it on a call with their architects and leads and our senior managers. Yeah that was a bit of a dick move on my part but I didn’t care.

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

#156

Post by busterarm »

l0b0 wrote: post #48

Even on a purely technical level every organization has unprovable things its members believe in. Challenging any of these openly is a surefire way to get told in office-ese to STFU noob. Quietly demonstrating that they were wrong results in at least some cognitive dissonance, with all the mental fallout that gives. Even worse, you've done this after challenging them, and everyone gets defensive. And the absolute wor…

Very early in my working life I had the misfortune of doing data entry and cashier work where I significantly outperformed my coworkers. I was _hated_ in these jobs.

What I didn't realize was that the team's performance was dictated by the top performers and that _everyone_ was intentionally slowing down their work so that they could have a relaxed, easy job. By doing my best work, management set the expectation for everyone to work 10% better than that.

What I didn't understand at the time was that several of the folks in that job were lifers and they'd realized quickly that the compounding interest of always having to perform 10% better every month would break them. My eagerness to do good work was quite literally ruining their lives.

My take away lesson from this was to always try to work someone with people who are more skilled and more ambitious than you are or with people who want you to help pull them forward.

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

#157

Post by AlexCoventry »

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.

What are some examples of HN dumping on junior developers?

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

#158

Post by robertAngst »

codyb wrote: post #40
robertAngst wrote: post #12

Earlier quoted context omitted.

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.

Wait, programming=/= engineering

One is logic, the other is applied.

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

#159

Post by RandomGuyDTB »

kazinator wrote: post #151
georgebarnett wrote: post #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…

A good way to get people to come around to some idea is to sneak it in in such a way that they think it's actually their idea.

Leonardo DiCaprio? Is that you?

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

#160

Post by hutzlibu »

strken wrote: post #135
hutzlibu wrote: post #85

Earlier quoted context omitted.

"In the long run, few things are more expensive than a mediocre programmer. " Disagree very much. Mediocre programmers are very good for mediocre tasks, of which there are plenty of. The problem is only, if mediocre programmers work on advanced tasks.

How do you stop mediocre programmers from working on advanced tasks, and is the overhead of doing so greater than the cost of hiring excellent programmers?

"How do you stop mediocre programmers from working on advanced tasks"

Competent project lead/management

Assigning the right person for the right job. But yes, nobody ever said that is easy.

But in general: by definition there can be only some excellent programmers and lots of mediocre ones. So it simply would not work if every company only would hire excellence.

And it is also not neccesary nor useful, since there are so many boring, mediocre task around, meaning the excellent programmers can focus their time and energy on the complex, interesting problems.

Post reply on HN