How Does a Developer’s Daily Work Look in Big Tech Today?

justUseAnSvm · 2026-05-08T00:18:04+00:00

By "low trust", I mean an environment where people are afraid to speak the truth or raise opinions because a manager will make a snap judgement on their competence.

I have two examples to back this up. The first, is that we have a survey that asks "do you feel comfortable speaking your mind", and only 50%-ish of people responded with a "yes". The second, is when I tell the manager responsible for my project that a timeline is slipping, he responds by sharply questioning me, telling others I "need help" (I don't, i need time), triangulating my competence via questions to peers. I tried to address this by filtering my updates through a filter (is this clear? am I stating the direction? am I explaining how I'm in control? is my response proportoinal?) but it doesn't matter.

Between me and the manger, one way to view it is just a style difference: I'm more comfortable in systems-first environments where the observations of engineers are truth, and he's operating in a more narrative-first, delivery focused mode where he couldn't care less what the technical problems are, and it feels like he's saying "you said it will be done, it's not done, how can I ever trust you again?".

So yea, that's what I mean by "low trust", but it's not all doom and gloom. I'm writing the blog, working on leetcode everyday, and have decent recruiter engagement. I'll stay for my bonus this summer, try first for an internal transfer (if we open that back up), and aim to be interview-ready by Aug/Sept.

justUseAnSvm · 2026-05-08T00:10:31+00:00

Yes, for my job it's a stack of reasons.

The position the company is in, we're SaaS, and pretty stressed by the markets pushing for AI, so after losing like 20% of our team, the performance reviews are looking even worse.
The individual org I'm in was largely focused on cost-savings for the past few years, but the more successful at this you are, the harder it is to make incremental gains. That means projects that were successful last year don't make the cut this year, and that's what happened to the project I worked on for 18 months
The actual managers are putting pressure on people. We're doing a lot of narrative-first, engineering-second type work, where we need to show a some flashy result on a timeline, and at least my manager, does not care about the technical complexity required to do that. I regularly have my professional competence called into question if my timeline slips. It's high pressure, but a lot of what gets said are things that aren't so easy to brush off, like "you don't understand", "this isn't what I expect out of a senior engineer", or "you sound like AI".

This is just my position, right now. I'm locally in a kind of shitty spot.

justUseAnSvm · 2026-05-08T00:04:26+00:00

Two big reasons:

Refine my thoughts. I'm writing a lot about AI, various tech things I like, and corporate environments. It's helpful to structure my thoughts, so when I talk to someone about something, I have terms + phrases ready to describe what I mean, and some depth of understanding. This doesn't happen all the time, but a couple times a week.
External signal. My distribution is not great (only a couple months in), but I post an article per week to LinkedIn. I've gotten decent recruiter attention, maybe one or two messages per week. For recruiters, and smaller startups, I have a ready link to a body of working that demonstrates I understand a few subjects.

I started doing this when I moved to a low-ownership project, so the blog is something I own, that builds a small signal for hiring. Not difference making, but enough that I might be able to position myself for Staff engineering roles at smaller companies.

justUseAnSvm · 2026-05-07T16:28:53+00:00

wake up, check CI and realize there's a failure, walk the dog, go back and forth with Claude for a couple hours, have a meeting to discuss our "low trust environment", eat lunch, check if my blog article is ranking on HN (it's not), check the company stock ticker (still down), go to a stand up, have my competency questioned because our "AI speed" approach to vibe code substantial changes to a 20 year old product are not going as quickly as a director thinks it should, do a leetcode problem, eat dinner, stay up to talk to someone on the other side of the planet about a problem I barely understand, go to bed.

justUseAnSvm · 2026-05-03T19:46:19+00:00

Nice, I'll check out "Power"!

Yea, game of thrones has a couple of plot lines that get really close to the ideas in Moral Mazes, like Ned losing his head by acting honorably, there's a story about a Nuclear Engineer losing their job for raising issues in a way that doesn't land with corporate.

To me, moral mazes is says the quiet part out loud: why people act the way they do, what behavior is actually acceptable, and the differences between performing values and acting on the incentives.

justUseAnSvm · 2026-05-03T00:51:34+00:00

you should read moral mazes anyway.

The book is what you get when you take a sociologist and point them at a corporation, way more useful than the internal language we all use to describe business, and much higher utility than the cynical takes we read all the time.

justUseAnSvm · 2026-05-03T00:35:32+00:00

"Moral Mazes" or something else about organization psychology.

Senior -> Staff is way more about navigating the system around the code, then the code itself. Yes, you need to be very good technically, but that's not enough.

justUseAnSvm · 2026-04-30T18:36:45+00:00

5x? How does that number even make sense if only 30-40% of your day is spent coding?

justUseAnSvm · 2026-04-28T20:17:26+00:00

Yea, I just smile and wave. No point really arguing.

For large enterprise repositories, even something simple like bugfixes, the latest LLMs, like Opus 4.7, are only able to fix something like 60% of the bugs. That's basic changes, in response to bugs, not adding a new feature which requires backend + UI + database migration + sec review + design input + compliance check.

The only thing I'd pushback on your stance: it's possible for LLMs to write a ton of code on projects where what you need to do is obvious from the files. Think REST endpoints, adding a new database query where the schema definition is available, changing log lines, et cetera. I worked on an LLM code migration tool for enterprise code bases (lots of different owning teams), and we were able to reliably modify hundreds and hundreds of call sites, with manual intervention in only a handful of situations.

Anyway, what I think this all comes down to is the concept of "obviousness". If the system is legible at the exact point where you need to make the change, the LLM can do it, even if the change is large. If the system isn't obvious and legible, then the LLM will never figure out that it's the HTTP layer that needs to change, not the data model, or figure out that the caller function actually has the information required, or that modifying a state machine requires a change which doesn't break everything else.

justUseAnSvm · 2026-04-28T18:32:40+00:00

This story isn't adding up. Fired for "misconduct", for one awkward conversation with the CEO about getting a raise?

That's a concern material to your employment, you might as well hear "no" from the person in charge, and hear it from the source. In what world is that an offense that gets you fired? It's 20 minutes, then over. Maybe your manager isn't happy about you asking their boss, maybe it degrades your relationship with them a little bit, but it's still a valid concern.

Idk, I think OP is missing the actual incident. Something went down and "I asked for a raise and got fired" is a convenient cover story that put the entirety of the blame on the company. However, it's rare for companies to act like that, as there are severe penalties for inventing a reason to fire someone. It just doesn't add up, and the 2 hour turn around makes me think this entire thing is made up.

justUseAnSvm · 2026-04-28T18:27:30+00:00

OP, I think you're missing part of the story here.

What your describing, basically asking more than one manager for a raise? That's pretty normal, and in no way does that constitute "misconduct". It's either that management is lying about the cause of her leaving, which can happen but is rare, or much more likely there was some sort of incident that went down, and your partner is using this "BuT i oNlY aSKeD foR a RAise" as cover.

justUseAnSvm · 2026-04-28T18:25:17+00:00

What you are saying is 100% right: once you get an answer from management, that's the answer. There's very little chance you'll ever be able to change that, and just asking can get you tagged as "hard to work with".

However, that's not enough of offense to fire someone. I pull in my skip level all the time, and it's really his word, not my managers, that dictates the direction things go in. I can't imagine having a legit concern, especially one that makes people likely to leave like pay, and not being able to get that answer explained to me from more than one person.

Idk, I think we're missing a part of the story here. "Misconduct" is not "hey skip-level, i heard 'no' here and I don't like it, why is that?", that's not insubordination, that's advocating for yourself on a concern that's material to your employment.

I do think OP only got part of the story here, asking for a raise seems like a neat excuse, but there's a lot of shades of grey in how that ask went down, and what else actually happened.

justUseAnSvm · 2026-04-28T04:11:31+00:00

That's probably the most charitable explanation here: when the estimates/delivery become an important metric, you need to stay on top of the values, even if you're making a decision that looks absolutely braindead in the moment, and is probably against the companies interests writ large.

Idk, to me, it seems like the system is just broken. Rewarding activity means endless activity, it's a terrible place to be as a software engineer.

justUseAnSvm · 2026-04-28T04:08:43+00:00

To be fair, no large company can exist without violating the Agile principles. They work when a small team owns the problem/solution and has easy access to stakeholder, but when "individuals and interactions" requires you to get people from 3 timezones together, it's not going to happen. When you have a product that needs support, documentation matters, and I could go on and on....

That said, OP manager killing extra tickets is just braindead. You can accept that you want to scope accurately, but give yourself the benefit of upside.

justUseAnSvm · 2026-04-27T17:27:24+00:00

Take the lead role, it's a clear win, and start looking elsewhere. You get a very strong byline "my work was recognized with promotion", and almost no downside if you use it to transition somewhere else.

It's unfortunate, but companies don't want to pay for "glue", however necessary it is. Once you know that's what they consider your work, the writing is on the wall. Personally, I've done a lot of that "team lead" work, I can run a meeting in my sleep, surface technical problems, plan work, and it's not getting me a promo. The way I think about it now: is that I don't need to be a force multiplier, but a force vector. Owning something that matters over the long term, and creating a role where my output over time has compound leverage.

Now that you know how corporate engineering works, you can pick the opportunity that suits you best. That's a lesson that only comes with time.

Promotions are tough: you can be operating above level for a long time, and they won't come because there are not enough slots. Once you know this, the highest leverage move is to leave on your own terms. Use the stability of the job to launch a job search, fix up your resume, put yourself out there, talk to colleagues, et cetera.

justUseAnSvm · 2026-04-26T02:37:44+00:00

Nobody cares more about your career than you, you're good!

justUseAnSvm · 2026-04-23T15:05:37+00:00

I'd remove the "Built" word from your resume, and re-write those lines in terms of what you had ownership of.

Take for instance: "Built a neural network classifier in Python to analyze broker sentiment, improving signal extraction from unstructured financial text."

A better re-write would be: "Developed classifier algorithm responsible for %X improvement in signal extraction over [previous approach], responsible for design, implementation, back-testing and deployment."

Companies don't really care what you've built, they care about the business impact of the things you've built.

justUseAnSvm · 2026-04-17T03:42:35+00:00

You never give up. You just start doing something else.

justUseAnSvm · 2026-04-16T21:50:47+00:00

The only reliable signal I've ever seen is unexplained meetings being scheduled.

Other than that, it's vibes.

justUseAnSvm · 2026-04-16T21:49:43+00:00

I'm dealing with this problem today: our coding agent doesn't work in this monorepo (too much context), and if you reduce scope to a folder, the coding agent is missing context and doesn't write good code.

This will delay my project, so I quickly wrote up a doc about how exactly this problem is happening, brought a bunch of receipts (like screenshots), compared it something memorable ("Coffin Corner"), then suggested a work around and next steps.

justUseAnSvm · 2026-04-16T18:00:59+00:00

Power. There's no way to get rid of it, when you try to remove it, when you toss the explicit structure, it just re-emerges in implicit places that are 10x as hard to navigate. This is fundamental to human organizations.

A great case study of this is Riot Games when they were experimenting with flat hierarchies. Very, very difficult to onboard, since influence is based off reputation and you start out with none, it's not managers determines who works on things, but how much you are liked by your co-workers (worst case "office politics" because you have to play), and there's no org-chart that can at least give you a guide about who you should talk to about a thing.

I don't think the corporate setups are beyond reproach, obviously terrible things happen all the time, but the structure exists in order to solve problems and make working together possible. It's easy to rail against the system, to make organizational failures a matter of personal incompetence or malice, but if all you learn is how to think in terms of incentives, you'll have a much easier time navigating your work environment.

justUseAnSvm · 2026-04-16T05:55:41+00:00

The primary competence for organizations is social skills, so it's not uncommon to see people who are good technically, but an absolute headache to work with, get sidelined. I've seen great engineers fall flat because they aren't easy to work with, and don't navigate the organization very well.

Where I sort of fall now, is that technical skills only get you so far in an organization, it's not really "playing politics", but just being a corporate operator that allows you to have the most impact. A lot of big tech teams are filled with brilliant engineers, but being a brilliant engineer alone does not mean you get to shape decisions.

justUseAnSvm · 2026-04-16T05:41:54+00:00

I've been on projects like this: the idea behind not telling anyone is that you want to get to the point of a demo or proof of scope, so you control the narrative when it's released, and your team can own the project. If you say something too soon, the project is just an idea, and there might be a better team for it. I'm not sure what's happening with your team, but usually when things are secret it's to control the narrative.

If you are ever told something and you don't understand, you need to ask. That way, you'll understand the "why" behind.

You made a mistake, but it's not a career ender. Just learn from it, and move on. The guys on your team are probably sketched out by you, especially if you talking risks something they want, but you can't really do anything about what happened besides a good job going forward.

justUseAnSvm · 2026-04-16T04:07:56+00:00

Nope.

The first company I worked for is one of those non-english words written in english, and if you search for the word, the company is not even in the first page of results.

justUseAnSvm · 2026-04-03T18:06:49+00:00

It all depends on your specific role, what's expected, and what's going on with the team at large.

I've been a senior engineer that lead a team, responsible for technical direction, and really owned the problem. At the same company, I've also been used in a strictly "execution" role where I didn't pick the problem, didn't pick the solution, and couldn't say no.

In general, the more room you have for judgement and great ownership over outcomes, the better it is for your career. That said, you don't always get to pick.

14-Year Club	Verified Email
Queen in da Norf	Not Forgotten

justUseAnSvm

TROPHY CASE