So I guess this is now a recurring series called Myth of the Sinking Ship. The name is inspired by the idea in software development that one good developer cannot steer a failing project back on course when it was doomed to fail in the first place, whether it was by the powers that be (management tying up funding, lack of a team, impossible deadlines, growing requirements without limits, etc.), or the personalities that be. The analogy is similar to a master oarsman on a slowly sinking ship, who, no matter how good his oar, how great his strength, simply cannot shovel out enough water faster than it is coming in.
Parts 2 and 3 of this series covered my experiences at a small company (<100 people total) and the glaring red flags that popped up at a certain point in the projects that I contributed to there.
In this chapter of the series, I’ll go a little into the red flags now showing up in a big way at the current company and project. Once again, as I said before, it’s time to find a way off this rock.
The good news in this edition of the corporate circus is that I now have enough experience to “see” when things are going to get ugly. Because of these powers of prophecy (sarcasm? maybe? who knows) I smell the bs hundreds of miles away now instead of opening my front door and seeing it on the welcome mat. I have more runway to escape than I ever have before due to what I know now about how projects are managed at this company and how these scenarios play out.
It’s been nearly 5 years since I started working as a software engineer professionally, and I’ve got enough experience (and bag of tricks) now to leverage myself as a competent mid to senior level engineer. Hell, I’ve hardly written any code at work for the past 3 months. My time has been divided between:
- Helping senior engineers troubleshoot and designing multiple possible solutions to their problems, partially because I’m fearing becoming obsolete as a developer, and partially because I’m frustrated that people who are senior in title to me cannot grasp Google well enough to find answers to their problems and come up with solutions.
- Mentoring junior developers on coding standards and best practices (effectively, the big no-no’s of writing code in an enterprise environment)
- Delivering completely ad-hoc on-the-fly reporting data and application analysis to my feature lead (at this point, in title only. He’s never had this type of role before and every 15-min call I have with him is a 45-min long panic attack from him about management)
- Uncovering the skeletons in the closet (recall my old post about the Winchester Mystery House diarrhea detective work) in this new project I was assigned to. To give you some idea of what’s going on:
- The application is for all intents and purposes, legacy. Uses outdated and vulnerable frameworks and libraries. Running on old servers with poorly designed technology. The majority of the codebase was justified to me with the literal rationale of “because we had to.”. Fair. But if you’re gonna be like that, then at least dedicate some time, any time, to cleaning up your messes. A sloppy janitor only works for a day, after all.
- Before I joined it, the way the work was done was by a single engineer who heroed through every single request sent his way from every direction, every team that asked for anything, he was the SME and point of knowledge for everything in the project. In software we call this tribal knowledge, and it’s a sign of very bad things to come. If Joe Blow suddenly ups and outs from the project, no one else has any idea of what really went on under the hood. This is the current predicament, funnily enough (but I can’t even laugh at my own schadenfreude today).
- A spread of junior developers on the team, who are literally less than a year into their careers post-college. One of them is somewhat competent in a very narrow capacity, the rest are requiring a lot of mentoring and education on the application they’ve been a part of for the past year WHICH I ONLY JOINED 3 WEEKS AGO. Imagine that, someone new comes into your project and in 3 weeks of digging through your disgusting spaghetti, is able to provide answers to questions from the rest of the team WITHOUT CONTEXT.
…
Anyways I’m starting to rant now, lol. Enough talk of the present monkey freak circus. The next logical question you might ask after reading the drivel above is: So what are you gonna do about it?
Well my friends, I am not a superhero coder anymore. I operated like that in my first job out of college, if you recall, and it did a big number on my mental and physical health. These days I do my job, only my job, and that’s it. When that starts to bleed into my personal time, it’s time to step back and analyse wtf the point is of work.
So as the series suggests, I am finding a way off this rock. I’ve spent the last 2 weeks heavily coding in a new language to prepare for interviews. I’m putting in 3 hours a day after work to reteach myself Java, but this time for the enterprise world. My background with Java goes back to 2008 and the days of Java 6. Back then, I coded mostly for fun and school projects. I had no serious aspirations of returning to the language when I picked up C/C++ in college, nor did I think I’d go back to it for the past 5 years, as I’ve mainly been a C#/.NET Core head. But like all great programmers before me, I must continue to be language-agnostic and start looking at languages as tools to solve a problem. Not everything is a nail to be hammered, and the approach to problem solving has to be well-tuned. Pick the right tool for the job and nothing more.
That said, Spring Boot seems to be the API framework of choice these days in Java. I’ve been following https://spring.io/guides/tutorials/rest/ to get a general understanding of the pieces and how they all fit together. It’s a lot of work for someone who (in all honesty) does not burn the midnight oil studying programming nonstop everyday. What I did at work for this company was generally enough to satisfy that itch, and after fighting for 8 hours a day through red tape, approvals, back-and-forth emails about bureaucratic processes (all necessary evils of the job I admit), and finally 1-2 hours of focused coding, I’m no longer scratching that coding itch at work. So I must do it outside of work, for better or worse.
I see this as a net positive. If I don’t get the job I want somewhere else, I’ll at the very least have learned something NEW and TRANSFERRABLE that I can take with me to the next place.
That’s about all I can muster for now. If life throws me any significant updates, I’ll broadcast that here.
Over and out.
The Life and Times 