Find Your Meaning in Tech: Irene the Developer
INTRO
When there was a project that demanded the attention of executives and those in charge, she was the one that developed it. When drastic changes were made, she was consulted. When a lower-level project required a developer, she was asked who should be involved. Yes, she had made quite a name for herself.
She was:
- loved throughout the organization
- confident
- able to present information to others in a meaningful way
Irene was the dev team.
SUPER DASHBOARD
Recently, she was tasked to work on Super Dashboard, a substantive application. It would allow for executives to think and measure in strategic terms.
Middle management touted this as a transformative product. It was really going to be something. It would draw the praise of the CEO. It would look great on appraisals.
The sacrifices to push this out in a short amount of time would be inconsequential compared to the ripple effects… no… the waves that would be seen from Super Dashboard.
Of course, this was the second iteration of the dashboard. The first one was a flop. It had way too many metrics. Middle management had learned that nobody likes doing data entry… and it’s hard to enforce when they aren’t doing it.
No… this iteration was going to be better. It was simple. Data entry was only needed every few months. Junior managers just had to enter some text, update some colors, and everybody was good.
The dev team agreed. It was so painful to create the first iteration of Super Dashboard. They were ecstatic to appease the middle managers. They put Irene, a dev with no equal, on the job.
They made huge changes to the tech stack. This product, they decided, was going to use modern tools, modern frameworks, modern hardware, and it was going to look great.
The sacrifices to push this out in a short amount of time while learning a new stack would be inconsequential compared to the tsunami that would be known as Super Dashboard.
Within a few months, Irene and the dev team worked at a feverish pace implementing the application in their new stack. It was a painful process, but the product looked fantastic.
The CTO loved it
Middle managers and the CTO declared it a success even before launch. It looked fantastic, it met requirements, and one thing was very clear: Super Dashboard was going to revolutionize the organization.
LAUNCH
Launch went without a hitch. There were bug reports on occasion and the dev team was usually able to release a patch in a matter of days. A couple of new features were added without any problems as well.
The buzz surround Super Dashboard quickly dissipated. The dev team naturally assumed that since the product was awesome, there wasn’t a huge load of feature requests or bug reports.
Things were good. Time for new projects. The team scurried about working on various ideas and applications.
SIX MONTHS LATER
Nobody told the dev team. The new CEO hated Super Dashboard. The company used it for a couple of months, but the results were not worth the CEO’s time. Since junior managers rarely updated it, it was out-of-date and junior managers forgot how to use it.
Fortunately, a new crop of middle managers was on the case. They had a new vision. A better vision. They wanted a dashboard that would allow executives to think and monitor company objectives in big-picture terms.
Middle management evangelized this as a organization reformational product. It was really going to be something. The CEO would truly love this new product.
The sacrifices to push this out in a short amount of time would be inconsequential compared to the enormous benefits that would be seen from Ultra Dashboard.
Of course, this was the third iteration of the dashboard. The first one was a flop. It had way too many metrics. The second one was a flop. It had too few metrics. Middle management had learned that nobody likes doing data entry, but they are going to have to some anyways.
The dev team agreed. It was so painful to create the first and second iterations of Super Dashboard. They were ecstatic to appease the middle managers. And, of course, they put Irene on the job.
YOU KNOW THIS STORY
You have been here before, haven’t you? Don’t be shy. Speak up.
Perhaps, you’ve already decided what this story is trying to convey based on your perspective.
- Non-techie: “They shouldn’t repeat themselves so much”
- Dev Manager: “They shouldn’t change their stack with a short deadline”
- Junior Manager: “Everybody should meet their deadlines for reporting”
- Middle Manager: “They shouldn’t make changes so often”
- Cynical Person: “I bet that CEO couldn’t do better”
You’re not wrong, but this post isn’t about processes, dev stacks, or management philosophies. This post is about you.
Put yourself in Irene’s shoes for a moment. You are a solid developer working in an environment that just forced you to invest a large amount of effort and creativity into building two versions of the same application. Afterwards, they ask you to do it again.
Why
Why
WHY
WHY
WHY
WHY ARE THEY DOING THIS TO YOU? YOU’VE INVESTED SO MUCH INTO SOMETHING THAT IS NEVER GOING TO WORK OUT. COULDN’T YOUR TIME BE SPENT DOING SOMETHING BETTER LIKE COUNTING CEILING TILES.
IT’S OKAY
It sucks. You invested a lot of time and effort, neither of which is worthless. Management should have done a better job and they should have taking better advantage of your abilities.
I really want to tell you:
Management will definitely learn from this. It will get better.
But the reality is:
Management might not learn from this. It might not get better.
Sorry… that’s my trying to comfort you again. Really:
Management probably won’t learn from this. It’s downhill from here.
And how does that make you feel? Pissed off? Upset? Or maybe… just maybe…
…you can make peace with that. Accept that those around you will let you down… frequently. This will allow you to focus on the things you can control.
Let me bring you in on a little secret. You work in the coolest field on the planet. You rig up tools and make computers do really cool things. To the rest of the world, you are a damn magician, a wizard, a computer snake-charmer, a code lion-tamer, and a brilliant technician. We invest our hearts and souls into our code, but we pay a price.
The greatest thing about working in tech is how fast we can build something cool; we suffer in seeing how fast it can be summarily obliterated
Attachment leads to heartache when you lose what you are attached to. Working in tech is uniquely difficult. You may get attached to a code base, a stack, a language, or some other technology. But these are extremely transient and susceptible to change. On one hand you’ll be constantly engaged, but it’s not always when you would chose.
Enjoy making cool stuff. Be prepared to lose it, but laissez les bons temps rouler.
Thanks for reading! If you enjoyed the post, I’d love to know! Reach out on here or on Twitter @dennythecoder.
