The Best Programming Advice I Ever Got (2012) • Hacker News Board

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

#71

Post by darkerside » Sat, Dec 15, 2018, 9:44 PM UTC

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…

Where can I subscribe to your newsletter? This is a skill I think we all need more of, not just in software but in all aspects of life.

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

#72

Post by moneytide1 » Sat, Dec 15, 2018, 9:44 PM UTC

porphyrogene wrote: post #9

pmikesell wrote: post #5

Earlier quoted context omitted.

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?

I don't think "100%" and "probability" can exist in the same sentence (speaking in binary but also saying 0.999)

I think the parent was inferring that there was a chance progress could be reversed at his/her past companies because of the office politics/territory/decorum mentioned in the original article.

Raw efficiency averted by someone's need for the spotlight.

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

#73

Post by hashhar » Sat, Dec 15, 2018, 9:45 PM UTC

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. I changed the design so that the service itself would update the counts so as to avoid costly queries.

I brought down build and deploy times for a service by removing unused gradle dependencies, structuring the build to allow using parallel builds and removing unnecessary configuration generation using templates and the entire team was glad that I solved a major pain for them.

Sorry you had a bad experience but I think this is what we mean when we say company culture.

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

#74

Post by rabidrat » Sat, Dec 15, 2018, 9:48 PM UTC

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.

It's the serialization/deserialization that gets you. And not just the actual transformation, but also the fact that you have to turn every operation into some message. What could be a fast loop to read/modify/write the bytes in some rectangle in video memory, now has to read all those bytes into a flat buffer, do the modify (probably with extra code because the layout of the mask and the layout of the buffer are no longer compatible), send through the kernel, and then get unpacked and written to video memory in the other process. For infrequent or batch jobs this might be a well-structured interface with some good robustness features. For user interfaces which should be low latency it takes 10-100x as long and for no actual benefit.

Also doing things in big chunks is more efficient, but usually adds latency.

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

#75

Post by williamdclt » Sat, Dec 15, 2018, 9:53 PM UTC

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 nonsense and second because it avoids having people that are single points of failure (only one to work on this part of the code).

I would consider toxic a work environment where somebody would talk about "my code" after it's been merged.

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

#76

Post by [deleted] » Sat, Dec 15, 2018, 9:53 PM UTC

robertAngst wrote: post #15

Since the article sucked, I'll give the 2 best engineering advice I've received from 2 different senior engineers: >Remember when you'd go to eat at a restaurant, and the kids menu has that game where 'What's the difference between these two pictures?' That is Reverse Engineering. You have a part that works, a part that doesn't work. What is different? >"You just kind of figure it out". Not sure how to start/solve a…

[deleted]

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

#77

Post by darkerside » Sat, Dec 15, 2018, 9:54 PM UTC

ramraj07 wrote: post #57

DavidWoof wrote: post #53

Earlier quoted context omitted.

> Hiring highly competent people to build software does not scale as well as hiring (many) more less competent people. I can't imagine an aphorism I disagree more with. I constantly come across companies with similar-sized platforms where one has a development staff 10 times the size of the other (both in cost and size), all due to the complexity and quality of the code. In the long run, few things are more expensive…

You're absolutely right, but what he said is also true: the act of hiring by itself becomes fairly unscalable unless you're lucky and get a constant stream of good candidates (which again won't work in your favor if your company isn't primarily known for its engineering).

It does become more difficult (most people don't hire people who are better than they are). That's different from saying that mediocrity scales better than skill. Skillful programmers understand points of leverage and reduce maintenance costs over time.

Purposefully hiring mediocrity? Big companies do it, but not on purpose. Survivorship bias is in play here. Taking that approach is a form of managerial cargo culting.

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

#78

Post by robocat » Sat, Dec 15, 2018, 9:56 PM UTC

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…

The whole point of the article was that there was no one you could "tell" - the problem was political not technical.

"I've realized that there were probably a dozen programmers on that ancient project who knew why the system was so slow and how to fix it".

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

#79

Post by jeklj » Sat, Dec 15, 2018, 9:56 PM UTC

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.

Come on.

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

#80

Post by hutzlibu » Sat, Dec 15, 2018, 9:58 PM UTC

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.