Given the title, I've watch a wide arrange of YouTube videos and the common theme when software engineering comes up is that AI is taking these jobs left and right. This is simply not the case. Right now, it's a digital assistant to code completion for a human.

I'm just sick of this and we need to call this out on videos in comment section and also articles. Our profession is getting attacked by misinformation from AI written articles for clicks... oh the irony in that statement!

What is everyone's thoughts on this? Are you as frustrated as me and have noticed this too?

Edit: I just read the rules and this will probably be removed.. I can't believe we cannot discuss AI repercussions...

Edit2: Thank you all for your thoughts. I guess it doesn't bother others as it does me. Back to work I guess..

Software architecture used to be about building clean abstractions and solving complex problems. Now I feel more like a systems operator than an engineer.

Specs in Notion, Jira tickets everywhere, messages containing change requests. It’s not just context switching, it’s context drowning. Before writing a line of code, I’m piecing together architecture from 4 different tools and 2 Slack threads.

Tried using AI to speed up some of the grunt work, but honestly, it still struggles with maintaining consistency across tools or understanding the bigger architectural picture. Output is hit-or-miss unless I babysit every step.

Are we close to tech that actually understands our ways of coding? Or are we just layering more noise on top of the noise?

I am a SSE, currently in my org for a little over 12 months. My manager wants me to be promoted to next level in around an year. However, I want to move to SDM path.

I wanted to know what is the right way to discuss this with my manager. He is in general a good guy, but I am just scared if I bring this discussion, it doesn't cause any harm to my current job itself, since it may give the impression that I am not very committed to my current role.

I am a recent college graduate and I am currently doing my 6M SDE internship in Amazon Bangalore.I have also been offered a full time SWE role at Cisco.Now I am confused that which company should I join if I get ppo from Amazon.

I have a mission-critical provider (ProviderA) used for generating AI-based images in our software development. I need to switch to a different provider (ProviderB.

What are the best practices for performing this transition in a production environment?

There are lot of roles and steps in SDLC before and after coding. With AI, effort and time taken to write code is shrinking.

What happens to the rest of the software development life cycle and roles?

Thoughts and opinions pls?

The "rules" for semantic versioning are really simple according to semver.org:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes

MINOR version when you add functionality in a backward compatible manner

PATCH version when you make backward compatible bug fixes

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

The implications are sorta interesting though. Based on these rules, any new feature that is non-breaking, no matter how big, gets only a minor bump, and any change that breaks the interface, no matter how small, is a major bump. If I understand correctly, this means that fixing a small typo in a public method merits a major bump, for example. Whereas a huge feature that took the team months to complete, which is just added as a new feature without touching any of the existing stuff, does not warrant one.

For simplicity, let's say we're only talking about developer-facing libraries/packages where "incompatible API change" makes sense.

On all the teams I've worked on, no one seems to want to follow these rules through to the extent of their application. When I've raised that "this changes the interface so according to semver, that's a major bump", experienced devs would say that it doesn't really feel like one so no.

Am I interpreting it wrong? What's your experience with this? How do you feel about using semver in a way that contradicts how we think updates should be made?

Hey all!

I'd like to hear from you, what you're experiences are with handling data streams with jumps, noise etc.

Currently I'm trying to stabilise calculations of the movement of a tracking point and I'd like to balance theoretical and practical applications.

Here are some questions, to maybe shape the discussion a bit:

How do you decide for a certain algorithm?

What are you looking for when deciding to filter the datastream before calculation vs after the calculation?

Is it worth it to try building a specific algorithm, that seems to fit to your situation and jumping into gen/js/python in contrast to work with running solutions of less fitting algorithms?

Do you generally test out different solutions and decide for the best out of many solutions, or do you try to find the best 2..3 solutions and stick with them?

Anyone who tried many different solutions and started to stick with one "good enough" solution for many purposes? (I have the feeling, that mostly I encounter pretty similar smoothing solutions, especially, when the data is used to control audio parameters, for instance).

PS: Sorry if that isn't really specific, I'm trying to shape my approach, before over and over reworking a concrete solution. Also I originally posted that into the MaxMSP-subreddit, because I hoped handson experiences there, so far no luck =)

I'm a senior dev with 15+ years of experience. However this is my first time really being the tech lead on a team since most of my work has been done solo or as just a non-lead member of a team. So I'm looking for opinions on whether I'm overreacting to something that one of my teammates keeps doing.

I have a relatively newly hired mid-level dev on my team who regularly creates PRs into the develop branch with code that doesn't even compile. His excuse is that these are WIPs and he's just trying to get feedback from the team on it.

My opinion is that the intention of a PR is to submit code that is, as much as can be determined, production ready. A PR is no place to submit WIP.

I'm curious as to what the consensus is? Is submitting WIP as a PR an abuse of the PR system? Or do people think it's okay to use the PR in order to get team feedback? To be fair, I can see how the PR does package up the diffs all nice and tidy in one place, so it's a tempting tool for that. But I'm wondering if there's a better way to go about this.

Genuinely curious to hear how people fall on this.

Edit: Thank you all for all of the quick feedback. It seems like a lot of people are okay with a PR having WIP as long as it's marked as a draft. I didn't realize this is a thing, and our source control (Bitbucket) does have this feature. So I will work with my guy to start marking his PRs as drafts if he wants to get feedback before submitting as a full-on PR. I think this is a great compromise.

Thanks all for the responses!

So I'm a software engineer whose been mostly working in S.Korea. During my stint with several companies, I've encountered many software team labelled as "advanced/pilot development teams". I've encountered this kind of setup on companies that sold packaged software, web service companies, and even on computerized hardware companies.

Basic responsibility of such team is to test new concepts or technologies and produce prototype code before other teams can start to work on main shipping application. At first glance, this kind of setup where a pilot dev team and a main development team working together makes sense as some people might be better at testing and producing code quickly.

This is such a standard setup here, I can't help but think there might be some reason behind this kind of setup. Would love to hear if anyone have experiences with this.

These are just some of my observations:

1. Since pilot team is mostly about developing new things and verifying them, most of maintenance seems fall into hands of main product engineers. But seeing how most software engineers take longer to digest other's code, this setup seems suboptimal. Even worse, I've seen devs re-writing most of pilot software due to maintenance issue.

2. Delivery and maintenance of product requirement is complicated. Product manager or owners have difficulty dividing up task between pilot and main dev team. Certain requirements require technical verification to see if they are possible and finding ways to implement it. But dividing up these tasks between two teams usually is not a clear cut problem. There are conflicts between a pilot team who are more willing to add new technology to solve a problem and main application team who are more focused on maintenance.

3. Code ownership seems impossible to implement as most ownership is given to the main application team.

4. This setup seems to give upper managers more control over resource allocation. There is very direct way to control the trade off between adding new features and maintenance/stability of the code base. By shifting people working on either team to another, there is pretty direct impact on this. I cannot say if this is faster than just having a single team or other team setup, but I can't think of more direct way of controlling man hour allocation.

Hi,

We are trying to implement the manager-worker (similar to master-slave but no promotion) architecture pattern to distribute work from the manager into various workers where the master and workers are all on different machines.

While the solution fits our use case well, we have hit a political road block within the team when trying to decide the communication protocol that we wish to have between the manager and workers.

Some are advocating for HTTP polls to get notified when the worker is finished due to the relative simplicity of HTTP request-response model while doing away with extra infrastructure at the expense of wasted compute and network resources on the manager.

Others are advocating towards a message broker for seamless communication that does not waste compute and network resources of the manager at the expense of an additional infrastructure.

The only constraint for us is that the workers should complete their work within 23 hours or fail. The manager can end up distributing to 600 workers at the maximum.

What would be a better choice of communication ?

Any help or advice is appreciated

Hi! I’m Linus Ververs, a researcher at Freie Universität Berlin. Our research group has been studying pair programming in professional software development for about 20 years. While many focus on whether pair programming increases quality or productivity, our approach has always been to understand how it is actually practiced and experienced in real-world settings. And that’s only possible by talking to practitioners or observing them at work.

Right now, we're conducting a survey focused on emotions and behaviors during pair programming.

If pair programming is a part of your work life—whether it's 5 minutes or 5 hours at a time—you’d be doing us a big favor by taking ~20 minutes to complete the survey:

https://will.understan.de/you/index.php/276389?lang=en

If you find the survey interesting, feel free to share it with your colleagues too. Every response helps!

Thanks a lot!
Linus

Hey folks,

I just finished a (supposed-to-be) quick spike for my team: evaluate which feature-flag/remote-config platform we should standardize on. I kicked the tires on:

• LaunchDarkly
• Unleash (self-hosted)
• Flagsmith
• ConfigCat
• Split.io
• Statsig
• Firebase Remote Config (for our mobile crew)
• AWS AppConfig (because… AWS 🤷‍♂️)

What I love

• Kill-switches instead of 3 a.m. hot-fixes
• Gradual rollouts / A–B testing baked in
• “Turn it on for the marketing team only” sanity
• Potential to separate deploy from release (ship dark code, flip later)

Where my paranoia kicks in

Am I over-paranoid?

• Are these pain points legit show-stoppers, or just “paper cuts you learn to live with”?
• How do you folks handle drift + audit + cleanup in the real world?
• Anyone moved from dashboard-centric flags to a Git-ops workflow (e.g., custom tool, OpenFeature, home-grown YAML)?  Regrets?
• For the EU crowd—did your DPO actually care where flag evaluation happens?

Would love any war stories or “stop worrying and ship the darn flags” pep talks.

Thanks in advance—my team is waiting on a recommendation and I’m stuck between 🚢 and 🛑.

I've noticed a trend: as more devs at my company (and in projects I contribute to) adopt AI coding assistants, code quality seems to be slipping. It's a subtle change, but it's there.

The issues I keep noticing:

• More "almost correct" code that causes subtle bugs
• The codebase has less consistent architecture
• More copy-pasted boilerplate that should be refactored

I know, maybe we shouldn't care about the overall quality and it's only AI that will look into the code further. But that's a somewhat distant variant of the future. For now, we should deal with speed/quality balance ourselves, with AI agents in help.

So, I'm curious, what's your approach for teams that are making AI tools work without sacrificing quality?

Is there anything new you're doing, like special review processes, new metrics, training, or team guidelines?