6 min read

On Realizing You've Made a Huge Mistake

I’ve worked for several large companies, and with the exception of one, I’ve hated them all. I’d get to a point fairly quickly with each of these companies where I dreaded going in, even logging in.

Why can’t I get along with people? Why can’t they get along with me?

I’ve made a huge mistake.

So, here is an unordered list of things that I absolutely can’t stand. Of course, these attitudes/behaviors/mentalities can be found at companies of any size, but they seem to flourish in large environments.

  • Not caring to address technical debt

    Is technical debt an indication of a bad place to work? Of course not! And, like most answers, it depends. Is the company a startup that is just cranking out code to get the product to a working release? Is it a very specialized area of the codebase? These probably aren’t reasons to be concerned, and most startups have plans to go back and clean up the technical debt that was always going to be incurred at the beginning of the project.

    However, it’s probably a problem if the code is years old, and there never seems to be time in the “sprint” to fix it (if working in an Agile environment). And it’s definitely a problem if, when mentioned, it’s derided as not providing any “value” to the customer.

    Part of me expects this kind of asinine comment from a certain type of manager, but not from a fellow programmer. As programmers, our domain area is the code. We are its advocate. Others in the organization advocate for different things, as they’re supposed to. So when programmers align themselves with other interests, ones that are usually at odds with ours, it’s very disconcerting.

    On a side note, if you’ve attempted to address technical debt on your own as you come across it and you’re told in no uncertain terms that it’s not appreciated and/or a “distraction” for the rest of the team, it’s over, time to move on.

    This is related to…

  • Nothing matters except providing value to the customer

    You believe in the project you’re building and working on? That’s great! But you also need to be concerned about the quality of the code, its maintainability, security, et al. No one else in the organization necessarily cares about this, but you do, or at least you’re supposed to.

    If you think something is important but are told that it wouldn’t provide any “value” to the customer, that’s a red flag that shouldn’t be ignored. Especially if it comes from a fellow programmer.

    Features are great. Everyone loves them, and nothing fulfills the promise of technology to uplift and help people like a shiny new feature that makes buying some tchotchke even easier. However, if this world-altering feature request would be infeasible because of the state of the codebase, it is part of our job as programmers to temper insane expectations with reality. We need to be a voice of reason in the room that will speak honestly about the concerns.

    Of course, you’ll end up doing it anyway, because capitalism, and in so doing will add to the already insurmountable amount of technical debt, but you’ll be earning that salary by telling people what they don’t want to hear.

    And that feels good, doesn’t it? Not bitching about stuff on the side but addressing it head on?

    And let’s talk about the reality of this kind of rudderless direction. It will lead, if it hasn’t already, to an increased time to add simple features to the product, an increased fragility of the code, and an increase in the number of bugs, including severe ones.

    Now, that’s “value”!

  • Programmers that assume you’re an idiot

    You’re directed to ask your question in a public channel, because that’s where all the “experts” are. You ask your question, usually after you’ve spent a not-inconsiderable amount of time on it, and you receive a dismissive “have you tried turning it off and on again?" response. Depending on the context, perhaps it could be warranted, but usually it’s not and is a reflection on the individual.

    But if you’re unlucky, it becomes something you expect, and you get this curt and reflexive response from more than one person. Chances are, then, that it’s endemic to the environment, and it comes from the top down.

    Sorry, but it looks like you’ve made a huge mistake.

    Of course, these painful digital communications can easily be sidestepped by directly contacting the “experts” or having a quick call with them. Unless, of course, you work in an environment where the manager(s) want all communications to happen in a public forum so everyone can be a “part of” the discussion.

    But you and I know the truth about that.

  • Programmers that are bothered by PRs that aren’t in the sprint

    I’ve had programmers tell me that they don’t like when I submit PRs on things that haven’t been addressed in the sprint. Of course, there are legitimate reasons to object to this, such as having the changes on an unrelated PR, or that it’s so big that it becomes a time investment for someone else, or that it’s distracting me from the planned issues on which I’m supposed to be working.

    If none of those situations are true, though, it makes no sense to me to object to these types of fixes. And my usual response is, so what? I’m fixing something and improving the codebase. Of course, that’s absolutely the wrong response for the situation, which makes it absolutely the right response for the situation.

    A common suggestion has been to create another ticket and put it in the backlog. But, on this team, the backlog is where tickets go to die.

    These kinds of quick fixes are usually related to technical debt, and I’ve worked on teams where a significant dent has been made in the amount of tech debt by simply chipping away at it like this. For example, if it’s in the same file or module as the one you’re working in, fix it and be a good citizen.

    So, why is this seen as a problem on some teams? I’m not even sure The Shadow knows the answer to that one!

  • They’re serious about Agile

    There’s a scrum master with Post-It notes. There are several meetings during the week that culminate with something called a Retrospective. All your natural human instincts in your DNA cultivated over millions of years instructs you to laugh, but a quick look at the faces around the room tells you that this is all Very Serious Stuff.

    Of course, everyone I’ve ever talked to hates Agile. Some still cling to the idea that it’s a great methodology, but it’s just that no one is doing it right.

    Sadly, no one at your company feels this way, and so every day you have a Standup where no one listens to anyone else and everyone stares dumbly at their tracking device. If you’re really unlucky, some Serious Person will bring up an Action Item and the next thing you know you’re out in the Parking Lot.

Goateed Manager: We can’t find good programmers!

Good programmers: I hate to tell you this boss, but the reason you can’t find us isn’t because we’re scared away by the quality of your codebase and the quality of your programmers.

If you don’t agree, leave a comment below! I l{o,i}ve to hear your opinions!