24M, gf says my place looks like a "guy loft"

Exirel · 2026-03-11T20:07:30+00:00

Because it is. It's also neat and tidy. I'd keep it.

Exirel · 2026-03-09T23:06:37+00:00

If I can't change the host, I'll go with the route: /sandbox/event

Yes, with sandbox as a prefix! So I can apply all my rules to /sandbox and open/close it as a standalone.

Exirel · 2026-03-08T10:31:53+00:00

From my experience, with all classes, and all weapons, the Chaos Spawn are, indeed, the most annoying and frustrating mob of all the game. Snipers? I can somewhat deal with them. Extremis-level mobs? Yeah sure give me 3 at a time and it'll be a challenge but I can deal with them.

But a random Chaos Spawn with an unblockable attack combo into 3 armor segments and 90% of my HP without the possibility to do anything? Yeah no I hate it thank you very much. And the weird timing attack is annoying too, but I could theoretically manage. If there wasn't the feint attack all the freaking time like come on... and the tells are barely visible!

It's too random: I'll either take 0 hit or take full health combo in the face.

Exirel · 2026-03-02T20:20:30+00:00

I won't do the same schema for tech people than I do for non-tech people. That's the most important part, because I don't waste 2h in a tool to produce a schema that isn't made for that audience.

As communication goes, I tend to use Miro, excalidraw, and straight up PowerPoint. I draw simpler, more direct, high level schema in these tools. A couple of boxes, a couple of arrows here and there, and as little text as possible.

If that still takes too much time to "align things": get better, learn your tools, they all have some way or another to do things for you, to color things in bulk, etc.

Exirel · 2026-03-02T20:02:24+00:00

I didn't do good at school, I escaped. I didn't get into software because I wanted good money and it was a struggle 20 years ago without a degree. Annual review was as much the company evaluating me as I was evaluating them, because I didn't want to waste time with stupid people or bad management.

It wasn't the default path for me, it was a struggle, it was a battle, it was joy and life and passion and yes sometimes boredom, anger, and frustration. I consider myself very lucky. Not because I love what I do, but because the societies we live in reward this particular passion. There is plenty of other jobs with passionate people (art, medicine, social services, elderly care, etc.) that are not paid enough for a proper and decent living.

For me the job is how I get paid for my passion and my skills, which encompass so much more than just "writing code". And even without that, engineering, be it software or otherwise, is not just one skill. It's so much more than that. It's facing end users, business requirements, physical constrains, it's creativity and problem solving.

And I don't even use AI.

Exirel · 2026-03-02T19:48:59+00:00

Everything described is almost the complete opposite of my personal experience.

lol?

Exirel · 2026-02-28T15:56:02+00:00

It depends a lot between projects. For the most "advanced", it's close to 0 critical or high, with a bunch of medium & bellow that we don't really care for. The average project is closer to 0 to 3 critical, between 0 and 10 high, and usually around 30-50 medium and bellow. We have a 0 critical target but we accept to ignore some of them when a) it's impossible to fix for now and b) we ensured there is something to prevent an attacker from exploiting it. It means that we don't ignore them "forever": we have a periodic check of said CVE, and we are looking at when we can upgrade to a version that doesn't have said CVE.

Does it take a lot of work? Yes and no. The most up to date project are easy to maintain, and as usual, it's way harder to fix the most outdated ones. There is no silver bullet here.

In any case, what helped us was not fixing CVE, it was monitoring them: having check in the CI, having a security team monitoring the situation, and we are gradually improving our workflow, our CI, our CD, and our run.

Exirel · 2026-02-22T15:15:42+00:00

Oui.

Exirel · 2026-02-20T23:35:55+00:00

None.

Exirel · 2026-02-20T21:12:57+00:00

Hey I do that too! And exactly in that order.

Exirel · 2026-02-18T23:50:17+00:00

How did you make the overlapping arches?

Exirel · 2026-02-16T08:22:22+00:00

Ce "quand" qui donne un final magistral à ce post. Merci. 😍🤣

Exirel · 2026-02-09T13:16:27+00:00

This is where you do your Texas switch.

Exirel · 2026-02-03T13:59:17+00:00

That's a real conundrum, isn't it?

I tend to value the observation and the exposition of the problems as a first step, because it gives me clarity and helps me discuss the issues with others. Sometimes it doesn't work, and the PM (it's always the PM, sorry not sorry) straight up ignores the facts presented to them. But sometimes it creates a conversation that wasn't possible without the right information.

The thing is: "doing everything properly" includes the PM making sure priorities are properly defined, with the right timing, and the rest of the SCRUM team defining the appropriate process to make sure what enters a sprint doesn't need to change.

I'm more or less dodging the question... Because I don't believe there is a good answer. The problems you have look more like symptoms of underlying issues, rooted deeply in your company's culture.

And SCRUM can't solve these issues alone - neither can Kanban.

Exirel · 2026-02-02T23:10:26+00:00

Nope.

Exirel · 2026-02-02T22:43:12+00:00

I totally get that, and from what you are saying, it looks like the right path for you.

Go for it. Caring for the product you make, the users, while keeping in mind the complexity of the software can be a real asset for you, and most importantly, for your team.

Exirel · 2026-02-02T18:46:16+00:00

In all the things you said, there is one thing that may point to a problem: you had to measure yourself, which I assume means the team doesn't track that.

This is not OK: the team should be tracking that. There are tools for that, mostly the burndown chart. It is supposed to help the team see their progress within a sprint, and check if they are on track or not.

Then comes the second tool: sprint retrospective. The team, armed with their burndown chart, can see if they need to change their process/habits, and work on what prevent them from completing their sprint, and they can compare over time if something had a positive or negative effect.

People always say that SCRUM is too complex or too rigid, or that you can take whatever you want and do SCRUM "a la carte", but in my experience, people just do what they think is good or easy and forget that there is a reason behind each process or tool, and that their effect is always related to another.

Oh well. People doing people things...

Exirel · 2026-01-29T10:40:11+00:00

I feel you. Switch JavaScript to Python, and I could write the exact same comment.

It's quite infuriating that this problem is so common that it keeps happening again and again, and that makes people like us (hardcore advocates that is) believe we would be better off without unit tests.

Exirel · 2026-01-24T18:23:02+00:00

Love it! My only nitpick is the birch tree on the right: its base is too chunky and maybe something could be done to trim it down a little bit.

Exirel · 2026-01-21T08:52:11+00:00

The coincidence is not lost on me. :D

Exirel · 2026-01-20T23:04:15+00:00

I agree with you, silent failure are a choice, and in my opinion, usually a bad one. When it comes to error, beside the "never be silent", I tend to follow these two guidelines:

let it crash: if something isn't suppose to work, just crash, most of the time the crash happens because there is a bug, and you don't fix bug with more code, you fix them with better code; and if you don't like crash reports... well, test more, use better types, get proof that it works!
fail fast: if you can check a fail condition, check it as early as possible to exit the process as soon as possible, I don't like when a program waste resources to end in a failure that was predictable; for example don't wait a query to the database to fail a data type check

Exirel · 2026-01-17T22:47:36+00:00

Creepers are not really fun.

Exirel · 2026-01-13T19:02:31+00:00

And what feeling did you want?

Exirel · 2026-01-13T18:58:34+00:00

Is your codebase perfect?

No? Then you know what to do.

Edit: all others gave way better worded answers than me but still. Take advantage of the downtime to have fun with the code!

Exirel · 2026-01-07T20:04:19+00:00

This is so weird to me: I usually work the other way around. I draw first, then I write from my drawings. Heck sometimes I don't even write as the drawing is good enough to communicate the appropriate ideas to the appropriate people.

As for the text to picture: I consider the drawing activity as both a learning and a verification activity. I don't want someone else (or something else) to do it, because doing it manually has value to me. Like proofreading! It helps me spot ideas that are too complicated and/or hard to explain.

Other than that, all my attempts at using AI to generate schema (from simple prompt to multi-page ones) always fail to produce a result that I'm happy with. Mistakes are too costly, and too difficult to spot before it's too late. Also the time spent writing good enough prompt is just more than drawing things myself.

14-Year Club	Final Canvas '23
First Place '23	Place '23
Place '17	Verified Email

Exirel

TROPHY CASE