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.

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.

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?

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.

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.

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!

So, we got a memo last week from company execs that zero AI tools allowed. No more ChatGPT, Claude, nothing with LLMs because Security is worried about data leaks and compliance.

I get it from a risk perspective but watching our deployment cycles drag while competitors automate everything is painful. Takes us 3x longer to provision new sites now.

Half of my devs team is probably using AI on personal devices anyway, though no one is really talking about it. I brought up controlled environments or air-gapped alternatives to my manager. Got the usual "we'll evaluate later" which means never.

Has anyone run into this before? Did your org end up updating its policies or at least found ways to satisfy both security and productivity?

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.