Author Topic: Using Claude Code for embedded work  (Read 38994 times)

0 Members and 3 Guests are viewing this topic.

Offline az1

  • Regular Contributor
  • *
  • Posts: 61
  • Country: us
Re: Using Claude Code for embedded work
« Reply #125 on: April 28, 2026, 08:51:56 am »
Even if those sites go under a login (not for me yet AFAICT) they were scraped long ago.

But of course.  Source code hosted on Github never changes.  I stopped hosting new projects on Github years ago.  It's not just Github, nearly every site these days uses anti-LLM protection of some sort.
« Last Edit: April 28, 2026, 08:53:39 am by az1 »
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6440
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #126 on: April 28, 2026, 08:59:45 am »
For sure, but if you have some good coders, they will have their own ways of doing stuff and you will not be able to re-educate them. Not if they are any good, and you don't want bad coders :)

This is back to front from my experience and you are a seemingly perfect example.

I change projects on a month by month basis.  Different languages, different customers, different code bases.  Often different styles, different ways of working, different ethos.  Different tooling, workflow, CI/CD, cloud env.

I work in the project style.  Literally within seconds of opening a file in a code base I can recognise their styling and follow it.  Because I have seen all of them before. 

Consistency is king.  No team lead will ever deny this.

On claude.  An actual issue we have with Claude is the opposite to what you say.  Because you are using the chat interface and giving claude a pin hole to look through.  We actually find the opposite.  When we want claude to help migrate or update existing code, it is extremely difficult to get claude to NOT follow the current conventions and styling.   If there is a pattern in use in a project or a coding style and we want to change it, we have to be very strong with prompting scaffolding to overrule claudes attempts to remain consistent with the code base it's in.

EDIT:  I think a common "resistance" to using claude properly from many on this thread and elsewhere is related to this.  People who have only ever done software alone, in a one man band or as the only "software guy" in small the company, have no 'ways of working' for software in a team, even a team of 2.

No documentation.  All project knowledge in one persons head.  Riddled with untracked technical debt.  Riddled with half finished bits of work.  Stubs of half written code.  Commented out code with no explaination everywhere.  No code repo.  No CI/CD.  No issue tracking.  No Wiki.  Nothing that will make a team work.  So even the introduction of a virtual junior is unbareable and unmanagable.

claude is not your issue if you are in this boat.  Your practices are.  It probably will take you quite a while to get around some of claudes "higher" standards and get it to produce work of that standard.   Software is a practice.  At least go and look at what that means.
« Last Edit: April 28, 2026, 09:06:58 am by paulca »
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11236
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #127 on: April 28, 2026, 09:31:53 am »
EDIT:  I think a common "resistance" to using claude properly from many on this thread and elsewhere is related to this.  People who have only ever done software alone, in a one man band or as the only "software guy" in small the company, have no 'ways of working' for software in a team, even a team of 2.

No documentation.  All project knowledge in one persons head.  Riddled with untracked technical debt.  Riddled with half finished bits of work.  Stubs of half written code.  Commented out code with no explaination everywhere.  No code repo.  No CI/CD.  No issue tracking.  No Wiki.  Nothing that will make a team work.  So even the introduction of a virtual junior is unbareable and unmanagable.

claude is not your issue if you are in this boat.  Your practices are.  It probably will take you quite a while to get around some of claudes "higher" standards and get it to produce work of that standard.   Software is a practice.  At least go and look at what that means.

Claude is probably the best thing to happen to a developer you described. For example, compare these two commit messages - one is written by Claude, one is written by me:

Sample 1:
Code: [Select]
    controlroom: F12 also flips units.participating='yes' in fcr DB
   
    After MQTT approval, a detached prod-query child updates the unit row;
    on 'UPDATE 1' it appends an 'Approved and enabled participation' note
    and signals the parent via SIGUSR1 to redraw the view.

Sample 2:
Code: [Select]
   small things

Both commits are made for the same reason - committing needs to be done, to get forward with the business. Both received the same amount of attention from me.
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6440
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #128 on: April 28, 2026, 09:44:02 am »
Sniff.  I see MQTT, child threads and a DB "row".

I see async event->transactional action.

Be careful :)

EDIT:  Less is probably more here.  Depending on your throughput rate (non-functional requirements) you could do the DB transaction in the MQTT thread.  This way you know it cannot get triggered by another event while processing the prior one.  Saving you a mutex later.  The DB will possible serialise the transactions, depending on the setup, but I wouldn't let it get this far.  Without "transactions" it will just race to last write wins.  With transactions one of them will get aborted or both rolled back if they collide.

If you do have enough through put to need to split your Producers->Consumers into many/many I would suggest a "Pool->Queue->Executor" for the DB.  You take a pool of DB connections, all warm and ready to go.  When a transaction happens, you pull one out, give it the queries/transaction and pop it into the queue.  The DB executor then sequences them one at a time.

The issue that still doesn't solve though is "out of ordering" due to thread delay.

If you are only updating "one row" and not a relationship or compound transaction to multiple tables... you might just get away with letting the DB handle it.  It's only if you need to, say, add a new row and update a foriegn key on another table that our of ordering and race conditions will be an issue.  You can get two MQTT messages competing, but that is just normal.
« Last Edit: April 28, 2026, 09:52:28 am by paulca »
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 6035
  • Country: gb
  • Doing electronics since the 1960s...
Re: Using Claude Code for embedded work
« Reply #129 on: May 12, 2026, 09:58:40 am »
I do have another data point: yesterday I had to draft a complicated document (lease related). So I gave Claude (which had just cut me off for a few hours) the min sub level of £150 for the year (plus VAT) to get this job done. And it looks like this payment rate pretty much stops the constant expiry every time you ask it to read a PDF or some such. I can now use Claude Code too but have not yet tried it.

Now I find Claude does not cut off at all, with what I do.

Claude is also significantly better now than a year ago.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6440
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #130 on: May 13, 2026, 11:21:07 am »
Claude code and the PDF problem. 

A PDF file is very, very token dense in it's formatting.  Claude will attempt it if you ask.  The likely hood of coherent useful output however depends on just how much formatting tokens there were and how they got processed.  Small, simple, PDFs which are very basic in formatting, like basic datasheets with tables, it might do okay.  These are usually datasheets and the like which are only a few 100kbytes.  Many PDFs are not created this way, some use very complex dynamic layouts and all manor of "cruft" hanging off them.

It's a waste of tokens.

So, use other tools designed for manipulating PDFs to get at the real content.  When I tried claude with datasheets for a project it started out well with the 500kb memory datasheets, but when I gave it the 5Mb processor manual...  it was clear things where not going to work.  Very high token cost, poor an d inconsistent recall from it.  So I pointed this out to claude and it explained it's own limitations.  It then suggested it help me install Poppler which will export the PDF contents to basic Text, preserving tables (as text tabbed lists) and columation etc.  Then have claude process that text version.  Orders of magnitude less tokens, far better recall of hard facts.

A specific failure mode with the processor datasheet.  30-40% of the manual is bus timing digrams.  The real meat of the puzzle.  But they are imported and compressed bitmaps from a technical drawing program and claude didn't even see them.  Even after the text extration this was an issue of course.  Eventually claude found enough in text form on the internet to start making sense.

Its the same pattern across the board really.  Claude alone gives you non-deterministic issues, so instead you give claude a tool to do the empircal for it to get deterministic output.  Then point claude back at that output.

This is why automated testing infra/tooling is important.  Goals having outcomes that claude itself can test empircally.  Then it's non-determinstic portion will loop on trial and error until it gets it to pass.... or gives up and changes the test.

EDIT:  It recurses on itself though, as claude does a good job of writing those tools for itself and that still anchors the indeterminstic loop.
« Last Edit: May 13, 2026, 11:28:55 am by paulca »
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 

Offline SpacedCowboy

  • Frequent Contributor
  • **
  • Posts: 439
  • Country: gb
  • Aging physicist
Re: Using Claude Code for embedded work
« Reply #131 on: May 13, 2026, 11:42:26 am »
Maybe my Claude has learnt from your Claude, because it always runs pdftotext and analyses the ascii text in /tmp for me :)

I feed it data sheets and the like on a regular basis. It seems fine with it.
 
The following users thanked this post: Siwastaja

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6440
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #132 on: May 13, 2026, 12:00:30 pm »
Maybe my Claude has learnt from your Claude, because it always runs pdftotext and analyses the ascii text in /tmp for me :)

I feed it data sheets and the like on a regular basis. It seems fine with it.

It's more that Anthropic are watching industry evolve techniques which they release in the next patch.  Most of "it" is front-end "orchestration" code in Typescript, IIRC.

That also embodies the value of AI startups quite well.  Ephemeral.
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6440
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #133 on: May 13, 2026, 12:01:35 pm »
Food for thought?


"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 

Offline Unixon

  • Frequent Contributor
  • **
  • Posts: 762
Re: Using Claude Code for embedded work
« Reply #134 on: May 13, 2026, 03:27:06 pm »
Food for thought?
Isn't it obvious yet?

The best application for this type of AI is making cat videos.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 17799
  • Country: fr
Re: Using Claude Code for embedded work
« Reply #135 on: May 13, 2026, 03:48:15 pm »
Food for thought?
Isn't it obvious yet?

The best application for this type of AI is making cat videos.

Not really, the best application is currently talking about it, making videos about it.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11236
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #136 on: May 13, 2026, 04:51:17 pm »
Not really, the best application is currently talking about it, making videos about it.

Your bitterness is getting kinda cute ;D
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 6035
  • Country: gb
  • Doing electronics since the 1960s...
Re: Using Claude Code for embedded work
« Reply #137 on: May 13, 2026, 05:05:30 pm »
The video makes good points, and supports my own use of it where I use it for specific chunks of code.

It is probably disastrous if used to generate large server-side programs.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11236
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #138 on: May 13, 2026, 06:16:03 pm »
The video makes good points

Sure, all the absolute classics with neither any new insight, nor any proof, example cases or something else of actual interest/fun. Very agreeable, because all concerns are legit. Classic "preach to choir". Nothing quantitative, just qualitative babble, which is easy to produce, for AI or human, with not much effort.

Quote
It is probably disastrous if used to generate large server-side programs.

Not any more disastrous than humans generating large server-side programs. But with poor planning and poor supervision, speed and apparently low cost of initial work can be scary. It probably is possible to generate a very complicated unmaintainable mess in a month; classically, before AI, that happened within 4-5 years of timeframe, and 5-10 million spent in programmer's and management's wages, and 100 million billed from the customer.

Like, who would have thought? It is well known that most complex software projects are failures, either total or partial, full of "technical debt" and very hard to maintain. Train AI with the "industry practices" and what do you expect to happen? It's not going to magically solve fundamental software process issues, it's just cheaper and faster.

I see it solely positive, though. If something can be created in a month only to be seen as no-go, it is much easier to ditch and start over than if it took 50x more time and 100x more money - the classic sunken cost fallacy is big part of long-standing software quality crisis that has plagued the societies since early 2000's if not earlier.

Datacenter energy use and effect on RAM prices are actually my biggest concerns, if a lot of "work" is going to be wasted. Compare to human programmers - even if they produce utter and equally damaging crap, while eating oxygen and producing CO2 in the process, we still think their existence as human beings has an inherent value irrelevant to their software contributions, and we still think that the money we put into their wages is "well spent" because it allowed those people to get butter on their bread, which we attribute an emotional value to.

It gets more interesting when we assign an emotional value to human programmers doing their jobs worse than AI, instead of just paying them some unemployment benefit.
« Last Edit: May 13, 2026, 06:40:49 pm by Siwastaja »
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 6035
  • Country: gb
  • Doing electronics since the 1960s...
Re: Using Claude Code for embedded work
« Reply #139 on: May 13, 2026, 06:53:36 pm »
I tend to agree; the video is pretty bland. But there are other reasons why large IT projects tend to fail.

For example in the UK National Health Service, most IT projects fail because of poor staff buy-in, which in turn is caused by recruitment practices which bring in too few smart people (a polite way of saying too high a % of the 1.5M staff is thick, and what keeps it going is a small % of good hard working people).

More generally, most IT projects fail because of incompetent initial specification. Incompetent people gravitate to large organisations, especially govts. This is obviously known in the large contractors who always tender for these jobs, so they quote low to get in. They know they will get paid provided it meets the spec even if it doesn't work. Then they quote a high daily rate for mods, and these are always needed to make it work. Often, the cost overruns cause the project to be scrapped.

AI might save money by accelerating the scrappage cycle :)

Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 
The following users thanked this post: Siwastaja

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11236
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #140 on: May 13, 2026, 06:59:53 pm »
I tend to agree; the video is pretty bland. But there are other reasons why large IT projects tend to fail.

For example in the UK National Health Service, most IT projects fail because of poor staff buy-in, which in turn is caused by recruitment practices which bring in too few smart people (a polite way of saying too high a % of the 1.5M staff is thick, and what keeps it going is a small % of good hard working people).

More generally, most IT projects fail because of incompetent initial specification. Incompetent people gravitate to large organisations, especially govts. This is obviously known in the large contractors who always tender for these jobs, so they quote low to get in. They know they will get paid provided it meets the spec even if it doesn't work. Then they quote a high daily rate for mods, and these are always needed to make it work. Often, the cost overruns cause the project to be scrapped.

I think it's spot-on analysis. How AI actually ends up changing this, it's very hard to predict. Now it's already clear that out of functioning team of 10 programmers, you can take the brightest one or two, and replace the remaining 8-9 with Claude. And projects that actually require a team larger than ~50 people should be nearly non-existent (maybe a linux kernel with all the driver work etc. is an exception to this). This means that with AI, team of 5 actual human engineers should go very far. But they need to be good ones.

But will it work out this way? What if you replace the wrong people? What if there was no "bright mind" in the project at all? What if the development was crap because no one had any idea how it should be actually done? What if there is only a "product manager" who keeps wanting the wrong things, implemented the wrong way. Then the result with AI will be equal failure, just faster. Or, in worst case, not even faster, but even more complex. Maybe you were given a 5-year timeline and 100 million budget "because that's how software projects always are" and now you are 20x more "productive" producing crap? Yes, that's a real threat.

Silver lining is, that underperforming "product manager" could be replaced by AI, too, and it's not probably any worse. Ask Claude for the "big picture" suggestions and they are usually pretty sensible because that's basically through consensus filter, while you get some of the usual software industry mistakes baked in, you also avoid some super weird atrocities real "managers from Hell" are capable of inventing.
« Last Edit: May 13, 2026, 07:01:40 pm by Siwastaja »
 

Offline az1

  • Regular Contributor
  • *
  • Posts: 61
  • Country: us
Re: Using Claude Code for embedded work
« Reply #141 on: May 13, 2026, 08:41:24 pm »
Now it's already clear that out of functioning team of 10 programmers, you can take the brightest one or two, and replace the remaining 8-9 with Claude.

 :-DD :-DD :-DD

I've been working on a small software project for a few months (Embassy compatible HAL for a few Renesas RA chips).  Someone popped up recently in the chat room and asked about policy around AI code in pull requests.  They'd been working on the exact same thing, only they'd been heavily leaning on Claude.  I don't really have a dog in the race because they were aiming to include their project in the official Embassy repo and I'm not.

We've been working on these projects independently for the same time so I thought it'd make an interesting comparison.  I'm not some mythical 10x coder but am already way ahead of them in terms of peripheral support and documentation.  Their whole project demonstrated that Claude did not understand the task at hand and nothing was being maintained.  Documentation referred to directories that don't exist, code referred to different directories that don't exist.  But the worst part was that the code Claude excreted looked plausible enough that a senior dev might waste their time reviewing it.  My favorite was that they used tokens to change a path from absolute to relative.  Claude came up with 40-odd words tho to describe that trivial change, so that's something, right?

But that's not news.  Anyone who relies on AI burdened companies like Microsoft (Github) or Cloudflare can point to AI induced outages.  So, sure, AI will replace jobs insofar as people are willing to lower their standards.
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 6035
  • Country: gb
  • Doing electronics since the 1960s...
Re: Using Claude Code for embedded work
« Reply #142 on: May 13, 2026, 09:21:24 pm »
The problem with lifting code from Github is that it is easy to publish something on there (or elsewhere online) which is somebody's copyright or patent.

The owner may not discover it for years. For example, I run a forum (not electronics) which has been going since 2012. From time to time we get copyright infringement threats over a photo or something that was posted on there years before. Just got one over something from 2018 - 8 years ago. Forums are protected from liability provided the alleged item is removed within a few days (in general terms) but the lengths of time are interesting.

And with AI lifting huge amounts of code from places you have idea of, this is surely more likely to happen. I would certainly not want to use AI to generate code which will then be published for anyone to examine e.g. open source ;)

Cloudflare is a great service but is losing its way. Its website is now highly browser version sensitive - a sure indication of cretins running the show.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline Bud

  • Super Contributor
  • ***
  • Posts: 7933
  • Country: ca
Re: Using Claude Code for embedded work
« Reply #143 on: May 13, 2026, 10:13:30 pm »
Cloudflare has claimed Post-Quantum readiness, not all browsers versions support that. This may be the/a reason.
Facebook-free life and Rigol-free shack.
 

Offline Unixon

  • Frequent Contributor
  • **
  • Posts: 762
Re: Using Claude Code for embedded work
« Reply #144 on: May 13, 2026, 11:54:48 pm »
Not really, the best application is currently talking about it, making videos about it.

 

Offline Unixon

  • Frequent Contributor
  • **
  • Posts: 762
Re: Using Claude Code for embedded work
« Reply #145 on: May 14, 2026, 12:19:00 am »
In earlier videos they struggled with getting hands and teeth right.
Now it seems this is more or less fixed...

 

Offline 5U4GB

  • Super Contributor
  • ***
  • Posts: 1755
  • Country: au
Re: Using Claude Code for embedded work
« Reply #146 on: May 14, 2026, 06:00:04 am »
In earlier videos they struggled with getting hands and teeth right.
Now it seems this is more or less fixed...

They still have serious problems with jabberwockies though, and since no amount of training on videos will fix that, you need an actual understanding of human anatomy, I don't know if this can ever be resolved by a stochastic parrot.

For people not familiar with the term, it's when body parts appear and disappear as a person moves.  Because a video of someone turning around has limbs and things not visible at times, the parrot magics up something corresponding to when the parts disappear and reappear in the scene.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11236
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #147 on: May 14, 2026, 06:16:14 am »
I've been working on a small software project for a few months (Embassy compatible HAL for a few Renesas RA chips).  Someone popped up recently in the chat room and asked about policy around AI code in pull requests.  They'd been working on the exact same thing, only they'd been heavily leaning on Claude.

So what was the problem they were solving, and why?

The whole AI slop phenomenon exists because it is now easier to pop up and start to "contribute". Harmful contributors always were a thing, now just amplified because AI acts as force multiplier.

I.e., someone "wants to help", maybe with no harm meant, but wanting to help is not enough, you need to understand what is needed, why and how and do that. In case of AI, ask it to do the right thing. This is especially important when contributing to projects maintained by others.

Things like security reviews are an exception: they seem to work now because anyone can prompt "read all the code and find security vulnerabilities" and as most actual developers of actual projects have found out (https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/), the slop is almost gone now. But if you ask the AI to fix those issues, it's already hit-or-miss - sometimes fixes are obvious, e.g., adding a bounds check to prevent overindexing, but sometimes changes in program structure, even external behavior is needed, and then you need to be the one who maintains the project; someone who knows how the project should work. AI can guess, just like outsiders can guess.

But adding new features is especially risky, with humans, with AI, and probably with AI even more dangerous because it can do so much more in so little time. This is exactly why I said keep the 1-2 bright minds, those who know what is needed, and let AI act as force-multiplier to them. This seems to work for us very well. Accepting random work from outsiders, no, that does not work, and AI does not magically make it work.

TLDR, main developers, if any, should be using the AI, separate "AI enthusiasts" putting their noses in foreign projects is the slop problem.
« Last Edit: May 14, 2026, 06:37:27 am by Siwastaja »
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11236
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #148 on: May 14, 2026, 06:27:19 am »
They still have serious problems with jabberwockies though, and since no amount of training on videos will fix that, you need an actual understanding of human anatomy, I don't know if this can ever be resolved by a stochastic parrot.

For people not familiar with the term, it's when body parts appear and disappear as a person moves.  Because a video of someone turning around has limbs and things not visible at times, the parrot magics up something corresponding to when the parts disappear and reappear in the scene.

I have been wondering why we haven't seen a significant paradigm shift in generative AI image, especially video generation; AFAIK, it's still basically predicting pixel colors pixel-by-pixel with a neural network, and for that, it's amazing how well it can work, but will result in six fingers which then, when sequences of frames are generated, morphs into four fingers.

Why don't they use something LLM-like to produce more anatomical "simulation" of object / body part trajectories, use that to produce 3D models, then use the pixel-based NN to apply textures - or something along that idea?
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6440
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #149 on: May 14, 2026, 06:30:32 am »
Peter and Siwastaja.  You are close, but quite off the trail.

The software industry is in free fall right now, it's completely lost it's way.  That is from BEFORE AI.

2017 - Cloud.  Most people wanted their infra converted to cloud.  They got sold in. 
2020 - Pandemic.  Demand for software went up 10 fold or more.
by
2022 - The majority of "technical" staff in the industry are not degree qualified.   In fact not qualified at all.  No background, no commitment, no "trade", no "practice", no "discipline".  Just any punter off the street that can pass a code interview got hired and give the same fucking title as me.  They really want to be a chef and have not a single care for software.  Grrrr.

2026 - The critical mass is gone.  Qualified and skilled engineers ... actual qualified, background, life, carreer engineers are so few that the entire language, discussions, ways of working are gone.

Seriously in 2024 I had to survive a meeting where the project managers spent 2 hours inventing release notes.  Literally they know nothing and they are trying to work out how to do software from scratch again. 

Every time you drop something like, "If we don't have requirements, we should not start.", you get confused looks and are apparently the problem.

I'll be honest with you and say, I haven't 'delivered' on power for over 4 years.  It's eating me alive from the inside out.

The pace is about 10th what it was before.  The gravity towards a working solution is non-existant.  Nobody can even "picture" the "done state" in their minds, so they don't even believe there needs to be such a thing.  They start in the middle and work like chaos.

AI will not fix it.

When they (my last work) started asking us engineers if they had certifications and if they would mind getting some.... I asked, "When you higher a manager for a development management role, do they do certificates in management?  Do you even send them on a training course for same?  No?  Didn't think so."

My answer to them was repeated over and over again.  "Please refer to my CV".  Which includes a FULL education history in software, a 2.1 degree, Higher certification in software design, Lower certificate in generic 'Computing science'.  20 years of experience working with household names, Tier1 international organisations, banks, governments.  "Please refer to my CV".   Because they never read it.

Honestly, it's so bad that those qualifications... when your bum is on the seat these days is worthless.  The majority of people don't understand your rigor and practice and see it as a threat to progress.  You are the problem and the main part of it is your "Software Engineering" skills.  They are not welcome.

EDIT:  The plus point is made in that video.  The projected collapse and utter failure and chaos will make my skills worth quite a bit more.  The question is.... can I survive the career until that happens and survive the collapse without tell people what I really think and losing the job.

Right now I feel like I am walking on thin ice.  The career is barely working at 51 and I have 16-17 years to retirement and no budget to retire early.  It's not a small load.
« Last Edit: May 14, 2026, 06:46:28 am by paulca »
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 
The following users thanked this post: Siwastaja


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf

 

-->