I hate every interaction with our tooling. I loathe our older-than-dirt source control system. I hate our 4+ hour build times from scratch. I can’t stand our “never plan shit” development process. I despise waiting 3+ months to see my changes in prod. I’m baffled by our RTFM onboarding process when the “manual” is some document written at project launch that’s never been updated in the 10 years since.
My current task is simple, took a short time to write my code. But I’ve had so much trouble with tooling that the process of submitting a code review has stretched over a week. At this point, I know what I can do next to fix it, and it would take maybe 20 mins to do. However, I can’t bring myself to even do that.
As cruel as it feels to say, my manager is like some NPC. I am on two teams, one of which I meet with every day who doesn’t understand the work I’m doing for team #2. Team #2 meanwhile consists mostly of people I’ve never met, not even on video calls.
The company is huge and I don’t feel like I can make any impact. My plan at this point is to try and hold out for my 1 year shares to vest and then bounce. Take 6 months to brush up on dev-ops skills and then look for a new line of work.
your company either wants change that you can take action on or thy will let their software rust and become irrelevant
if it’s genuinely upsetting you consider looking for other jobs or unironically just caring less
I made plenty of pitch calls on things we can improve and there’s always some bullshit excuse
I’ve had so much trouble with tooling
Obvious skill issue. /s
I don’t feel like I can make any impact
Assuming you don’t just want to vent, but maybe get some sort of unfounded and useless opinion from a total stranger to go along with your misery, let me oblige. I’ve never been a cog in a truly large company, but I’ve been rubbing shoulders with managers and C-level just barely enough to begin seeing “their side”, and consider it in my interaction with cOwOrkers and management to effectively act as a conduit or translation layer between camps. It’s a metagame you’ll have to want to play, but it can be rewarding to finnagle the systems of human psyche to have a positive impact, not only for yourself.
From a manager’s perspective, everything has a cost. It’s called tech debt for a reason. As long as paying the interest on your tech debt outweighs the perceived cost of paying off the debt, you’re doing the right thing from a business perspective. In addition, be keenly aware of the fact that you personally will impossibly know the huge dark-company iceberg that is the existing tooling and its context. I guarantee you that there’s so much unknown to you, which makes the proposition “I would fix this in a few days, just let me!” seem rightfully preposterous, and thus actively dangerous, as you obviously don’t fathom the full complexity of the larger issue and would necessarily break things for others, despite your best intentions and competence.
Yes, the tooling certainly is utter garbage, and they should never have locked themselves in such a horribly broken situation, but there they are, and you can’t just “fix this” without understanding the implications. Many devs, myself certainly included, easily fall into the trap of seeing an obvious and clear way of fixing everything™ in a matter of minutes, and realizing too late that “just one more patch” is an endless pursuit, all while breaking user-space for others on the way. It’s a meme old as dirt among hackers.
Assume you don’t know all the details, and really nobody does anymore, and you’ll live a happier life if you leave this (business) decision of letting code rot to others. It’s their money they’re wasting.
What you can do, however, is gold-wrapping the pile of shit you need to work with. Find creative ways to wrap byzantine processes into a bunch of scripts for yourself to automate and generalize your tasks specifically, and watch your productivity soar and your mental health rise, and offer that as a working band-aid to your peers and manager. That’s not only a better use of your time than seething over how shitty everything is, but also plays very well into a devops mindset and is actually kind of fun. It also comes across way better than being the “new guy who knows everything better, but actually hasn’t seen nothing, yet”, which leads to people not listening you in the first place. That vibe is an instant turn-off for any lead, and leads to shadow-banning you from interesting, fruitful conversations you seem to look for.
Obviously I’m confabulating all of this, and this may very well not apply to you or your situation at all. This is just a behavioral pattern I’ve seen way too often, and it’s helpful to detect this in oneself to prevent unnecessary frustration all around.
My plan
is possibly your best option. Go ahead. You have no obligations or “loyalty” towards an uncaring entity holding you back.
4h build times… ouch! I’m betting this is Rust or TypeScript.
Actually, C++. An enormous codebase plus we build all dependencies from source. I asked my dev lead why we don’t have access to pre-compiled dependencies and he answered with a mix of embarrassment and “that’s just how it’s done”.
A 4h build would be OK if I only needed to do it once. However, our source control system lacks even a basic conception of branches, so each new ticket requires destroying and regenerating your workspace.
If you want an unsolicited advice:
…
There may be reasons to keep building everything from the ground up (usually reproducible builds and security are presented as such), but there also may be ways to fix build times while adhering to the requirements.
We use Nix for building and binary cache plays nicely with it, but it is also not always too fast, it’s hard to start with, most of our team hates it and wants to replace with something simple (not fruitfully, yet), but it may solve some of the issues.
That is, if you want to solve those, I’m not sure I would if I were in such a situation.
