Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 try to let people know it was really you who is responsible.



Maybe Russ wasn't sneaky - especially since he said it was early in his career? Maybe he fixed it thinking everyone would 'high-five' him for the win. Unfortunately, he didn't understand the political ramification at the time.

I've tried your approach. In my experience, the outcome depends on the person who has created the mistake - not the person who fixed it. Yes, be gentle with the solution, but that will not solve the problem if the person you are dealing with does not share your sentiments.


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".


" 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.


It depends what one's goals are. Improve the system? Build good working relationships? Make yourself or your team look good?

In many cases similar to the one you described, the other programmer has already heard what you are trying to tell them and chosen to disregard it, for reasons good or bad. You have outlined a good starting point, but if you stop pushing, you are likely going to maintain the status quo.


"They may or may not take sole credit but it doesn't matter."

If you improved something greatly then it is your credit and it matters that it was you and not someone else. IP conflicts are a different story, one that I would like to see avoided with OpenSource becoming standard.


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.


I do not agree with this. One bit. He was not the sneaky party.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: