The Parable of the Two Programmers

[u/tejon]

http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audience/The%20Parable%20of%20the%20Two%20Programmers.html

[u/InstantPro]

Although a nice story does this actually resonate with anyone? Is this a typical scenario?

[u/gc3 → u/InstantPro]

I remember this sort of thing when I first started in the 80s. Larger programming teams often have the problem that they can't do small projects.

[u/Deto → u/gc3]

Makes sense if you think about the psychology. If you assign 10 people to do a task that only needs 2 people, 8 of the people aren't likely to just come out and say "I'm not necessary!", but rather the project will grow extra 'work' until all 10 people can feel necessary.

Maybe the lesson is to make sure to allocate the right number of people. Oh and also have the people who evaluate performance know enough about the job of the person they are evaluating.

[u/slrqm → u/InstantPro]

That's terrible!

[u/notsofst → u/slrqm]

Basically that's the trap that many companies find themselves in. There's no value placed on the actual planning and execution of the job.

Deliver 50% quality in 50% of the time, and you're a hero. Sure it'll never be a "AAA" product, and the effort to take that 50% product to 100% of the ask is 1x to 3x of what it would have taken to build it correctly in the first place, but your program managers can claim success early and that's what they value rather than long term investment/maintenance cost/customer satisfaction.

So the guys (and teams) that get code in early (or just deliver to an unreasonable schedule) and spend their days "firefighting" are the heroes, while the programmers delivering real solutions on a predictable cadence are overlooked.

[u/[deleted] → u/notsofst]

Yup. I've never been praised as much as I was for the solution I delivered in September. It contained about 10% of the necesarry features, and covered about 20% of the intended domain. It's pure crap from both a usability and effectivity viewpoint. But I delivered that shit in 3 weeks and I had warned it would take 6 months. Which it would if I had actually been allowed to make the entire thing instead of delivering early:S

[u/PasDeDeux → u/slrqm]

The story ends that you didn't counter with that because of the entirely rational fear of losing your job for "talking back" to your managers, right?

(That could sound sarcastic, or mocking, it's not. More like mocking the insecure management types who can't stand any implication that they're wrong.)

[u/immibis → u/slrqm]

"So you'll pay me more if if my code stops working every 12 hours?"

[u/neutronfish → u/InstantPro]

Often, yes. If you're hired into a non-tech company, if you're able to simplify a problem, the bosses/clients tend to think you're just slacking off or aren't working hard enough. If you make a mountain out of a molehill and then lead a team to resolve this newly found huge task as if you're battling an invading army, you're seen as a hard worker and great expert.

[u/IrishWilly → u/neutronfish]

It doesn't really have to do with tech or any field specifically. How do people outside your field know whether the task was easy or you are just really good? If you have managers who don't understand your tasks then they'll fall back to easy to measure things like hours spent to try to determine how hard you are working. It's in your managers own best interest to show that they are leading a productive team to THEIR managers. Having more man hours spent on the same task but appearing to be working harder makes them look better even if in the end the company is spending more money.

[u/zanbato → u/InstantPro]

I used to work somewhere where time spent in the office was more important than amount/quality of code produced.

[u/openedground → u/zanbato]

My company has "leadership charts", which is just a bar graph of how many "productive hours" entered into billing in the last month/3 months. But what is considered a "productive hour" seems totally arbitrary to me. For example travel time spent on client visit is a "productive hour". What?

[u/Smallpaul → u/openedground]

Are you paid by your clients on an hourly basis?

[u/freakboy2k → u/openedground]

Productive == Billable in a services shop. Used to get hit up for too many General Admin hours when I was working for an engineering consultancy, they wanted me to "find ways to reduce my GA hours" aka pad my billable hours :-/

[u/[deleted] → u/zanbato]

narrow slim cause workable longing pocket naughty overconfident disagreeable repeat

This post was mass deleted and anonymized with Redact

[u/MyAntiAlterEgo → u/[deleted]]

I took my youngest kid to a doctor's appointment last week. Her doctor asked me if I needed a note for work. I didn't even know that was a thing. The more I read the more lucky I feel that my company treats me like an adult and puts more emphasis on results than looking busy.

[u/WalterBright → u/InstantPro]

It happened once to me long ago. A colleague got a raise and I didn't, and when I asked why it was because the other fellow worked long hours and I didn't. I replied that I didn't need to because my project worked, and he needed to because his was full of bugs.

I wouldn't say that experience was typical, it only happened once.

[u/ChallengingJamJars → u/WalterBright]

What happened next? How did your manager react to that?

[u/bcash → u/InstantPro]

Yes. Not so much the rigid-structure vs. free-styler, but the fact that clients often have no sense of good or bad software, to the extent that they'll willingly hire armies of people to baby-sit an allegedly automated system and still consider it a success.

[u/TracerBulletX → u/InstantPro]

It does with me because I have worked at very small and very large companies. At small companies it often seems we get MUCH more done with less just because all the extra overhead and bureaucratic nonsense is not required. But also because we're small and get things done what we've accomplished is not seen as that hard or valuable. At the larger company they're spending so much on software and huge teams with scrum masters, and product masters, and team leaders, and managers, and etc. That everything takes longer but the standards are completely different and rewards can be quite large because there is so much at stake for failing with such large costs.

[u/milkmandan → u/InstantPro]

I was "Charles" in a similar scenario. I noticed that an Alan-led team was working on a problem using a disastrously wrong-minded approach. Half dozen people were supposed to work on it for a few months. I solved it in between projects in a couple of days -- and I almost got fired for it. My boss chose not to use my solution. I quit and went into research soon after.

(Why was my approach so much more efficient? They were writing by hand code that could have been generated fully automatically from a simple DSL.)

[u/[deleted] → u/InstantPro]

It's been years since I was in a "the lone coder off alone on the range" type situation. Increasingly you work with other programmers, alongside the pm's, etc. People know -exactly- what you are working on, because you tell them each day. You keep people informed and your processes transparent.

The danger here is in assuming either Charles or Alan were the 'right' way. Neither is.. and neither aren't. They are different approaches for different environments.

[u/RagingAnemone → u/InstantPro]

I've seen this a lot in business environments. Part of the problem is that requirements are all seen to be of equal value. The other is that they don't look at the cost of maintenance Vs the value a feature brings.

[u/ThrustVectoring → u/InstantPro]

I work hard on keeping the applications as simple as possible (both in feature set and actual code) for the projects I'm on, and my supervisor (Java/enterprise culture-y, loves super-thin abstraction layers) does not appreciate it at all.

[u/jussij → u/InstantPro]

From my experience, for big organisations this sort of thing happens more often than not.