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

111–120 of 247 posts

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

#111

Post by Aeolun »

jpatokal wrote: post #100
hashhar wrote: post #73

Oh man. I am so glad that I had the opportunity to work at an organisation that actually celebrated a few such improvements i made. There was a data ingestion job which inserted 4 million keys into Redis. It was awfully slow. I sped it up a lot using the Redis protocol format and redis-cli --pipe. They praised me for that. There was a dashboard which queried data from a MongoDB collection and calculated some counts.…

It's not about the tech, it's about the politics. If everybody agrees Redis is the way to go, sure, go ahead and optimize it. But what if there's a VP who's been arguing that using Redis is a mistake and you should be switching to MongoDB?

You kick the hornets nest.

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

#112

Post by Aeolun »

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

> 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 progress”. You're not wrong, but equally I'd argue that if you need a huge amount of groundwork to implement change, you're probably in the wrong organization. Good organizations value good ideas, irrespective of who thought of them.

People need to be able to distinguish good ideas from bad ones if this is to be indicative of a good organization.

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

#113

Post by steve_taylor »

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

It’s a mob, reinforced by a system of rewards (upvotes), punishments (downvotes) and the politics of “karma”.

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

#114

Post by sonnyblarney »

haxorito wrote: post #43

I made same mistake, I saw how old system underperformed and that I could make it better, faster, more stable and bring higher profit. When I presented that my boss, next I know I’m in room with HR, my bosse’s boss and technical lead (who was practically executive director), to my surprise boss started conversation with “your actions concerning me...” they told me to give all the related code, documents and remove ev…

Though I'm sympathetic to you, I feel there is more to this story.

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

#115

Post by khalilravanna »

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

Say that a bug occurs in the code that I wrote and I'm more familiar with than anyone else on my team. I'll gladly say "I wrote this, I'll fix it". In a perfect world, we'd all understand every part of the project as well as the next coder. But in my world shipping features on time is often more important. I do not consider my work environment toxic at all. Just an agile startup

I think you’re both in agreement. “My code” when it’s a bug is fine because you’re really showing humility and responsibility. I think it is the one exception to “our code” being used as the standard way to refer to code. When the code is great it should be “our code” and by proxy the team’s success. Not one person’s. And when there’s a bug that’s not your own it should be “our bug”. You don’t want to throw anyone under the bus because we all make mistakes. (That’s not to say all bugs should be ignored. Your team should investigate why their code failed and how they collectively can learn.)

I think the “my code; my bug” thing is great because if you lead by example people will follow suit and take responsibility for their failures as well. I think that’s a great effort to move towards a more positive culture.

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

#116

Post by sonnyblarney »

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…

" then tell that programmer, and only them"

Talk is talk - and can be easily dismissed and rationalized away.

It mightn't have been a novel idea at all to do the 'single process' but in order for it to work, someone 'had to do it'.

It might have been more prudent to 'get it going' - and then somehow socialize it very differently, maybe by inviting the other team in and 'giving them the credit'.

Sadly - sometimes orgs have to be wiped out.

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

#117

Post by sonnyblarney »

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.

Well, many systems do IPC and often this is done over sockets.

Maybe a better question is, in 2018 why don't we have much better, cleaner, simple, IPC?

If the system was slow due to this, it might have been the sheer quantity of data over the IPC/Socket. Looks like they were rendering on one side (i.e. 'making the picture') and then pushing that to a different process to rasterize, i.e. 'draw it on screen' which just seems a little crazy. I'd imagine this was probably due to some kind of legacy thing.

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

#119

Post by sonnyblarney »

This is the fault of the higher level executives. Clearly there was no oversight, no ability to discern what's going on their teams.

And it's actually ok that there was much more spent than they planned for on something, this is the nature of development, even that there were competing ideas, even groups ... this is normal. But that there was no accountability for obviously bad actions - not good.

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

#120

Post by swframe2 »

I suggested to my engineering director that we pivot our dev effort to avoid what I thought was a pending disaster. He responded that as long as he was director he would never make the change I suggested.

Six month later the CEO replaced him and the new director announced he was going to make the pivot I had suggested. The old director resigned but advised the new director that it was not worth keeping me in the org because I was a trouble maker.

Since helping people in a position of power over you is often perceived as threatening, just let them fail and focus on moving up in a org outside their reach. I would suggest moving to the competition and working to crush your old group.

Post reply on HN