
The Best Programming Advice I Ever Got (2012) - reforge_reborn
http://russolsen.com/blog/2012/08/09/the-best-programming-advice-i-ever-got/
======
logfromblammo
The lesson is that the system is often more than just the computer software.
The requirements may be more than just the software requirements.

I was fortunate to recognize that early at my current job. We have boatloads
of software requirements documented, but the prime directive is not even
spoken aloud: "Produce 40 billable hours per week, for each employee,
forever."

And that is why the database is a mess and the code sucks beyond all reason.
Any reduction in technical debt directly translates to a reduction in the
perception of work being done. In short, the customer knows nearly nothing
about software development, is willing to pay for status reports, process
documentation, and meeting minutes rather than working code, and has a budget
completely independent from the value of the work product.

Have you ever looked into some code and seen a WTF block, and it turned out to
be a workaround for a bizarre bug? Here, the entire code base is the WTF
block. The bug is in the human organization. I do not have the permissions to
commit anything to that source tree. So I suck it up and send out resumes.

You don't fix _anything_ until you first understand why it is broken. In the
context of the CAD rendering, it is likely that some people had invested a lot
of effort into convincing the management that their laziness was actually hard
work plus frustration at their resource constraints. Think like Wally from
Dilbert. That slow rendering is a system-enforced cap on productivity, slowing
down the fastest workers.

In the psycho-clueless-loser model, that is the losers getting a leg up on the
clueless. A psycho would have first manipulated the political situation for
personal advantage before releasing the fixed code. A loser would have left it
alone as already being to their advantage. Don't be clueless, folks.

~~~
aaronem
For those like me unfamiliar with what's here termed the "psycho-clueless-
loser model", it appears to be what is more commonly termed the "Gervais
Principle", and you can find what looks to be a reasonable overview of the
subject here: [http://www.ribbonfarm.com/2009/10/07/the-gervais-
principle-o...](http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-
the-office-according-to-the-office/)

------
baldfat
Good read, BUT the advice is stay away from Drama and especially work Drama.
Seems to me 50% of people are damaged immediately by work Drama and the other
half die slowly with maybe one or two sort of winners.

I would go work somewhere else and stay happy.

~~~
naterator
Yea, the lesson is: If you find yourself in a situation like that, bail out as
fast as you can. When we're young we are often not taught—or more importantly
we do not have the opportunity—to simply GTFO of the crappy situation we're in
(Family, Bullies, etc.). It has tragic consequences both early in life and
later on. It's (one of the reasons) why we get school shooters, why people
stay at crappy companies when they don't have to, why people stay in
destructive relationships.

Modern society often allows us the freedom to avoid people and situations we
can't control but don't want to be in. For the love of god, please take
advantage of that.

~~~
michaelochurch
If you bail on every company that's dysfunctional and political (that's about
90%, including of startups) you'll probably get stuck with the job-hopper
stigma before you find a good company.

Employers get away with horrible conditions and general dysfunction _because
of_ the job hopper stigma, but unfortunately, one person leaving bad
situations immediately (instead of wasting months to years trying to make
lemonade out of piss-lemons) is not going to break that stigma. In fact, it's
going to lower your value and make you more likely to end up in dysfunctional
companies.

A better strategy is to play the game, well, by learning how to do enough in
typical, semi-dysfunctional environments to get career credit, while keeping
an eye out for better opportunities. This all-or-nothing attitude that many
young people have toward corporations ("if they think that way, then I don't
want to work for those losers anyway") doesn't pan out in the real world. Even
the good companies have plenty of stupid, political people in them.

~~~
vinceguidry
The answer to "job-hopper stigma" and any and all other competence-trigger
hurdles is simple. Sell the benefit, not the feature.

In other words, change the conversation from "who you are" to "what you can do
for them". A track record of accomplishments does a lot more to convince a
stake-holder that you know what you're doing than a list of previously-held
positions. If all you have is a list of previously-held positions, then sure,
if there's more entries on it than years, you'll have a rough go at it. But
you don't have to operate this way.

Nobody is unemployable. There are only people who have figured out how to
convey competence and people who haven't.

~~~
aaronem
Well. Conveying competence is, indeed, a valuable skill. But the most it can
do for you is to get you a seat at the table. What will you do once you've got
the job, and it comes time to play the game?

And, while we're at it, why assume that the only possible reward for playing
the game is the opportunity to keep playing the game? Isn't it possible that,
in playing the game with sufficient skill and artistry, you can create for
yourself the opportunity to do the work you joined that company to do?

...to be honest, I really don't know the answer to that last question at all.
But it sure is an interesting question, don't you think?

~~~
vinceguidry
> What will you do once you've got the job,

Do your job? I'm having trouble understanding what you're getting at. If you
don't like your work environment, then leave. Just don't take six months to
figure that out. But really, you should know whether you would like working
there before you take the job. It's not that hard to take a few of their
current employees out for coffee and ask them what it's like to work there.

Not every job has the insane level of politicking described. Just find a place
where you fit in. It exists.

~~~
baldfat
> really, you should know whether you would like working there before you take
> the job.

My worst work place had an extreme micro-manager of a president. People were
fired after working there 15 years on the spot and others their department was
under performing for years and years never were let go.

Final straw: Unannounced layoff of 10%. They fired people at their desk all
morning and afternoon and did not have an all company meeting till 3:30 pm.
The bonus the job had a loop hole and didn't have to pay unemployment tax. So
everyone didn't know they did not qualify for unemployment and were left with
2 weeks severance pay and found out they didn't qualify many weeks later after
they were denied their unemployment.

Should have known: This was a place I knew intimately for 5+ years. I was
friends with most of the staff. I did have coffee with half a dozen people and
well made a 10+ year commitment mentally before taking the job left 6 months
afterwards on my 4th year of employment. Now I LOVE my job working for Head
Start.

------
aeturnum
This story leaves me with a completely different takeaway message than the
author got.

It seems like he got involved in situation he didn't understand and may have
risked his job (and perhaps the jobs of others) in the process. His process
demo'd better, but he has no idea why some people were opposed to it.

What if this was a product that emphasized security, and he inadvertently
violated the security model to get speedups? Understand the processes you're
working on, and the problems that your co-workers are dealing with. In this
case, he could have made his life easier by identifying the "faction" that
wanted what he wanted and working with them.

~~~
Spearchucker
" _Understand the processes you 're working on, and the problems that your co-
workers are dealing with._"

Go further than that. Step back and look at the environment as a whole. It
helps to spend time understanding a situation before assuming you have
appropriate ideas about changing it (ref. below).

[https://www.wittenburg.co.uk/Entry.aspx?id=46870dcd-70cb-4ef...](https://www.wittenburg.co.uk/Entry.aspx?id=46870dcd-70cb-4ef8-98ed-91c94714fe03)

~~~
larrydag
In my opinion I think the author did try to address the big picture. He
brought it to his boss, and his boss's boss. If ideas are commodities worth
trading then why was the market closed from the top down? This is a lesson in
corporate culture which I think the author explains quite well.

~~~
aaronem
> In my opinion I think the author did try to address the big picture.

Sure. But grandparent's point is that he did it backwards: first he made the
changes he wanted to see, and _then_ he demoed it up the chain and got himself
in hot water. Had he first taken time to develop a thorough understanding of
the situation and the environment in which it had origin, he'd have been able
accurately to evaluate how best to take action in order to bring about his
desired result -- or indeed whether it might instead be best, despite what had
originally seemed to him a desperate need for improvement, simply to cultivate
the detachment necessary to take no action at all.

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

I am not being too cynical in thinking that this doesn't exist? I mean this is
the core of how teams interact. Politics is reality. So is territory. Fuck
decorum, though.

------
Duhveed
Great article. I was just thinking "whoever told you that was high" when the
author pivoted and said it was bad advice. The first comment was spot on...if
the current is dragging you toward the drama, swim up the shore to a new gig.

------
andreasvc
What I don't understand about this is how people are able to express their
dissatisfaction about someone else making the code faster, when it's so
transparent that they are just butt hurt that their way of doing it wasn't so
good after all. Of course I get that such people could from then on hold a
silent grudge against you, but I can't understand how they can openly complain
about this without making it totally obvious that it's just an ego thing.

------
tremols
I have been there in that sort of situation where managers twist their
eyebrows at an efficient or productivity-enhancing solution. The essence of
the java enterprise consulting business is fixing an unnecessary complicated
mess with a similar, new buzzword backed mess.

So the interesting thing here is how bureaucracy and efficiency seem like
natural enemies; a subject which always reminds Terry Gillian's Brazil movie
where the terrorist guy is the one who fixes things.

------
craigyk
The original architecture sounds like maybe it was just ahead of its time.

/s

------
jorgeleo
I think that the advice, if taken literally, is a bad advice.

But it does point to the fact that the system is not just the technology, but
also the people around it

I think that a better way to go about it was to comment first with the proper
people that you MIGHT be able to make it run faster before doing anything (all
though you know that you already did it). And drop the case if they don't want
it.

I can see that somebody might want to move the drawing calculation process to
a more powerful box serving more clients, and distribute the client with a
different license... in other words, there could be a business case for the
original configuration, and knowing it might help you to discover the negative
stakeholders (the people interested in the status quo)

Should you always stay out of others people code? I think not, I think that
there is a place for it. But from there to modify and publicize the
modifications there is a big distance. Some people treat their code as their
baby, and no parent like their kid criticized.

~~~
DavidBradbury
The point wasn't to stay out of people's code. He used that "advice" as a
reminder to not be what those people were/are.

~~~
jorgeleo
And what are "those" people?

~~~
andreasvc
People who get upset if you touch their code. I think in your other comment
you missed the fact that there was already an ongoing debate about this
particular part of the code, and it wasn't going anywhere. In such a case a
demonstration that the other method _is_ faster is more compelling than more
fruitless debate. Speculations on other reasons why the code should've used 2
processes is useless, as it is clear from the article that this change made it
possible to get things done faster, no need to argue with that.

~~~
jorgeleo
"People who get upset if you touch their code" which is what i mean when i
said that some people treat their code as their baby.

I wrote it before the debate began, it just got posted after it, that is not
in my control.

The speculation was to point out that he didn't managed the situation
properly, he just dismissed the current implementation as idiotic and proceed
to change it. But you missed my point too. Which is why in some scenarios run
faster might not be the first priority.

~~~
andreasvc
With "the debate" I referred to what is mentioned in the article of the two
departments who disagreed about the best strategy.

I don't quite follow you. In the article it's made quite clear that people
_wanted_ the code to run faster because then they could get more work done.
Yes there are conceivable scenarios in which faster code is not better, but
the article made clear that it wasn't the case, so I think the speculation
didn't add anything.

