5 Things That Killed Software Development for Me
The year was 2013 and I had just graduated from college. And I was already employed when that happened, so I was living the dream of a fresh graduate. After all, I’ve been hearing this for the last 4 years. Go out, graduate, and get a job. This is the dream, right?
Well, for a good chunk of my life, it sort of was. Only in time did I realize that it wasn’t my dream though.
I’ve been involved in music, mostly playing instruments, ever since I was like 4 years old. I started playing the piano in 1994 and some years later I moved on to guitar. And while I may not be the best player out there, this was the only domain I was actually invested in getting better.
Until of course, I went to college and I started doing the so-called “right” thing. Get a degree, get a job, and become responsible or whatever. And for the first 2–3 months, when I was involved in the training programs at the company I was working for, it was really great. But everything changed when I realized two things. I didn’t know it really well back then, but I do now.
After the first 3 months, when I finally landed in a team on a real project, I realized that my views about software development were so skewed they could have been an abstract art painting that made me the necessary cash to buy the company I was working for back then.
You see, after 4 years of college where everyone told me how I’d change the world once I am done by actually building something really cool using code, I started working in a team and the programming aspect was like an after-thought. Everything was about this Agile process, which according to one of its creators, should be abandoned. So before you go about saying I’m talking nonsense, there it is from the creator’s mouth.
And yeah, he is referring to how Agile is implemented in most companies, and in all honesty, that process sucks. Agile in principle is not a bad thing. Its implementations though…you know what, I’ll go about that in another post.
As I was saying, everything was about these dumbass rules that no one really knew how to implement properly. And on which we’d spent literal hours, missing our lunch breaks, just to discuss if a story should be valued at 3 points instead of 5. I mean…what…what was the purpose of all of this? In the time it took to dissect how many XP points we gain after that side mission is done, we’d have finished the bloody thing…
Over the years, I came across many things that slowly but surely killed my desire to be a software developer. I still stand by the fact that developing software is a really cool thing, but not how it’s done in companies. Not by a long shot.
Anyhow, let’s go over the 5 things I mentioned in the title:
1. Too much emphasis on the cult that is the company philosophy/values
Sweet Doom Slayer, is this thing insanity. And I mean insanity, in the purest of forms. Each and every time I had an issue in my first company, the default answer was: “well, we should see this as a challenge we need to overcome”. I’m like, no, no, this is not how any of this works.
I am feeling frustrated in this bloody project because I ain’t got no information, the client doesn’t know what he wants, and you expect me to finish developing something no one knows anything about. Of course, the next line would be something pertaining to some random company value like being kind, be with a smile, be an obedient slave, or whatever. Because Heaven forbid you showed any actual emotions there. Just swallow it up, I’m sure there isn’t any supervillain that was formed this way because he couldn’t manage his dark side and when he snapped, he was always between two distinct personalities.
I think the peak insanity I’ve experienced in regard to this was years later down the road when I had not one, not two, but 5 people tell me something needed to be done. I had an email, then the email sender told me again after I already replied knowing it had to be done, then my manager (who was in the reply) told me again, then another colleague, and then finally at the 5th one I snapped and told them that I knew I had to do it and I already had 4 other mentions of this.
Then the talking to came and my manager said something that we should always try to make other people’s day better because they might be having a hard day at work. Oh yeah? They’re having a bad day and feeling bad? What about my day? What about how I feel? Are the other people trying to make my day better? Shh, you’re not being kind to them. Try smiling more and being in love with the company more. It doesn’t matter that you are reliable and working smart…
2. The broken Agile methodology implementation
I’ve gone over this in some previous paragraphs, but man is this implementation broken. And that’s because people cherry-pick what they’re implementing and they give way, way too much power to the client.
It never failed to impress me, in a negative way, how broken the system is. Mostly because managers are gutless and can’t tell the client: “listen, you can’t just change the scope of the sprint in the middle of it and expect us to finish it”. No, instead they’re like: “hey, can you add this to your already loaded schedule?”. You could try to say no, which I did, of course, because I’m not going to be responsible for something I didn’t account for. That’s on you, my dear incompetent managers. That’s…on…you.
And don’t even get me started on the hours and hours wasted in sprint planning meetings, which shouldn’t really take more than 2, 3 at the very most. But since people are busy dilly-dallying and wasting even more time in other meetings, of course those responsible to plan ahead aren’t doing their job. May the Maykrs have mercy on your soul if you tell them that though.
3. Too many frameworks (or framework fatigue)
The only people that annoy me more than Agile apologetics are JS framework apologetics. There is absolutely no need for this big of an amount of JS frameworks that essentially do the same thing but in a different manner. There was even this joke, which rings true:
And some of you might say: “Well, sure, there are many, but just choose one and go with it”. That’s an option, of course, leaving aside the fact that each and every framework gets outdated after like 6 months. Well, not outdated, but a new version comes out every 6 months for some frameworks and there’s a very good chance the framework version you’re on will move out of LTS in about 1–2 years so, guess what, you’ll have to do version upgrades whether you like it or not. And we all know how those go…
And the second problem with the pick one and go with it mentality ties in with the next problem.
4. The incredibly incompetent people that are part of the hiring process
So, remember how I said that picking a framework or language and sticking with it is a bad idea? Well here’s where that kicks in. Say you are an Angular developer and you want to change workplaces. But there aren’t many openings for Angular devs. And you’re like: “oh, ok, I guess I can go and learn ReactJS or VueJS or whatever, then I can apply”.
So you do that, thinking it will work until you’re rejected at the HR phase because “yOu DoN’t HaVe EnOuGh ExPeRiEnCe”. You could try to explain to them that the learning curve isn’t going to be that big since they’re basically the same thing, sort of, but with a different syntax. And you might get lucky in some places.
And that luck will quickly turn into a nightmare when you’re greeted with a useless algorithm coding challenge, which will require you to use some concepts that you have last used in college and will never…ever…ever use again.
I am an advocate of dropping certain challenges or at least not having them by eliminatory but…apparently, I am in the minority.
And finally, there is also this:
To all companies that do this. Do us all a favor and bugger off out of here with that.
5. There is no closure and people fake who they are
I’ve had managers parrot a certain line too long. And that line is “work never ends”. But why? Well, an easy answer is that you gotta upgrade your framework version every time a new one comes out in order to remain relevant and you know, have your app still working.
There seems to be no end to the projects you’re working on. People just drag on and on and keep on adding stuff to it to the point where it just becomes an unmaintainable mess. And I think to me, the sense of not knowing when something will end is the worst part. It’s like I have to become a hamster on a wheel. And I’ll be damned if I’m going to do that.
Also, people have to fake emotions way too much in this domain. No sensible human being’s reaction to being belittled by a client is to say “thank you”. This isn’t Hell’s Kitchen, and that is a bloody show where Gordon Ramsay screams for ratings…and because the chefs serve raw food but, you know.
In the end, I will always defend actual software development as a wonderful job. Not everyone can do it and not everyone should. Wonder who shouldn’t do it? All the companies that fall under any of the 5 points in this article
