
The Best Programming Advice I Ever Got (2012) - pplonski86
http://russolsen.com/articles/2012/08/09/the-best-programming-advice-i-ever-got.html
======
eranation
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. But those words were valuable nevertheless, and
> I've gone back to them time and again.

Every time some annoying new-hire comes to me with a dumb idea that is
obviously not going to work, Stay the Hell out of other people's code plays
back in my head and I _listen harder_.

Every time some other engineer has an opinion about my code, I remember what I
thought of the idea that you should mind your own technical business and I try
to _disengage my ego_.”

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

~~~
bartread
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.

------
ken
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 Correct Answer, so it becomes a political question.

When my electrician has a power supply over here and needs power delivered
over there, we all know he's going to use wires, and he knows the right gauge
to use. He's got a book somewhere with the answer, and there's a regulation
somewhere that says what he's required to use. But I just trust him to use the
right cable, because that's his specialty, and I've never seen him make
something that was an order-of-magnitude worse than was required, or that I
could do on my own.

Respecting boundaries is a lot easier when you can trust that other people are
generally competent. This will continue to be a problem for the next 100 years
until we figure out the right way to make good software.

~~~
leaveyou
>>There's definitely value in respecting boundaries. Sometimes you have to
take a small local inefficiency..

I don't think anyone argues with that. It's just that sometimes some of the
biggest impostors hide behind "boundaries".

>>This will continue to be a problem for the next 100 years until we figure
out the right way to make good software.

A lot of people figured it out already.. but those are a minority and the
field is fueled continually with poorly instructed people. The Business can't
distinguish quickly between these two categories and often it does not even
bother (good interviewing is hard or expensive) because (in Europe) it's not
the software efficiency or other quality making the profit.

~~~
ken
> A lot of people figured it out already..

You'll have to expand on this for me, because I find this claim shocking. Who
figured it out, and what did they figure out?

~~~
leaveyou
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 for them. It's just
that these people are dispersed in a sea of devs tuned to Microsoft Framework
Factory or busy building castles on Javascript Frameworks Sands.

~~~
tormeh
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.

~~~
leaveyou
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.

~~~
tormeh
One-of-a-kind construction projects are notorious for cost overruns. It's
ridiculous, just like enterprise software projects.

~~~
redisman
Same with civil engineering. They're building a new mass transit and it's 5
years late. Oh well.

------
georgebarnett
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 progress”.

~~~
avinium
> 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.

~~~
sseth
> Good organizations value good ideas, irrespective of who thought of them.

Ideas with only upside and no downsides may be trivially executed. The
problems come with ideas where costs are certain and up-front, while benefits
are medium-to-long term, and the transition may carry risks of its own. Big
changes and ideas usually are disruptive and the best organizations may still
struggle to pull them off.

In my experience even in good organizations people may have different
assessment of what's a good idea precisely for these reasons, and getting
people aligned behind such changes is what leadership is all about, and does
need patient groundwork.

~~~
darkerside
Even downside-less ideas bear some opportunity cost, no matter how trivial the
change (or intangible the cost). I agree with everything else you said.

------
haxorito
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 everything from my
computer. After that incident I never got promoted, my annual bonus was always
50% of everyone’s. No one in the team wanted to talk to me, I was excluded
from any design meetings. Eventually my whole team got promoted to principal
engineers and all new comers were one level above me. That was the worst 4
years in my life ( I had to work for them because of the work visa)

~~~
HeyLaughingBoy
When you presented _what_ to your boss, exactly?

Did you suggest "I can make it better, faster, more stable...?" or did you go
ahead and make the change and say "see?" Were you in a position where you
should even have been thinking about this system?

I wonder what steps in this story you're leaving out?

~~~
jpatokal
+1. The fact that HR's involved strongly suggests that OP was messing with
something he had no business to touch.

~~~
StavrosK
I don't understand this, or the linked article. Can someone explain to me what
_possible_ reason there can be for responding with disciplinary action when
someone proposes an improvement?

~~~
hueving
An easy reason that often gets left out of these stories is that someone spent
weeks on a rewrite without authorization rather than working on burning
priorities.

~~~
zbentley
That's a real problem, and quite common. I think it's important, when
confronting or correcting someone doing that (whether they're your employee,
colleague, superior, team lead, etc.) to emphasize that they're not being
punished or thought poorly of because of their ingenuity or initiative, but
because they're wasting time and need to stick to the plan. Otherwise,
initially headstrong but very capable people are often ground down before they
have a chance to get used to the roadmapping/planning/etc. process at a
company. This is especially true with new engineers.

I have no idea if the GP post you're replying to is someone rationalizing
being in that position as being "disciplined for touching the wrong code", or
whether something actually screwy was going on. I just wanted to mention that
distinction because it was important to me when I started out (if people had
come down on me for having ideas, instead of for wasting time, I'd be in a
much less useful, happy, and capable place today).

------
Tomte
The author, Russ Olsen, has written a book, "Eloquent Ruby".

It's probably the best programming book I've ever read. It teaches high-level
concepts, hard technical stuff about how Ruby really works, and does so in a
conversational voice.

And in all of those points it succeeds spectacularly. He never sounds
arrogant, he never feels colloquial to the point of being imprecise. Just…
pleasant.

I have cooled down on Ruby and don't have much use for the book nowadays, but
if you use Ruby, get this book in preference to all others. Including the
"essential" Dave Thomas book.

~~~
scruple
I've had a copy of Eloquent Ruby on my bookshelf for years, just sitting there
collecting dust. I picked it up yesterday after reading this comment and,
while I've only made it through the first four chapters, I have to echo the
sentiment. Once I finish it, I'm going to give it to a junior on my team. I
think they're at a point in their journey where the messages in this book will
really help them.

------
usawco
I had a similar experience and similar results. Someone wrote code to perform
1000 queries to pull back 1000 rows in a specific order rather than issue one
query and let the Java collection order the results. Amazingly, another person
wrote more logic to add a switch to skip this step because it literally took
10 minutes for the app to start when connected over VPN. The fix was trivial
and startup time went from 10 minutes to 300 milliseconds. Being the new guy
coupled with the fact they had actually lived with this for years, I was
immediately hated.

~~~
hashhar
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.

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

~~~
jpatokal
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?

~~~
Aeolun
You kick the hornets nest.

~~~
JimmyAustin
"If you come at the king, you best not miss."

If you criticize a seniors ideas, and they interpret it as you coming after
them, you better destroy their reputation, or they'll destroy you. It's hard
to destroy someones reputation within an organization, and most people get
defensive when newcomers (especially juniors) come in with suggestions, so
it's typically not worth kicking the nest.

~~~
Xcelerate
> 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 perspectives about what can be done." I generally
think that's the right approach.

Judging by the number of systems in different fields that have been overhauled
by outsiders to the field, I imagine real innovation has less to de what
thinking of new ideas and more to do with navigating the minefield of human
psychology.

~~~
vezycash
"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](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 was
sleeping and forgot to put it back.

Morning came, owner woke up to a laggy system. Discovered the cause and went
straight to the culprit. Instead of an apology, he got insulted and reported
to school authorities.

Culprit panicked and threw his own ram into another room mate's locker - not
knowing that rams have brand names and serial numbers. The owner refused the
found chip and after a search, found it in the culprit's laptop.

Case over right? Wrong!

We all got called up to an office and asked, "Who do you think took it?"

I naively answered with all the logical evidence. The "judge" accused me of
slander. And warned me not to talk about it any longer or face disciplinary
measures.

I later discovered that the culprit's father visited the official and our
meeting's true purpose was a coverup.

In other words, be wary of higher-ups who ask for critique, advise,
improvements, ideas...

~~~
0db532a0
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.

~~~
NateEag
If you have a good manager, yes, it can be. A good one will often have years
more experience at navigating tricky social and political situations than you
do and will be able to help you work through any difficulties you're having
with coworkers.

Good managers are far rarer than good programmers, though.

A decent litmus test for whether your manager can help with these kinds of
problems is whether they've been on lots of productive projects and whether
everyone likes them.

If both things are true, they likely are quite good at navigating
interpersonal conflicts and arriving at win-win outcomes. It's nigh-impossible
to achieve both those outcomes in a large organization otherwise.

~~~
0db532a0
I’ve given up on the idea of good and bad people. I myself am good or bad
depending on how it suits me. How could I do anything else?

From my experience a manager will choose the option he thinks is most
beneficial to his continued employment in the company. This includes
maximising team support/influence over for instance making a change in a
product with measurable benefit to the company, a change which even he himself
might agree is a good idea. Who could blame him? Any manager who didn’t act in
this way would surely be naive and idealistic.

Assuming this is true for managers, what benefit could possibly be had from
complaining about other colleagues. It could only serve to reduce his trust in
me, and increase his fear that I would do the same to him.

It is very difficult to balance things like team support, ensuring that I have
interesting work to do and also ensuring continued employment. I have been too
naive and idealistic, and now I am looking for a change of strategy.

It’s all well and good to be aware of these realities, but much more difficult
to put the conclusions into practice. Sometimes I think you’re just born with
it.

~~~
NateEag
A further reply, beyond my simplistic defense of my use of the term "good
manager":

It sounds like your "naive and idealistic" manager overlaps with my "good
manager".

I will argue that a manager's principle responsibility is actually to be a
maintainer of relationships. Her responsibility is to maintain her
relationship with each of her direct reports first and foremost, next to help
them maintain their relationships with each other, and finally to help them
maintain relationships with the other employees/teams in the company as
necessary.

Managers do have some logistical tasks they have to take care of, but mostly
they "manage" humans, and that is fundamentally about keeping the
relationships healthy and functional.

It sounds from your description like you've never had a good manager, and I'm
sorry for that. The good ones definitely are idealistic, but they're not
naive.

They are, as I mentioned earlier, in much shorter supply than good
programmers. I've worked with far more decent programmers than I have decent
managers (though since teams have N programmers to 1 manager on average, that
may just be sampling bias).

I should also note that when I'm having trouble with a coworker, my default is
a one-on-one attempt to resolve the issue(s) directly. If that fails (or in
the rare case where I think it's a bad plan), I don't go _complain_ to my
manager as such - I ask for their help in mediating conflict and negotiations.
Because a good one focuses on relationship maintenance, they're often better
at handling those situations than I am, and at helping the different members
of the conflict understand each other and resolve their disagreements
amicably.

Again - good ones are rare. I'm sorry you haven't gotten to experience one,
from the sound of it.

------
gweinberg
This a beautiful story, but the title is wrong. It wasn't "the best" advice,
it was "the most important advice". Big difference. The advice itself is
terrible, but getting the advice, particularly from the top boss, is
incredibly valuable.

------
moneytide1
"But the best way to have a future is to be part of a team that values
progress over politics, ideas over territory and initiative over decorum."

Recently had to quit my job because of exactly this.

People will sabotage things simply because they want the useful idea to be
theirs.

~~~
squarefoot
"People will sabotage things simply because they want the useful idea to be
theirs."

Not just that, they will sabotage things if it makes them more profitable,
which probably happens in thousands companies worldwide everyday.

1\. Get a contract.

2\. Sell some crappy software to the customer.

3\. Wait for them to ask for more speed.

4\. Complain it's their fault because their hardware is too old.

5\. Offer to either install new hardware or rewrite the software.

6\. Profit!

Guess what happens if someone makes the software perform optimally at step 2.

~~~
rocky1138
The way capitalism is supposed to work is you quit this job and open a shop
which does the same thing as the existing company but doesn't artificially
reduce speed, using that as a competitive advantage. The end result is that
the first company is required to either adopt your strategy or fail, either
solution leading the consumer to a better result.

~~~
XorNot
Which is why the no-compete was invented...

~~~
rocky1138
I've read that those may be illegal or unenforceable according to the law.
Check your jurisdiction.

------
edw519
"Stay the hell out of other people's code."

Great advice if you want a miserable 40 year career as a team player in mind
numbing corporate work prevention departments.

Bad advice if you want anything more out of your programming career.

Horrible advice if you want to make a difference by sharing your gifts with
those who need them.

You don't get that many chances to do what OP did by jumping in and making
dramatic improvements.

The only reason I have ever avoided staying the hell out of legacy code was
when opening that can of worms was just the wrong thing to do for everyone.

Otherwise, I got the hell in there.

Sometimes I was thanked.

Sometimes I was reprimanded.

Sometimes I was fired.

Always I learned something, usually the best learning I ever had.

(And as for getting fired, I wouldn't have changed a thing. This is actually a
_good_ thing. Better to push the limits, find out who you're dealing with, and
move on quickly rather than being miserable for years without ever
understanding why.)

The Best Programming Advice I Ever Got? ... Always Do the Right Thing. (Even
if it takes a lifetime to figure out what that is.)

~~~
gcb0
I highly suggest you go back and re-read the text :)

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

~~~
dktp
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

~~~
StavrosK
It's fine if you yourself want to take blame for some code you wrote. It's not
fine if someone else wants to blame you for it. You wrote it, but someone else
reviewed it, and (probably) still someone else tested it and yet someone else
released it. It's a team effort.

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

~~~
sonnyblarney
Let's also consider that the worker is not always correct, and that managers
might face such advice all day long from various sources, often by highly
passionate devs who also assume they are right.

In this case, it seemed that the director was 'wrong' but I don't think that
there should be any inherent assumptions that an arbitrary engineers advice on
pivoting is somehow the 'better' path.

Also, there's a huge difference between being 'wrong' on a technical
opportunity, and 'negligence' (i.e. not doing research, observing facts) or
'malfeasance' (i.e. willingly doing the wrong thing for the advancement of
self etc.)

~~~
swframe2
My advice applies to the worker who has done enough research to feel confident
that they've found a vastly better way that is likely to meet with resistance.

------
ydnaclementine
I'm just not piecing it together. The author was told:

>In the future, stay the Hell out of other people's code.

But then says:

>Actually it was terrible advice, advice that I've gone out of my way to
ignore in the years since. But those words were valuable nevertheless, and
I've gone back to them time and again.

So was that advice bad and why? Or did it end up being useful, and why?

~~~
Exuma
This article literally made no sense

~~~
moneytide1
I see how it's counter intuitive - almost seems as if the author is
contradicting himself. But it did drive a point home, especially that last
sentence. This is what I took away from it:

You may be able to come up with better ways to do things, but that often means
replacing or voiding the efforts of coworkers or bosses. People have fragile
egos, and may feel their job is being threatened since you are arranging
things more efficiently. This could churn office politics, and cause problems
that have little to do with the job itself (emotionally compromised workers
and shifting hierarchy).

Likewise, it is our responsibility to embrace the skills of fellow workers in
order to enhance workflow. There is no such thing as superiority if you're a
member of a team. Kill the ego and think about constant improvement for the
group

~~~
Gibbon1
> but that often means replacing or voiding the efforts of coworkers or
> bosses.

Comment: Having a work environment where people up discard and replace the the
work other people have done is really really bad for moral. If you let that
stuff happen continually you'll end up with a team where no one cares or takes
ownership of anything.

------
darrenhobbs
In 1999 my boss's boss loved Silverstream.* It stores code in the database!
Anyone still using files for code is obsolete!

We had 12 beefy servers powering our site. So I rock up and realise we're not
using any of Silverstream's features, and its just acting as a servlet
container. Big boss had moved onto bigger and better bossing by now so wasn't
around to stop me.

After a couple of weeks of investigation, we demonstrated that Caucho Resin is
better in every way. Fraction of the cost, starts super fast and runs like
lightning. Great. We happily switch over and all was well for almost a week.

A few days in the head of Ops barrels up and demands to know if this was all
my fault.

"Ummm, yeah?"

"Great. What the fuck am I supposed to do with the other 11 servers??"

I think they'd had to fight for budget for enough hardware to run the site
with Silverstream, and young me had just made them look incompetent. They
forgave me eventually...

* I actually like Silverstream's core ideas. It was just a little ahead of its time, and stored code in the db. And was 12x too slow.

------
SagelyGuru
It reminded me of how I once got into hot water with the Boss over introducing
a binary search into their huge customer file search and update operation,
which used to take three hours to run. When the program stopped in five
minutes, everyone was mortified that I had broken it.

------
astazangasta
There is an entire world to be dissected in the final few paragraphs. The
essence of the error the author made (and we know he made an error because he
ended up in the head boss's office being chewed out) is to imagine that a
successful project is founded on good technical grounds; not true, or not only
at least.

The author's presumption here is that the advice was bad, and he learned the
opposite lesson (don't accept social boundaries). But the advice WASN'T bad,
because the organization doesn't consist of just code product, it consists of
a set of programmers, managers, executives, users, customers, etc.

The important question this article raises is: WHY do people write code? What
makes someone want to write good code? What motivates them to do work? What
motivates them to wish to cooperate with others in their effort, to
communicate their problems and insights, and contribute to the greater health
of the product?

This, more than anything else, kills projects. The smartest people on earth
can accomplish nothing if they petulantly refuse to cooperate, and in order to
accomplish that you need to pay attention to more than what is merely
technically best, you also need to pay attention to the people in your
organization. What do they WANT? If they are anything like a normal human
being, they want - to appear successful, to be valuable, to have their skills
be seen as valuable, to have their ideas and work be appreciated by others.

We can, of course, dismiss this as "ego" or "politics", as the author does,
mere cruft that gets in the way of the ur-goal of the organization, a
beautiful product. But if we do so we're really ignoring what people want -
and that is NOT to merely be a gear slowly ground down in the service of the
greater good, eventually worn out and replaced by a newer, better gear.

Such advice, that we should ignore the very normal (and yes, egotistical)
motivations of ordinary human beings at work, is perhaps not the best advice
you could get.

------
thr0w__4w4y
(background: my expertise/degree is microprocessor design and digital logic,
although I've done a butt-load of firmware in C and C++ in my career)

One time (long time ago) when I worked at Motorola (this was back pre-2K when
working at Moto actually meant something). There was a systems level problem,
and I was brought in as a systems engineer to diagnose a problem (think "big
system with tons of FPGAs, fiber optics, embedded CPUs, firmware, etc.)

Pretty soon I delivered my suspicion that the real issue was a hardware
problem (this after looking at network data on a capture)

The hardware director said (I wrote this down in a notebook, I'm quoting
verbatim): "I stake my career that this isn't a hardware problem. It's either
a firmware problem or a misunderstanding of the requirements."

It was a hardware problem. I demonstrated it a few weeks later and the chip
vendor confirmed it (it could take up to 2 weeks to reproduce the problem)

After that my name was shit. That's when I learned that office politics are
very fucking real, and sometimes you have to decide if you want to be a
lifetime corporate employee.

I left less than a year later, hung out a shingle as a consultant and life has
been great since then.

You can try to bend the world (or your employer) to your will, but it isn't
going to end well. If my life goal had been "work for Moto for 40 years then
retire", that wouldn't have worked out so well, for multiple reasons.

I'll always bet on myself before I'll bet on BigCo. I'm contacted every month
on LinkedIn by Google, Amazon, etc. (I've trained lots of their employees) and
my answer is always the same: "thanks but no thanks"

Apologies if this sounds self-aggrandizing. 100% not the intention. Just a
lesson that you gotta look out for yourself, and the real world is
complicated. Own your career, don't put it in the hands of BigCo. BigCo
doesn't give a shit about you.

------
l0b0
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 worst, as the author experienced, is when
money or ideals is at stake, and you unknowingly shift the goal posts.

I worked at a place with mostly time-limited positions as my first job, and
based on what my original boss said I'm pretty sure the new boss passed over
my application because of politics like these. But like the author this only
strengthened my resolve to question my own and others' assumptions.

~~~
busterarm
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.

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

~~~
usawco
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.

------
philipyoo
Politics makes me sad. My main interest in wanting to become a developer was
to have the ability to build improvements. I want the company to do well. I
want the team to receive recognition. I want the people around me to be happy
and to be working on a product they care about.

~~~
WilliamEdward
It's funny, because I wanted to be a developer for the exact opposite reason:
to develop what I wanted, for myself not for a company.

There's few other fields where you can be this creative, where there's
infinite potential and infinite niches available. Why waste it all and get
tied up in politics? I sincerely thought the ability to do anything was the
reason people became developers in the first place.

------
z3t4
Communications! Don't stomp on other people to get to the top, instead get
them to boost you up! Example: Make the changes to see if it works, but
instead of showing it to your or his boss, you tell the one who wrote it that,
"hey I got an idea on how to make this 100x faster". Only when he/she says
your idea will not work, you say "actually I did test it, see". And you might
get valuable information like for example the political status.

------
crimsonalucard
No human is perfect and people inevitably make mistakes. Including big
mistakes.

Imagine this scenario. You created something very complicated that you're
proud of. You spent a lot of time on it and your integrity and reputation rely
on this thing you built.

Little did you know that what you built could be done in a way that is easier
and 10x better. The foundation of your reputation is in shambles. What would
you do?

I can tell you what I've seen from experience. The very people who tell you
that bias doesn't affect them or complain about how politics always trumps
technical problems are the very people who will FOLD when the same problem
hits them in the face. No one is perfect and there will be a time that this
happens to most people... a time when that person will be utterly and
completely wrong about something they've advocated for so long.

It's trivial, easy and immature to advertise and complain about the weaknesses
in other people. I want to see a blogpost about a programmer coming to terms
with their own grave mistakes... their own imperfection.

Once you realize how hard is to do that, then you will know know what to do
when this problem infects your work place. First and foremost you must
introduce change without hurting peoples' pride. You must be empathetic and
take into consideration how other people will feel if you try to pick them
apart. If you take steps to do that, people will return the favor in kind. If
you attack the scaffolds supporting the reputation of your peers, expect
everything that you've built to be attacked as well. Remember. No one is
perfect.

The original poster is as responsible for creating a toxic work place as the
people he's complaining about. I'd bet he'd react the same way if the tables
were turned.

------
kazinator
What a bizarre story! Of all the people in the org chart, the "Biggest Boss of
All" should be most concerned with the company bottom line, and least with
protecting individual developer egos from each other. The wretchedly slow
performance of the CAD system could easily have cost that organization
customers. Just, wow.

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

~~~
Lio
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.

------
romeisendcoming
Depends on your model. In a small business where you have a couple experts in
different domains it makes perfect sense to talk about individual ownership.
It's not toxic: it's forced practicality. In larger environments with close
skill parity it doesn't make sense and hurts morale.

------
ape4
The change made the program faster but nothing is simple. When the GUI and
backend were different progresses there was memory space separation. It was
impossible for a stray pointer in one to klobber the other. Also there was a
protocol between the two - which could be used over the Internet.

~~~
gitgud
That's what I first thought too. There's was obviously a decision to separate
the processes, but the performance gain of combining them was probably more
meaningful in the end...

------
russolsen
Now that my job resembles the 'biggest boss of all' more than the young
developer that I was all those years ago, I often think about what I would
have said to that young man.

If it were me I would thank that young developer for all the hard work and
offer a few bits of advice on getting things done without pissing people off.

And then I would get all of the leads together and have a serious talk about
how we can take care of all of our people while at the same time producing the
best system humanly possible.

Good developers work hard and care harder and, being human, they have egos.
But everyone has blind spots and everyone makes mistakes and the essence of a
good organization is that it blends the strengths of all of its members.

------
Cpoll
> I had supplied a war winning weapon to one organizational faction and the
> other factions were not happy

The real problem is that there are adversarial relationships within the
organization. It can be an ego issue, or perverse incentives, or conflicting
departmental objectives, or short-term thinking. Anyone who doesn't spend
their time focused on politics or covering their ass will still have their
motivation sapped, and soon no-one will care about making the product better.

The non-dysfunctional response is "great initiative, we'll get a meeting
together and discuss the pros and cons of implementing your spike."

------
Koshkin
The idea (and practice) of "code ownership" is one of the most annoying
things. First of all, it creates an atmosphere of some kind of laziness and
lack of responsibility on the part of the individual team members (perhaps,
not all, but still) for the results of the entire team's work. It also
promotes what in my view is a rather insidious habit of assuming that if
someone has wrote a piece of code long ago they are still responsible for it
and, moreover, they are ready to instantly answer any question about it, as if
it is supposed to stay fresh in the developer's mind forever.

------
usawco
I also believe smart people will do dumb things from time to time - especially
under the pressure of deadlines. It's always good to assume they were having a
bad day.

I know what does not work - printing out a "team-mate"'s code and pinning it
to your cube wall w/o even asking a question about it. That goes in the bucket
of things I thought I'd never see in the workplace.

Truly amazing...

------
AnAnonyCowherd
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 fact, it was his initial failure that caused my boss to write
the first version of the program. When they saw that my boss had hired me,
they doubled their efforts.

Their version of the idea was total garbage. Nobody would use it. It was
terribly slow, clunky, and had a fatal flaw that would have caused people MORE
work than just not using their program.

The boss of their group managed to get one of his underlings moved above my
boss. He told us to stop working on my program. We did. They brought it
Microsoft consultants to try to make their version suck less. It didn't work.

I suggested many things to work together. Rebrand. Code features they needed.
Use some of their software. Whatever. All rejected out of hand.

We BEGGED our boss to IMPLORE the other manager to AT LEAST fix the "fatal
flaw" of the other version. He agreed to, but we knew he wouldn't.

We released a bug fix for production. The other manager lost his mind, and got
our manager to force us to hand over the code to his group. It took them TWO
YEARS to make a single change. My program happily ran like a clock during the
interim.

They finally gave up on their version.

My boss was put on a PIP. I was put on the tiniest project possible (which was
completely doomed anyway), and forced to write what should have been a quick
and dirty web app as a corporate, Java monstrosity. (But I repeat myself.)

In my first meeting, the other manager's toady told me to my face that he was
going to kill the project I was hired for. In 4.5 years, I never even met the
other manager, though he sat 50 feet away from my last cube.

There was no winning. My boss was very politically savvy, and just plain nice.
There was nothing he could do. I stayed completely out of it. I did the job I
was hired to do, and embarrassed the wrong people. He was written up. I was
put out to pasture.

You can say that I should have done things differently. Maybe. Maybe not. What
it tells me is that I was in the wrong company. Which sucks, because I could
have written LOB tools like this for the rest of my career there. But this
sort of dimness of vision is rampant throughout the company concerning
anything related to IT. According to them, the only way to write software is
to follow a strict waterfall methodology, in Java, with overseas contractors.

Making the company suck to work at, and the act of wasting millions of
dollars, because it helps you build a political fiefdom, is an idea that needs
to be rooted out and eliminated by the C levels. Why does this not happen?
Instead, one of the C's just did a "post-mortem" on this whole fiasco, and the
result was that IT needs to be "more aligned" with the business, and have
better "communication."

Really? That's the level of acumen of our C-levels? They can't smell the
metric buttload of BS that was shoveled in that meeting? OK, then. Good luck
in the future!

I start a new job on Monday. Crossing my fingers that they will be open
minded. I wonder if my old company will still be viable in 10 years.

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

~~~
AnAnonyCowherd
I suppose someone would say that I could have been more diplomatic, but
someone needed to voice a differing opinion. Unfortunately, there was just no
way -- diplomatically or otherwise -- I was going to be allowed to influence
the culture or the process. Too many other people had built their careers on
the back of a 30-year-old process. It was, as they say, entrenched. Sometimes,
you just get dealt a bad hand, and you can't draw into a winner.

------
techbio
> They knew, but they kept it to themselves because in that organization,
> there were some things that were more important than making the system
> better.

Hope this isn't the best advice I ever get.

I do like that it wasn't the biggest-boss-of-all's words that mattered, but
how the words made him feel: never be this guy.

------
sbmthakur
I work in a small team. I occasionally find a thing or wrong in my teammates
code. But instead of changing things I simply talk it out with them.
Requesting them to try the change also ensures that they've their sense of
ownership. It has worked nicely for me till now.

~~~
Vektorweg
I think, that is a bad argument, but a good practice. Always have the devs fix
their own mistakes, so that they can learn from them.

------
curtis
I'm not certain that the title does the article justice.

The advice the author received was:

> _In the future, stay the Hell out of other people 's code._

However, the author goes on to reject this advice and gives some alternative
advice instead.

~~~
mattnewton
The advice was so bad that it helped him not make that mistake. It was so bad
it was good

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

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

~~~
sonnyblarney
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.

~~~
sinisterdeath
I think a common approach for IPC these days is to use named pipes. Chromium
uses it and I've used it in one of my projects. You still have to deal with
serialization and deserialization overhead but its usually pretty quick.

[https://www.chromium.org/developers/design-
documents/inter-p...](https://www.chromium.org/developers/design-
documents/inter-process-communication)

~~~
sonnyblarney
Funny you should bring that up as I'm just looking into that on Node.JS - how
was your experience using pipes? Any warning signs / pot holes?

------
cleandreams
This is weird info right now because after an acquisition I got a big
promotion on the technical ladder so that getting into other people's code and
rewriting it is now a big part of my job. It's fun but I would not want to do
this without a lot of management support. Also I work hard at relationship
maintenance and buy-in.

------
aj7
People keep saying, “this is bad advice.” But this an article on software
corporate politics, with a facetious title.

------
dang
2014:
[https://news.ycombinator.com/item?id=7774016](https://news.ycombinator.com/item?id=7774016)

2012:
[https://news.ycombinator.com/item?id=4366110](https://news.ycombinator.com/item?id=4366110)

------
luord
The best programming advice I've gotten is from Tron: "fight for the users".

------
kingofhdds
It's not a programming advice. Similar counsel is dispensed in various tech,
and non-tech fields, because it's about relations with other people which
sometimes could be more important than efficiency for one's career, or
comfort. However, to discourage from thinking about improving other
programmers code, and call it "the best programming advice"? No way.

~~~
avinium
You didn't read to the end. The author recognizes this as patently _bad_
advice, and was glad to have received it so he was conscious of what _not_ to
do.

~~~
kingofhdds
Yup, my fault. I exploded too quickly, probably because recently had a similar
discussion related to my own work.

------
stefek99
Some people just scan the content, I actually read the full article!

------
HillaryBriss
it may not be good advice, but it gives you something to think about

~~~
vubui
Why is it not a good advice? Care to elaborate?

~~~
mdpopescu
I'll give you two reasons:

1) It's not your code, it belongs to the company.

2) If you can't accept changes to code you worked on (NOT "your code"), you're
unlikely to improve.

I agree these are not absolutes. It might be that you understand the
subtleties of some particular device / library / whatever much better than
other people, and their changes to the code you wrote with those quirks in
mind are bad because of their lack of depth. Talk to them, or better yet use
meaningful names / comments in the code so that they understand _why_ you
wrote it that way.

------
perpetualcrayon
I always worked for small companies early in my career for exactly this. The
suspicion that large corporations are driven by egotistical sociopaths.

Now that I've worked for a large corporation I have proof that I was right
(YMMV). Not only that, egos can become such a barrier to progress that
projects within these companies become what I would consider criminally
incompetent.

------
TwoBit
Anybody who agrees with this advice works in a shitty company with bad
culture.

~~~
lucb1e
Downvoting not because I agree or disagree, but because I think the
generalisation does not help the discussion.

------
juddlyon
"It is difficult to get a man to understand something, when his salary depends
upon his not understanding it!" \- Upton Sinclair

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

~~~
blowski
Your description of Hacker News makes it sound like it's a single person with
a uniformly consistent opinion. It isn't.

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

~~~
busterarm
Some of us don't care so much about the karma. Reactions to my posts are
either extremely polarized (one way or the other) or basically neutral. I've
even gotten the occasional ban threat from dang when I say something
particular unpopular. Occasionally there's still some worthwhile discussion
that happens here.

------
jeklj
I did something similar once but failed to glean such a valuable lesson from
the experience. My takeaway was, those people are touchy so leave their shit
alone. Not because it’s right but because I’m just trying to get through my
day, and i don’t need _more_ politics in my working life. People can be
assholes, it’s just how it is sometimes so let them be.

Among my own team, if I raise points or ideas that get disregarded in this
manner (as opposed to more thoughtful demurrals), I let it go and don’t push
the issue. I’ll speak up if I think I have something worth considering, but
I’m not going to beat you over the head to see things my way.

Still, the takeaway regarding being on the other side of that table is really
important. Once you start feeling that indignant reaction or “yeah right
newbie”, listen harder.

~~~
darkerside
I've fallen in the same trap. And you're right, you can't fight every battle.
But I think the best approach is not to make it a battle in the first place.
Sometimes bringing things up in the right way and with the right energy helps
people be more receptive to your advice.

~~~
jeklj
I don’t want to fight battles, at all. At least not in my working life but
really not anywhere else either.

I’ve seen a lot and done a lot in my career, and I don’t feel I have anything
to prove to anyone anymore. On the other hand I do find it enjoyable to
discuss ideas in a collegial environment where people really are trying to
figure out what’s best.

If we can agree on ideas as equals and proceed then great. If not, I’ll live.
If someone gets mad because I had an idea to improve something I’m not going
to get too twisted up about it. Life is too short for all this stuff, and it
isn’t important in the scheme of things.

------
alexashka
All it reminds me of Steve Jobs saying A players only want to work with A
players.

B players hire C players, C hire D and before you know it, you have the
politics described in this article.

~~~
BeetleB
It's convenient to try to squeeze his story into Steve Job's mold, but in my
experience, it's the A players who tend to be the most guilty when it comes to
these kinds of politics.

In my company, I've worked in two departments - one full of highly intelligent
folks, and the other full of mediocre ones. In the former, these kinds of
politics prevailed. I recall a particular instance where one person was
working on a library, and he would actively invade other _teams_ to shut down
projects that remotely resembled his - even if his library did not supply all
the features the others were building, and even though _he had not yet
released his library_.

In the latter team, people knew they were mediocre, and were much more open to
learn because of it. Pointing out problems with their code never triggered
their ego.

~~~
darioush
Those who I consider A players don't foster insecurities about their coding
abilities in their egos.

~~~
BeetleB
Your thesis is pretty circular. You're not making a statement about A players.
You are merely _defining_ them to be that way.

~~~
ScottBurson
It's fair to define them that way if such people actually exist -- which they
do. I've worked with some very smart people who don't have these ego problems.
Some do, of course, but I wouldn't call them A people.

------
tinkerteller
This is mind numbing article and probably not worth anyone's time. The so
called "best" advice is: __Stay the hell out of other people 's code*.

------
drharby
Cultural fit is now my primary hiring consideration, and this is why. Good
advice, quick read, 9/10\. Needs more dog

------
InclinedPlane
This article is at best half useful, and missing the other half is potentially
quite dangerous (to organizations, to people's careers, etc.) What's missing
is a discussion of power and power dynamics (and healthy vs. unhealthy
versions of same, let alone how to work effectively in either or drive
change). Partly this comes down to a failure on the author's part to care
about power dynamics or look at their own power. In this case the author was
able to just blindly drive change by charging in like a bull in a china shop
and the only consequence to themselves was a very minor verbal admonition,
that's an indication of their level of power and where they sit in the overall
power structure of their org, not every dev. in a similar position would see
the same results, however. Many people would have to navigate that problem
much more cautiously to avoid becoming fired or ostracized.

( _Edit: and indeed I see another comment in this thread about someone who did
exactly the same thing as the article 's author and it turned out very poorly
for them because they lacked the power the author has/had._)

Additionally, the author completely ignores the value of "soft skills" and
implies that all that's necessary to have a positive impact where you work is
to blindly seek the technologically superior choice whenever possible,
ignoring politics, power, and ego (yours and others) along the way. There's
value to that, but there's also great potential for that sort of mindset to
lead you astray, because it's often difficult to know "what's best" in every
situation. In the article's example the pros and cons were fairly
straightforward, but most of the time the situation is likely to be a lot more
complex or a lot more subtle. And it may be easy to make the wrong value
judgment (and consequently fight the wrong technical fight) based on
ignorance.

On top of that, this story is very frustrating because it only concerns itself
with technical problems. At the end of the day the organization was still just
as dysfunctional as ever even though it grudgingly fixed a technical problem
it found it couldn't ignore. The author helped fixed a defect in code but they
did almost nothing to help fix a much larger and more serious defect in the
organization they worked in.

~~~
watwut
I would not expect junior to fix large organizational issues. Not much
possible.

Also, while I strongly believe in treating people with respect and using
social skills to the extend one has them, sometimes the right action to take
is the one that makes people angry. When your relationships make it impossible
to solve technical issues, it not junior who inadvertenly fixed issue who is
not displaying social skills. It is whoever feeds the power struggle between
departments.

------
dkrikun
Could not disagree more. The author most probably freed the company from its
dysfunctional stagnation due to some political issue. It is thanks to his
ignorance that he resolved an issue, something that had to be done.

In general, staying out of other people code is a bad idea. It promotes lack
of transparency and agenda proliferation. This is because the owners of the
code start being a "monopoly", can work less hard, provide exaggerated
estimates etc. When people know that others can read there code, maybe hack on
it, make something faster or simpler -- well they work harder and tend to be
more transparent.

~~~
wmichelin
Sounds like you didn't read the article :)

~~~
dkrikun
I did and I know the author says "actually it is a terrible advise" but he
also continues to soften his statement

------
robertAngst
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 problem.
Figure it out. This means researching, doing math, proving, and testing. And
as I've done this more and more, math is really really useful to prove things.

~~~
ArchTypical
Already more interesting than the whole clickbait blogspam i just reread (to
make sure i didnt miss something the first time).

