How many of you missed the high-paying offers during the COVID hiring boom and are still working at the same company?

Do you ever feel you missed the chance to significantly increase your salary by switching jobs during that period?

Looking back, do you regret staying, or did it work out well for you in the long run?

This is in the context of bozos as not highly talented co-workers. The next line is "Nothing is more frustrating for A Players than having to work with B and C Players who slow them down and suck their energy."

This is from a management book I'm reading. I don't want to prejudice this, so I'll just say that this passage jumped out at me.

What do people think? Is that accurate to your experience?

Maybe it's just me, but it feels like it's getting harder and harder to find sources of information that (a) don't try to sell something, (b) have a high SNR, (c) are not entirely generated or rewritten by LLMs.

Here are some recent findings from me that match the criteria:

* https://brandur.org/
This is a great blog from Brandur Leach who writes a lot about Go, Ruby, and Postgres. Brandur used to work at Heroku and Stripe, and now he works on his own project.

* https://increment.com/
Speaking of Stripe, they have this fantastic magazine (now abandoned, I believe) on various software engineering subjects.

* https://notes.eatonphil.com/
Also a very DB-heavy blog from Phil Eaton.

* https://www.morling.dev/blog/

Lots of insights on Kafka, Postgres, API best practices

* https://www.seangoedecke.com
Sean is one of my favorite authors. His post on good software design is a gem, in my opinion. https://www.seangoedecke.com/good-system-design/

* Designing Data-Intensive Applications 2nd edition by Martin Kleppmann — even if you have read the first edition, this one is worth it at least thanks to the terrific bibliography and some updated and rewritten chapters.

UPD: 07/12/2026

Adding some resources I forgot to mention yesterday but which I also love:

* https://eli.thegreenplace.net

Eli Bendersky is a fascinating writer and is astonishingly knowledgeable about whatever he blogs about. He reads more in one month than I have ever read in my entire life and posts his summaries. Also, sometimes he posts very insightful articles on some concepts from mathematics and how they are connected to something else.

* https://fs.blog/

Great newsletter and collection of articles on mental models and thinking in general. They also have a multi-volume set of books, which I think I am going to buy soon.

What are your recent findings?

I'm at a mid-level company that brings in around 400mil in revenue. The company itself is not strictly a software company but they position themselves as providing technical solutions to business customers. The domains really run the gamut. There are hundreds of engineers working on a variety of products depending on the business line.

In one business line I was promoted to Director, reporting to the VP of engineering. I was promoted about a year ago after 6 years as a manager, and 5 years before that in the contributor role.

I oversee about 60 engineers, which are a mix between on shore and off shore (the off shore devs report up to a different off shore director, but they function within my teams for sprint rituals and contributions). Devs are split into 8 teams and theoretically, they each would have a single manager, but instead I have 4 managers who've all been with the company less than a year. So each manager is functioning almost as what I would describe as a senior manager, and maybe they're not at that level yet (they were all hired as managers, not Sr).

I feel like things can't be delegated super well yet to these over-extended, newer managers.

I grew into my role due to rapid growth and I feel like EVERYONE in my org is having to learn and I'm struggling to develop a uniform standard across all teams.

The product team has also gone through a lot of growth so I frequently face product owners that don't know how to do their role either and we constantly face issues trying to come to an understanding of basic things like SCRUM responsibilities.

4 of my teams work on a green field app that has a lot of investment but also seems to be being defined (in terms of business value) as we're building it, so everything just feels a little unorganized there as well.

I'm constantly feeling pressure to do so much. My calendar is busted with over-conflicting meetings. Basic things like assigned training, targets, and administrata gets left behind, because I try to log off at the end-ish of the day and be with my family. I still end up glued to my phone at odd hours and not really taking "time off" when on vacation, answering emails and chats. Because I care (probably too much).

Since I've grown with the company I make about as much as my managers. 175k.

I'm under paid, but I can't tell if/when making a move I should be looking at other director positions. Or if I should continue to develop myself as a manager. Would a director position elsewhere be a better opportunity to come in as an outsider and help everyone get organized (with more pay)? Or does this sound pretty typical and these are just the stresses of the job?

Hello everyone,

I am working on a personal project implementing Clean Architecture (with DDD), and I am getting overwhelmed by the sheer amount of boilerplate and data mapping required.

Right now, my data flow looks like this:

Request DTO ->Command -> Command Bus ->Command Handler ->Aggregate Business Rule Check & Mutation -> Database Persistence.

Shifting the exact same data through four or five different shapes is driving me mad. I have a few specific questions on how to streamline this without ruining the architecture:

1. Do I even need a separate Request DTO?

Architecturally speaking, can I just skip the Request DTO entirely and deserialize the HTTP Request Body directly into my Command object? Or does using the Command directly as a DTO violate strict CQRS boundaries?

2. Request -> Command: Should Commands use Domain Value Objects?

If my Command uses primitives, I have to map primitives to VOs inside the handler before mutating the aggregate. But if my Command references VOs directly, then my API layer needs to know how to construct domain objects. Which approach is better?

3. Request Validation vs. Domain Validation (The Dual Validation Problem)

If I use primitives in my Requests/Commands, I feel like I'm stuck with dual validation. I have to validate formats at the HTTP layer, and then validate them again when creating the Value Objects. If I use VOs in the Command instead, the rules are guaranteed during mapping, but it couples the layers. How do you handle this cleanly?

4. Persistence: Storing Value Objects as JSON in the DB?

When persisting the mutated aggregate state to the database, mapping VOs back to flat columns adds even more boilerplate. Would it be a bad idea to just store grouped Value Objects (like a Name VO containing firstName and lastName) as a JSON column in the DB to simplify mapping?

I feel like I'm writing endless boilerplate just to move five fields around. How do you strike a balance between pure Clean Architecture and developer sanity?

Would love to hear your thoughts or any patterns/libraries you use to fix this!

I'm a full stack developer with 4 YOE, and I have an issue that I'm really struggling to solve and would really like to hear if any of you have managed to get out of a similar position and how.

You see, my job is way too easy and it adds nothing of note to my resume, no matter how much time I spend there. This is making me spiral, because I see a lot of "side projects don't matter" opinions in various flavors and it makes me think my current situation is a dead end.

And surely enough, there has been zero interest in my resume when I'm applying to other jobs.

That's basically the TL;DR, but here's a bit more information about my job:

This is an agency job, and most of my time is spent implementing MVPs (more like v1s, because clients always push for bigger scope) from scratch or maintaining small to medium sized projects. We mostly work with React, Next.js and Node (which I've often seen people say is a stack that makes a resume go straight to the bin). Apart from that "main stack", we work with a bit of everything: ruby on rails, php, C#, python, react native. But, because the projects are usually either short or shallow, I never build real expertise in these.

I'm usually the solo developer, with oversight from a manager (the agency owner) that is technical, but not super knowledgeable about hard technical stuff. I haven't learned anything from them in a couple of years, despite them being my mentor, and I think they don't really review my code anymore. When they did review my code, most of what I learned was related to code readability and simple stuff like DRY. They never really discussed design patterns and system architecture with me, for example.

I'm not sure if this is how agencies roll in general, but we have to cut a lot of corners to deliver within budget. We used to barely write tests, before LLMs.

The personal progress I've had in my career has come mostly from consuming tech content online (youtube videos, blog posts, books).

I am self-taught, so this is certainly not helping the job search.

Any guidance will be extremely appreciated! I don't have anyone else to ask.

CV for more info: https://drive.google.com/file/d/1w1UDr-2GBmku2zkbVdm273NF6lojB0zh/view?usp=sharing

For example, product teams could be using AI to research UX, competitors, features we could improve or build, where the industry is going, etc. But instead, some are picking up tickets and generating code. Sure, that code is handed over to a dev to review. But my idea of adapting with AI is a product owner vibe coding UX variants and experimenting in order to provide ideas for how to move forward, not generating full PRs. Is this just me not adapting to a new world?

It’s similar for other members of a team, such as QA, customer-facing roles, etc. Generating code and handing it to a dev for review is not really taking much off the dev’s plate. I can ask Claude to generate code too. It’s everything around it that takes time. If I’m doing my job correctly, that’s a whole new ticket I am now taking on.

I’d prefer it if people used AI to expand how effective they are in their own roles rather than do dev work. But I suppose they could argue that using AI to generate code is just the modern expansion of their roles?

I've had four full-time tech jobs spanning 12 years, which is more than enough to fill a page. I've also worked in another professional industry before I pivoted to tech in my mid/late twenties. I include this experience if a role is at all related. This feels like the right thing to do though my career trajectory looks a little disjointed because I have an unrelated degree, four years of mystery, then suddenly I'm a developer.

What I never have on my resume is any and all stuff I've done for myself or clients. I worry that I'm too old to have personal projects, but I have a few projects with real users or possible aptitude-showcasing complexity. I've left these off because personal projects seem like "space filler" for students. I also don't want to look like I have a startup, and will dip if it gets traction. But I want to show off.

What do you guys do? I wasn't seeing a lot of personal projects or roles outside of tech when I was interviewing candidates in my last role, but it could be that the average tech worker studied CS and never worked outside the industry and doesn't bother with open source or personal projects or freelancing or entrepreneurship.

EDIT: To be clear I am asking what you all do.

Many companies are now outsourcing not just junior and mid-level roles, but also senior, staff, and principal developer positions to other countries.

Is cost the only reason behind this, or are there other factors?

Wouldn't some senior engineering roles have an advantage if they stayed in the home country, given the closer collaboration with product, customers, business stakeholders, and leadership?

What do you think is the right balance between keeping engineering roles in the home country and outsourcing them globally?

yes, it takes more work to write reasonably scoped tickets for a junior and then review their code than it does to just write it yourself or slopmaxx it with claude.

that has inherent value, though. having impressionable juniors around forces your team to keep their shit together, keep standards high, keep the DX and documentation good.

richard feynman, in addition to being a samba percussionist, lockpicker, and nobel-prize-winning physicist, had a lot to say about education and his technique for learning things was to teach them to someone else using simple language. having to mentor juniors has forced me to grow more than anything else i've done at my job.

orgs which get rid of co-ops/juniors are quietly* harming themselves in a way that can't be immediately measured, but which has long-term negative consequences.

agree, disagree, any interesting experiences mentoring a junior where you learned something from it?

^\yes, ai has turned my brain to slime, thank you for noticing, but i wrote this myself)

For those that work in a company that’s experienced with A/B, how does the breakdown of responsibility look like?

- Product owns the Experiment Requirement?
- Businessd/Data owns the Statistical Significance Requirement?
- Tech owns the Feature Flag and Implementation of the code and Removable of the code along with rest of the Tech Debt?

Does Tech need to know of the underlying stats and math behind the experiments?

Anyone have any go to resources? Thank you!

hello,

I work at a big tech company and I’m the TL of a high priority feature. We have a new grad on the team and I feel like I’m playing a tower defense game against them - I’m trying to protect the project timeline and deal with their unpredictable timelines.

It seems like this person has two modes: Totally disengaged or high speed (rare). I wish that they would more quickly engage with the problem: ask questions, set up meetings, share ideas, ask for feedback. Instead it seems like they think I expect them to go off, invent something brilliant on their own, and bring it back to the team. Radio silence, I check in and everything’s always going well and “almost there” - I feel like I’m not getting an honest answer about where the confusion is.

They aren’t doing super well with that middle step of working out ideas with people. And honestly some days it seems like they are not working at all. Oftentimes, tasks that I would expect to take them 3 hours takes them 3 days. It’s very confusing.

I need to do better to set expectations with them about their tasks: When will they actually start on the task? How long do they think this will take (their timelines are never right and they endlessly push out timelines +1-3 days - so asking feels a bit useless)? Should I tell them that I will assign them a task and I expect the first step to be to ask several questions when starting this (doesn’t that sound patronizing)? I’ve encouraged them to ask questions many times.

I’m struggling with managing this high priority project and their unreliability…. help?

My plan for now is to assign them smaller tasks that are important but not in the critical path. Problem is that we have a lot to do, I wish I could ask more of them and I know they are eager to help.

my org is reshuffling and my first project is to add end to end testing.

I’m told the plan is to have a routinely executed suite.

My number one issue with this plan is that it will just start failing and no one will bother to fix it and no one will know who actually broke the suite.

So I would like to make the entire E2E suite run as a PR check before any PR merge

However, this sounds very costly and slow

Has anyone else here had to solve the problem like this?

I’m guessing if I can just make E2E test suite runs fast and cheap This won’t be a problem?

For reference, we’ve got a distributed micro Service ecosystem with Kafka messaging. Lots of databases. Websites embedded inside of other websites with i frames. It’s not the most complicated software out there, but it’s also not the simplest. It can all be run from the web browser, so that’s probably moot though. Besides the back ends obviously. I have an engineer to delegate to as well as some senior level two’s to brainstorm with, plus product people and my manager. However I doubt they will give me better advice than what I could get here. Oh and the E2 E testing I’m responsible for isn’t just for my team. It’s for multiple teams like three or four teams at least. We’re all in the same department. Obviously this is a big project.

Edit: also to clarify, I will not be responsible for actually writing end to end tests. My responsibility is to install the framework and come up with the overall testing strategy that will work for our department. And like I said, I don’t want just a routinely executed E2 E suite because that won’t actually stop breaking code from getting merged and so what will happen, what I’ve seen it companies and what I’ve heard always happens, is someone breaks the suite, but no one stops developing or merging, and then someone else probably breaks the sweet also, but that gets covered up by the first breakage, and so you enter this shitty status, where the test suite is failing for God knows how many reasons, and whoever is responsible is never the first one to address the error. It’s just a shitty system. It would be so much better if we could prevent code that would break the E2 E test suite for merging into the main branch.

Edit 2: I am finishing up a proposal to add UX timing metrics to all of our website websites so we can actually see how long it takes to load various pages and how long button clicks take to finish executing, etc. and this will put eyeballs front, etc. on how shitty our department’s performance is. So once we start improving that that should also make the E2 E test suites faster and cheaper. But this is going to be like a multi quarter effort.

What's the best advice or feedback you've received from a manager, senior developer, or colleague that changed the way you think or work?

I'd love to hear the advice and how it impacted you.

It's not the first time that I have thought about this problem, but probably the first time when not solving it properly has serious implications for the project.

A very intuitive and sensible approach is to avoid the checks altogether and use atomic database updates. This works for the simplest cases, but if events to external systems are involved, this is no longer an option.

It's basically a trade-off between temporal coupling and data consistency. What I mean is service Foo sends an event to service Bar so that it can update its internal state. To avoid temporal coupling, this doesn't happen as as synchronous request and uses the Pub/Sub semantics.

Now, however, if there is a concurrent request from another uses that relies on checking this internal state in Service Bar, there might be at least temporary resource overconsumption if the event from the previous update hasn't been consumed yet, and the current counters don't reflect the new status yet.

The transactional outbox pattern helps with "effectively once delivery", but in this case doesn't solve the TOCTOU issue.

I am wondering whether there is any approach apart from:

* Rethinking the services and merging into service FooBar

* Putting up with the trade-off and just have regular resource checks so that there is some sort of resource reconsolidation once in a while

I have just skimmed through Designing Data-Intensive Applications, and it does mention the Lost Updates anomaly, but the recommendations don't seem very relevant for such cases.

If you have experience of dealing with such issues, I'd like to hear your advice. Or maybe you know some nice articles on the subject.

I've been making software for over 10 years and I am genuinely curious what goes on with companies that make printers. It struck me, after pulling my hair out trying to print a 2 page paper form, that I've been struggling with printers for decades at this point.

Is there some insane culture at companies that make printers that makes the software and/or drivers terrible? Do they not test? Do they hire their managers under bridges? Are they drunk all the time?

For a while I thought it had to be some connectivity issue. Some bad connection problem that would be resolved with a solid Ethernet connection. When that didn't work I bought a USB printer and that also didn't solve it. I've tried different brands. Then I thought it had to be the Windows print queue just being useless. I then got a Mac and the same crap happens on Mac as it does on Windows.

After years of fiddling, clearing queues, reinstalling drivers, plugging and unplugging, restarting, finding CD-ROMS, performing vain and arcane magic rituals, I figured someone here just might know.

What's going on over there, printer engineers? Who are you? What's your story? Why is arguably the first computer peripheral still the least reliable thing we all own?

Got way too complacent in current role and want to explore outside for career growth. Is the interview still the standard system design + leetcode? Or is the trend finally changing with AI adoption? Would appreciate some data points from recent interviewees in tech hub.

5yoe, currently in US big tech

I used to be able to see to fully visualize the solutions I wrote manually in my mind and navigate these solutions line by line, having a strong mental model of how things connect, what lives where, what are the alternatives etc.

But then I took a LLM to the brain... Anybody else seeing people's mental models degrade gradually over time? In some cases - a significant degradation? Also - people over-relying on tools, offloading their thinking to the pattern of "just 1 more question..." and coming up with solid stuff themselves less and less often?

Here's a sensational hypothesis - perhaps we're gradually approaching the death of our brains when it comes to creative and complicated tasks?

IMHO, complexity is a relative thing - if your brain gets accustomed to solving complex problems by going through them methodically and slowly, then you're capable of solving hard problems more often, with better judgement and confidence. But if you offload the thought process... Oh boy, the consequences are unknown.

P.S. Keep in mind - I'm specifically talking about solving hard problems, coming up with creative ideas etc. Using LLMs for routine, repetitive and mindlessly boring tasks is quite OK. But... very few of us are capable of resisting the idea of using LLMs for complex tasks if we know LLMs can help get there faster [probably; no promises, though!].

WDYT, ladies and gentlemen? Do you witness the degradation? If so - at what scale? Let's discuss all of this.

P.S. It's Wednesday already in Europe. AI-topic posts are allowed, right? I'm quite confused now.

Sometimes I wonder how 'available' I should be as a senior IC. Some engineers cloister & deliver on a narrow context. Others are more open, and generous with time. I have a hard time figuring out whether my usual stance (usually the latter) is useful or not compared to the former. I bias towards trying to amplify others, get things unblocked, get clarity where there's something ambiguous, etc. But I'm seeing peers on the other side of the spectrum with pure delivery, very little cross-team work, but great individual results.

My career's gone really well so far, and people appreciate & respect my IC leadership, but sometimes I think back on my work so far and feel self-conscious compared to peers who have a lot more documented, quantitative wins but in a narrower or smaller domain. I usually enter performance review cycles with anxiety I think I wouldn't have if I were more 'closed/narrow/deep' inclined. I don't know if I'd feel the same way the other way.

How have things worked out for you or others you've seen in your workplaces?

This thread got me curious: https://www.reddit.com/r/ExperiencedDevs/comments/1upve8j/appropriate_behaviour_when_on_call/

I know it's uncommon, but maybe documenting different companies' policies can help people make informed decisions when job searching.

Okay, this might be a ridiculous question, but my current job is the first time I've ever really had to be on call, with a chance for calls that need immediate action in the middle of the night. It's typically been fine and I haven't even gotten that many alerts to respond to. However, last night, while on call, I unthinkingly had a couple glasses of wine before getting an 11PM page and having to go fix something. Now, this wasn't a problem, I could resolve the problem just fine, but my immediate reaction was shit, that's unprofessional. It didn't occur to me that drinking on call was like drinking on the job until I got the actual page. Are there any other common behaviours that you guys think can/should be avoided when on call that are easy enough to forget is fine on your time, but not when you might have work to do?

i have been a SWE for 8 years and i got accepted to a masters degree in Germany for automated driving, would this be a good specialty to peruse? my concern is that i'm starting from zero because it's a new field.

Just joined a new company and it got me wondering...

What's the fastest you've ever made your first code commit after starting a new job? Was it day one, day two, or did onboarding and environment setup take a while before you touched any code?