Never Trust a Programmer(johnnance01.wordpress.com)
johnnance01.wordpress.com
Never Trust a Programmer
http://johnnance01.wordpress.com/2010/06/15/never-trust-a-programmer/
13 comments
"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.
Indeed; my worse experiences have been exactly of this sort.
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.
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.
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".
The neat thing about contract law: Actual impossible contracts rarely are enforceable.
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).
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.
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.
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.)
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.)
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.
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.
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.
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.
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.
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.
Happens way too often. But it's understandably difficult to solve as an organizational issue.
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"?
"Is the author trying to trap non-programmers into understanding their error by (falsely) promising to provide them a scapegoat?"
Yes.
Yes.
More like never trust anyone who says yes too quickly.
Wrong title, good post, crucial topic. Thanks!
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.