Even with (more) UX engineers, it was incredibly difficult to get any development done. When I was in this space, management and contractors were incredibly entrenched playing political games to grow teams even bigger to get more funding. There was nobody with any authority using the thing end-to-end saying “this sucks”.

I worked for a German car company for a little bit, in a team responsible for a similar system: https://www.srcbeat.com/2023/08/sbt/

Unfortunately for those who have those values, not all paid positions involve acting on those values.

Random brain dump incoming…

Most businesses pay money to solve problems so they can make more money. You can solve their problems - but not in the way that you may be thinking.

This is a generalisation that is not strictly true, but I say it to illustrate a different way of thinking: Businesses do not undertake penetration testing because they want more secure software. They do pentesting so they can stay in business in the face of compliance and bad actors.

To find a job, you want to start learning what people pay for. People pay contractors to come in and fix things, then leave again (politically easier, sometimes cheaper). People pay sotfware developers to develop features (to sell more stuff).

Start looking up job titles and see which ones interest you (DevOps, frontend dev, backend dev, embedded…). Don’t get too stuck on the titles themselves. It’s just to narrow down what kinds of business problems you find interesting.

Other random questions:

• What specific projects are you interested in?
• What types of problems do you like solving?
• Do you like digging in and finding those tricky bugs that have been bothering people for years?
• Do you like trying out new frameworks which let you think about the system differently?
• Would you rather implement a database or GUI toolbox?

Once you’re deep in the belly of the beast, you’ll find ways to exercise those values. It’s hard to know in advance what this will look like.

Ah yes! That is a great trick that kept me going doing software dev professionally.

Instead of trying to get the system I was working with to interact correctly with some shit enterprise system, I would find common protocols (or related protocols) and implement that well. Then I would discover more specifically where the shit enterprise system was behaving badly, and point to something politically neutral (like an IETF RFC) to help get us out of a rut.

It made debugging so much easier. Those specifications and open-source implementations have had much more engineering talent put in them than what I was usually dealing with.

Ah come on, we all know as software people we can never stop the spreadsheets from being the real data interchange format ;)

I’m not so surprised anymore. I’m self-taught using open-source software projects for guidance. But not everyone learns like that. For example in the commercial software dev world, having patches easy to apply with minimum tooling isn’t usually a priority (for better or worse).

This is actually a little story I had half written down; your comment prompted me to finish it. Thanks! https://www.srcbeat.com/2023/11/git-email/

Honestly, DNT as it’s implemented in browsers today is not a sufficient solution

I’ve come to the same conclusion (blogged about it here https://www.srcbeat.com/2023/11/linkedin-do-not-track/) after updating myself on where it’s all at.

I also think about pop-ups back in the 90s/00s. Imagine if browsers sent a “No-Popups” header (or something) back then. I doubt we would have seen any change in company behaviour. Instead, it took something like Firefox to implement pop-up blocking by default (https://lwn.net/Articles/130792/).

Yes that’s true. I guess what I wanted to point out is that GitLab has dependencies like Postgres, Redis, Ruby (with Rails), Vue.js… whereas Forgejo can use just SQLite and jQuery.

McCodeBurger

Something not mentioned yet: Forgejo, the software running Codeberg, has a smaller feature set and narrower scope than GitLab (“GitLab is the most comprehensive AI-powered DevSecOps Platform” from their website).

Forgejo is much easier to administrate for smaller groups. For example compare the dependencies mentioned in the Forgejo installation documentation and the Gitlab installation documentation.

Ironically this site serves koko analytics, which now ignores the Do Not Track header (as per Mozilla’s recommendation, mind you). See commit 6890f3c.

Thankfully uBlock Origin blocks loading the scripts.

Assuming MTP is Media Transfer Protocol?

MacPorts is so boring and underrated.

Oh there is absolutely zero disappointment.

Years ago I wanted to learn how OpenBSD worked. Some people said to me “ah you want to get into programming at OS level? I was a bit disappointed with Go. But don’t learn C, learn Rust; Rust is the future there”. So as a total novice I looked at all 3 on the page. My impressions were: Go looks easy, C looks a bit harder, Rust looks… way too advanced for a beginner like me.

Later when I heard of Zig I started reading and it looked a bit more like what I expected a “future C” to look like.

I wish I had more time and skills to do work in C, Rust and Zig. I’m a Go programmer by trade.

Would you say Go is popular enough to be called mainstream?

Zig is what I thought Rust would be like when I first heard of Rust. I’d love to try Zig for some hobby things but can’t get it running on OpenBSD (yet!).

I am consistently surprised by what companies are willing to pay to not worry about capacity. Incredible DataDog bills, for example, because they didn’t want to think about how many application metrics to store; “just keep it all!”. And boy do they happily pay for it!

Ok I’m starting to understand where you’re coming from now! It sounds like the leaders are happy for humans to do the work of increasing capacity on-demand rather than tackle the engineering challenges in handling workload spikes. The priority is to appease customers who are from well-known, “impressive”, well-paying (maybe not?) companies. Does that sound sorta right?

Inform and throttle. Think about how your own computer works. If storage reaches its max capacity, you get a signal back saying “filesystem full” (or whatever), not “internal storage error”. If the CPU gets busy, it doesn’t crash; things start slowing down, queued up, prioritised (and many other complicated mechanisms I’m not across!).

You could borrow those ideas, come up with a way to implement the behaviour in your systems, then present them to whoever could allocate the time & money.

Another approach is try to get a small, resource-constrained version of the system running and hammer it by loading heaps of data like those customers do. How does it behave? What are the fatal errors and what can we deal with later?

Agreed. I didn’t know about these features - I’ve never written any Perl before - and I do find them kinda interesting and cool. But not really surprising.

A less clickbaity title might be “Exploring Raku’s built-in shortcuts for CLIs” or something. Still 6 words. And I still would have clicked and enjoyed the article! Really appreciated its positive tone and clear examples!