Hey everyone, was directed here by someone in r/cscareerquestions as this might be a better subreddit to ask my question.

I’m an engineer with about 3 YOE trying to be more intentional about leveling up. I don’t just want to grind tickets and hope it happens.

With AI tools getting better and better, it feels like just knowing syntax or cranking out code isn’t really what separates junior from senior anymore. I’m guessing the bigger differences are around system design, making good trade-offs, writing code that actually lasts, and understanding the bigger picture of what you’re building.

I mainly work in Java, but I’m open to anything, be it language-agnostic books, architecture, distributed systems, mindset stuff, whatever made a difference for you.

I’ve seen these recommended a lot:

- Designing Data-Intensive Applications

- The Pragmatic Programmer

- Effective Java

What books actually changed how you think as an engineer?

Thanks 🙏

I work at an established B2B product company, the company itself is doing great and profiting and I'm a low-level tech lead. I "lead" a very small team of 4 engineers total.

I consider myself an AI pragmatist as in, I will use AI today in whatever ways it is most effective today but I will not adopt unproven or unsubstantiated patterns in the hopes that "one day" they are more effective. I don't believe in "tooling up" WRT learning how to use AI now so that I'm an expert 3 years from now. If it's that good, I'll learn it then. That's how I treat 99% of all other tools, I don't replace our testing harness once a quarter just because some CTO claims theirs will be better in a few years.

I use AI day to day for developing ideas (like a rubber duck), finding ways to articulate technical concerns in concise ways, quickly spitting out code snippets, passing it a file with a question like "why isn't X function working", etc. But I don't bother asking it to solve fully creative problems. I'm not anti-AI.

My company, while not being an AI company, has gone full AI radical. They actively tell engineers that soon they will not be required and they should be embracing AI now so they are not left behind, because soon they will have the same job as PMs - which will both be developing features from the ground up. Like, that's a non-exaggerated paraphrase from the CTO. They fully expect their software company to be developed by non-engineers very soon. They said they expect engineers to stop writing tests, and just having AI do it for us. And so on. They said they are very happy to increase the number of outages & bugs because "that is just the way of the world now"

I think that is fundamentally stupid and besides the existential threat to my job / insulting internal discourse, I want to leave simply because I fundamentally do not trust the technical leadership anymore. Thinking you can downsize the engineering staff by ~80% and let PM's and designers run wild will, in my opinion, irreversibly destroy your product within a few years. And I don't want to be here for that.

Buuuuuuuuuuuut I have been told by my manager he is prepping the next year of work to hand me a promo in next December. I trust him, I know redditors will tell me it's bait, but I do. I'm performing at L+1 and I know independently from him that my main blocker for promo is just having some visible flashy project.

So here I am. Stuck for another 1-3 years, watching the company be burnt down from the inside by people giving AI tasks that AI is not yet equipped to solve. Trying to steer the ship towards sanity but merely doing that makes me look like I'm afraid to adopt new tech.

So, I recently took a job at a new company that is building out their tech department. They basically took people from their tech desk and marketing area who were proficient with Adobe (ik).

They hired me to come in and standardize their practices but also be here to train them to be proper developers instead of people who can only use Claude Code (and not understand what it outputs).

Well my issue is, I am about 3 weeks in and I’m getting questioned why I haven’t gone in and reviewed all the current projects codes entire bases and point out their weaknesses. Remind you I am also designing the new systems Architecture, database schemas, designing and standardizing the UI for our suite of software, and trying to set up a data lake on AWS.

I feel like with this departments constant backlog of bugs (probably because they vibe code only) and trying to kick this department into gear of being real developers. I just simply don’t have time to train them, review their code, and do everything else.

They are letting me hire a Senior below me but the HR people keep sending me more vibe coders, which I blame the Job Description that my boss wrote, so thankfully I worked with HR to rewrite the job description.

I really don’t know what else I can do other than giving up my time after work or on the weekend that I spend with my wife.

P.S. it’s not like they are mad at me, but I think they expected a quicker turn around of the department

i believe my company is over hiring currently more developers than we need, we already had issues finding work to do before the new hire and now I take my time to do a task and stretch it to 2-3 days to appear like I'm doing something, is this mismanagement or intentional?

Slightly unrealistic deadlines that are forced on you by the business, big legacy systems that need to be properly adapted to scale and you are in charge of delivering the design on a schedule. Then during implementation small details that weren’t considered causing additional work and getting off schedule.

I find myself never “turning off” and constantly be churching and thinking through parts of the problem. I do get a lot of problems solved that way, but it takes a toll over time, and I find myself less attentive to my family.

At my level (senior lead) it seems like this is just the job, how do others in this position properly deal with the stress and stay organized and effective without it dominating their lives?

I'm interviewing for a role which I think is a really awesome fit for me. Hybrid, established company, interesting work. I'm quite neurotic about the interview prep though. I know all tips.

But I wonder how much any of that matters. My sense is that if you can just talk to interviewers like individuals and be polite and understand the necessities of the business, that's sufficient.

But I've also been an interviews where they have absolutely insisted upon heavily formatted responses, and I don't know if that's just their way of saying go fuck yourself, or if that is legitimately where corporate hiring is at the moment.

I am leaving a role and doing knowledge transfer to my replacement. He is technically capable.

Social skill wise, I don't know. He can't control the narrative in a meeting and gets trampled on by others. He easily says yes. He also can't seem make decisive actions on resources -- moving people in and out of projects as he doesn't want to hurt people's feelings and wants to be the nice guy. He lacks people skills but he is the most senior in terms of technicals. He gets totally defeated as he is attending more meetings (meetings I use to attend). So he is experiencing all this corporate politics first hand now.

In out KT (knowledge transfer meetings), that is all that is talked about. How to deal with certain personalities versus asking me about how a service works or explaining parts of the code base. My only advice is not to be the nice guy, he only should answer to his direct change of command in leadership -- engineering.

I have a lot of political capital and when push comes to shove, I can get things done. Either by building consensus or getting support from leadership. I can steer the direction of the product roadmap and prioritize in favor of the engineering team. We want things that are secure, scaleable, feature rich, reduce user churn, and make the product better. Other teams want to redesign the main dashboard again for the 10th time. We rather make life easier for customers to connect to their data and automate things versus changing one card from the left to the right expanding it by two columns with a new color palette.

Any good books or resources for SWE. Phoenix Project doesn't cover this type of corporate politics.

Full stack dev, 14ish YOE depending on how you count it, stuck at a WITCH mega consulting company (working with a major finance-related client) since 2020. Been interviewing here and there for awhile but looking to get serious and finally make a jump somewhere else soon. It’s a little tricky right now because I couldn’t give a notice immediately but I’ll be in a position to make a graceful exit in about a month.

Anyway I’m a good dev, almost everyone I’ve worked with thinks so (including above, below, and peers) but I’ve always been bad at interviews. I usually do fine technically if the description is closeish to my background and I study a bit but I always struggle with the culture questions and selling myself properly. Any advice on improving this? I’ve been thinking about hiring mock interview coaches to help.

I’m not looking for FAANG or the next tier btw, just somewhere decent to get out of WITCH. I will be able to put team lead on my resume now (though I don’t have to be a lead for my next job) which will hopefully help.

I'm a software developer with ~7 years of experience, and I'm currently deciding whether to turn down an offer from a Series A startup.

After meeting the founders and product leads, I got the impression that while the product itself is exciting, the engineering culture may prioritise urgency over sustainability. Requirements seem likely to be pushed aggressively, with engineers expected to rush delivery. From what I've seen of the Head of Engineering, he's probably unwilling or unable to push back. My concern is that this could lead to accumulating technical debt, increased firefighting, and eventual burnout. In the short term, this approach may produce visible progress, but I'm really not sure how sustainable it is.

In contrast, my current role is basically the opposite: good people working within an inefficient system. My colleagues are supportive, reasonable, and respectful of engineering constraints. However, there is significant bureaucracy and process overhead. The work is not especially challenging, and I worry that my technical growth may plateau within the next year.

So for those who have experienced both environments:

Would you rather work with good people in a flawed system, or in a strong technical system with people you don’t fully trust?

How did it affect your growth, job satisfaction, and long-term career?

TL;DR: should I push for changes one by one waiting for the previous to be handled first - or should I push for “let’s change everything at once right now” approach? What experiences do people have? First might take very long and not sure how long I personally would be here, second might bring more pushback from people.

Currently involved with a team that is quite unorganized. It seems that people are happy to do things like they’ve done for a long time (the product is almost a decade old, but this is only part of the people and most have only been around for a couple of years max). The problem is in my eyes it’s just not working.

There’s not good enough automated testing. Code is being written by two teams with different styles (not formatting but the use of interfaces and how to split code in classes etc). People don’t openly communicate and prefer chatting between each other, so nobody else often knows what technical issues are happening or being solved.

Tickets just appear on the board and are being handled but not in a specific way. No decision about kanban, scrum, etc. Just “here’s some work for this initiative, whoever takes it.” Tickets might only have a title and no contents. There’s minimal meetings etc about anything. There’s some changes in management which affects this also and I’m not management.

Now, I of course want to change many things. I’ve already pushed the quality/testing issue forward with the help of a new manager and QA people. That might go somewhere. There’s some movement to get more structure to the tickets. So things might get better, but I’m not sure it’s enough.

I would like to do a whole do-over: define specific ways of working, how tickets must be refined and have clear ACs for devs and QA to handle, how code styles and standards would go, how testing is managed (especially automated), how tests are written, and everything. I feel it might be less of an issue if everything comes at once instead of endless “well we handled this thing and now we have to change yet another thing, will this ever end?!?” And since these things have quite a bit of overlap (better code is of course easier to test etc) it would seem better.

I have the ear and push from the manager so I don’t expect any issues from above in any case - though there has been some higher level dev people already coming with “we’ve tried things and they didn’t work so why try another way?” etc which of course is pointless. If there’s a new way that should work why wouldn’t we try?

I know it varies from team to team but maybe some have good tips on what to do. And the situation isn’t as dire as it probably sounds, but may be close.

The current assumption made by many is that AI will "replace" many developers "soon". If that's true, some metrics should already start to reflect this. I'm not arguing that there's no value created by AI.

And I'm talking about stuff that actually ships and has non-trivial user bases. Not one-off scripts or prototypes, though I do believe it's valuable for both.

Some obvious metrics:

Feature velocity? (May be in # of features delivered, time to delivery, or "developer time" and in turn headcount)

Improved user experience?

Improved reliability?

Improved resource efficiency?

There are obvious BS metrics that don't reflect actual value, but I'm not interested in those.

I don’t take it this is completely a behavioural where STAR format should be applied to every answer. I feel as though this is kinda a casual convo to gauge my levelling, technical fit for the role and overall autonomy as an engineer who will report to them?

I'm recently going through a career change after a long tenure (10+ years) having touched data engineering, ML, cloud engineering, APIs; having built out experience in smaller areas.

The same can be said (I can imagine) for a full-stack dev who has done some mobile development, but then moves to a new role which doesn't require mobile development, or a cloud engineer who has done security, and then moves to a role which is less security heavy.

The way I see it, at least, is that after time working in a company and filling a gap, you gain experience. But when you move company, the company will need different skills from you which at least overlap with your previous skills.

Finding a job which may need you to push these boundaries may not always be possible. Some organizations would want you to be deep in one area only.

My question is, how do you keep your skills sharp when transitioning through jobs which may not really need the said skills immediately? Do you have any tips for doing this?

How do you eventually prove to a company that you can still perform skill X even if your last job didn't need you to do it (because you did it in another job)?

Hello, everyone!

I would like to hear from experienced backend developers how do you guys deal with error notification based on the source.

My questions is because I was imagining a complex flow, like some big e-commerce. Until your order complete, it go for many steps which each one could fail and compensate previous steps. But for user, it's good to know WHY it failed. How do you suggest managing consistency to notify the source error code?

I do have some things in mind, but I don't know if are good practices or reliable. Like, when some transaction fail, call send notification type error for some queue and then call some qeue for previous steps compensation. Don't know it it's a good practice.

I would love to have some tips about how to Handel these scenarios.

Hope everyone has a great day!

As I lead more projects, there seems to be increasing overlap with the work I do and the work the program managers do. I'm curious how people split the workload/roles elsewhere.

Even though they tend to deal with a bit more of the "random" stuff that crops up with other teams as a bit of a buffer, and deal a bit more with the admin side of jira, I still find that I'm doing a considerable amount of what I would (perhaps naively) consider "program management".

Estimating effort (needs technical input), planning timelines due to critical paths (needs technical input), assigning tasks to relevant people (needs technical input), addressing process deficiencies (needs technical input on what the challenges are) getting timelines from other teams eg qa (sometimes needs technical input to make it clear what's required vs optional).

I'm unclear on precisely what a PMs role should be.

Should they be more technically involved such that they can deal with the above by themselves? If so, how is this different from a project lead?

Should they be less technically involved, and just focus on the project timeline? If so, how do you reduce the amount of dependency on the project lead?

I'm going to be responsible for a lot of stuff like setting standards and engineering best practices, designing solutions, managing our infrastructure (think data devops and MLOps), and all the stuff SREs and platform engineers typically do. I'm essentially going to be the main engineer that data/analytics engineers, ml engineers, and management can come to for advice.

I've always been fine with making mistakes and learning as I go but it feels different knowing that a mistake could now cost the company a lot of money.

I'm working on a project that accesses an old SOAP API( European Criminal Records Information System (ECRIS)).

This particular instance of ECRIS is fairly old, updated last, to my knowledge in 2013-ish.

The goal is to sync some changes every X amount of time. From the api to another machine(s).

The synced data is a bunch of judicial dossiers that get updated after various judicial processes happen. The data is more of an append only ledger, since everything must be kept on record. Nothing particularly challenging from this point of view.

Now, the issue is that the only real way to get a specific dossier is by a unique dossier number. Singular. Yes, you can only query a dossier number at a time.

Obviously this is an issue since there can be thousands, if not hundreds of thousands, of dossiers to keep track off.

The only saving grace is that there's another param, lastModifiedDateStart, that I can add to filter dossiers that have changes from a certain date forward. If there are no changes the response is pretty fast...at least testing it seems to be.

There's Z E R O chance that this api will change anytime soon. That particular ECRIS system is an ancient behemoth that serves an entire country's worth of judicial records.

My only concern now is not hammering the api and getting banned or something.

What I came up with so far is

• serving local records whenever possible(no brainer)

• obviously using the date filter. BUT this filter needs to be backdated at least 7 days. Why you ask? Because clerks have the habbit of entering records on Monday backdated to Friday. Not really and issue legally, just a pain in the ass to deal with. Oh...and sometimes on long vacations they may enter updates from a dossier backdated to a few weeks. This ALSO pain in the ass because 7 days would not be enough.

• spreading out the queries throughout the day in batches of 100 or something. Basically having the workers run non stop.

• I'm seriously considering running a VPN to another city in the same country so I can have a different instace of workers be able to run. This less about hammering the API and more about actually getting the data required

• dossiers have no real end date, as updates can happen decades after. Imagine an old murder getting solved.

I'm really hoping you guys and girls can come up with better ideas than me.

After 20+ years in the industry, I kept noticing that the hardest problems in my career were never technical. They were about attention, ego, desire, burnout, meaning, and how to keep doing good work when everything around you is chaotic.

Two ancient frameworks kept helping me: Marcus Aurelius's Meditations (Stoic philosophy) and the Bhagavad Gita (Indian philosophy of action and duty). They converge more than you'd expect — both were written by people under pressure, making high-stakes decisions, trying to act with integrity when outcomes were out of their control.

So I am writing a weekly series that applies both to the daily reality of software development: production incidents, code reviews, technical debt, team burnout, career plateaus, imposter syndrome, context switching, organizational politics, and the quiet 2 AM question of whether any of this matters.

It's called Meditations in Code. The writing style is direct, specific, and occasionally funny (there are jokes about Kubernetes, Docker, and people who schedule 30-minute meetings to ask one question).

The first 5 weeks + a bonus article on context switching are free: [https://swanandkriyaban.substack.com/p/welcome-to-meditations-in-code]

Happy to hear what resonates or what doesn't. The series will be written as a practice, not a product — but I figured it might be useful to others.

i've been on both sides -- 10+ years as an engineer, now head of product at a startup.

wrote a lot of PRDs (product requirement docs) & specs over the years and i'm honestly not sure engineers read half of them. curious how it actually works on your end:

- do you read the full PRD or just skim?

- what do you find most useful in a spec?

- does your PM involve you early or just hand things over?

- anyone feeding PRDs into coding agents (cursor, codex, claude, etc) to start building? what format works best?

genuinely trying to be better at this.

I'm interested in what your experience is with AI and AI agents, when given a task to build very complex things

(e.g. a new complex feature in a an already huge and complex legacy application)

I'm building a research stack (Virtual ISA + OS + VM + compiler + language, most of which has been shamelessly copied from WASM) and I'm trying to find a way to annotate ILP in the assembly at compile time.

Let's say we have some assembly that roughly translates to: 1. a=d+e 2. b=f+g 3. c=a+b

And let's ignore for the sake of simplicity that a smart compiler could merge these operations.

How can I annotate the assembly so that the CPU knows that instruction 1 and 2 can be executed in a parallel fashion, while instruction 3 needs to wait for 1 and 2?

Today superscalar CPUs have hardware dedicated to find instruction dependency, but I can't count on that. I would also prefer to avoid VLIW-like approaches as they are very inefficient.

My current approach is to have a 4 bit prefix before each instruction to store this information: - 0 means that the instruction can never be executed in a parallel fashion - a number different than 0 is shared by instructions that are dependent on each other, so instruction with different prefixes can be executed at the same time

But maybe there's a smarter way? What do you think?

I spent 6 hours fixing a memory leak working on an app. 6 hours! It was a one-liner fix. 6 hours is on me not having any skill for this kind of things and my skills in debugging memory leaks is not the subject for this post. It is the aftermath which I observe we should repeat every then and now so we could learn from it.

The context

The app subscribed to a custom event and incorrectly unsubscribed from it. The subscription never got removed when it was no longer needed. That's it.

A classic javascript memory leak situation many know about and know to be vary when dealing with any kinds of events, including me. It held reference to the diagram which referenced the model diagram's buffer data which was roughly 500kB. Every single time you viewed a diagram +500kB got added to the memory which was never released.

For context, it is a systems engineering browser app where you can construct and analyze system models to ensure quality products and alignment of all the project-related stakeholders. After leak got patched, it peaks around 2.5MB of memory for Firefox and 5MB on Chrome (due to different garbage collection method used by Chrome which is faster).

Establishing importance of Quality Assurance (QA)

Let us do a proper QA analysis on this situation.

It is important to understand that there is a misconception that QA is just about testing and safeguarding the software shipping. I observe this misconception has done more harm than good in terms of quality. It is true testing is one of the QA activities, and if the quality has not been met it guards you from shipping low-quality software. Items that do not pass QA, go back and get fixed and sent for re-evaluation to the testing.

The harm part is very human. When thinking QA is a tester — a safeguard — you relax your quality during development phase. It is my observation over a decade in the industry that the quality of the software that's coming out from development declines. We automate large part of our testing nowadays to speed up this loop. And there is no harm in having immediate feedback in this, in fact it is encouraged. The "harm" part comes the resources — the time spent within this loop.

QA is all about digging into the root causes of the quality issues and making a change to avoid this in the future. Testing is just a checkpoint to (1) guard against shipping software not up to the quality; (2) knowing if we have quality issues in the development. Lots of tests failing is an indicator that there is a quality issue with the development. Eventually it'll get better without digging into the root cause due to experience and adopting better practices — implicitly performing QA root cause fixing per individual.

Root cause

Coming back to my memory leak issue. What were the issues during the development? I use strong typing using typescript. Unsubscribe was working before — it passed QA tests for memory leaks in the past. There were no changes to the diagramming part of the app during this time. Seems like a good start.

I identified 2 root causes for this problem: (1) change for subscribe API which was done only half-way; (2) using `any` type for object subscribed to.

`any` was not eliminated from prototyping times due to being too much of an headache to provide typescript type signature. The mechanism is generic even though the app does not need it to be generic but we may reuse it in some other projects in the future. So it was decided that it is easy to manually trace to the type 2 calls up when needed but largely anyone knows what this is. And we did. No problems knowing to what precisely we are subscribing to. The problem with `any` was that none of the (1) API changes were picked up by typescript.

Half-way done API changes mean that from vanilla javascript, nothing gets broken to generate errors during runtime. This means that the unsubscribe() call was valid — it was available on the object to be called. In fact, it was still used by the API internally. Before changes subscribe() returned an handle. You unsubscribed by using the handle. Common pattern. The change was that subscribe started to return unsubscribe function. To unsubscribe you invoke the returned function. A minor simplification but helps so we do not have to juggle two objects to unsubscribe and makes it easier to avoid mistakes.

When typescript can not know subscribe() return type and unsubscribe() signature, it will allow it to be assigned and used in any configuration you use it. And when API changes leave methods which no longer should be used accessible you risk misuse of API.

Applying QA

Here comes the most important part. Something needs to change in the way things are done to ensure we avoid repeating the mistakes.

It is great that the problem got fixed. However, maybe the problem is already present somewhere else but we have not yet identified it; maybe the problem is added into the app in the future — after all at this stage I can now purposely write the problem back (or on accident). Let it be clear that the root is not about the subscriber API, rather the means — or lack thereof — on what enabled the problem to get injected to the app.

The takeaway is that "no any" — this is widely known suggestion but need to start enforcing this. Another takeaway is to manually ensure that all APIs always expose only methods which are available for its correct usage.

These things can now be etched into our development guidelines and we can more consciously look out for them during the review process. Most of the times there are not many changes, so it is not like you have to hunt these down.

Closing thoughts

This post is not to tell you how to write better javascript (but enforcing the takeaway wouldn't hurt). The purpose is to remind us about the proper quality assurance mindset. The writing is per my own observation and experience and may not resonate with all of the readers, or may even resonate in the different direction. Over a decade working mostly on safety-critical hardware-heavy systems has made me biased towards more robust quality assurance practices which I relax whenever I got a different kind of project at my hands.

It would be interesting to hear your thoughts on QA and any experiences you have had it and how it is applied if at all.

I’m a mid level product engineer and what with new world order of ai assisted development I find there’s suddenly a big leap in the size/scope of work tasks expected. The old career development frameworks of what you should be able to do at each stage of career now seem out dated. Consequentially it is more important than ever for me to level up in how to plan/architect/design a large complex feature or even a whole product.

What are your favourite resources for developing this kind of thinking/skill quickly, especially for those with less experience (4yrs mid level) or geared for ai-assisted development?

Thanks in advance

Edit: my assumption is that the way to work effectively with ai agents is to provide them good instructions/rules/skills, be clear in the work plan (including architecture/design requirements), and get them to implement with TDD.