Wow I haven’t posted in a hot minute. I’ve been really busy; well I was really busy.

I think it’s finally time to talk about this, as embarrassing as this can be to talk about.

I’ll just be upfront; I got let go

About a month ago I was let go from Checkr. Brutal lack of culture fit, poor understandings of what the role meant and while it’s given me a lot I can talk about, talking about it sucks. Despite that, I do want to talk about, it taught me a lot of good lessons, and taught me about what I want to find in work.

The Lessons

These 5 months of employment have taught me more than I ever thought that they might. For a long time I have thought of software engineers, and software developers as mostly the same thing. But, I have learned the hard way that I was wrong about that.

Software engineer vs Software developer

Key distinction here is autonomy, buuuuttt

Big difference is software engineers are expected to take up much more of the business and the slack than their developer counterparts. Those familiar with my resume may be confused by my lack of awareness about this, but my software engineer positions have both been on platform teams, leading to this distorted view I’ve had.

As a dev, your options can be rather limited. Testing may be done by QA, product decisions are owned by product owners, even design is owned by someone else. Your slice as a developer can be very small, just doing the making part and doing none of the decision making. Now I’d argue a great developer is engaged with all groups and helps them make better decisions, but that’s not required. It is however required for engineers, and a history of going above and beyond in my role as a senior developer now just became the floor.

A business focus

One of the things that was a source of some of my contention with my previous manager was me not ending the project sooner, keeping in mind that I did get it done by the time it was expected to be done. I picked up a project from a senior engineer before they were out, and as someone with mostly developer experience, I started diligently working on the jira tickets, communicating what I saw as blockers to those tickets, and trying to multithread work upon being blocked. This was communicated to me as a problem, because I was viewing the project from my role, an engineer to get the predetermined project done, as requested, on time. But instead, it was better to view it from the business’s side.

• How can I complete what the business needs early?
• How could I get a good enough to call it done and then spend the rest of the time cleaning it up but the business was satisfied with the output?
• How could we show the people at the top of engineering the business value?

This is something I’m familiar with doing on my resume, but doing as part of my day to day work totally blindsided me. In the past, not only has that not been my responsability, but when I made strong cases for product changes I was often told that that wasn’t a priority to the business and not my place to be making those decisions, that it was product’s responsability.

Deployment practices & AI

I was going to try to talk about these two in separate sections but they really went hand in hand during my time with Checkr. I’ve got a problem.

I don’t trust code.

I got this attitude at Paycom, where it served me well the whole time I was there. Things have second order effects, sometimes there are counterintuitive outcomes from using a function. This is at the bedrock of my difficulty with AI. I’m used to writing code, cleaning it up, and debugging through it to make sure it was doing what I wanted, and then writing a couple tests.

However in agentic flows, and in the product engineer world, that’s not how you protect your code. Unit tests first, observability, monitor design and dashboards (shoutout datadog). These are how you launch code as a product engineer and how you make sure it’s safe and working correctly.

That scares me a lot. That’s too much trust of code, and a monitoring skillset I frankly lack. How do I trust my results? How do I trust there aren’t hidden problems in my code?

Working with the valley folk

Silicon Valley people are crazy. While I’m sure this is no revolution to anyone in the year of our lord 2026, but it is still worth note, not that it's inherently bad. Holy moly I was not ready. The overtime people worked regularly, the openness and freeness of responsibility at work, the open conversation about how to game the company, and the people who just cared so much about,,, software business. Now it’s not like I don’t care- I have a software blog after all that has like 3 people read it.

But like seriously who broke you???

The Falloff

If you’re still reading at this point reader, I’m rather done with the tech world. I’ve been laid off twice, left a shitty place after a couple years, and been let go. At this point with agentic tools where they are I’m looking to move out of cloud apps / webdev / backend completely. Looking to pivot to embedded or something generally lower down the stack.

If you know anyone in solar or EV technology willing to take on or just chat with a 5-year software dev with a computer engineering degree and an interest in real electronic systems and sustainability, hmu (cbcunningham20@gmail.com)! I’d love to talk during this career pivot.

-Hool

P.S. I’m planning on posting a bit more while I’m unemployed with some very dev projects and some only dev adjacent posts. Look forward to it reader!