top of page

They're Babies with a Second Grade Reading Level

  • Writer: Jer
    Jer
  • Apr 2
  • 11 min read

We need to talk about developers and software engineers.


At my previous job, I had the pleasure of arguing with a developer on proper ticket hygiene.  You see, the request was to add data validation to three fields used for customer request intakes.  The acceptance criteria listed each field individually with what the data validation needed to be. 


The intake form had a total of 6 fields.  One of them, topic, was used to generate all reports run off the data that this form is generating.  As such, this one field was a dropdown, with the 8 or so options.  At no point was it mentioned in the ticket description, nor in the AC.

When the QC (The QA team at this particular job) noticed that the Topic field was now a free entry field, with data validation matching another free entry field that was in the AC, I was called in.


The developer’s argument?  You didn’t say not to change the topic field, and therefore, how was he to know that the topic field needed to stay as is.


Upper management, siding with the developer, since developer = super genius in their mind, told me to rewrite the ticket so that it matches what the developer wanted.  What came from that was a 28 page document (including photos), detailing every minute detail surrounding the website that housed the form, the form itself, API calls, DB structure, fucking everything.  Next to each individual detail was “- do not change,” until they reached the very end of the document where it listed the three items that needed to be updated, and the updates that needed to occur.


I sent the ticket back to the developer and gave notice.

---

A more recent discussion is best described in meme format.



Patrick Star ID meme.  "Your sprints last 2 weeks? Yes.  You complete 20 points per sprint?  99% of the time, yes.  Since this project is pointed at 15, it should take a full sprint?  Yuppers.  So it'll take 2 weeks?  That's not how story points work!!
Just so you know, if you say shit like this, I hate you.


The bastard fully admitted that he understood that the executives didn’t give a fuck about story points, they just needed to know how long the work would take, and when they can expect to have the work deployed but refused to give any sort of timeline.  Not even a rough estimate, nothing. 


So, I went back to the steering committee and said that this relatively simple project would take eight weeks.  They were not pleased; neither was the head of application development.

“I told you that we finish 20 points per sprint 99% of the time, and that your project was only 15 points, so we’ll do it all in one sprint.” 


Yeah, but you refused to comment on if that would be the next sprint, the current sprint, the sprint after, and when I asked if you would commit to it being two weeks until it’s in testing, you said that’s not how agile pointing works.


“What’s not to understand?  15 points is less than 20, of course it’s going to take two weeks, where did you get eight?”


I have made a mortal enemy.

---

Last story, I swear.  A friend of mine is handling work surrounding a new office location that will be opening up in Q1 of 2025.  There is a ton of work that is involved in getting the office set up and running properly, and (if I’m being honest) he’s a bit overwhelmed by the sheer magnitude of work happening in very quick order.  The log-in screen for associates has a drop down with all the locations in it.  He contacted one of the developers and let them know that they needed the new location added to the dropdown ASAP so that they can start the initial onsite testing.  Since he didn’t have access to their ticketing system (a point for another article), the developer said he’d handle it.


A full fucking month later, the location still hadn’t been added, despite the constant pestering.  Finally, the developer said that the reason he hasn’t been bothered to work on it is because there wasn’t a delivery date on the ticket… the ticket that he, himself, created.

When asked what he thought ASAP meant, the developer said “it means when I have the time to work on it.  As soon as possible, if I’m working on something else, it’s not possible for me to work on anything else.”


They Are Not Heroes, They Are Not Saviors, Forget What You Know

There is this attitude towards developers that many MBA dickweeds have.  They speak in hushed tones, with an heir of reverence typically reserved for gods.  They heap praise on them with such an ardent fervor that dancing, tongue speaking evangelicals would express concern at their intense devotion and worship.


When someone excitedly says that the developers will be in office, it conjures images of the front doors slowly opening up as a thick fog pours in.  The developers walk in a tight pack in slow motion.  People all around swooning, as their aura (probably from not fucking showering) pours into the lobby.  Kenny Loggins’ Danger Zone plays.  A front-end developer gives finger guns to the security guard.  The security guard isn’t gay, but those finger guns made him feel… funny, in a bi-curious way.  The lead architect removes his knock-off Oakley’s, briefly rubs them against his “JavaScript has no class” t-shirt, and tosses them to the CEO, giving him a knowing nod.  The CEO catches them and instantly starts ugly crying; it was the moment he’d waited his whole life for.


Seriously, the fawning over developers needs to come to an end.  Not just in project management, but in the business world in general.  What we’ve done is elevated people to the point that they’ve become unmanageable.  The better they are, the more unmanageable they become.


How many times has someone sarcastically said, it’ll be done when I tell you, or I’ll get to it when I get to it, and you just have to roll with it, because, well, what the fuck option do you have? 


They’ve become any leader’s worst nightmare.  Try to manage them in a meaningful way and you’ll be met with a dabbling of workplace deviance.  You know, maybe a little intimidation, a dash of showing up late, a healthy dose of taking very long breaks, served on a lovely bed of treating everyone around them like shit.  Don’t manage them at all, and suddenly you have a rogue employee doing whatever the fuck they want, forcing others to make up for any gaps there might be from this one dude refusing to take direction.


Some of my Closest Friends are Developers

I remember watching a documentary about prodigies.  One of the participants was this young girl who was amazingly gifted in music.  Took to the piano at a very young age, could play songs by ear, was able to freely improvise songs that sounded like they were written by a great composer.  At one point I remember one of the interviewees say that on all metrics, that at six-years-old she was easily in the top five of greatest pianists in the world. 


The problem was that she struggled with other things.  She wasn’t very good at math and science, her reading comprehension was low, and because she grew up being told how amazing and talented she was, her social skills also fucking sucked.  These weren’t to the level of being considered a savant (a prodigy is one who has special skills or abilities without any mental disability or low IQ, where as a savant has the skills/abilities while also having a mental disability and/or low IQ), but there still was a noticeable gap between their piano playing and other life-important skills.  She chose to hyper specialize in one skill, which meant being under leveled in others.


This is why I call developers babies with a second grade reading level.  If you met a baby who could read at a second-grade level, you would be pretty impressed, right?  But they are still a baby.


Yes, it’s impressive that a developer can somehow turn words and symbols into an application that can do damn near anything, but they are still acting like babies, and that’s the part that people seem to forget.


A kid I’ve been mentoring for a few years now lost his job early in 2024, because the company he worked for (dealing with IT infrastructure that comes with specialized/custom software), fired the entire PMO, including half of the QA team, because the lead developer was able to convince the executives that they didn’t need project managers, because Agile allowed them to manage themselves.  Further, that without a PM, they could more efficiently work with the infra team, since they would be working directly with them, not as two separate teams.


As I understand it, the experiment lasted a bit over six months, and they hired everyone back (well, at least they recreated the positions). 


Things like this (devs thinking they don’t need a PM to handle aspects of a project, because they don’t need a manager comes up a lot in the discord server) only cause problems within an organization, and honestly, it’s really fucking childish. 


I need to know when this task will be done, so I can let the higher ups know.

                It’ll be done when I tell you it is.

                Uh, no, I need to know so I can tell the project sponsor, who, might I remind you, is the reason you’re getting fucking paid you crusty cashmere jiz sock.


In their 2007 Harvard Business Review article Leading Clever People, Rob Goffee and Gareth Jones discuss the difficulties of managing clever people, when they don’t want to be lead.  They want to be independent, and allowed to do their own thing, pursue their own projects, and so on.  They also say “you must help clever people realize that their cleverness doesn’t mean they can do other things.  They may overestimate their cleverness in other areas…”

I read that, and I think about that pianist prodigy, an absolute genius when it comes to playing the piano, but totally socially inept, due to always being told how great she is.  Then I wonder: is this unfounded idolatry of developers by senior leadership making all of these fuckers think they are “clever.”  Have we created a situation that requires us to follow Rob and Gareth’s lead and understand how to lead these clever people?  Are they overestimating their cleverness because they are demi-gods according to the executives?


Yes… the Answer is Yes

I know that up to now it sounds like I’m talking about tearing down people without talking about building them back up. 


Well, it’s not about tearing people down, for one, and building someone up after tearing them down only seeks to enforce the things that were there when you tore them down.  I hear motivational speakers talk about Kintsugi, the art of breaking pottery and re-fusing it together with gold.  The bowl that was, is the same fucking bowl after you fix it, only it looks better from the outside, but in reality, nothing fucking changed.


What we are talking about is elevating people, elevating their skills, their attitudes, their professional life.  But working with these people is like telling them you want to help them catch the elevator to the third floor, all the while they insist that they are already in the penthouse, but in reality, they are still in the fucking lobby.

You can’t help to elevate someone’s skills to the next level if they have an overinflated opinion of what floor they are already on.  And you know what doesn’t help that overinflated opinion?  When the organizational culture treats these peter-cheeses like the second coming of Shoko Asahara. 


A quick note to all the developers who are becoming defensive, I call bullshit.  I know for a goddamn fact that you are thinking of someone who fits this description perfectly.  For me, his name is Lucas, fuck that guy.  For you it could be anyone.  Chris, that motherfucker who was so full of himself that during planning poker would severely underestimate the story points because “well, everyone says eight, but for me, I’d say it’s only a three.”  And you should be saying, yeah, fuck that guy!


A quicker note for the execs who claim that you’re only wanting to ensure the team knows they are appreciated.  Bullshit.  I know that you’ve all had that one fucker who thought that they knew everything there was to know about everything and derailed a meeting to tell you why what your doing is wrong, even though they didn’t have the full picture.  For me, it was Karrie, fuck that guy girl.


Careful the Things You Say, Children Will Listen.  Careful the Things You Do, Children Will See and Learn.

Yeah, I’m not done calling developers fucking babies.


There are a few things we can do to help mature software engineers.  First off, controlling what we say about them.  To be more specific, don’t say things like “the company’s success is all due to your hard work;” “without your support, we wouldn’t be where we are today;” “you’re the backbone of this company,” etc.  This just reinforces the feelings that they are indispensable.  While it is important to ensure that your employees don’t feel like they are at risk of being fired at any given moment, it’s also important to ensure that they don’t feel like giving their two-weeks notice would cause the company to completely fail, because they are just that important to the organization.


Words have meaning, and if you’re an executive, words hold weight.


Instead, praise the team for large accomplishments, and praise individuals for smaller individual accomplishments.  Drop the hyperbole (leave that to us).  They aren’t the backbone of the company, but their contributions are indispensable.  They aren’t the reason the company is successful, but they do play a vital part in that success. 


Secondly, start insisting that they do their fucking part.


I’ve argued that the reason some developers think they can do their job without a project manager, is because they don’t know what we do.  There are so many little bullshit specialized things that have to be done to ensure that everyone and everything is synced up.  It’s something that you don’t want to pay a developer to do, so you have a PM to handle that shit.  We are there so that others can focus on getting their work done, without being bogged down by updating 20 stakeholders who all need a different report and update.  Some of that BS work the PM does, requires some insight from those who are doing those other jobs.


So many times, though, the concern that we’ll hurt the devs poor ego by insisting that they provide updates, that organizations bend over backwards to keep them happy.  How many of these things sound familiar:

  • Why do we have standup every day, I’m doing the same thing today that I was doing yesterday.

  • I can’t estimate the time it’ll take, because that’s not how agile works, so I’m not even going to try.

  • I’m not going to the solutions meeting, just write the ticket and I’ll message you if I have any questions.

  • Why do we have to be part of the backlog grooming?  Just let the product owner do it, I don’t care what tickets are in the backlog.

  • Sprint retros are a waste of my time.

  • Why am I in so many meetings, you scheduled me for three meetings this week.

  • Sprint planning, more like time wasting… because it’s a waste of time… time wasting planning… you know what I’ll workshop it and get back to you. 

    • Wait, I got it!  More like superfluous planning.  Fuck yeah, got ‘em!


It’s time we stop apologizing for insisting that these annoying baby children take part in the damn process.


Standups are so we can get regular updates, it beats the hell out of the alternative, where you provide updates directly, and then get bombarded by the dumb ass questions that stakeholders always fucking ask.


Solutions meetings, grooming, planning, etc. all require someone to be present that has knowledge outside that of the other participants.  If you’re invited, it’s probably because they need someone with your specific expertise.  Again, this beats the shit out of the alternative, which is total and complete fucking chaos.


Time estimation is something that they just need to accept.  It’s what the client cares about.  There are plenty of models out there that can translate LoE or story points to a time estimate, some of which are built into some of the top software project management applications, we just need the developers to own that model.


Lastly, we need to stop placating these babies every time they get mad because they failed or made a mistake.


Fellow contributor, Josh, tells a story about when he was a QA and had to send tickets back because the acceptance criteria wasn’t met.  Rather than sending the ticket back, however, he was told to write a bug ticket, because that reflected better on the developer.  And they had to do that, because the poor devs were sad that he said they messed up, snarf snarf.

Tell them to stick it up their ass.  Let them be sad.  Let them be mad.  Let them be fucking pissed off.  Not only that but use their mistakes/failures as a way of elevating them, by letting them wallow through their self-hate.


But every time you say, “it’s ok Lucas/Chris/Karrie, we’ll create a bug ticket because you’re such a good boy/girl, and you did everything you were supposed to because you’re PMy’s special little cabbage, and that mean QA was being so mean,” it only moves them closer to believing that they are in the penthouse, when the truth is they are standing in the porte cochere. 

Recent Posts

See All

Commentaires


  • Facebook
  • Twitter
  • LinkedIn

©2021 by Astutely Obtuse. Proudly created with Wix.com

bottom of page