Nope, not even in the same ballpark, er, playground.
TL;DR: Nobody is solving real problems for users, that's hard. So they're solving substitute problems that are easier for themselves.
The conceit is the "playing with themselves" metaphor: I.T. managers are building themselves dollhouses, and I.T. developers are building tech playgrounds, then just playing with themselves.
None of the above are listening to or delivering what users actually need.
// Interesting take, but author after meandering down a rant wasn't sure where to go with it so just sort of stopped writing mid-weeds.
Hi Terreta. Yes, it feels like it stops abruptly. Plenty directions for elaboration. But weeds started to get thick. I am thinking separate satellite posts will do better.
"A nerd is conforming messy users to his playgrounds’ “correct” view. What doesn’t comply to it is “incorrect” and is rejected from his clean playground.
Complete self absorption, not a hint of care for the user.
I implemented a “high priority” feature required from me by scrum master who talks to “business”.
I chose the correct recommended practices to follow - therefore the result is good.
I used the correct new framework everybody is using - therefore the result is good."
> I used the correct new framework everybody is using - therefore the result is good.
Boy, I've heard that one a lot around here. As if framework choice was more important than actually solving the problem that you're there to solve.
To put a positive spin on this: modeling a domain well so that you can solve real problems with it is a joy. Dirtiness of the problem domain is where it gets really interesting, and you start getting away from the idea that programming is just glue code and pasting stuff from Stack Overflow. I can usually tell when I've bumped into it when I just want to stop writing code and stare out the window for 30 minutes. I don't always do that, but I should.
so sad to see some of the grammar being really off in this otherwise pretty insightful piece: "them selves" instead of "themselves" is but one of many examples. I would otherwise forward it more...
A sentence like:
"""they change their minds and mess up the clean code ...that a Playground dev already imagineared with him self."""
should be rewritten, for example:
"""...that a "Playground Developer" already conceived."""
Neologisms like "simplisti’fy" are maybe ok in certain nerd circles, but they make the write-up less readable for the most important target audience: actual users of these badly designed "playground IT" systems.
I don't like it myself. But I want to differentiate "simplify" as in remove non essential complexity, from solving the problem naively, simplistically. Which is what a simple minded go-getter manager does. Lots of accidental complexity from nerd toys gets added in the process. So pretty much the opposite of simplifying.
I think there is an additional reason here too. Software development work is (too often) seen as heads-down, anti-social work. Large corporations often bridge communication between software developers and the business/end-users via third-parties, such as product owners/manager, architects, and business analysts. Remember the "telephone" game we all played in kindergarten, where a message whispered between participants becomes comically unrecognizable by the time it reaches the last person? That is BigCorp software development in a nutshell.
Solving this communication problem is uncomfortable. Connecting software developers with end-users is hard. It means software developers have to have courage to ask "dumb questions" when the end-users explains something too quickly in jargon-laden terms. It means that end-users have to be patient, with the time to teach and explain enough about the problem domain. People with strong communication *and* technical skills are hard to find, and creating ongoing mutual respect and cooperation between end-users and the oft-hated IT department is only possible when employee attrition is low enough to create long-standing relationships.
Software development is fun when it is a high-momentum, self-contained exercise. So we direct our energy to complexity, because its fun and safe. We don't need to stop and engage with end-users who speak a language we barely understand. We don't need to create consensus among disagreeing end-users representatives. We just need put on some good music, drink some coffee, and solve clean technical problems, rather than messy people problems. I'd guess most software developers would say "you don't pay me enough to deal with people", and walk away.
Hi yold_. It is made heads-down anti-social work by simple minded managers. They create infantilized environment that self-select for devs that don't like to talk to people.
Talking to people is trusted to "big boys" from business. You've listed the roles. Business big boys will sell complexity to clients through IT woo wooo. More complexity - more revenue.
I guess the most useful understanding from my post is that it is by design. It didn't "just" happen. Corporations bread them and make it a norm. This proliferates an understanding of a dev as an infantile that plays with himself.
Thank you for showing me I probably didn't articulate that understanding well enough.
34 comments
[ 4.3 ms ] story [ 77.6 ms ] threadTL;DR: Nobody is solving real problems for users, that's hard. So they're solving substitute problems that are easier for themselves.
The conceit is the "playing with themselves" metaphor: I.T. managers are building themselves dollhouses, and I.T. developers are building tech playgrounds, then just playing with themselves.
None of the above are listening to or delivering what users actually need.
// Interesting take, but author after meandering down a rant wasn't sure where to go with it so just sort of stopped writing mid-weeds.
"A nerd is conforming messy users to his playgrounds’ “correct” view. What doesn’t comply to it is “incorrect” and is rejected from his clean playground.
Complete self absorption, not a hint of care for the user.
I implemented a “high priority” feature required from me by scrum master who talks to “business”. I chose the correct recommended practices to follow - therefore the result is good. I used the correct new framework everybody is using - therefore the result is good."
Boy, I've heard that one a lot around here. As if framework choice was more important than actually solving the problem that you're there to solve.
To put a positive spin on this: modeling a domain well so that you can solve real problems with it is a joy. Dirtiness of the problem domain is where it gets really interesting, and you start getting away from the idea that programming is just glue code and pasting stuff from Stack Overflow. I can usually tell when I've bumped into it when I just want to stop writing code and stare out the window for 30 minutes. I don't always do that, but I should.
What self-respecting, competent techie would want to be one of the "dolls" in such a playpen?
The article is solid gold.
Further recommended reading material (which I read and loved) - Will Stor's "The Status Game".
"Dollhouse mangers’ purpose is recognition from higher-ups."
Yup, that's "The Status Game" right there.
Several types of status game are played:
- "Virtue" Status Games (conforming to a framework, no matter how ill-fitting to the real world)
- "Prestige" status games - designing an elegant system, and being respected for the elegance and cleverness
- "Dominance" status games - for HR and management types, who control and unnecessarily oppress everything, striking fear into employees to conform.
Solving this communication problem is uncomfortable. Connecting software developers with end-users is hard. It means software developers have to have courage to ask "dumb questions" when the end-users explains something too quickly in jargon-laden terms. It means that end-users have to be patient, with the time to teach and explain enough about the problem domain. People with strong communication *and* technical skills are hard to find, and creating ongoing mutual respect and cooperation between end-users and the oft-hated IT department is only possible when employee attrition is low enough to create long-standing relationships.
Software development is fun when it is a high-momentum, self-contained exercise. So we direct our energy to complexity, because its fun and safe. We don't need to stop and engage with end-users who speak a language we barely understand. We don't need to create consensus among disagreeing end-users representatives. We just need put on some good music, drink some coffee, and solve clean technical problems, rather than messy people problems. I'd guess most software developers would say "you don't pay me enough to deal with people", and walk away.
Talking to people is trusted to "big boys" from business. You've listed the roles. Business big boys will sell complexity to clients through IT woo wooo. More complexity - more revenue.
I guess the most useful understanding from my post is that it is by design. It didn't "just" happen. Corporations bread them and make it a norm. This proliferates an understanding of a dev as an infantile that plays with himself.
Thank you for showing me I probably didn't articulate that understanding well enough.
Same goes for SOME sports, I mean whenever you score a goal, your team automatically are making a profit from you. Not that is bad, but it still does.
But what you're explaining is part of the software development or I.T. in general.