←back to thread

388 points replyifuagree | 6 comments | | HN request time: 0.986s | source | bottom
Show context
corry ◴[] No.37966968[source]
“Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”.

Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly.

It’s like asking sales people what their quota should be. They pick a number that is no-brainer hittable, because there is a lot of complexity and many unknown variables in getting deals signed, so to prevent looking bad they’ll pad their number. But their no-brainer number is below what the business needs.

So you tell them their quota is going to be a bit higher. They’ll have to stretch to hit it.

And it’s even MORE important since their comp is DIRECTLY tied to hitting that number.

And yet sales people aren’t writing article after article about how self-set quotas are sacrosanct, should only settable by sales people themselves, and how clueless management is to try to get more performance above the no-brainer target.

replies(16): >>37967032 #>>37967045 #>>37967049 #>>37967125 #>>37967129 #>>37967177 #>>37967191 #>>37967206 #>>37967725 #>>37968246 #>>37968785 #>>37968936 #>>37969087 #>>37970168 #>>37971201 #>>37975757 #
paulcole ◴[] No.37967045[source]
There’s a consistent belief here that Programming Isn’t Like Other Work™ and that you can’t estimate it, it’s so mentally taxing that you can’t do it for more than a few minutes at a time in complete silence, and that it’s closer to Da Vinci sculpting the Sistine Chapel than kludging together a few APIs.

It’s fun to think you’re special and easy to do when you’re paid a shitload of money.

replies(2): >>37967228 #>>37967497 #
replyifuagree ◴[] No.37967228[source]
Programming is like some kinds of work.

It is very much unlike operating an established manufacturing facility. But, about two thirds of dev work has a lot of parallels with creating a new manufacturing facility that manufactures a new kind of thing using new materials and techniques. The primary parallel is that a new facility requires a lot of discovery. Whereas if operating an existing facility constantly required a lot of discovery that disrupted operations it is likely the business team would pivot to something more lucrative.

Sadly most developers work in companies that have a manufacturing management system, which is inappropriate for managing development work, primarily because of pressure+timeline patterns typically applied via silo on silo kingdom building.

replies(1): >>37967242 #
paulcole[dead post] ◴[] No.37967242[source]
[flagged]
replyifuagree ◴[] No.37967692[source]
One thing to watch out for is confusing IT work for dev work. I see this a lot with business folks.

An example of IT work is installing MS Office on a laptop by hand.

An example of dev work is integrating VBA into excel so that office users can automate excel using VBA.

replies(2): >>37968928 #>>37969789 #
1. paulcole ◴[] No.37968928[source]
But yeah thats kinda my point. Integrating VBA into excel isn’t the Manhattan Project. Unless it’s your first job you can probably break the project down into steps and give a decent estimate of time on each.
replies(2): >>37970327 #>>37970792 #
2. replyifuagree ◴[] No.37970327[source]
Integrating VBA into excel was an interesting one as the excel team refused to just pull it in as a dynamic dependency but wanted it embedded straight into the deployment to avoid the DLL hell that was common on the windows platform. In addition going from having no automation via something like VBA to having automation required some pretty complex work.

As for the Manhattan Project, you might want to think on the difference between the words complexity and difficulty. And then you might consider that when working with nuclear material to create the world's first nuclear bomb, you would want to keep the complexity as low as possible, sheerly out of self preservation.

replies(1): >>37970574 #
3. paulcole ◴[] No.37970574[source]
Neat!
4. pixl97 ◴[] No.37970792[source]
Yep, this sounds like the kind of project you make a guess, write up, and it works in that amount of time on your machine.

Then you push it out into the field and you get flooded with calls on it not working. Turns out it only works in your version of Excel on Windows without some particular set of patches installed. Manhattan Project was easy, they didn't have to worry about any backwards/multi-platform compatibility.

replies(2): >>37970982 #>>37972000 #
5. paulcole ◴[] No.37970982[source]
Exactly, I’m glad you’re on my side with this. It’s great to have your support.
6. replyifuagree ◴[] No.37972000[source]
lol, I'm just thinking of how awful the Manhattan project would have turned out if it had half the invisible things that can go wrong in software deployments.

If software caused mushroom clouds each time it had a problem in the field, nobody would let MBAs run software projects!