
Never Trust a Programmer - iamwil
http://johnnance01.wordpress.com/2010/06/15/never-trust-a-programmer/
======
mwsherman
It's a problem of incentives. When I worked in a corporate environment, I
worked very hard to ensure that people asking for things were the ones who
paid for it -- even internally. A project # to bill against for everything.

In the agency world (where I was), carefully billing time was de rigueur for
client-facing people. I pushed to have it apply for non-billable internal
people too.

So the "idea people" had to do cost-benefit. Requires a cultural change (and
trust), but it brings discipline to both sides. Really helped.

------
hga
" _A programmer has to be quietly focused doing mental gymnastics to produce
clean working code. It’s difficult and takes all your energy. There’s no time
to run around to see whose throwing you under the bus._ "

Indeed; my worse experiences have been exactly of this sort.

------
iamwil
The other thing I'd add is an expectation from sales/non-technicals that you
produce an golden egg the first pass through.

People say they want to be agile, but they rarely realize that it also means
you have to do less.

I often got hammered on not being fast enough, and yet, when cutting corners
and throwing it together with boogers and duct tape to get it to a
demonstrable state, I was told it wasn't presentable to customers because it
didn't have the frills and throw pillows.

Next time, I'm just not working with someone that doesn't understand mvp.

~~~
sophacles
It is better than dealing with the salesmen selling things that just are not
possible. One time I was given a day to implement a magic iPhone detection
algorithm. It had to distinguish from iPod touch, and somehow this was to be
done based on "network characteristics". So during an emergency meeting the
salesman said "It can just be done from the MAC address, quit whining." Well
after a while we managed to get hte customer happy, and the salesman was told
"Next time, if you aren't sure talk to the programmers first". The programming
team was told to expect a new hire that "knew what he was doing".

~~~
gte910h
The neat thing about contract law: Actual impossible contracts rarely are
enforceable.

~~~
sophacles
Yeah, unfortunately there is this other thing called "at will employment"
which means I pretty much had to do what the bosses told me to provided it was
legal (which is different from physically possible).

------
phsr
This story is very close to a place I worked at as a co-op a few years ago.

The sales and PMs would promise the world to the clients, and development
hours were taken away from the developers to support the IAs that were
overbudget. We had a solid dev team and delivered the sites on time, but one
of the projects was all wrong in the client's eyes (due to poor specification,
the whole IA -> Design -> HTML workflow was a very slow, behind schedule
waterfall) and it was blamed on development. We quickly made the changes, that
project ended well.

I ended up leaving after my co-op to accepted an offer from a prior co-op.
Shortly after, most of the dev team quit, and the VP of technology was fired.
A couple of months ago the company closed its doors, owing months of paychecks
to employees, and clients lost project/money.

------
brown9-2
Pro tip for those newly graduated programmers or those in school:

Avoid companies like the one described in this article like the plague.

(Although I suppose it's hard to tell what things are like from the interview
process alone, but a business model based on selling to large enterprises is a
red flag.)

------
weavejester
We've found that detailed sprint burndown records are a useful tool. If you
can say "historically, our estimates are 90% accurate", and then pull up a
bunch of charts and figures to back up that assertion, it lends a lot of
weight to your argument.

------
BobLee
Programming and research are an expectations game. Your manager neither knows
what you do or how long it might take. My manager once had to write my status
report because I was so busy.He was a good manager but revealed himself to be
totally clueless about what I was doing.Thereafter I became extremely serious
and a bit paranoid about my status reports.

Necessarily a manager evaluates you by whether the product works or it doesn't
and is on time or late. You are evaluated against management expectations. The
more that they expect,the worse you do. Because expectations are typically
unrealistic,you can get a fine reputation for perfunctory but consistently on
time work.

Decrease early expectations to do well. During project planning be pessimistic
and extreme humble. Programing and research have very high product and
deadline risk. For each project have a contract with your manager that
identifies the main risks, and accept responsibility for only what you can do
something about. Your professional self management will impress your manager,
but he will hate the uncertainty.

------
jister
I worked on a company just like this 7 or 8 years ago. I remember the project
of the other team that went in flames because of the ridiculous estimates that
the sales people committed to the client and our idiot VP agreed to take.
People literally worked 24x7 for a month or so.

~~~
tomjen3
That is the first problem.

Never work more because somebody else screwed up.

Second, document your estimates and then let the manager write his and in the
end, see who was closest.

------
javajones
Boy isn't this the truth. My last job the project manager was great at getting
everything in writing and a signed contract up front. It made life so much
easier. When they came back with we want this too. He would just point at the
contract and say, once we've completed this contract we can make a new one for
the additional items you would like. Worked like a charm.

------
Ennis
This is a very good article. The message has been written about many times but
it's still important. It's not easy to say no or push back. It can even be
fatal in organizations that don't enforce "ownership." How can you say no if
no one is asking you?

Happens way too often. But it's understandably difficult to solve as an
organizational issue.

------
thyrsus
I'm baffled by the title. Is the author trying to trap non-programmers into
understanding their error by (falsely) promising to provide them a scapegoat?
Or is he using "trust" as in "trust in the omnipotent"?

~~~
chaosmachine
_"Is the author trying to trap non-programmers into understanding their error
by (falsely) promising to provide them a scapegoat?"_

Yes.

------
NEPatriot
More like never trust anyone who says yes too quickly.

------
cema
Wrong title, good post, crucial topic. Thanks!

