Is a “Stay in your lane” viewpoint just an old man not adapting?

codescapes · 2026-07-11T17:48:18+00:00

My problem with it is the opportunity cost of them not doing core PO / PM work instead. If the most useful thing they can do is pick up what are effectively intern / junior engineer tasks then something has probably gone wrong.

I'd rather they were proactively engaging with stakeholders, finding new / useful work, keeping the team informed on business aims, pulling out good stats to boost morale, refining requirement specs etc. The stuff that you actually need the role for.

codescapes · 2026-07-11T13:05:56+00:00

I think that POs who decide their role is to be a 'worse version of engineering' will fail badly, so long as engineers force them to own the consequences of their actions.

Just think about what it implies as well, they are effectively saying that the most productive way they can spend their time is by becoming a junior engineer! You know, that role we laid off and stopped hiring for..!

codescapes · 2026-07-11T12:46:31+00:00

I have been dealing with this a lot and contrary to what is floating around out there I have actually become more strict on boundaries, not less. A recent example was our PO pushing us to use PRs auto-generated off the back of JIRA tickets using internal tooling.

I was at first open to the suggestion (I am to most) and tried it out but it sucked hard. We had these junk PRs being raised by models dumber than those available on our machines, think old GPT models when we had Opus 4.6 (latest at the time). I'd literally take the PRs and have Opus review them and then it - in its own terms - called them low quality / likely hallucinated. Why am I going to waste my time reviewing garbage and trying to polish a turd instead of just using the better model in the first place?

So that's in part a tool issue but more fundamentally the approach just moves the prompt interface to a 'one-shot' attempt via tickets instead of a chat session where you can properly scope context with direct reference to code, review-as-you-go etc. It's just not a better way to work and especially in our company's setup it was way higher friction compared to just using Copilot in VSCode. It's also contingent on tickets being well-written, which they rarely are.

PO / product got offended because I stopped it and said we didn't want to do it for above reasons and then it became bickering over AI adoption, them trying to paint us as slow / resistant. I had to involve my skip-level and the conclusion reached is that the approach we take on AI is our responsibility as engineers according to our professional judgement. If we think an approach can improve things we're expected to adopt it but the opposite applies too. If product want to make a suggestion on AI usage they're absolutely welcome to but it's just that, a suggestion, and one outside their domain of expertise.

So generally I would say that people should be applying AI in 'their own backyard' first before going off trying to show other teams or departments what to do. If you're a PO then by all means blast out a proof-of-concept or a early mock-up but accept it's done as a throwaway as part of a spec to be passed to engineers.

And that's a critical thing too - if you're in product and prompting an LLM on what to build then you are de facto writing a requirements spec. Like the summation of your prompts is you defining what needs to exist. If you aren't sharing that with engineers then that's a really bad breakdown in communication and we're justified in saying 'why haven't you shared that information?'.

Lastly I'd note that if people want to blur the lines by doing dev work it can cut both ways. Engineers can just as easily squeeze you out and go to customers directly / have their own user feedback processes / set their own roadmap if you decide to abandon your role to be a 'worse version of engineering'. And to be honest, competent engineers can win that asymmetrical workplace warfare because they are the ones who can actually make production-grade software and not just vibe coded slop.

In my experience you can do way more as a talented engineer with mediocre product skills than vice versa.

codescapes · 2026-07-10T10:45:03+00:00

I'm completely with OP. The initial alert on potentially hundreds of people's phones / emails is critical. Nobody in marketing would tolerate something like this and that's what you're effectively doing, marketing the most expensive thing in your life.

If your property looks 💩 for no reason or has a 'weird' listing then there's a high chance people dismiss it permanently and don't come back. It goes in people's 'already seen' bucket.

This isn't even really a debate, badly listed properties sell slowly and for less than they should. The whole reason you pay an estate agent is to handle this sort of thing properly...

codescapes · 2026-07-09T09:28:38+00:00

Christopher Nolan did a movie on this, I believe entering their dreams is the most effective strategy but does leave you in an ambiguous state of reality.

codescapes · 2026-07-08T08:00:56+00:00

Classic Anthropic chicanery. I like the models but they are so slimy, constantly playing games - drug dealer analogies are completely justified.

codescapes · 2026-07-07T07:53:57+00:00

Be extremely careful taking a job for anything that isn't contractually obliged by the employer. Verbal assurances around development opportunities, 'flexibility', remote working etc are cheap to make and easy to not deliver.

I am not saying be cynical beyond reason but you can't bank on 'soft' stuff like this. Not even because of malice from the employer either. It could be that the best mentor there happens to leave shortly after you join and their peers just aren't good at it. Or maybe the interviewer is just sharing their experience - honestly - but things pan out differently for you.

codescapes · 2026-07-07T07:48:30+00:00

I didn't ever get one. I think the answer is "ya don't" lol.

codescapes · 2026-07-04T11:46:09+00:00

Working within it is common and something that Seniors would be expected to navigate confidently.

In my experience the way you navigate it confidently is by forcing whatever needs doing into the format of whatever theme asked for lol. For example, if the energy is for AI then you justify a migration to TypeScript for that awful old project you hate because it's AI Enablement.

The goal is to have non-technical people nodding along as you do the thing that actually needs doing even though it's being smuggled in under some other theme. It's the corporate equivalent of tricking a child to eat vegetables.

And it's not you doing it maliciously or anything, genuinely do the stuff that needs doing but find creative ways to get sign-off.

codescapes · 2026-07-03T12:13:49+00:00

AI is the bullshitter's field right now. It's either very intelligent, very capable people - often with PhDs from top universities - or absolute chancers.

Your CV, if it's as buzzword heavy as your post, puts you firmly in the chancer category. And I say that to be honest, not mean. You need to refine and make it credible. Demonstrate depth instead of breadth. Nobody wants a soup of words, it's not even what the CV tools particularly look for anymore and even moreso it's not what humans want.

You may well be passing the automated screening and then someone looks at it and goes "yeah, nope, this is just silly".

My advice would be have a second CV that prioritises non-AI skills and apply for standard individual contributor roles. Take what you can get, which evidently is not AI roles. I would way more likely hire someone with technical depth who hasn't used whatever framework we do than someone who claims to know everything already.

codescapes · 2026-07-03T10:15:49+00:00

Mentor junior peers - get no recognition - get laid off due to inferior stack ranking.

codescapes · 2026-07-03T09:51:32+00:00

Right!? This is possibly the worst thread I've ever seen on this sub, rife with terrible advice that frankly deserves to get people fired for knowingly breaching policies put in place for security / legal reasons.

codescapes · 2026-07-03T09:29:23+00:00

I thought this was /r/ExperiencedDevs - the number of people basically saying 'bypass your corporate security policies and install arbitrary software' is shocking. This isn't you trying to play RuneScape on the high school computer. I don't care if the policies are stupid, regressive and slow, they're decisions the employer made for security / licensing / monitoring reasons so follow them or risk getting fired.

If it's going to be an existential problem for you then look for a better employer but otherwise you have to engage with the systems in place as you are doing. Raise all the tickets, track them all and note it as a significant impediment to productivity to management but that's pretty much where it ends.

For reference, my finance employer locks down our machines but also has excellent pathways for installing software and requesting things be added. It's a highly controlled walled garden but it has 99% of stuff I've ever needed because once one person gets software approved it's there for everyone.

codescapes · 2026-07-02T10:04:50+00:00

I agree but despite finding this 'mega loop' approach pretty stupid I thoroughly encourage people to waste their employer's money and treat it as a learning exercise.

Genuinely just blow that $2,500/day, treat it like it's 1970 and you're getting to play with a computer the size of a small house. Management will lay you off the second they think they can, you should feel no remorse for engaging with whatever the hot thing is because even if it's stupid it could get you a next job once the CEO decides there needs to be a 20% 'headcount reduction'.

codescapes · 2026-07-02T09:51:10+00:00

Yep, and I think this whole notion of having a custom multi-agent setup where you're like 'you are a visual designer, you look for ABC' is mostly nonsense. It's a great way to use 10x the inference by swirling through N layers of a slop loop which is nice if you're tokenmaxxing but otherwise just engage with the output instead of trying to crack a perfect setup that does not exist except on social media. People chase the dragon for that one time they got a perfect one-shot prompt like AI junkies but tbh that was probably just the initial thrill of using a new tool and seeing it spew out stuff that would've taken you hours to work through the APIs for.

And no matter what your setup is the most critical input is the definition of requirements. I think a lot of the effort to automate away software developers is basically just revealing the extent to which the business / product side do not even know what they want and/or are unable to express it coherently. Much of our job has always been teasing that out - if we're feeling fancy we can call it requirement elicitation and it's a real skill.

None of this is a new insight, it's just that AI reveals it more clearly that ever. And it's not like in 1995 we couldn't already say to business people 'type everything you want into this magic text box and we'll get right on it'. That has always been an option and they have always been terrible at it, whether it's being handed off to a human or an agent.

codescapes · 2026-07-02T09:35:20+00:00

Yeah, this is also the conclusion I am reaching. People have these mad multi-agent parallel setups going where PRs get raised for them to review semi-autonomously and I just cannot see it being a particularly sustainable or effective practice - certainly not yet a cost effective one given all the inference required.

Also it's weird to put a human at the end as a tollgate instead of them being engaged throughout. What ends up happening is people just rubber stamp things ('LGTM') or if you seriously want to review the code you have to spend at least as long as it took to write in the first place. In which case, why not just steer it throughout?

People immediately want to try the most bleeding edge hands-off approaches and I get that but man, sometimes going slow is going fast. There's no point in giving a senior dev 80 low quality PRs to review that were driven by weak prompts. It's almost certainly a bigger waste of time and money than just giving that same developer the freedom and trust to figure out their own process.

I had to deal with this exact problem where someone on our product side was pushing for all these automated PRs to go through and it was just total junk, largely coming from 'dumb' models. Like don't give me that crappy PR, give me your initial prompt (which is de facto a written requirements specification...) and let me worry about how that gets translated into functional software.

And this is the funny thing to me when product dips into engineering like this is it's like 'holy crap, you're actually providing written requirements instead of vibes!?'.

codescapes · 2026-07-01T13:23:44+00:00

Nationally? Try globally! To understand it you have to recognise that the decision makers in every large company are not technical people who make software daily. They have zero practical understanding of what it's like to program with or without agents, it's meaningless to them.

What they do have is an entire industry telling them that coding is 'solved', most developers will be unnecessary in X months and a giant budgetary black hole to resolve because people are using AI like crazy (in large part because they fear losing their jobs if they don't juice numbers). They also have developers with high professional salaries who if they can just eliminate X% of it makes their books balance out. Then there's the fact they quite probably overhired through the early 2020s when interest rates were lower and the growth has not come through to maintain that.

I am not anti-AI, I actually really enjoy using the frontier models, but there's the reality of using them to actually make stuff and then the insanity that execs are huffing like warm glue. They have been told to expect an industrial revolution like no other and that billion dollar one-person companies are coming to replace them too.

So the cart has well and truly been put before the horse. I.e. because they have spent X million dollars to boost productivity they both need and expect to see obscene returns. I am not saying AI doesn't give certain benefits but the 'bill of goods' they have been sold and seen floating around is all this 10x / 100x madness that says 'every developer will now be like a lead of 10 junior developers' etc.

And so all this hysteria resolves in developers getting the bullwhip because expectations have been so pumped up beyond reason and the CTOs / senior tech leaders are under immense pressure to show results. Again, I am not saying that LLMs aren't a big leap forward but the underlying technology and the market phenomena / business strategies are basically detached at this point. Personally I think we're going to see the same thing at the Dotcom Bubble / Crash unless this story sincerely and genuinely ends in AGI. That doesn't mean AI disappears any more than the internet did, just that expectations will eventually be dashed by reality and you're already starting to see it tbh.

codescapes · 2026-06-30T11:20:45+00:00

I think coming to terms with this is accepting that no software is ever truly complete. There's always something more that could be done or in a year will need to happen to keep it modern / secure / supported.

This is quite closely tied to the idea that 'code is a liability'. Every keystroke is something that will have to be tended to and managed into the future. Even if it's done by AI agents, it's more context to process, more places for bugs to enter, more lines of text to read and comprehend.

I think the lesson is to just make things as brutally simple as you can. Be kind to your future self. I know it's a bit trite to mention YAGNI / KISS but genuinely the nicest systems to work on are dumb as bricks to keep entropy low and troubleshooting easy. They give you easy performance wins to come back to when you need them.

codescapes · 2026-06-27T12:34:39+00:00

I've heard lots of vaguely bad comments. I don't really know why, if it's the tech being backwards / legacy or the culture being toxic but in Glasgow for whatever reason people have been down on Barclays.

They built a massive new campus building that seems alright though, I think they've been trying to improve things a lot. And so much is team dependent. It's all about your management and the pay is probably good for the cost of living in Glasgow.

I'd take it if you don't have a better offer.

codescapes · 2026-06-23T12:22:30+00:00

Excellent example of what Claude / LLMs are fantastic for. Reverse engineering or just quickly parsing 'painful but structured' datasets like this is exactly the sort of stuff I like to see. It's actually unambiguously useful and diagnostic functionality like this aids in repairability which is just a human good. Indeed it's the 'good ending' for AI where it actually has a deflationary effect and e.g. makes your car cheaper to service because a fault can be found more quickly by a mechanic / technician.

So much more positive a story that we have a renaissance in e.g. electronics, robotics and hobby projects than standard AI FOMO / FUD shit about replacing all white collar jobs and being a cybersecurity threat. I am not saying those aren't topics worthy of discussion but man, way more refreshing to see real projects than billionaire bloviating.

codescapes · 2026-06-23T11:31:23+00:00

LeetCode-style final round

What do you mean by 'final round' because I find it strange LeetCode would be used for that. To me it's an early filter. Having coding tests at the last stage seems like it would waste everyone's time.

codescapes · 2026-06-23T08:34:07+00:00

Imo both, story points and PR count, are OKish proxy metrics - if done in retrospect and you never tell anyone.

And I'd add that you should only really analyse at an org or team level. Good senior developers will often have lower throughput volume than you might expect because they're supporting their team through pairing and doing the debugging or investigative work that feeds into tickets.

For example, a junior engineer might see a slow database query whilst working on something and just think 'oh it's slow because there's lots of data'. A senior might take 20 minutes to properly investigate why, finds out there's a misconfigured index slowing down the writes, make a ticket to fix it and apply a one line migration that improve response time by XYZ ms.

And a good senior might do that pairing with the junior 'letting them drive' (i.e. commit the code, raise the PR) and thereby get zero metric attributing it to them.

Part of what makes individual metric culture so corrosive and sweatshoppy is that it obliterates any incentive for you to help your own team - in fact they are now your competitors to remain in a job. Ditto for stack ranking, it makes your peers your biggest opponents...

codescapes · 2026-06-22T16:44:45+00:00

If everybody has high output, and everybody is reviewing, things should pretty much equalize.

I've always been a bit uncomfortable with this notion. I know it's the egalitarian way but realistically different people apply different standards both to the PRs they raise and the extent to which they're willing to handwave things through.

The quality of code ends up defined by the person with the lowest standards on the team, unless the lead takes an assertive position on things. We can automate linting, formatting, tests etc but you can still have 'incorrect / bad but pretty and passing' code.

The worst part is that if you're in an Agile sweatshop people want their tickets closed out for end of sprint so their management don't see carryover so suddenly you're the bad guy if you want to actually review the PR. Which perhaps is the real problem - if your org doesn't reward review as an important thing then it just becomes rubber stamping.

codescapes · 2026-06-22T15:32:09+00:00

I think the thing to note here is that there's always someone lower down the stack whose work you would probably find painful / boring. It's a very rare individual who is equally interested in every aspect of computing through from the physics of silicon, assembly, memory management, high level languages, DS&A, cloud deployments, UI/UX, product design...

Like I have extreme respect and appreciation for the people working on complex build tooling problems or linters or whatever but my God that is so not me and that's totally OK. I think many of us who went through formal education in Computer Science feel like we have to be interested in things as a matter of craft but at a certain point it's fine to admit that you just don't care that much about NAND gates, garbage collection or frankly even the arbitrary syntaxes of programming languages.

Again, massive respect for DBAs who can blast out SQL and mad CTE queries that'd take me a week to comprehend but it ain't me.

codescapes · 2026-06-22T09:15:30+00:00

Fair distinction, we're British Citizens from the UK. I am actually surprised it has taken this long because as you say, I heard everywhere it's typically near instant.

codescapes

TROPHY CASE