I had surprising lessons in a stupid job where I cut half of the effort through scripting. Albeit it wasn't the boss, but the colleagues. Everybody complained about how dull the tasks were. I offered the script to people nearby, which they refused. Ok. A month later I ended giving this up to a lot of people, suddenly the first one who refused jumped on me angry asking why I didn't give it to him/her too.

People are .. people.

People are people indeed, which means people are not companies. The best interest of the person you work for might not (will almost never) be the same as the best interest of the company. Superiors want people who are working hard for them, because it makes them feel more important than half the people working 2 hours a week for them (even though the output is the same).

You're working for a person, not a company. If you forget this, then you might end up surprised.

> You learned that people value effort over results.

People still value results, but they expect the price of things to be vaguely related to the cost of materials + time + small profit margin.

And in an efficient competitive market, prices are related to costs. If there were 5 identical providers of "web page updates", then the maximum you can charge would end up close to how much of your time it takes to run the script, and the customer would get to keep the surplus value.

If you are in a position to get away with value-based pricing, then you have to be careful to keep your costs secret, because otherwise you make people irrationally angry about being ripped off.

So how much does adding drama to my work routine help my compensation rate?

True story (radically abbreviated and redacted):

One group, group A writes crap code. Another group, group B is meticulous and careful, constantly refactoring, using good testing and code review practices, taking care to design their software with forethought before ever committing code.

Group A's code is in a constant state of breakage. Group B's code always just works.

On the other hand, Group A is extremely vocal. Their manager makes sure to give updates at every meeting. Hosts (mandatory) all-nighter pizza parties to fix the crap they broke during the previous cycle. Large parts of the company are privy to the drama. "They're working so hard, really pulling their weight! So dedicated to the company!" Back slaps and high fives when things kind of, sort of, stop breaking. This is a constant, regular cycle. All the non-engineers think this is the hardest working group in the company. In a way they are. In that same way they are the stupidest group in the company.

Meanwhile Group B steadily builds good software quietly. No late nighters, engineers go home at reasonable hours, sometimes early. Same with managers.

Restructuring event. Cuts must be made. Who gets pink slips? The quiet ones. And their managers. Not the retards putting out unmaintainable crap day in and day out.

I feel that the manager of Team B has some responsibility in this story

You'd think so but (bad) managers never take the blame or responsibility for something unless it succeeds. That's been my experience at least.

But Team B were succeeding and he wasn't shouting about it to his superiors!

This is a signal of short-sighted incompetent management.

Sadly, it helps.

The guy in my former group who complained a lot and would push back to the management heavily was the one the manager respected the most.

The problem is: His complaints were often ridiculous and did not have merit - no one was fooled by them - not even the manager who usually ignored his complaints.

But his behavior (regardless of the content) was used unintentionally as a measure of how engaged the employee is and how much he cared about the work (complete BS - the employee was a good friend of mine and I knew him well).

This isn't just my view of the world. The manager essentially told me this.

Now of course, he was a pretty poor manager, but I do believe that unless a manager actively guards against these kinds of judgments, they will be the default.

TPS

The manager must know the work, otherwise he can't manage. Doesn't sound like the case.

In this case, the manager knew enough to know the person was spewing BS objections most of the time. He was actually an expert in the field and the discussions were often of a technical nature related to his expertise.

Although yes, it was a separate problem that he didn't know plenty of the operational "small" details which caused him to always underestimate project timelines.

What does TPS stand for in this context?

It's a reference to the movie Office Space. https://www.youtube.com/watch?v=Fy3rjQGc6lA

Actually I think it's a reference to one of the principles of the Toyota Production System (TPS):

A leader must understand the daily work in great detail so that he or she can be a best teacher of your company's philosophy. -- https://missiontps.blogspot.com/p/14-principles.html

That's different from the TPS reports of Office Space fame (https://en.wikipedia.org/wiki/TPS_report).

Over promise, under deliver. Smart move. Certainly one that anyone in programming can relate to.

I think you must've meant, "under promise, over deliver"? At least that's what Scotty was suggesting.

Thats the lesson you learn in life . But anyone starting their career will have a tendency to under promise, over deliver. I did this for some time until my manager told me to literally to go slow and deliver quality work instead.

so true. that exact situation happens where i work. One department's managers prefer flailers who work long hours fixing their mistakes over folks who deliver a working product with little drama. I observe that the latter example is interpreted as 'obviously it was easy'.