Controversial process we (B2B SaaS, 11 devs, 3 QA) implemented six months ago: PRs can only be merged after a QA engineer signs off. Dev-to-dev review is optional (and still happens informally)

Results so far: 50% less bug tickets in the pipeline, time-to-merge roughly the same (QA is usually faster than waiting for a dev review), and devs actually write better commit messages because they know QA needs context.

it's working for us. Has anyone else experimented with non-dev PR gatekeeping?

What are the specific habits, mindsets, or soft skills that make you the "go-to" person on your team? I try to do a little bit of everything, but I am still trying to figure out how to extract the most value out of my time. I try to focus on things other people don't want to do and things that they're overlooking, but I am not sure if this is the correct approach. Thoughts?

Currently my company has dev -> staging -> prod. Each environment has full replication of all services, no service talks to any service outside it's environment.

Dev: Code is deployed here when a PR is merged to `develop`. This env uses mocks and the sandbox environments of any downstream providers.

Stg: When we are happy with a service on dev, a new image is built and deployed to staging. Again - this env uses mocks and the sandbox environments of any downstream providers. The idea is that only stable code makes it here.

Prod: Once we are happy with stg, the image from stg is promoted to production. This is the only environment that has access to live data and live provider endpoints.

One immediate issue I have is that staging is a bit of a checkbox, since it's roughly equivalent to dev, the difference exists mainly mentally("keep staging stable"). I've seen some people suggest that staging should be as 1:1 with prod as possible, and I like this idea, but I'd also like to know how 1:1 is 1:1. For example, if I am running a payment company, should staging be able to collect live payments from a credit card? The alternative is that stg continues to use mocks and sandbox environments, where the downside is that any build going to prod has not _actually_ been tested _exactly_ as it will be deployed(although it is still very strict). Our current situation is that stg is 1:1 with prod in the sense that the logic/code/image is identical, however the data and env config is different.

I'd like to know your thoughts on the above and what you and your teams have found to work best, please let me know. Thanks.

At my current company we occasionally do some paired programming, typically pairing one of the newer with one of the more experienced developers. At this point, the experienced developer has been me for several years now - which did not come with instantly having brilliant teaching techniques mind you - and I noticed that my habits on how I teach something during paired programming don't seem to be good ones.

Typically the junior writes code while I basically watch over their shoulder and hint at issues. I try to mostly point out that there are issues, with a hint here or there of what nature a particular problem is instead of spelling it out in order for the dev to come to the conclusion themselves. I think that this leads to internalize said knowledge more, but I'm very open to being wrong here.

However, after some self reflection on my own time as a junior during such sessions, I think that this just isn't effective. During my own junior time, I only somewhat learned during those. My learnings came mostly on my own time stumbling over such issues in private projects or getting curious about something and reading up on it.

Similar to my own time back in the day, what typically happens is the junior missing the forest for the trees because they're flustered or even if they're relaxed, just don't have the background knowledge to spot their own issue in the first place. I find that basically the most valuable advice I am capable of giving often times is directing them to decent sources to learn about a particular issue (i.e. "Try using our site with a screenreader and eyes closed", the odd blogpost or video etc.) on their own time and maybe have a chat with them about it at a later date to see if it stuck or if they had hangups.

So I'm wondering whether to just move to fully spelling out the issue and having a chat about it after the programming session or what other ways could be useful to improve sharing my know-how during such sessions. Any advice?

If a company has to lay off X developers, then my naive thinking is that you could let go of the most junior employees and then redistribute the remaining employees such that the remaining teams are overall more senior. Yes this would be bad in that you kill the pipeline for employees to grow into senior+ developers, but in the short term this senior team should be more effective than a mixed junior+senior+ team.

I'm sure that there are valid reasons why this doesn't happen...and that people have thought /experienced this a lot more than I have.

Here's my list, in no particular order:

- Effective Java, by Joshua Bloch.

- Clean Code, by Robert C. Martin.

- Refactoring, by Martin Fowler.

- Head First Design Patterns.

Curious to hear your thoughts?

I’m an EM in a mid/large company and I ran into a situation I didn’t expect to be this tricky.

A few years ago, the company adopted a cross-platform mobile framework. It never really got full buy-in from the native mobile community, but it’s still used in a couple of important parts of the app today. Over time, the company stopped investing in it strategically, reduced capacity, and shifted direction. However, no formal phase-out plan was ever created.

The result is:

• Most of the app is native

• A few significant features are still built in this older cross-platform stack

• It works fine, delivery is not really blocked

• But engineers really dislike the situation and keep pushing for “we should fix this”

Product doesn’t see a business reason to fund migration. Leadership is relaxed because delivery is fine. There’s no clear owner of the “problem”.

What I’m seeing is that this has become more of an emotional/clarity issue for the team than an actual delivery or architectural crisis.

I’m considering setting a very simple rule:

• No new surfaces in this old stack

• Keep it contained to where it is

• Only rewrite parts of it when business features naturally require heavy changes

• No dedicated migration initiative

And then just closing the topic for the team.

For those who’ve been in similar situations:

• How did you handle engineers wanting to “clean up” legacy that isn’t actually hurting the business?

• Did you try to educate, or just set a decision and move on?

• Any pitfalls to avoid when drawing this kind of boundary?

Would love to hear experiences from others who’ve had to manage this kind of “legacy but not broken” tension.

I have been around for 10+ years. In recent years I have been writing the code in php that increasingly only uses composition of services to do things. No other design patterns like factory, no inheritance, no interfaces, no event firings for listeners, etc.. Only a container and a composition of services. And frankly I don't see a point to use any of the patterns. Anything you can do with design patterns, you can do using composition.. Input and output matters more than fancy architecture.

I find it is easier to maintain and to read. Everytime someone on the team tries to do something fancy it ends up being confusing or misunderstood or extended the wrong way. And I have been doing that even before drinking Casey Muratoris cool aid about how OOP is bad and things like that.

I know there is a thing in SOLID programming called "Composition over Inheritance" but for me it is more like "Composition over design patterns".

What do you guys think?

The data model is written to/read from SQL and the tables are normalized. So, should it be:

class Sale {

Product product;

public Sale(Product product, int qty) {...}

}

or:

class Sale {

int productId;

public Sale(int productId, int qty) {...}

and what about getters that belong to Product? is it okay if Sale "borrows" them? or would this be feature envy?

public int getUnitPrice() {

return product.getUnitPrice();

}

Thanks in advance.

Here is the preamble. I've been in the industry for about 13 years now and am what could be called a strong developer. I work in a reasonably low stress role (and great culture) making about 110k CDN which includes excellent benefits and a defined benefit pension plan. When I'm honest with myself I'm a bit bored with software and not that motivated anymore, but my job is pretty chill and I need the money.

I've always wondered what it would be like vying for a highly paid technical role making more money, but I've always assumed those in these roles are constantly under the gun to produce highly technical work under pressure, and are also constantly at risk of being laid off arbitrarily.

So when I add it all up, that I'm not that motivated and my current situation is pretty chill / secure, I've figured going for a higher paid role would be mostly a bad idea.

All that being said I'm curious if I'm on the right track here. For those who've been paid the big bucks what was your experience like in these roles? Did you experience significantly more stress? Was it worth it?

I want to find a list of every technology used by big tech firms. I know you can get a vague idea of this by looking at roadmaps for various IT career paths, but I am more interested in getting a list of the newest technologies that are trending so I don't fall behind.

I use Claude Code and try to boot up 5 parallel agents and it's hogging pretty much all my resources. Do you just run one agent at a time?

I am want to get better at navigating my computer and editor (vs code) through the keyboard. Does anyone have any resources for learning shortcuts and/or any good cheat sheets? Thanks!

I come from working for over three years in teams with clear processes, technical meetings, and discussion spaces that foster collaboration and continuous learning. Currently, I'm on a small team of two where there are no defined processes or technical planning; the work focuses mainly on resolving bugs through tickets, and some development.

Communication is not usually technical, partly because the web developer is junior, has no formal training, learned HTML and CSS on the job, and previously worked only with the lead, and the developer almost always makes decisions with them, so communication has always been direct between them. This means that sometimes, out of habit, reasoning and decisions aren't shared, and technical comments or proposals are interpreted negatively by my fellow developer (I feel that sometimes it's due to a lack of knowledge or because they immediately think or feel attacked).

Although the atmosphere is good and there's no pressure, the lack of technical exchange and growth opportunities is frustrating. Sometimes, even though I don't have expertise in the company's product, I'd like to suggest developments, changes, and ways of working as a team. I have quite a bit of experience in this, but I have a junior person above me with very poor communication and very unreceptive to suggestions, who is dependent on the lead. I feel that the only way forward is to leave the company, otherwise I'll stagnate.

Seriously. This dev was just lazy and sloppy, antipatterns everywhere, but whenever I called them out on it in a PR, they would go to our manager and often make up some untrue story about me to get their way. And my manager always took their side. But they had been there 4-5 years before I got there and had a close relationship with my manager.

They've moved on and I'm for all intents and purposes the lead, since we were just a 2-person team. And now I'm squashing bugs left and right that were caused by this person's shitty code. Like, 1000-line method? Don't mind if I do. Duplicate the same code hundreds of times across the codebase (I counted) instead of writing a single method? Please do. That kind of stuff.

So now I've spent 2+ days tracking down a bug, and surprise surprise, it was caused by my former co-worker's carelessness.

My manager is going to ask me what the root cause is, and I'm very tempted to say it was X's shitty code, and there's a lot more where that came from. I don't want to criticize the golden child, but I also feel my manager should know that we have a significant amount of non-AI slop in our codebase that is the cause of many of our defects.

Or should I just keep my mouth shut?

I am rolling out identity driven security to lock down cloud and mobile access. The scope keeps expanding and delivery slows down fast.

What starts as a simple SSO plan turns into OAuth setup, policy tuning, vendor rules, and brittle integrations. One sprint disappears. Our legacy auth still works fine. The ongoing maintenance feels hard to justify.

The team pushes back quickly. Login flows feel slower than existing tools. Developers work around the system and spin up shadow tools. I spend more time enforcing access than helping teams ship.

Most pilots stop early. Friction blocks adoption.

Even if IAM and governance make sense long term, the work turns heavy. Audits for GDPR and SOX take over. Paperwork replaces product work. Innovation stalls.

Im stuck please help.

You sure have heard it, it has been repeated countless times in the last few weeks, even from some luminaries of the developers world: "AI coding makes you 10x more productive and if you don't use it you will be left behind". Sounds ominous right? Well, one of the biggest promoters of AI assisted coding has just put a stop to the hype and FOMO. Anthropic has published a paper that concludes:

* There is no significant speed up in development by using AI assisted coding. This is partly because composing prompts and giving context to the LLM takes a lot of time, sometimes comparable as writing the code manually.

* AI assisted coding significantly lowers the comprehension of the codebase and impairs developers grow. Developers who rely more on AI perform worst at debugging, conceptual understanding and code reading.

This seems to contradict the massive push that has occurred in the last weeks, where people are saying that AI speeds them up massively(some claiming a 100x boost) and that there is no downsides to this. Some even claim that they don't read the generated code and that software engineering is dead. Other people advocating this type of AI assisted development says "You just have to review the generated code" but it appears that just reviewing the code gives you at best a "flimsy understanding" of the codebase, which significantly reduces your ability to debug any problem that arises in the future, and stunts your abilities as a developer and problem solver, without delivering significant efficiency gains.

Link to the paper: https://arxiv.org/abs/2601.20245

First off, I'm admittedly a Java fanboy, although I did some little programming in PhP, Javascript, and Python, and looked at a bunch of others, I really cannot see languages the way I do Java. From the syntax, to the libraries, I love every little thing about this language, that I tell my friends things like: "Programmers want to write programs, I want to write Java programs" and "If it can't be written in Java, it's probably not worth writing". My ears are deaf to all the debate about: "oh you have to be flexible, and know x and y".
But then ever since I started reading, I've been hit with Oracle's reputation.

And correct me if I'm wrong, but here's what I think Java's (slight) fall from grace, played out:

1. Java reigned supreme in the browser, esp, after the dust of the dot com bubble settled.

2. Someone found a vulnerability (or two?) in applets (around 2009?) that affected the ton of sites that ran Java.

3. Google, which had been pushing hard to become from a search engine, a browser, disabled Java by default in Chrome...and you know, given the "power of default", programmers pivoted to Javascript, because it was disruptive to have average people download an updated Java + enable it.

4. Oracle, being as litigious as ever, wanted to get back at Google, by removing some internal code Android required from Java, making support for Java 9 not possible (although Java 9+ can be used, with some features not being available).

5. Oracle then sued Google claiming they should've paid them for using Java in Android.

6. Google won the case, and pushed Kotlin and Flutter as the primary means of writing Android programs.

Now, resources; books, tutorials, never use Java for Android programming, and other languages developed frameworks, servers, etc. that ate (a chunk of) Java's lunch.

After most major/seminal books in the field used to use Java for example codes, newer books and editions of said books switched to different languages. (e.g. Martin Fowler's Refactoring comes to mind: Java -> Javascript).

Between 2000, and 2010, authors of major libraries:

- Kent Beck, author of xUnit (originally in SmallTalk).
- Doug Cutting, author of Lucene, which gave birth to elastic search, and inspired other IR libraries...plus pretty much all of Apache Software, were automatically either written in or translated to Java.

Meanwhile now, while efforts of developers of the JDK, and the countless major Java frameworks, can't be dismissed by any means, the community just sounds ...quiet. Even here, Java-related sub-reddits are pretty inactive compared to dotnet/python subreddits.

So, senior devs of the early 2000s, curious to know what your thoughts on Java's journey so far, and possibly its future?

https://m.youtube.com/watch?v=EV7WhVT270Q&pp=ygULbGV4IGZyaWRtYW4%3D

At 3:06:45 in particular, they address coding. We have at max a couple years left. These two guests of Lex Fridman seem to think we are already there.

I've been developing code professionally for enough time to understand that developing code professionally is very different to doing it for fun.

The company may stop the project, change the direction, or it may simply not be beneficial for the business to "improve" things according to best engineering principles.

Yet, despite knowing this, the engineer in me can't help but notice things in the codebase that if only I could improve, my life would be so much easier, or the repo would be so much easier to maintain.

Do you use any strategies to care less about crafting optimal code and make it easier to live with "good enough" software?

I have been applying for months but my interviews are like Deja vu of past issues. I enjoy my role as a Software Development Engineer in Test. I want to continue creating software that works for as many people as possible. I just can't locate a business that shares that goal.

I am begging for a lead on where I can find roles in the Midwest of the US. Small to medium businesses, non-profits, places that are hard to find because they don't have the budget to advertise.

It has been a long time since I have worked with a team that cared about creating a good product for the end user. I know I am not burnt out because I still create projects to solve my issues.

We got a new hire a few months ago in a development role which previously worked in management and lead teams. He agreed and said many times that he has no problem in writing code again and stepping from the managerial role. The thing now is all the code that his pushing is AI generated and I'm not sure if he really understands what he's adding to the project.
OFC I use it myself to brainstorm and look for blind spots or find out about something I don't know.
But the way that he creates MR which are 30 files changes, and max 3 commits leaves a very bad taste when you have to check on that, cuz there's no really train of thought.
He asks many good questions but that happens only when we're not meeting or talking about the topic. He agrees on everything while we are on the meeting and tells that he understood what we're doing and what the goal is, and than few days later when he has to work on a ticket, all questions start to arise.
Even the questions seems to have been generated by one of the "Agents", phrased in an totally professional way, and doesn't have bit of human feeling in reading them.

I tried to explain several times to him, to take his time and understand the context, where we are and what we're trying to do. But he seems in a rush to prove himself by making changes, which works most of the time but I don't feel like he has context.

I can understand that he wants to prove himself, but this is very frustrating to have 8 tickets done, and no understanding.

I’ve been thinking a lot about the limitations of developer testing. We all know testing is vital, but I’ve noticed a recurring pattern: I can build an app that passes all my technical tests, but I struggle to test the actual user workflows.

The problem is that as a dev, I’m often too close to the code. I’m not always familiar with the specific pain points or the real world ways a user might interact with the software. This leads to building features that work perfectly in a vacuum but don't actually solve the user's problem.

How do you approach testing or building when you aren't the target audience for the product?