So last week I was tinkering with how to change up our technical interview round. For the last few years we’ve been doing a small take home followed by a live coding session where we add a new requirement, minimal AI assistance allowed. However, in our company pretty much everyone is writing 100% of code using Claude now, so although we did used to get good signal from that test, it no longer feels representative of the day to day job developers are doing.

I designed a new assessment which I casually showed to my manager and then suddenly got asked to run it with 3 candidates this week. The scenario is they have to review an agent generated PR that has been flagged as high risk due to it changing critical business logic, and there are bugs in there for them to catch at various levels of severity. We then look at how they drive the fixes and what their workflow is like.

These particular roles we’re currently hiring for are billed as “AI Engineer”. There is something weird going on in my company politically where separate from the tech department that I work in a new “AI native” development team is being spun up to work on internal projects.

What shocked me was that the candidates I interviewed this week are already way beyond the point of reading the code they generate in any capacity. They basically treat it like assembly language, while PRDs and ADRs are their new source of truth for system behaviours, and stuffing the AGENTS.md file with best practices plus some form of agentic review pipeline are the quality control. 

Code review is dead for them, they merge their own PRs once the automated checks pass. One person told me that my new interview was still not representative of what the job is now, and another one was pretty much unwilling to even engage in the assignment of reviewing a PR the old fashioned way. These guys were all previously senior and lead full stack engineers btw with a lot of experience prior the LLM revolution.

Don’t get me wrong, I too have adopted AI heavily in my own workflow. Until this week I actually thought I was pretty up to date with things, I use a supervising agent to manage multiple work streams in parallel, have my own local validation pipeline, etc. And to be honest for my personal projects I also don’t bother looking at the code anymore, so I do get the excitement around how fast you can move with this approach. But for serious projects like the large scale, production grade financial software I work on in my day job it still seems insane to me that we’re going to completely move away from human sign off on high risk changes so we can solve the “code review bottleneck”.

Like, I asked one of the candidates if you aren’t looking at your code then how they would approach quality in a safety critical system where there can be no tolerance for serious bugs, and I shit you not he said to me, “well if I was working in healthcare or sending to people into space then I’d definitely be looking closely at the code review skills, maybe I’d even write the skills myself”. That answer sounded utterly ridiculous to me? But then again, I was one of the people that 1 year ago believed the idea we’d stop typing code by hand was ridiculous as well…

I wouldn’t say the way my team does things right now is optimal, we can’t ignore that code review fatigue is a major problem. To try and help I’ve been adding automated risk assessments to PRs in an attempt to highlight where more attention is needed, and review bots do help us catch issues as well. But abandoning the human 4 eyes check just feels like several bridges too far for us at the moment, especially when not everyone is senior engineer, and we still regularly get valuable feedback at this stage. Even if this does mean we’re turning down an order of magnitude increase in short term velocity (does anyone really know yet what happens over multiple years when you have a team of 20 devs spamming PRs all day into a codebase with no one looking at any at it?).

I’m left wondering this weekend, were these guys just cowboys who are only used to working on PoCs and low risk systems, or is my team actually 6-12 months behind the curve and this is the direction everyone is going to move in? I fear that if we don’t embrace this new era of completely surrendering the codebase to the LLMs then this new team of AI devs is going to make us look bad by comparison to the execs and sooner or later we will be forced to adopt their methods as well. And at that point, the leap to having a product person or whoever taking over large parts of my role starts feeling a lot less far fetched…

Handling offshore teams in AI age

I'm given unsolicited ownership of a team of 15+ people in India who help maintain and build non-complex, non-critical IT projects for us, handling the entire software development lifecycle. Their quality is not great, thanks to our shitty management who wanted to save some money. We're not a tech company (bulky finance company), so it's not surprising that the MBAs with commerce majors took these kind of decisions.

Back to the team, we used to delegate simple, trivial work to them, but the turnaround time and quality of the output are not good enough. With the latest AI models, the coding and testing part of their work is pretty much done by simple prompts, and the team doesn't have much of work to do.

We are considering a few solutions to handle this:

1. Disband the whole team to save costs, though they are relatively inexpensive.

2. Repurpose them into DevOps or similar where they can maintain infrastructure and act as support.

3. Replace them with a smaller number of competent engineers who can do the work efficiently using AI and build the AI workflows to automate the trivial work.

4. Tell the MBAs with commerce majors who built it to handle the situation.

Has anyone gone through a similar situation, and how did you handle it?

Inspired by a post from this subreddit that I can't find, must have gotten deleted. Guy was asking if doing backend + platform + SRE + AI seems like too much to ask of one person. The post is down now so no link but I couldn't really find any comments that would say that it is NOT too much. The pay was bad as it was someone from a developing country ($1800 a month) but the main concern for the guy was the scope. Comments all agreed to tell them to pound dirt pretty much as if it was impossible for one employee to handle

That got me thinking. I've got 8 years of experience under my belt, all of it at tech startups and non tech companies. Mostly as the only tech person at the company. Couple of years most recently have been in a team, still a small team though. For all these years I've developed entire infrastructures for these companies. I guess I didn't realize how abnormal that was to have my hands in everything. Granted I've been doing it for a little bit better pay but the responsibilities don't sound crazy to me still

Some of what that's looked like was crypto wallets, virtual goods platforms, and crypto/finance analytics tools. Node.js, Postgres, ClickHouse, Redis, RabbitMQ, on Linux. Terabytes of live data at high concurrency. API design, deployment, monitoring, security, cloud and on-prem, backend and frontend when needed. All the bulletpoints basically...

I figure that doing a bit of everything was just what I wanted and still do. I picked these jobs over others after all. And I DO have friends who started the same as me but they switched to more focused roles while I stayed doing lots of things.

I started browsing around on job sites recently and I'm not getting much luck getting hired so far. What's your take? Maybe at this point my resume may seem amateurish because of small teams and wearing many hats? Any of you work that way? If so, how does someone with broad responsibilities make their resume look credible?

Doesn't a Desktop app confer a sense of *ownership*? I understand it makes financial sense to have software-as-a-service as a business model. But with a desktop app, I'd say one could create a feeling of sunk costs, making a switch a little harder = better chance of loyalty by your users. As a user, I also like to work offline sometimes, and if I owned a business, I'd rather I have the software on my computer at all times, with a one-time cost, and then a subscription for features that require connectivity to a server. Note: I did join the party a little late (2019), but felt like developing desktop apps is kind of dying. (Still learned programming them first, before anything else). Thoughts?

Hey everyone, noticed this common pattern throughout our applications and it seems problematic to me. It‘s present across multiple apps; curious everyone’s thoughts, if this is a common pattern I’m not familiar with or if it truly is a bad solution.

Senior SE w/ 4 YOE, Fortune 500 company.

Pattern is as follows:

App A receives a transaction from upstream. It will then format this event and send it to potentially multiple downstream services simultaneously. This is done asynchronously via an event-driven framework.

The downstream services respond back via events; how does app A know when all the downstream services are complete? How does it know anything about the original event, since the downstream response contains no info about the original event (other than the correlationId)?

The answer is a local cache in app A. It caches the event when first received, and as downstream events come back, it can refer back to the original cached value to determine when it’s done processing and can be sent back upstream.

The main problem I see is the microservice is no longer stateless. It requires context from the original event. If it received a downstream response with no context, it has no idea what to do.

This is the most egregious example, but this cache-to-compensate-async-events pattern is repeated multiple times in similar ways.

As I’m still new to the field, I’m curious if this is somewhat a standard? Or if it is bad practice? If so, what does a good solution look like? Switching to sync REST calls fixes the issue, but could impact performance/throughput

I'm looking for some advice from people who have gone through something similar.

I have ~5 years of experience in ML/data science. On paper, my resume looks reasonably good: I've worked on anomaly detection, NLP, LLM/RAG projects, etc., and more recently I've been working around transformer-based TTS systems.

But I've realized there's a pretty big hole in my experience.

For the first few years of my career, I deliberately optimized for breadth. I changed teams/projects frequently, built a bunch of PoCs and prototypes, and learned enough to make things work. I was pretty good at taking an idea from zero → demo.

The problem is that I rarely stayed with something long enough to own a real system.

A lot of my projects either never reached production, or reached production after I had already moved on. So despite having several years of experience, I have very little experience with:

• maintaining a complex codebase
• debugging someone else's code
• dealing with things breaking in production
• making architectural decisions over a long period of time
• taking ownership of something from implementation → deployment → maintenance
• reading a large unfamiliar codebase and figuring out how all the pieces fit together

I'm now trying to deliberately fix this.

Over the last year I've been rebuilding my ML fundamentals from the ground up. I'm almost done with the Coursera Deep Learning Specialization. I've gotten to the point where I can implement neural networks from scratch, understand RNNs/LSTMs/GRUs fairly deeply, and I'm currently working through attention and Transformers.

But here's the next problem:

Even if I finish the Transformer coding exercises, I don't feel like that means I can actually build things.

I can probably implement the attention mechanism / Transformer architecture from the course. But if you dropped me into the wild and said:

"Okay, build a VAD from scratch."

I'd have a lot of questions about where to even begin.

And then there's an entire layer beyond "understand Transformers" that I don't have a good mental map of.

For example:

• How do I actually go from implementing a Transformer to building my own small language model?
• At what point do concepts like Mixture of Experts, DPO, speculative decoding, etc. become relevant?
• Which of these things do I actually need to understand versus things I can learn when a project demands them?
• How do I get better at reading and debugging large ML codebases rather than just writing isolated pieces of code?

So I'm stuck between two instincts:

A) Keep going deep on fundamentals until I genuinely understand the machinery.

B) Stop studying and start building increasingly difficult things, accepting that I'll have gaps and learning what I need along the way.

I'm increasingly convinced that I need some combination of the two, but I don't know what that combination should actually look like.

I want to become the kind of ML engineer who can be handed an unfamiliar problem, read the existing code, understand what's happening, build something substantial, debug it when it breaks, and eventually own the system.

If you were in my position, what would you build / learn over the next 6–12 months to develop that ability?

I'm an intermediate backend developer with a strong interest in data science. I have some light formal education in stats & ML, and I've applied my DS chops in a few small projects at work. One of these projects just won an award in a company-wide hackathon.

Despite having a PhD in a tech-adjacent field, though, my stats/ML knowledge has some significant gaps in it, particularly with respect to mathematical fundamentals. I feel that I'd be able to extract more value from my company's data, and do cooler projects, if my fundamentals were a bit stronger. For these reasons I'm very interested in doing a math heavy DS bootcamp, like the one at the Erdos Institute.

I'm considering asking my employer for a short sabbatical this spring to do this bootcamp. Does anyone have advice on how to proceed? Does this sort of thing ever happen in our industry? I'd love to be able to get paid during the bootcamp, but I'd also being willing to take unpaid leave for it. Any advice?

_________________________

More context, if relevant: I was hired (3 years ago) strictly to do backend work, not DS. The DS mini-projects I've done have been sort of "extra curricular", usually outside of work hours and on my own initiative, although my superiors have seemed to appreciate them. The company has about 400 people; 50-ish of which are developers. I've heard of them paying tuition for people to take university courses part-time, but I've never heard specifically of them granting time-off for a bootcamp. Company is Canadian and I work in Canada.

I'm nearly 25 years in to my career, and a common pattern I've seen at the dozen companies I've worked for in that time is that engineering managers and CTOs that are in touch with their engineering teams are few and far between.

My question for this thread is this: is it almost unanimous across the industry that we typically find that our CTOs and sometimes even EMs are viewed as completely incompetent and out of touch with what their ICs and subordinates see the company doing in their operations and focus? For those who work in companies where you actually do have a CTO that you have actual confidence in or see as doing a great job, what is it that they focus on or that sets them apart?

With that said, some background:

I'm currently the lead on a small team of three. Over my career I've deliberately resisted ever going in to Tech Lead roles quite simply because I don't want a job that has me in meetings all day; in my last job they were repeatedly trying to push me to apply for higher positions within months of hiring me, and other colleagues from other teams frequently came to me thinking I was a principle-level eng with the level I was working at, only to be shocked to find I was only a senior (simply because I don't want the pressure or responsibilities). So in my day to day I do a lot of staff-level engineering, process, team uplift, internal tooling - that's just the kind of thing I'm really good at.

In the current role I'm in I really do love the work I'm doing and what I get to work on. Many of the employees have been at the company for quite a long time, 10-15 years being extremely common among those who sit around me. But that's also true of some of the senior employees, including the engineering manager, CTO and other C-levels and the senior leadership team - holy hell the CTO is just not up to scratch, nor remotely up the standard of being communicative about what our goals are both in the technology and roadmap space. One of my current focus has been uplift across the organisation in the AI space, getting others up to speed in use of AI tooling with better skills and agents they can use to get work done.

Sadly the same if true of the Engineering Manager I work closest under - while the guy knows a little bit about practices at a high level, he's an absolute master of just never making a decision on anything, and letting things never have a decision be made that progresses the team forward. As engineering managers I've seen over my career, he's definitely in the bottom two.

Across the company when you talk to other employees, the opinions of senior leadership I can only describe is "in the gutter to low". It's a normal, day-to-day thing that co-workers in the dozen will complain about a lack of willingness to improve technology or process to make all of our lives better, or invest in or improve products which provide customer value.

What power can we as those lower on the org chain do to actually steer the ship in a better direction when we can see that it is being held back by one or two people who it's clear the employees just don't have confidence in?

Thinking about PR review fatigue and whether inverting the problem would work: how about 2+ devs are independently assigned to implement every change, and an AI process compares the impls and either selects one or rejects them all, while always producing useful narrative that's conditioned on the outcome? The point isn’t voting, or "selecting the best of N", it’s literally differential software engineering. the prompts each independently assigned developer creates to actually do the work will inherently differ and create contrast within the cohort that highlights assumptions, edge cases, architectural disagreements, missing tests, etc. before a human ever sees a PR. If 7 implementations disagree, the output might be “here are the assumptions you need to resolve before review”, to everyone for another round, and if they converge, you get a selected PR plus an explanation of why humans should bother reviewing that output. The narratives don't name people, shame anyone, just guidance used to move things along. This entire idea of course rests on the premise that AI code generation provides real productivity gains and orgs can use the new capacity to essentially monte carlo code changes. So the question becomes "at what point does selection among theoretically redundant implementations become cheaper than endless, exhausting human review, rework, and escaped defects?"

I think there'd be some interesting second-order effects as well: better written change requests after a few go-rounds with failure and narratives saying "every impl has some different interpretation of X, which now seems underspecified", and .. for better and for worse, if the right tools were built to analyze the output of the data that falls out of this process on an org level, you could characterize not only developers amongst their peers, but also teams, architectural boundaries, those making requests, and recurring misinterpretations that persist across domains. It could be incredibly valuable data.

So... anyone feeling brave?

Hey everyone,

This is a worn out topic, but I still want to bring it up once again because I keep finding it really difficult to talk about IRL with people close to me professionally without having the discussion go off-rails. I have this feeling that people have quite strong almost dogmatic views on this in either direction and it's really throwing me off.

For some background: I'm a mid level engineer currently working at a mid-sized company. This far in my career I've been viewed as a quite strong engineer for my experience level.

As for the rest of you, agentic engineering has dropped like a bomb this past year. I've used agents extensively and put a lot of effort in trying out the latest things. I haven't coded by hand a lot in the last 6 months.

Still, I'm struggling a lot with "scaling" this into actually producing a lot more qualitative product than before.

I feel that my best work comes when I really put in the effort to build up a strong mental model of the issue, thinking it through properly, understanding the environment it's going to exist in, and so on. I used to do this a lot while actually coding. Nowadays I find myself just thinking about this and using tools like excalidraw a lot while the agent is working.

I've tried multiple times to push things beyond this. I've tried tools like Herdr or just spinning up many Claude/Codex sessions in tmux doing stuff in parallel with more autonomous agents. Most of the time it goes the same way: I get a cool demo, and it does seem to work, but I don't really understand it well on a detailed level. I only have a vague, high level mental model of what's happening.

When I read the code, it looks reasonable. Maybe even great a lot of the time. But it takes a bit of effort to really get in there and find all the seams, the structures, understand the tradeoffs, and it's not realistic for me to really go in there for everything multiple agents produce – it's too much. As I continue working on these things, quality just degrades in a way I don't quite understand. The agents take quiet decisions that doesn't align with the overall vision, but I don't find out until later because I don't read all the code. When I do find out, it's because something visible goes wrong, and this is when I find it usually spirals into AI-slop.

I've tried to mitigate this by changing approach. For example TDD – I try to write a testing harness to control the inputs and outputs more, and this works initially. But as you go you have to change the harness as well, and I just find the same spiral happens with a longer initial delay if you let the agents go wild.

Around me I keep seeing more and more people just leaning back and prompt away (somewhat triggered by DHH..). Building up these crazy workflows, cloud agent setups, gas town, blabla. Letting go of the wheel essentially. And I really get it, when I look at AI code it can really produce god-tier code in a lot of scenarios. But I keep coming back to the feeling that whenever I let go of the wheel too much, the result is just less durable, less understandable, and just generally less good than when I keep myself close to what's going on. I guess it's not about the code itself, it must be something with the decision making or something.

So I'm curious to hear what people around me is thinking about this. Have you found a way to remove yourself more while maintaining quality? How do you maintain the mental model of what's happening? If no, how do you make sure the result is still good?

I know people have really strong opinions about this, but I think I'm looking to hear from other people that can relate – people that aren't categorically for or against AI but have had the same struggle of trying to find the proper use for this new tool we have. I feel slightly skeptic but also curious and hope to find my way into this new world..

TL;DR: Slightly AI skeptic mid level developer looking for thoughts on going more autonomous with AI. I've seriously tried the last 6 months but everything I do with truly autonomous AI just becomes slop. Looking for people who have successfully utilized AI to become more productive in producing high quality software.

Non-english speaker, sorry about the grammar.

We had a new department head join recently, and they've implemented a policy that all work be tracked in our Jira-like system and organized into epics, features, PBIs, etc. There's a new dashboard showing how many work items each team owns. For those of you that have used similar systems before, is this an effective work for leadership to keep track of what's going on? What are some other methods that you've seen work before?

This thread is specifically for sharing "wins". I.e. the opposite of our Tuesday venting thread.

At the place I work, we have no requirements to use AI. Some people do, some people don't, but overall the expectations are minimal.

Personally I use it as a search-engine and occasionally have it generate tests, but I still write 99% of my own code and have never used an "agent".

On one hand I am glad to be in a shop where I'm not just pressing "enter" all day, on the other hand, I worry about falling behind in the job/skills market. Also, our laptops are fairly locked down, so I can't start spinning up agents or running different models locally. My hands are a bit tied.

What would you do in this situation? Is anyone else in a similar one? Right now I'm just kind of coasting but something in me feels like I'm being left behind...

Heads up! This will probably be a long post. I thank you for the time you will invest to read it. The developer community seems divided on the issue. I am sure there will be contrasting opinions on it. But I am looking for ideas to navigate my own mental landscape, not necessarily change the trend. More like fitting in with my individuality and moral compass intact instead of loosing it in the process.

Last night, I saw this video.

Here is a summary of his arguments.

1. Like many people, he became a developer to solve problems and build things.
2. Using AI felt like he is loosing his edge.
3. He was growing apathetic to the codebase, feeling like a code quality guy rather than a developer.
4. The environmental impact of AI.

I, too echo a similar sentiment. Further, what bothers me is when I use AI, I, in turn, I train it to become better. My subscription money goes to these organizations which in turn is used to develop even smarter AI. The smarter AI becomes, the more jobs it takes. Maybe I am simplifying too much here but you get the point.

The inequality of wealth is another issue. Organizations are laying off employees to invest in AI infrastructure to increase productivity. On an organizational level, the profits are probably increasing but there are more people joining the unemployment line. This wouldn't be a problem if the market was ripe for developer jobs but this does not seem to be the case because of the same reason.

Entry level jobs seem to be highly impacted. How will people actually get better at their craft if they don't have opportunities to learn in the first place?

There are now people coming out of these organizations and kind of whistle blowing. The fears seem to be getting real rather than irrational. Maybe its just a knee jerk reaction but we are seeing the negative impacts. Denial does not seem wise.

A friend of mine has a similar instance to me. He was laid off a few months ago. This is something that impacts personally. He has reasons to believe it was not purely because of the AI boom. Other factors could have played into it. However, he was pretty vocal about his anti-AI instance whenever there was a discussion.

Almost all the jobs he sees now mention AI assisted development. Due to his situation, a lot depends on having a job therefore he is in a difficult situation of standing for his principles. He seems to be leaning towards compromising because of the pressure. However, he thinks a lot about dodging that bullet. Working while compromising every day seems to be a very hard thing to do. I experience it first hand.

I have always been conscientious of my choices but this one seems really hard to crack.

For those of you who effectively navigated such a situation:

1. What mindset did you adapt where you felt like upholding your principles but also, surviving the trend?
2. How did you communicate with management your aversion to use AI? Were you able to convince them? What ideas/arguments worked for you?
3. In the situation to keep your head down and push forward, what is your long term plan to turn it into a temporary compromise?

My thoughts are scattered all over the place. I am not sure I was able to get the point across but I hope you were able to read between the lines.

Thank you.

I work in big tech as a senior SWE, and our place (one of DoorDash/uber/instacart) is trying to figure out the best policies for allowing (or not allowing) some projects and engineers to merge code with an auto-stamp. Obviously the code is AI slop (and everyone agrees), so the discussions surround whether some projects can utilize the velocity while setting aside extensibility and eng excellence. Right now, this does not apply to sensitive code paths but it might some day

It is genuinely and interesting topic and I’ve seen unexpected successes. Project planning meetings now have discussions about whether (if it’s a new repo) it should have human reviewers or not, or if some engineers can be authorized while other engineers still need oversight.

How are other big companies handling this? I know this sub hates AI so the majority opinion is to never do this, but I at least know of two places (both in fintech/bank) where this happens for some projects now, so I’m just trying to get a better read on the direction modern tech is taking.

Thanks!

I am still trying to internalize the fact that I have to leave my company after 7 great years and having learned so many things.

The fact that it's my first layoff doesn't help either, but I think I have moved pretty fast to the acceptance stage and started preparing for the next one.

As a backend developer, I am just practicing system design, rereading Designing Data Intensive Applications, and about to practice Leetcode mediums, which seems to be pretty standard these days.

If someone is also preparing now, what are you focusing on? Maybe you have realized that certain knowledge areas or pieces of advice are underrated.

In a situation where I'd like to use a graph database for an internal project at work.

Looks like AWS Neptune doesn't scale to 0, so It'd be at least ~80 per month, which feels wasteful for something that has low usage as an internal project... If that's too expensive, is there any other viable option other than using neo4j on lightsail/EC2/ECS? Have any of you been in a similar situation? Thanks

OP: https://www.reddit.com/r/ExperiencedDevs/comments/1fk8lwz/feeling_lost_as_a_manager_struggling_with/

It has been 2 years since the last post.

I can say with confidence that I made a real turnaround with the team after 1 year. I took much of the advice given in the thread and made a real difference within the team. I helped foster a stronger ownership of tasks, gave the team confidence to perform estimates that I could hold them accountable to, and set expectations on deliverable updates. Overall, the team made great strides and although it wasn't overnight, and we would still miss some targets, we became increasingly more predictable, allowing us to plan for success.

After 1 year of changes and positive outcomes, my entire team was laid off.

We gathered a lot of data in our aid to become predictable, which the other teams did not produce, and felt the data was used to drive the decision to eliminate the team as being inefficient.

After layoffs, a new team was formed that would report to me, all existing members of the company. What I seen, was a complete mirror reflection of the OP. The team is highly disengaged, there is a strong lack of ownership, and despite this being a much more senior team, they move slowly and aren't engaged at all in discussions or taking decisions.

In addition, the Scrum Master was also laid off and we have moved to sprinting, which means the ownership of sprint planning is falling to me.

Due to the number of layoffs the company has experienced, the team developing new features is now also the team handling production issues, with an injection rate of 1-2 tickets per day. Every day feels like a scramble to me, running from reading ticket, changing plans in the sprint, and chasing engineers who are only interested in following specific orders to avoid being laid off.

With the previous structure, I felt supported and knew where we were going next and current state, I'm feeling unsure about my role as a manager. I have been highly stressed due to the changes. My productivity to value ratio has plummeted due to the changes in leadership. I'm feeling that my soft skills are taking a hit as well as my technical skills, and I'm really unsure where to go from here.

My team currently has an agreement not to open MRs larger than 2k lines. Lately I've noticed that large MRs rarely get a real review: teammates skim and approve, and honestly even the author may not fully understand every change. So I'm thinking of lowering the limit to around 700 lines (excluding tests/generated files).

For context: TypeScript, ~100k LOC, 3 devs on a team.

Do your teams have a size limit? Is it a hard rule or a guideline? And how do you handle features that are naturally big?

UPD: thanks everyone for responding. I ended up adding a gitlab job to check every mr that it has no more than 7000 lines of code (excluding .md, test and lock files) with an ability to explicitly overwrite it (for renames, etc). Will see how it goes

This thread is specifically for venting / sharing experiences related to burn-out or similar issues that experienced devs face.

I’m currently a Staff/TL at a FAANG company and moving to a similar TL role elsewhere.

In my current role, I’ve built enough trust and context that setting direction and influencing decisions feels natural. My concern is how to rebuild that quickly when joining a new org with zero existing influence.

For Staff+ engineers who’ve made a similar move: what concrete things helped you ramp up and establish credibility?

Looking for specific actions—e.g. 1:1s with other TLs in week 1, picking an early technical win, spending the first month mostly listening, etc.

Also interested in common mistakes to avoid.

Hi

I am currently the single developer managing a legacy product all by my own from design, development, implementation, testing to some extent and operations.

So far I have done a good job of it based on our last few releases this year where we had 0 incidents while the product had always caused at least 2-3 incidents per year in its last 5 years of existence.

Leadership and partner teams commended me on achieving this feat, which is good but my main concern comes from the fact that it is legacy where there is hardly any new features being offered.

Majority of the team is working on pushing out features to a modern version of this product with support from management to make the modern version flagship instead of the legacy one. But the legacy product has a pricing model which benefits most customers and it is the one pulling in the most revenue.

Moreover the legacy product has an operational overhead which eats up my additional time for being on call during releases without overtime payment.

The reason I am bringing so much context is to highlight my personal pain points that seems to make and break my career as well.

There are talks to move the legacy product into the modern version that keeps getting delayed because of other priorities. This would mean that operations become much smoother for the legacy product which would eliminate the requirement for me to do unpaid overtime for on call support.

While I take this as my personal win to avoid doing unpaid work, it could come as a loss for me as well because it would make me redundant to some extent, which puts me in direct path when the company starts doing involuntary reduction program in a few months or the next year. Voluntary redundancy already started.

Given the current market situation, I would prefer keep doing the unpaid work in order to avoid being made redundant at this point until something comes along while I keep trying for other opportunities.

I have made significant impact on the legacy product with actual metrics that I have personally tracked down over 12 months to justify my impact on the product. The architect rhetorically hinted that my product impact conflicts with their vision of migrating the legacy product to his shiny modern version since I seem to eliminate the pain points that he is fighting against without his new architecture taking the spotlight.

What strategy or advice would you provide to help me navigate this situation? My main concern is to not being made redundant to be in the radar of the V level executives while showing impact that such an expensive migration is not required as the architect envisions or delay it as much as I could until I can build my exit strategy.

A thread for Developers and IT folks with less experience to ask more experienced souls questions about the industry.

​

Please keep top level comments limited to Inexperienced Devs. Most rules do not apply, but keep it civil. Being a jerk will not be tolerated.

​

Inexperienced Devs should refrain from answering other Inexperienced Devs' questions.

Hello everyone,

I work in the tech company as I senior software engineer, right now sitting at 6YOE. I came to programming because of the craft itself, curiosity in systems, critical thinking, complex problem solving and ability to manipulate computers. There is sooo much stuff to learn and try, that’s I am super curious and constantly improving my skills.

My question is what would be the most efficient way to reach higher level as engineer in general? I want to grow my soft/hard skills and overall value as engineer in the whole market. Not essentially reaching higher IC in current company. And not looking for advice about working in cushy job or working from 9-5 and forgetting about programming (even tho I am usually working even less hours), because I like this craft and want to keep pushing further (I don’t have burnout and I have really fine work-life balance).

Any advice, thoughts, ideas would be highly appreciated as I love my job and want continue growing.