At this point, how much of career growth in tech comes down to luck?

Good CTC, good company, good projects, and good overseas opportunities often seem to depend as much on timing and luck as on skills.

I feel 70–80% of people are reasonably talented now. Most people can learn, adapt, and work with different tech stacks when given the opportunity.

Is the game becoming more about being in the right place at the right time?

Before containers and Kubernetes, I deployed services onto virtual machines. We had a fixed number. When the peak arrived at night, whoever was on call tried to spread the load by hand. Buying more hardware took time, and some unreliability was acceptable.

Then AWS and Cloudflare made it easier to throw money at capacity and let some infrastructure scale. You have to design the system with scaling in mind. And a bill.

Now tokens add cost.

If you own both the service and the bill, what’s your strategy? How do you cap, what cap acceptable? How to gracefully degrade? And how rules applies across the organization?

It feels like we are coming full circle to the times of the Silo Engineer, but on steroids. Back in the day when social media feeds were chronological (if they even existed), the Silo Engineer would retreat into his cubicle to Create (it was usually a he).

He was Creating and Creating, and then a few weeks later the results came back. If you were lucky, you got what you asked for or something close to it.

No one knew what the Silo Engineer was making, whether it was a sound solution from the architectural, security, or code quality point of view. It was a Silo. There was little discussion or collaboration, there was only self-review of code - at best.

After exiting the Flow, the Silo Engineer would often come back to his Work weeks later and wonder: "who in the F wrote this S?"

... It was beautiful.

Seems like with LLMs we are entering that era again, but it's different.

Smaller teams, mentally overtaxed developers, exhausted from scrolling walls of generated code they don't understand, on multiple projects at once - no one really talks to each other again.

Tickets - Claude, Slack messages - Claude, code reviews - Claude, "have your Claude talk to my Claude".

So, here we are - same idea, but at a higher, more reckless pace.

Let's see how this ends, I guess ¯_(ツ)_/¯

This is one of my pet peeves: the inability to actually deprecate the "old" version of something is always so hard. There are always users who don't want to switch. Or that obscure feature you don't want to support in v2 that keeps users from switching. Or my favorite: a general suspicious attitude against all new software.

I'm currently writing internal software for a high tech Corp. It's an even worse situation than writing paid software for actual customers.

Did you manage to deprecate it? Even to delete the code entirely?

My day job involves a lot of contract work building all kinds of software around novel uses of LLMs. So we start with "Could LLMs do X?", and generally find this pattern:

• Holy shit, they can! This seems to work mostly!
• Oh shit, but not really. It makes inscrutable mistakes, and does so slowly.
• Actually, we should move 90% of this back into conventional code.

And we end up with the LLM basically being used to do intent/data extraction from text, and....well, that's it. LLMs are great for writing code, but at runtime it's difficult to find a use for them other than as a bridge from raw text to conventional software.

Which is actually fine, except that it's still expensive. On a lot of projects it just totally dominates compute costs just to do its (admittedly cool) trick.

So outside my dayjob, I have a travel planner project which helps people build custom Rick Steves-style european itineraries (tripsnek). As a fun experiment, I played around with a natural language interface a while back. It showed potential, but it also couldn't really be justified on a free app with no revenue. So that was that.

When the first decision models were introduced recently promising the LLM smarts at 1/10th the cost, it looked like the door opened back up, so I had to give it a try.

Edit: I just realized that, since these are so new, I should have included at least a brief explanation of what a decision model is. Essentially, they are LLMs that do not return any natural language. They only return structured decisions: yes/no, true/false, choose-from-a-list (e.g. pick from an enumeration). This is what allows them to be so efficient, and each decision is also associated with probabilities (which is something conventional LLMs are particularly unreliable at). I have intentionally avoided mentioning the company that launched the first one, since I think they are suspected of astroturfing marketing, and it doesn't matter anyway because there are already competitors open-weight alternatives since the cat is out of the bag on how they work (and that they work). Ok, back to the original post....

The app itself is essentially a conventional optimizer (a genetic algorithm), backed by lots of data about cities and travel times between them, and which can account for arbitrary user constraints and preferences. This last bit is what needs to captured by a user interface, and here I am taking a stab at a pure language interface as an alternative.

Here is an (ai-assisted) write up of the results, TLDR:

• Yes/no and choose-from-list parameters obviously worked incredibly well out of the box - preferred mode of travel, preferred pace, general interests, etc.
• Questions that required picking from very large sets - specific cities and sights, dates and ranges - were naturally much more challenging, requiring relatively complex regexes and text munging.
• It all netted out to a pipeline that matched, or even exceeded, a sophisticated conventional LLM provided with similar instructions, at roughly an order of magnitude lower cost...but also an order of magnitude greater code complexity (see figures).

Again, this is an initial stab, and I don't know if I'll keep pursuing it, but its already good enough that I am convinced it could be very good if I do and - just as importantly - its so cheap that its totally plausible for a free app sustained on a shoestring.

I'm not sure I even regard the additional code complexity as a burden. Sure, its more work, but it is also fully debuggable, optimizable, extendable code. If something goes wrong, the odds are now much higher I can actually fix it directly rather than with mystical incantations in a prompt.

Another dimension of this is that it offers the potential of capturing significantly more subtle aspects of user intent than are really feasible with a conventional UI. People have limits on how much time they are willing to spend figuring out how to twiddle knobs in a UI, which constrains how nuanced I can make my optimizer. As currently built, it cannot incorporate "the user kind of wants to go to Venice" because I don't know how I would build an elegant UI that would allow them to express it. Natural language could handle things like that organically, which is really neat.

Finally, I think I find decision models so refreshing because they don't have that dark cloud of generative AI. They do their job of answering questions about text humans wrote, then its back to software. It's just straight regular centaur shit.

Hope you all find this informative. You can try out the (experimental) interface here, and use the checkbox toggle to see a full drill down on all of the questions being asked and the answer that the decision model returns: https://tripsnek.com/describe/

AI Disclosure:

• This post = zero AI used
• Travel planner app = very little AI
• Jev pipeline = heavily AI assisted
• Results write up/figures = heavily AI assisted

Self-promotion disclosure:

• this post includes a link to my app

I maintain an open source project which builds a call graph with a confidence level on every edge, mines git history for co-change and ownership, and maps which tests reach which code. I'm now thinking of adding migration tracking on top of it, the requests to httpx or v1 client to v2 kind of thing, and I want to sanity check the design with people who've actually run these

The plan for spotting a stalled one is to look for two libraries with the same job both imported in the same repo, then use git history to see when the new one first showed up and whether the old one's file count is still dropping or just flat. For in-repo stuff, deprecated functions that still have live callers, using resolved call edges so it's more than a grep. Call sites that only match by name would be marked "verify by hand" and left out of the remaining count. Then the leftover sites get grouped into PR sized chunks using co-change history and package boundaries, with each chunk showing whether any test reaches it and who owns the files

The obvious limit is that dynamic dispatch, reflection and string-built names will hide some sites, so the count is a lower bound at best

For people who've driven one of these to the end, what number did you actually trust for "how much is left"? Files, call sites, owners? And what threw off your remaining count in the end, wrappers around the old client, generated code, vendored copies?

It's Saturday and I am working for a client on a feature that I started to implement yesterday. For that I used a previously implemented service that retrieves account data and polls it, until the etags differ (the BE I am calling is .. slow).

So I added a new method since the need arose and chose to use a kind of streaming approach, using C#'s IAsyncEnumerable. I implemented everything using Mistral and my local LLM using my "prose-coder" approach, which basically means: I write pseudo code and the LLM spits out what I want immediately. sometimes in very small (single line) or larger (method) increments.

Then I review.

An then my bloody slow-cycle begins: First I review the output, then Mistral reviews the output. Then I am not quite happy and let Claude review the code, and F me I am in a review loop and out comes - IMO - some really really good implementation which hopefully has all the edge cases covered (discounting business logic edge cases which the clanker can't know about).

And in the end, this whole process feels subjectively SLOWER, but I know that I was faster? I worked on the feature for a total of approx. 4 - 5 hours, including testing, fighting the stupid ERP that I am polling ( I have access to it )..

My point being: yes, I am definitely faster, but man, these LLMs trigger my need to make everything bloody perfect.

Am I the only one? My feeling is that the quality of my output using LLMs as reviewers is much much better now - but the subjective speed is a different matter.

(Note: I am self-employed (for about 2 years), 20+ YOE.)

And no, I have no idea what the point of this post is, I guess I just want to see people's opinions. Treat it like cafeteria talk :-) Ta!

Someone at work gave me a compliment how it's nice I leave status updates (comments) on my work items. Which tells me they do read it. That also tells me, it's not a common thing anymore?

If you're writing status updates on your work progress, how often do you do it and what does that look like?

For those that don't, I'm keen to hear your thoughts too!

So I'll try to explain this situation, and I can provide context in the comments if need be.

I'm working on a project that I originally found and raised to my team. Basically, we're upgrading to the newest version of our e-signature vendor's API/SDK. Our current version is out of support, but still works.

Everything was going fine until I ran into a problem with updating a signer using an email address that had already been used to sign in the signature request. I went through pretty much every test case I could think of. I tried different forms, a different app, a different controller, different scenarios, etc. I compared the successful cases against the failed ones, trying to isolate what was actually different.

Eventually, I came to three possibilities:

1. It's a restriction in the vendor's API.
2. It's a bug in the vendor's API.
3. Something I'm doing is wrong.

I figured opening a support ticket with the vendor would at least help eliminate two of those possibilities. Support answered some of my questions. They confirmed it wasn't a restriction, and based on the error messages and test case I provided, they said it could be an edge case or bug worth confirming with their team.

So based on that, I wrote up my own documentation outlining the problem, what I tested, the results, my conclusion, and the next steps. I sent that to my team.

This caused my team lead, who's also my boss, to bombard my messages basically saying that it's not the vendor, it's our app. She then sent me a screenshot of Google AI-generated code snippet of an endpoint on the vendors api/sdk that doesn’t exist. Worse is that she included her prompt of he specifically telling it to include stuff that doesn’t exist.

That's what really got me. I responded with a link to the vendor's actual API documentation and thought it was over, until the director got involved. At that point, I spent more time debunking misinformation than I did writing up the original documentation. Once it blew over, I sent a message to everyone involved and called out the use of AI in this context.

This has been a recurring thing she does where she thinks a quick Google search or AI can solve a problem that you've spent actual time investigating. Frankly, I don't want to work under someone in a management/lead role who operates like this.

This is obviously one specific example, so take it at face value, but yeah, I can't stand this team culture anymore.

I see a lot of common negative themes in our daily AI circle jerks here on this subreddit: Huge unreviewable PRs, code quality declining, technical debt spiking, unwarranted contributors, lazy developers putting in no effort, etc... etc...

As someone who has hung out on this subreddit the last 5 years and been in the industry for 10, a lot of these problems are the same old problems that have always been prevalent in our industry, just at a smaller scale; but with AI so many of these problems are exacerbated by the fact that anyone can just rip on code nowadays, even the non-technical folks and the bad engineers.

To be clear I think there are very valid complaints around AI, like coming to terms with the loss of our craft, or the fact that our jobs are now agent managers, but there are an equal number of complaints that aren't hitting the root cause of why those problems exist at their company.

Huge unreviewable PRs, Technical debt, Lazy engineering: You have an accountability problem, and AI is making this worse. Where are the staff engineers and the managers at these companies? Do they have no spines? Why are people not catching heat for dumb shit and why are these people not being called out and either talked to or shown the door? Accountability is an extremely important trait in a good engineering culture, if people use AI they still must be held accountable for their work from start to finish.

Unwarranted contributors, Slop code: You have a DX problem, where are your strong linting contracts, pre-commit hooks and CI guards to prevent poor code from even making it into a PR in the first place? Large swaths of these complaints just boil down to the fact that your organization has put zero investment into a strong DX culture outside of maybe running some tests in a github action. You should be linting for leaky abstraction, import contracts, doc string prose, and everything else that fits into your "blessed" paradigms whether that's MVC or some flavor of DDD.

This may not resonate with the folks here, or maybe it will, I'm just tired of seeing the same complaints with AI and ranting here because a lot of these problems can be solved by focusing on building a culture of accountability and empathy at your organizations.

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

Have a PM that used to be a DEV many years ago.

We were discussing estimates on a ticket, he asked me what I thought about getting something done within a week.

I mentioned just DEV work alone would be a week

He responded “what is causing these estimates? wouldn’t you just need to do XYZ? no offence”

With recent AI developments everyone thinks everything can be done in a few days.

My goal was to be as transparent as possible and I provided itemized estimates. “well we need to answer questions ABCDEFG”

and the conversation ended

but that whole thing put a bad taste in my mouth

He’s never been like this before and I’m worried he’s getting pressured

SWE for 20 years. I've seen plenty of posts about the soul-sucking prompt engineering some companies mandate now. Mine isn't one of those - AIs are a tool you are encouraged to use, but the output has to be understandable, human-reviewable, and you (as a dev) are still responsible for it and the consequences.

I think the difference is whether you give your codebase completely to the AI. If you treat the code the same way we treat assembler now, then that's what you do - you specify the what, and the AI completely handles the how, which leads to 5000-line pull requests, only reviewed by other AIs, and all that jazz. The problem comes when the AI can't do something, or you encounter a problem that a human needs to solve. Then you're faced with working out WTF a 1-million line codebase is actually doing from scratch, that wasn't even written by a human, probably with CxOs breathing down your neck. Good luck with that.

This decision assumes that AIs will always be able to solve the problem, of course. And maybe that's where we're all going, and writing (and understanding) actual code will become just as niche as assembler programming is now. But, given what I've seen of AI output and how nonsensical and daft it can be, we aren't there yet.

Unfortunately, it's not the devs who might end up maintaining it actually deciding where and how AI should be used. All that matters is throughput.

My company still keeps everything human-understandable, because a lot of people depend on the product working properly. That's unlikely to change in the next...year? 2 years? Who knows. But I really wonder where the craftsmanship of software engineering will go in 5 years time. Seeing what's happened even in the last 6 months, I have no idea what my long-term job prospects are.

Its a term I am using as a red flag for poor fit in my job search. I also do use AI quite a bit, but I am strongly 'human-first'.

To me 'AI-first' smells like heavy use of code gen and letting the LLM steer a dev intellectually. In my experience that is not wise or economical for code that needs to be reliable, maintained, or extended in any way. Its ok for throwaway stuff, toy apps, demos, finding bugs, rubber ducking, code review and other things, but 'AI-first' seems very unwise. Maybe I am thinking about it differently than most.

So, what does 'AI-first' mean to you? What does it mean to the people writing the job postings at your company? Is it just an ignorable meaningless hype term?

TLDR: Jevons paradox is misunderstood and data does not look good. Growth in demand for humans in software development is declining, and rate of adoption of new software is not matching the sheer amount we are producing now.

long version below:

I often see this Jevon's paradox cited as a matter of fact, ultimate reason why demand of software engineers will only increase

the proposed reasoning is simple:
- AI increases productivity in software development
- therefore cost of producing software goes down
- therefore demand of software goes up
- therefore demand of software engineers goes up

The fourth step is the fallacy

the Jevons paradox only says:

- AI increases productivity in software production
- therefore cost of producing software goes down
- therefore demand of software goes up

the missing piece is: will the increased demand of software offset the reduction in human labor needed to produce it? Jevons paradox DOES NOT tell you the answer to this question.

The cost of producing software (not running it, just producing it) is entirely based on human labor (unless you are producing something that requires lots of compute such as the learning part of ML).

the only conclusion (if we take Jevons paradox as the truth) is that:
If AI reduces the human labor required to produce software to 1/X, demand for software must grow to more than X times compensate for it. For demand for human developers to grow, the demand for software must create more human work than AI takes away.

the economic value of using AI comes from replacing human labor. If an AI can produce equivalent amount of software for cheaper than it costs when done exclusively by humans, increased demand for software does not inherently translate into increased demand for humans.

Much of that additional demand can instead be satisfied by consuming more of the cheaper input: AI

i will leave you with these relevant papers: https://www.frbsf.org/research-and-insights/publications/board-of-governors/2026/04/ai-coder-employment-compiling-the-evidence -> growth of demand of human software development is declining

and this one: https://www.nber.org/papers/w35275 -> an example of when most of the increased production in software has not seen a comparable adoption

the thing is, there might not even a comparable increase in demand for new software. Most of the productivity gains could be in just reducing the cost to develop and maintain existing one. Keyword: reducing the cost

Title basically. I've changed jobs recently and noticed today I have 6 open, unrelated topics in parallel, all due "ASAP". It results in lots of context switching and I feel pretty drained every day. I think I may have been spoiled before, having things more linear: deep work on one thing at a time, finish, move on. I'm curious what the norm is, and for those with a lot of topics, how do you manage efficiently?

EDIT: based on replies so far, it seems I was indeed a bit spoiled at previous jobs and this is closer to the norm, but that kinda sucks :/

I'm a tech lead. A senior developer on my team (we've worked together for over two years) produces code that isn't at the expected level as soon as a task involves some functional or technical complexity.

Concretely, in his MRs: no thought given to dependencies between parts of the domain, hard-to-read code, classes in the wrong namespaces, design patterns misused, business logic duplicated rather than refactored out of the legacy code.

What I've already done:

• Detailed feedback in reviews, MR after MR. It costs me a lot of time and I see no progress from one MR to the next (he told me he doesn't read my comments and just asks Claude to take them into account).
• Feedback in 1:1s on the most visible quality issues (lots of QA returns, code that sometimes doesn't work at delivery).

My problem is putting something concrete behind "not at the expected level." Simple, maintainable code is subjective.

That's why I'm reaching out to you: I want to address this issue in our next 1:1, but I don't know how to go about it.

Edit: I wouldn’t have thought getting so much replies, thanks everyone!

For the ones thinking it’s a bait post, sadly it isn’t.

I live in a country where you don’t fire people that easily, and, worse, I’m in a company rewarding everyone with an annual raise, despite being a low performer.

I feel genuinely stuck, I’m here to find solutions to make my work easier, and maybe, maybe, make his more enjoyable by being proud of what he delivers.

Everybody is focusing on AI here. You could have thought that using AI would make you a better developer, but for him I think it’s the exact opposite. I feel like he stopped thinking and trust AI to be better than him.

If you forgot about AI for a second and read again my post, my issue is the same: he’s not at a senior level and I don’t know how to get there.

My work place has a development budget of ~2000$ per year. Last year I used the budget to attend a conference“We are developers” and I found it rather underwhelming. The year before that I bought some books. I already have plenty of books.
Any suggestions on how to efficiently spend the development budget?
About me: I have >10YOE, work primarily as a C++ dev, I have dabbled in some Kotlin and Swift too.

Not sure if this is the right sub, but I started a company with a friend. He previously worked at a Mag 7 company and pitched me an unrefined business idea. I liked the concept, helped refine it, and came up with most of the actual product flow.

His background is in data analytics, so he’s been pushing for a data-collection feature that I personally disagreed with, but he believes will be valuable long term. I trusted him, he’s worked at mag7. I work as a senior dev at a start up company and I’ve designed and built the MVP of this product.

We had our first conversation about compensation/equity, and he proposed 5% equity for me. He said he’s open to negotiating, but his reasoning was that he’s taking a big risk if I deploy the app and then go MIA.
The 5% caught me completely off guard. So far, his contributions have mainly been coming up with the original unrefined idea, setting up meetings, forming the LLC, coming up with the name/logo, and helping shape the business direction. He’s a better public speaker so he’ll likely deal with the clients more.

Fellow developers, does this sound fair? How would you counter this?

Why do interviewers ask this question? And worse, sometimes they want to spend a whole hour deep diving into one project. What kinds of signals are they hoping to get? A recruiter asked me that with 5 minutes left to the interview, not sure what kind of answer they were expecting so I gave them an abridged version of a project I prepared, but I don't think they were sold.

I know I can get along with people and work well cross-functionally on a real project, but I don't think storytelling as a skill is relevant there. As for technical ability, there are other rounds for assessing that.

Personally im very happy about adding code conventions for services, endpoints etc. i am forcing their usage with hooks because they were not always picked up by agent.

Hi!

I’m a backend developer with 4+ years of experience, and throughout my career, I’ve never really worked with cloud technologies.

I have experience with Docker and Kubernetes, but I wanted to start working with a cloud provider since it’s quite commonly listed in job descriptions.

I recently finished a course and got familiar with the AWS essentials, so now I want to start practicing by building some of my own applications.

Of course, there are plenty of things to configure (I’ll be using Terraform for provisioning), but I’ll also need to integrate some AWS services using the AWS SDK.

My problem is that I don’t find it easy to figure out what I need from the documentation. Yes, I know I can always ask AI, but my question is: is the AWS documentation actually the issue here?

Maybe I’m just not familiar enough with AWS yet, but it seems unnecessarily complicated to find what I’m looking for: a clear code example showing how to do something specific and what the expected output should be.

What has your experience with them been? I don’t understand why these cloud providers are so popular these days, given the mess in their documentation.

Hey all,

For context I am still pretty early on in my career, at about 6.5 YoE. I was at FAANG as an intern + full time, then mid level at fintech, mid level at a gig economy company, and now starting a new role as senior SWE at fintech again.

The deeper I get into my career, the more I find myself caring a LOT about the intersection of product, business, and eng. I feel as though I am the opposite of someone that just wants to work on the eng - I deeply care about figuring out what and why we are building, in addition to how we are building it. I like planning meetings a lot, I like building bridges with PMs, I like trying to build the vision of the company from the eng perspective, and it bothers me when I am just "handed requirements."

To the title of the post: I feel like I have aspirations some day of trying to crack into director level roles, and was wondering how important it is to have giant line items on your resume with respect to business impact. Two contrasting examples might be:

• An infra engineer re-designed the observability platform at Uber, onboarding all services at the company to lower latency and lower cost.

• A product engineer brought Stripe Billing from 0 -> 1, driving XYZ millions in revenue

If you're someone that is looking to crack into leadership roles that lie at the intersection of eng and business/product, is it really important to find roles where you think the thing you're working on could be "famous"? At FAANG, I worked on an internal tools team that was successful, but never really felt like it had the capacity to explode. Do these types of line items matter, or can you really interview on performance alone?

I know that I'm still very early in my career, but I want to make sure that I'm looking for the right opportunities to crack into the product/biz side too. Thanks for any advice!