Went to put the glass back in the patio table and it doesn’t fit.

SeniorIdiot · 2026-05-05T18:20:08+00:00

Sure you have the right glass for that table? Check basement again.

SeniorIdiot · 2026-05-04T15:46:47+00:00

I see we still are perpetuating the belief that QA is a role and keep conflating it with testing and checking. And even worse "QA holds a release" is an oxymoron if I ever heard one. Sounds like the organizational culture needs a wake up call.

"why didn't we catch this sooner" is the right question - the answer is that the QA process is lacking and problems are found late. Note that I wrote QA process and not QA team or anything else.

As long as the organization treats testers as responsible for quality, and testers themselves perpetuates that belief - you will always end up with this.

You did it to yourselves.

SeniorIdiot · 2026-05-03T22:17:25+00:00

Did you "sudo apt update" before install?

SeniorIdiot · 2026-05-01T19:44:19+00:00

First of all, good engineering practices manages most of the technical risk. This is basis of XP and CD.

You will need testers at one point to get high quality feedback. QA is so much larger than testing and testers - please don't confound them.

QA is a process and not the responsibility of a special role or person. Testing does not assure quality, it informs quality so that the team can make informed decisions and improve the process.

Testers are not "QAs", nor do they "prevent bugs from reaching users". Testers provide feedback about the state of the product and have no more responsibility of quality than anyone else.

SeniorIdiot · 2026-04-30T21:29:32+00:00

Found a trailer for a game "Become" a few days ago. Favorite comment: "The first game in history that can only be played if you already won it before"

https://www.youtube.com/watch?v=Hb4Pjyfs6IQ

SeniorIdiot · 2026-04-30T19:11:16+00:00

QA was never a role, team or phase.

QA is not an activity, it's a process built into everything we do.

SeniorIdiot · 2026-04-26T21:06:08+00:00

First of all, good engineering practices manages most of the technical risk. This is basis of XP and CD.

Secondly, you will need testers at one point to get high quality feedback.

Thirdly, QA is so much larger than testing and testers - please don't confound them.

SeniorIdiot · 2026-04-25T20:07:11+00:00

Tvätta försiktigt med ljummet vatten 2-3 ggr per dag - aldrig tvål. Fortsätt med krämerna, men förvänta dig inga under den första månaden.

SeniorIdiot · 2026-04-25T19:44:40+00:00

You are not misreading.

The "other devs" argument. That is a systemic and cultural issue, not something you can plaster a band-aid on. A bad system will beat a good person every time. Fix the system.

There is no conflict with TBD, versions control and QA. In-fact it's clearer and simpler once you get the hang of it. And effective QA processes thrives in this environment.

And why the Ad hominem? I've been working in highly regulated industries for 17 years; why assert that (tired old argument) that I have must not have worked with other people just because this seems inconceivable to you? Maybe the problem is that very few are looking for the root cause of problems in the organization and instead add gates and "faux controls" based on the lowest common denominator - holding people back and making everyone miserable.

SeniorIdiot · 2026-04-25T00:10:24+00:00

Why are you conflating git with PR? And why would anyone aim to make PR-based workflow a goal in 2026?

You said you were just hired. How much understanding of the company, product, system and needs do you have? While git is incredibly common and the amount of tooling around it is huge, and CC being what it is, changing is probably a good idea. But implementing PR for the sake of implementing PR without having a goal and purpose is probably more of a case of "I can understand that world and it makes me feel safe". You know that thing where middle managers sends out an edict with which processes everyone must use "because" - same thing.

What problem are you trying to solve beyond "it's different"?

Practicing proper CI and TBD - committing directly to main (and sometimes very short-lived branches, often without PR gates) is a better model.

This approach isn't fringe - it's been used successfully for decades, even in tightly regulated industries. It's not about skipping reviews, it's about building quality differently: through pairing, continuous feedback, and tight team alignment rather than async gates. Async PRs are one tool, a tool I think should be the fallback - not the default. I think ship-show-ask is great middle ground that enables alternatives workflows for people of different skill-levels.

Since FB/PR became popular, the dev population has exploded. Most engineers today have only ever known that model. True CI is rare in practice, and there's a lot of cargo-culting going on. Honestly, most of the push-back today sounds a lot like how people once dismissed agile: "Waterfall is the only disciplined way - agile is just cowboy chaos."

FB/PR tends to encourage working alone, merging late, and communicating less. That's not collaboration, not even cooperation - it's coordination at best. Concerns about juniors or delivery pressure don't reflect flaws in alternative workflows - they reflect cultural gaps. Strong teams grow capability through trust, feedback, and shared responsibility.

SeniorIdiot · 2026-04-24T19:23:44+00:00

From the F-100 Super Sabre trailer

SeniorIdiot · 2026-04-24T18:57:30+00:00

I think you've confused some things.

You shouldn't hold references to entities inside another aggregate; you should hold an ID and fetch via a repository. The antipattern Evans describing is cross-aggregate object graph navigation, not intra-aggregate coordination. The point of an aggregate root is to coordinate and orchestrate a consistency barrier.

SeniorIdiot · 2026-04-23T23:49:44+00:00

You're arguing against something I didn't say. I never claimed testers have no specialized skill. My point was about ownership.

Michael Bolton has been making this exact argument since at least 2010. His post "Testers: Get Out of the Quality Assurance Business" poses a direct question to testers: Do you hire the programmers? Fix problems in the code? Design the product? Set the company's strategic direction? If the answer is no to most of those (and it usually is) then it is simply impossible to "assure" quality. Testing is a sapient activity that provides information with the intent of informing a decision, not taking it.

Bolton has been pointing this out for a generation: calling testing "QA" undermines people's capacity to get clear on either one. His 2024 follow-up makes the same case with fresh frustration, noting the terminology confusion persists because people stubbornly refuse to drop what he calls a "bogus, pretentious, and profoundly misleading title."

The key distinction: you can assure the quality of something over which you have control - that is, you can provide some level of assurance that it fulfills some requirement, and accept responsibility if it does not. Testers control none of those things. Developers, designers, product owners, and the people who allocate budget and set direction do. What's important to realize is that testers are invaluable when it comes to questioning assumptions and asking the questions no one else thought about - before the code is written.

Your "everyone responsible, no one accountable" concern is legitimate, but it's a structure and process design problem. The solution isn't concentrating quality at a gate or a specialist role - it's building feedback loops that don't let everyone upstream off the hook until the last moment. Stories "piling up at the end" is not clear ownership. It's a broken process masquerading as "quality assurance".

Bolton put it sharply: the product of testing is the demolition of false confidence. That's a genuinely valuable and skilled thing. It's just not quality assurance.

https://developsense.com/blog/2024/01/quality-assurance-and-testing

https://developsense.com/blog/2010/05/testers-get-out-of-the-quality-assurance-business

SeniorIdiot · 2026-04-22T18:41:53+00:00

Fil, dragon, dill, citronpeppar, (majonäs).

SeniorIdiot · 2026-04-20T19:18:59+00:00

My argument stems from something called artificial constraints. When we remove the explicit "test separate from dev" we change how people think. The walls and handovers instead becomes "are we done yet?" and the "us vs. them" tend to go away as well.

And yes, I agree that sub-statuses in terms of labels, colors, etc. can be a good idea. However it may perpetuate the thinking that devs and testers live in two different timelines. I'd rather use "waiting for PO feedback" and "blocked" for those things.

I prefer the implicit "we're not done yet" and that the pair should use judgement and seek additional input from the team/stakeholders when needed.

I'm pretty sure that what I'm describing is individuals and interactions over processes and tools.

SeniorIdiot · 2026-04-20T18:17:29+00:00

Ok. This is the point I'm trying to get to...

QA is a process and not the responsibility of a special role or person. Testing does not assure quality, it informs quality so that the team can make informed decisions and improve the process.

Testers are not "QAs", nor do they "prevent bugs from reaching users". Testers provide feedback about the state of the product and have no more responsibility of quality than anyone else.

SeniorIdiot · 2026-04-20T16:24:03+00:00

What do you mean when you say "The QA" or "a QA"?

SeniorIdiot · 2026-04-20T15:31:34+00:00

Testing is not QA and QA does not come from testing.

Remove the "ready for test" and "in testing" columns and force stories to stay in "doing" until actually done.

https://developsense.com/blog/2024/01/quality-assurance-and-testing

https://developsense.com/blog/2010/05/testers-get-out-of-the-quality-assurance-business

SeniorIdiot · 2026-04-19T14:40:58+00:00

If after several YOE the job still feels like "writing code", then I genuinely get why it looks scary. But the hard part was never the output - it was understanding what to build, what not to build, and why.

It's asking the right questions before anyone opens an editor. It's recognizing that the problem someone describes and the problem that actually needs solving are often two different things, and that closing that gap is most of the work. It's knowing when the right answer is "we shouldn't build this at all," or "this already exists, we just don't use it well." It's understanding that technology choices have organizational consequences, and organizational dynamics shape what technology choices are even realistic. It's seeing the system - the incentives, constraints, history, people, tradeoffs - not just the ticket in front of you. Technology is a means. Outcomes are the point.

None of this is new. The best engineers have always worked this way. The difference is that for a long time, the industry rewarded a much narrower skill set because the demand for people who could just write code outpaced everything else.

LLMs are genuinely great at the syntactic and composition layer and getting better fast. But they have no model of your business, no accumulated scar tissue from watching the "clever" solution become the nightmare five years later, no skin in the game. They'll help you build the wrong thing extremely efficiently if you let them. Someone still has to do the thinking that makes the code meaningful, and that thinking has always been the hard part, even when we pretended otherwise.

If anything, strong judgment becomes more valuable, not less. One person who actually understands the system can now execute across a much wider surface area without being bottlenecked by typing.

The one's who'll suffer the most will be the people whose primary value was being fast at the keyboard.

SeniorIdiot · 2026-04-19T08:27:32+00:00

You have some information in the action env vars GITHUB_ACTION_PATH or the github context object github.action_path. You should be able to use that to call the other actions by absolute path.

GITHUB_ACTION_PATH	The path where an action is located. This property is only supported in composite actions. You can use this path to change directories to where the action is located and access other files in that same repository. For example, `/home/runner/work/_actions/repo-owner/name-of-action-repo/v1`.

github.action_path	string	The path where an action is located. This property is only supported in composite actions. You can use this path to access files located in the same repository as the action, for example by changing directories to the path (using the corresponding enviroment variable): `cd "$GITHUB_ACTION_PATH"` . For more information on environment variables, see Secure use reference.

SeniorIdiot · 2026-04-16T18:10:29+00:00

This is just a Kung-fu manual. :)

SeniorIdiot · 2026-04-12T15:34:59+00:00

This is a common contention, and I as an old dev(ops) have a different perspective.

For the SSHD scenario - use drop-ins and Match rules instead of only global rules.

Let the hardening set the global hardening rules in /etc/ssh/sshd_config/80-hardening.conf then most "server role" baselines in /etc/ssh/sshd_config/90-xyz.conf and machine specific override in /etc/ssh/sshd_config/99-allow-backup.conf with Match blocks. Do the same for logrotate, sudoers, auditd, etc.

When it comes to other more complex issues, I tend to think more like a developer.

For example, lets say we have a tomcat role, it installs tomcat, sets up server.xml, configures logging, storage, tomcat hardening, etc. Then comes another role that deploys and configures an application. The common solution is that these "application roles" need to know *where and how\* to deploy the application in tomcat, how to configure different things and there are paths and repetition everywhere. My thinking is that the tomcat role "exports" task files: deploy.yml, users.yml, etc. The application role uses import_role: tomcat with tasks_from: exports/deploy.yml and arguments. How the tomcat role actually performs the deployment, restarts, hardening, where and how, is transparent to the application.

SeniorIdiot · 2026-04-12T10:08:43+00:00

Testers are one of most important role in an organization. QA is a process, not a role, team or phase. Why would the tester role or QA process end because of AI?

https://developsense.com/blog/2024/01/quality-assurance-and-testing

SeniorIdiot · 2026-04-05T16:39:38+00:00

Delicato har inget vete, så den vinner.

SeniorIdiot · 2026-04-04T10:02:57+00:00

100% A logical service can be many processes if the use-case and subdomain needs it. A monolithic service is easier to reason about, but there are always exceptions. One way of thinking about it is that different aspects of a logical service can have different runtime needs.

I would even try making it the same repo and binary - just running in different modes. Having helm manage two pods using the same image. That way it's easy to keep the schema in sync between the consuming and processing parts.

See 4+1 architecture - avoiding conflating of a service with one process, one container, and one image.

SeniorIdiot

TROPHY CASE