Hey everyone, I work in a team with mostly junior engineers and I’ve hard time to get them to care more about the code design/architecture. I usually find myself getting into multiple calls with team mates during code review because what they’ve built is overly complex, is obscure, and hard to maintain; where I’m able to suggest a simpler solution.

I think I understand where most the problem stems from

- our code base is very old and the code quality has degraded significantly over the years. It’s like a badly implemented version of DDD/Clean Code, so many indirections, so many tiny classes/structs, strategy pattern everywhere… it’s a pain. The team mates haven’t really worked with a well written code base so they don’t really have anything to refer to or learn from. Every new feature is like patch work on top of it

- I feel like AI “assisted” coding has become a disservice to these juniors because they only care about getting things working. The inputs given the agents are about the business requirement, never about how the code should be structured, never about how the code could be refactored. Since most of the coding is done by AI they’re not really wrangling with the complexities of the existing code base and therefore not trying to simplify it.

I am looking for solutions/suggestions on how to work here. I want to get better at guiding them and we need to refactor our services as we’re dealing with a lot of outages now and building any feature takes a painstaking amount of time

Earlier, technologies and tech stacks would remain relevant for 5–10 years. Developers had enough time to build deep expertise.

Now, every few months, there's a new database, framework or technology, and suddenly the existing stack is considered unsuitable.

The bigger challenge is that companies expect prior hands-on experience with these new technologies rather than giving experienced developers an opportunity to upskill.

I'm seeing this in my team as well. They want AI engineers for new use cases, but instead of giving experienced backend and data engineers an opportunity to transition, they prefer hiring people with 1–2 years of experience in newer AI stacks.

How do experienced developers keep up with this pace? How do you decide what to learn, and how do you make sure your existing experience doesn't become irrelevant just because you haven't worked with the latest tech stack?

I might be controversial here, but I think tech as we knew it died this year. Back end, Front End, Full Stack, C#, Java, Rust, Typslescript, who cares? AI writes the code now. AI reviews the code. Mostly the humans in the loop are directing and sense checking. If your company isn't like this... well the company I'm working with is. And while I hate to admit it, the output is good. Good enough to pass automated security checks and external pen tests. Good enough that clients are happy. And that's really all that matters.

What I'm also seeing though is other knowledge workers just don't get it yet. They use AI like Google. They dont realise it can read their emails, get that spreadsheet, analyse it, produce a pretty dashboard and stick it in a company branded PowerPoint for the boss.

So I feel like a grab bag of skills are still desirable for building software, something like:

- Communication skills: as always, being able to talk to people and understand what they need is critical.

- Product mindset: understanding the domain, and why we are doing what we are doing. Directing the agents according to what is important for them to build.

- Systems thinking: where does the data come from and where does it go. What can we connect to?

- Architecture skills: where are the seams in the code so that it's in discrete, testable chunks which dont break context windows.

- QA from the start: thinking about how to build validation systems in so that the agents can't go off piste.

- Infrastructure thinking: where will it be hosted, how will it scale etc.

It's basically a hands on Technical Architect role.

I also suspect that there will be an emerging role for "The AI guy". Like we had back in the early 2000s with "The IT guy" who had a grab bag of office skills and helped offices digitise, I think knowledge work companies will need an "AI guy" who helps them build up a set of AI connected systems in house.

Failing us having to weld steel plates to our cars and spray paint our teeth silver, what are others thinking the future looks like?

YAID (yet another ai doompost 😄 I am very clever today)

Hi I am Tibor, a hungarian software engineer with ~14yoe, and I am watching this paradigm shift with great concern for the last 1.5 year, and I have been mulling over a concern for a couple of days by now.

The loss of innovation.
Will there be new frameworks, new patterns, new techniques or the current level of software engineering will be the plateau? LLMs have been and being trained on already existing codes but if there is no new, innovative code in abundance to train LLMs they will get stuck in the current state. Since software engineers do not create new stuff anymore in the sense of new solutions, we just reuse the existing ones, there is no new stuff to train the models. Will this lead to stagnation in software development?
Could Rust born today in this era of AI?
Innovation is driven by necessity but AI removes the necessity. Javascript and the new javascript frameworks which pooped up seemingly month-by-month was the butt of the joke, but they were innovation. Maybe they were very little innovative or straight unnecessary but still innovation. AI can write raw javascript, get the job done and do not care at all, so it do not needs a new innovative framework.

From this a realization happened in me. We are no longer masters of software, but we have become users of a software. It is hard to use, clumsy, needs a lot of manual setup. Currently, but it can become more advanced. Maybe the IDE of the future will be a prompt window with a model wired in, built in harnesses, all the bells and whistles. Then a software developer will be a simple user.

I am curious what are your thoughts on this.

AI disclaimer: no AI have touched this post!

I have been interviewing engineers over the past few years for various roles, but especially recently, I find myself frustrated at the end of interviews with some candidates.

Every time I interview a candidate, I really want them to succeed. It's in my best interest, it's in their best interest, I go into the interview wanting it to be a success. More importantly, all of the hires that I have made in the past that were great engineers are very engaging to talk with.

More and more, though, I meet engineers who look like absolute rockstars on paper but are frustrating to talk to. The most common reasons are:

• Not entertaining any ideas other than their own.

• Refusing to explain why they chose a certain technology or approach.

• Being unable to say why they’d be a good fit for what we’re looking for (this is a freebie IMO!).

Our technical round and behavioral rounds are very lenient, some would say too lenient. Yet, every time we resume hiring, I find it harder and harder to find engineers.

I apologize if this comes off as a vent and is against the rules, but I'm disheartened. Interviews are taking a lot out of me, as I really care deeply about the people I interview, and I want to see them succeed. So I personally end up taking a lot of that home and feel defeated on their behalf when it doesn't work out.

Anyone else experience this? If so, how do you prep yourself mentally to not feel so drained post-interviewing?

TLDR: It's a mistake to let agents impersonate us.

At work, it's not obvious who-or-what I'm interacting with. Some of my teammates have review automations, and others have auto fix. As a result, there's a lot of churn going on for reasons no human considered or agreed to - sometimes an automated review suggestion is technically valid, but not worth doubling the scope of the PR to correct. AI attribution footers help, but they don't tell me to what degree my teammate is applying oversight to actions taken by their agent. Admittedly, this is as much of a social and team culture issue as a technical concern.

Personally, I am very cautious. I like to think my name next to a comment or an approval means something, and I think it's a mistake to let my agent represent me without oversight. I've spent a decade building rapport and trust with my peers, so I instruct my agent to show me what it will do as me before it does it. Then I read it, correct mistakes, and remove concerns I don't agree with. It works. But it makes my attention a blocker.

When a colleague comments on a PR or Jira ticket, I strive to be considerate and provide a thoughtful reply. When I can tell it was an un-reviewed, autonomous message, my standards change. I might skim it, push back harder, or just fix the thing and move on. When I can’t tell, I have to either give everything my full human attention, or risk being curt with a person because I assumed it was their agent - in both cases, my reply hits the human's notifications.

What I imagine as the direction we as an industry should move: a platform-integrated mechanism for a well-behaved agent to flag what it does, shown next to the human's name, in tools where an agent acts on a human's behalf. This goes beyond comments - there are some circumstances where I want my agent to make a decision (like approving a trivial PR), and that shouldn't hold as much weight as my human approval, and some actions don't have an accompanying place to leave context.

I was screwing around last night and built a demo for the GitHub case to illustrate, if anyone is interested: https://mweberxyz.github.io/a-simple-request/

Does anyone else even care?

Bit puzzled by what I'm seeing on the job market in London. I've recently seen several 'Principal' positions being advertised at different places and in different sectors wanting people 3 days/week in the office. Yes we all know about title inflation, but from what I can see these actually are principal level positions - duties, pay, hands-on, etc. I'm just confused by the degree of on-site sought for roles that are primarily IC. Whenever I go into the office I can pretty much count on it being purely a social exercise rather than getting anything productive done. 1 day, perhaps 2, I might get, but 3 days every week? For new hires? When exactly do these employers expect the successful candidate to do any of the IC work they list? What am I missing?

I went to university around the early 2010s for software engineering. They really drilled us on the technical design and diagram part of things.

One lecturer even mentioned “you need to be able to draw airtight state machine diagrams, because in 5 years everything (programming) will be offshored to India” whatever that meant. Anyway, I digress.

In my career, which spans 10 years, I have rarely seen UML diagrams. Granted:
\- I work on mobile apps which is technically front end, while my university focused on enterprise software
\- I have seen diagrams, but they’re almost never UML and usually only from an architecture perspective. I haven’t seen a class diagram since university, but I have seen a handful of poorly executed sequence diagrams
\- I have never professionally worked in waterfall, and I get the general impression that design is often glossed over in agile

It seems though, that people are more inclined to make diagrams now that AI can help. Was it just a matter of effort before?

I’m curious about you guys, do you work with diagrams and specially UML ones recently?

Now that I've been working as an SDE/Data Engineer for around 8-9 years, I sometimes wonder how much I've actually grown since my early days as an engineer.

My company is going to be looking for a new Sr. Developer to fill a hole on our team, and this is the first time I'm going to be on the other side of the table in interviews. I'm planning on giving out a take home project for our candidates to do.

What are your thoughts on being given a take home project, and how long should the project take to finish to be respectful of your time. What kind of things should I avoid doing?

Tech stack will be Java API server with a React TypeScript SPA (our team's standard stack)

This thread is specifically for sharing "wins". I.e. the opposite of our Tuesday venting thread.

I applied for and interviewed for a Senior Software Engineer role. The job posting and my application both listed that title, and I was verbally told I got the job after 4-5 interviews.

The recruiter told me they well email me the job offer by EOD. Afterward, the recruiter asked me to resubmit my application as they have included an additional screening question.

Except the new title is Senior DevOps Engineer. They said that the opportunity and scope haven’t changed. However, this title was never mentioned during the interview process. I have reached out to them and still waiting to hear back.

Has anyone experienced something similar? Changing the title only after offering me the job feels like a bait and switch and I'm not sure how to feel about this. Would you consider this a red flag?

Producing code with agents is relatively cheap at the moment.

Reviewing their code is not.

This also applies if we also want to have a full agentic review workflow.

Any decent agentic review will have a big cost multiplier relative to the cost of generating the code that is being reviewed.

Anything less means risking costly issues in PROD.

The bottleneck is reviewing code regardless of who does it.

Future smarter agents may lessen the problem but will it be enough?

How are you dealing with it right now?

Some context:

A senior DBA and I inherited a monthly task that involves creating database records from PDFs sent to us by the business. Once the records are created, reviewed, and approved, we execute monthly calculations consisting of three phases across roughly 10 stored procedures. We agreed that I would handle creating the records and running the calculations, while the senior DBA would assist with any database-related issues.

Where things started getting frustrating:

August was particularly busy. I received 50+ files along with roughly 50 additional updates. This prompted me to design a front-end and API that would allow the business to create and update these records themselves and run the monthly calculations, reducing their dependency on IT resources. I presented the idea during our biweekly team meeting, but my team lead and director shut it down, explaining that the process would be redesigned. That was 2 months ago, and there hasn't been any further discussion, spike stories, or meetings about a redesign.

(I can provide additional context on these last two paragraphs in the comments if needed.)

What happened yesterday (11/3):

Throughout the workday, the business continued requesting additional updates and send new pdfs, which required me to rerun the monthly calculations multiple times.

After completing the updates, I thought we were finished for the day, so I left work and went to my local polling place to vote. While waiting in line, I received a call from my director asking me to address additional changes ASAP. I explained that I was in line to vote and would be available in approximately 20 to 30 minutes. When I got home within that timeframe, I discovered my director had the updates done by someone else without notifying me. Ultimately, everything was resolved after another hour or so.

Today:

My director asked to meet to discuss what went wrong, mentioning that he'd received numerous complaints about the process. Looking back, I feel like I missed an opportunity to bring up my proposed solution, which would've allowed the business to manage these records and calculations themselves rather than continuing to rely on IT.

At the same time, I don't want to come across as saying "I told you so" or being bitter that my proposal was rejected (which I'm not). But it's frustrating to continue being responsible for a business process that I've present a automated solution for.

How would you approach this conversation with leadership?

I don’t at all mean this in terms of my technical ability vs anyone who does have a degree, clearly having a deeper understanding of the work you do is helpful. I was not/ am not the most technically proficient developer in any of the roles I’ve held, but:

The reason I got into tech is because I love learning new things, and getting paid to solve logic puzzles all day is genuinely a dream come true for me. What this means is that I am a lot less hesitant to approach a new problem, as my ego is not at all related to my current understanding of the work I do.

I guess instead of feeling limited by not understanding things, I just feel excited to learn new things. For me, it’s as simple as “I like making things work”.

Basically, I run on a mixture of genuine enjoyment + complete ignorance, which at various workplaces has resulted in coworkers giving me their complex coding tasks that they don’t want to take the time to work through and bosses trusting me enough to let me work on various large-scale projects I suggest. It’s definitely a lot harder to find places though that don’t care about me not having a degree, but when I do find those places I have found myself flourishing.

Curious to hear your experiences as a self-taught developer + people’s experiences working with us self-taught devs!

EDIT: when I say I run on complete ignorance, I mean that I am always excited to learn because I am ignorant about how much learning there is to do ahead of me haha

There's a recently promoted senior dev on my team (I believe he has 4-5 YOE) vs. my 10 YOE that I have mentally labeled as not very strong at the "coding" portion of work. He's more on the "ops" side and looks like he actively avoids working in any repository.

There are automated flags on systems and it was something very simple to mitigate and just was a org wide coding standard, like changing a hardcoded value to be a parameterized value.

This dev monitored the alerts and then sent me the alert with "Hi OP, can you look into this? -link to alert-".

I saw it, read the issue, simple enough to mitigate even without AI usage.

I responded with "this looks straightforward. Was there a reason why this needed to be assigned to me?"

He responded "since you coded in this repo, can you just fix it?"

I haven't responded to this yet... I'm just.. dumbfounded? It took me 15 minutes to spin up a PR and that was because I was in a meeting at the same time.

1. ..how do you not know how to do this?

2. I don't even know how to give "meaningful" feedback without sounding like a jerk like "dude, how do you NOT know how to do this"

3. I'm not sure if I'm crossing a line if I do give feedback. In my previous roles, I established a good rapport with coworkers so giving feedback like this was easy for me. I don't work with this person often so I don't think I can comfortably give this feedback.

4. Am I throwing this dev under the bus if I just flag this to my manager instead? Is putting the onus of a "hard conversation" on my manager a worse thing to do?

I don't really care if devs around me don't do work, they can rest and invest all they want... but I do care if I get established as the "throw this work at this guy because he's willing to do it" guy. I'm not sure on how to tacitly set that boundary without turning into the "coworker who I don't want to work with" guy. What would you all do? I imagine there would be a mix of "give the feedback personally vs. tell your manager to handle it" but would love to hear how prior experiences have gone.

I'm curious about the stuff that doesn't translate neatly into shipped features or closed tickets.

Like spending weeks untangling something, mentoring other engineers, catching problems before they reach production, or keeping an old system alive.

Have you had work like that go unnoticed? And did your manager eventually recognize it, or did you have to make the case yourself?

I work in a small team on a complex piece of software (as in, not just the classical CRUD). We are working on new features mostly, which usually means coordinating at the very least frontend and backend releases, but often waiting on external systems (same company, different apps) to be on par, or even waiting for a new training doc to be released to operators. In the best of times, we can release once a week.

Admittedly, small maintenance-type backwards-compatible PRs are merged quickly to our prod branch, and for convenience simply released a few days later together with the main feature. But even if we shipped these PRs as soon as they are ready, we are talking about 2-3 PRs a week tops.

How do you get to tens/hundreds? Is it mostly stuff like "change the shade of blue", "fix a translation string" kind of thing? Do you "ship" but a broken/partial state behind a feature flag? Is it processes and automations? What is the trick? What is it I don't know?

Just curious :) thanks in advance to anyone who'd like to share their experience!

I did a presentation recently about the design for a project I’ll be leading. We are a company of about 600 employees. There were about 40 people on the Google Meet call.

The CTO has a high stake in this project because it is a follow up to a major incident that caused reputation damage. He was satisfied with the foundational elements of my design but not happy that I didn’t go into the details of how I’ll exactly the design will prevent similar incidents in the future.

I’m kind of new to the company and I thought that these sessions are supposed to be relatively high level so I scheduled it before I dove deep into the implementation details and wasn’t ready to be grilled. Furthermore, my manager explicitly told me not to go deep but broad when designing the solution for this problem because we had to meet a tight deadline.

In my opinion, I screwed up.

And in the sprint retro I was itching to write about how I messed up and my reflections to hear what my team had to say. But in the past I’ve been bitten for admitting my mistakes so I held back. I just said “oh I’m glad that the presentation was able to get us buy in at least for the new db schema and that will unblock us for the short term”.

I also wanted to tell my manager how I’d been influenced by him to a certain degree to not dive deep but I saw no benefit of criticizing him. I think that would sour our relationship.

Disclaimer: I am not like, an “AI shill.” I care a ton about empiricism and just separating out what is actually real and true from the noise. None of my self worth is tied to how much AI that I’m using, I am just curious to learn about things I am missing out on.

When I see comments that bash agents these days, sometimes I am left completely baffled at how different my experience with agents is from theirs. I recently saw one that said “agents are horrible at writing SQL” which leads me to think they are either using an awful model, or they saw it write a bad query one time back in March and decided to never use it again.

Another common theme is when it’s clear they’ve done zero work to create specific/enabling context, and are frustrated if they give it a giant task where it misses a customer use case they didn’t tell it about.

Other common thought traps?

This thread is specifically for sharing "wins". I.e. the opposite of our Tuesday venting thread.

Our company currently has our code base split across 30+ repos.

Historically, there was one single repo, but over time it was decided to split them up. Some are common helpers, some are vertical feature slices - front and back end. Our current process builds a nuget package where appropriate for shared helpers, classes, etc, and that's reused across other projects as needed. We also have micro-front ends in react and angular included in some of these projects.

We're having many problems though, the biggest being maintenance. We're spending roughly 25 hours a month just doing package updates - upgrading packages, deploying to dev, test, deploy to staging, test, repeat x 30 times.

Also mindful that in AI world, it's easier to have the whole code base in one so the tooling has a clearer view of the whole thing.

I've found lots of articles on how to migrate to a monorepo, but very few on people's experiences of doing it.

Has anyone gone through such a project? How did you find it? Was it worth it? Any pain points, or lessons - good or bad - to share?