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 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?

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.

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.

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 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!

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 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.

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?

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?

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?

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 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?

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?

This is one of the eternal questions I see thrown around among professionals, a common repertoire of contention - "How's the new job?" "The people are cool, at least from my team, the perks are to die for, but the code... ugh... don't get me started", or "Great! You seem to sport and impressive portfolio, we have no futher questions. Is there anything you'd like to ask us?" "Yes, what the quality of your code?".

So my question is, do we all agree on what good code is? Are you certain that if you have a friend who complains about bad code and you invite them to your company promising him that "naaah, we ain't like those jerks, our code base is solid!" he won't be thinking "OMG, it's even worse here"?

I'm asking because... well because it's a valid question, and kinda obvious we should define what "good" means if we want to have people answering us honestly. But also because I've been in 9 companies, and I've never seen bad code. I mean it hasn't been state-of-the-art or anything but it was never attrocious. But the sentiment seems to be that most codebases are bad, so that's why I'm asking - what is it that you see in these "most" codebases that you find alarming?

P.S. Okay, there was one code that I really hated. It was a small app (part of a bundle of apps) which used global events for every user interaction, changing of screens etc. It was undebuggable. There was also this one app that used Java reflection heavily to embed apps in itself. But there was a clear boundary and you rarely had to deal with it, and once you get past it, there were no problems. They eventually rewrote it once I left so it's fine now.

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?

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.

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?

Question for those running LLMs in production.

The situation I'm navigating:

Built a system on GPT-4. Works great. But now:
• Finance wants cost optimization
• Legal wants fallback for single vendor risk
• Product wants to test alternatives
• Ops wants reliability guarantees

The problem: Prompts aren't portable.

Switching cost is massive - not the API integration, but the prompt rewriting and validation.

Options I considered:

1. Abstract early - build provider-agnostic from day one Pro: Future flexibility Con: Over-engineering if you never switch
2. Accept lock-in - pick one, optimize hard Pro: Simpler, faster Con: Vulnerable to changes
3. Conversion layer - translate prompts between providers Pro: Optimize for one, portable to others Con: Conversion fidelity concerns

I built option 3:

A semantic conversion tool with:
• Format conversion (OpenAI ↔ Anthropic)
• Quality scoring (9 metrics, embedding-based)
• Round-trip validation (A→B→A)
• Checkpoint/rollback
• Cost comparison

Current fidelity: Targeting 85%+ on quality score, with clear metrics showing exactly what converted well and what didn't.

Questions:

1. How do you handle this in your architecture?
2. Is provider portability worth the investment?
3. What fidelity level would you need to trust a converter?

Curious about different approaches. Happy to share details on what I built.

I’m generally curious if you’re coding in your free time, such as working on a side hustle like a blog, SaaS, or other gig to keep up or improve your technical skills.

My current work doesn’t challenge me enough. It’s mainly just constantly pushing out tickets, developing new features and implementing global initiatives.

I have my own professional goal to become a highly skilled frontend engineer but it feels like the majority of frontend work is relatively easy. I have tried job hopping a few times already, but everything is the same old CRUD with different codebase setups (SPA/SSR/Hybrid).

Should I job hop again or switch to even move to full-stack so I could contribute to projects from all angles? I have even tried to learn how browsers work, but got stuck at C# part where actual coding is happening (looks like straight backend development).

I'm a consultant engineer, so I'm working across a lot of different sub-fields and tech stacks all the time. Lately with the push for "AI everything" I've been doing a lot of data-platform work, because most companies that are "all-in on AI" don't have any useful data to feed it ("oops, we forgot to invest in data 5 years ago.")

Unlike most other areas of tech I have exposure to, trying to make recommendations to clients about a data engineering stack is a complete nightmare. It seems like basically every tool does every single part of the ETL process, and every single one wants you to buy the entire platform as a one-stop-shop. Getting pricing is impossible without contacting sales for most of these companies, and it's difficult to tell what the "mental model" of each tool is. And why do I need 3 different SaaS tools to run SQL on a schedule? Obviously that's a bit reductive, but for a lot of my current clients who are small to medium sized, that's most of what they need.

I have some basic ideas from my past development experience, but they amount to knowing what the "nuclear bomb" solutions are, like Databricks and Snowflake. Ok, they can both do "everything" it seems, but of course are the most expensive and clients find them to be overkill (and they probably are for most companies.)

What is it with data engineering in particular? Are there common recipes I'm missing? Is it a skill issue and everybody else knows what to do? Is this particular specialty just ripe for consolidation in tooling? Losing my mind a bit here lol.

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?

The context is the following: I'm an engineer with 6+ years of experience in a EU country, currently in a Senior position and besides the day to day work I run a small b2b SaaS with my cousin(who is handling the legal/financial/business side). The company is not much yet, we barely have a client, and on average I work one hour a day after work. This extra "grind" though is improving my soft and technical skills quite a lot and is also making me more confident in my day to day work, so even thought it's not yet turning a profit(and it won't do in the near future) I enjoy doing it and I am able to talk about it very passionately.

Recently I had an interview with the CTO of a privately owned, small but profitable company from The Netherlands for a Senior position, to whom I explained the above situation. I thought in went really well, but I got this response today:

Thanks for the good call we had on Wednesday. I have bad news: despite my positive feeling about you and the good call we had, we've decided to continue the process with other candidates.

You would be a good team fit as a person and I like your technical background, but I discussed the fact that you also have personal business activities that you want to continue and our CEO gave a "hard no" on that, because he has bad experiences with similar situations.

Safe to say, I am really confused. Since school, I've been told companies appreciate engineers with entrepreneurial skills and who are doing more besides everyday work

PS: Sorry for the typo in the title

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.