DEV Community: Matthijs

How to code like a boss?

Matthijs — Mon, 17 Mar 2025 22:56:20 +0000

Simple, allow yourself to code like a boss!
Honestly you are the problem! Not the tools, not the language, not your boss, you are!

Ok there is one exception to this, if you're stuck at your job, some of this may be out of your control. But is all other cases, you are in control!

TL;DR

Get annoyed and fix what pisses you off
Experiment and learn what can be done better
Get the right tools and use them
Use the language as it's intended
Does what others do work for you?
Make your boss work for you

Ok let's go!

Allow yourself to be pissed off!

I recently had to start using Windows again... and boyo does it fucking suck! Windows 11 is the worst and I have been fuming on a daily basis by its sheer incompetence. And yes I could consider them as minor annoyances and just accept them... but I won't... and nor should you!

Allow yourself to be pissed off at software that doesn't do what you want it to, curse and scream at your monitor! And use that as an indication to ask: is it PEBKAC? Or is the software just utter crap?

Change what you can to get rid of annoyances because these are the core reasons why you're not coding like a boss yet.

If your Windows automagically switches your keyboard layout from UK to US or vice versa, remove the layout that pisses you off... or use not-windows
If your IDE is really slow, figure out why and uninstall the plugin that is sending all your data to $bigbrother
If your unit tests fail because someone made a change, sit down together and figure it out
If your boss doesn't let you experiment to improve your skills/efficiency, find another boss

And related, consider the ergonomics. Is your desk, chair, computer, laptop, screen, mouse and/or keyboard up to snuff? If you wanna be good, you're gonna be doing this for a while so ensure your body is gonna hold up in the longrun.

Experiment

Just because you've always been doing it like that doesn't mean you have to keep doing it like that. As a matter of fact I really really... really fucking hate that mentality!

So the other day I decided to do yet another new experiment: does Neovim and Go make me more productive? Thanks @ThePrimeagen for giving me another hobby I could do without! Did I need to do this? Nope... not for my job at least... but did I want to do it: HELL YES! I love trying out new things to see if it can either help me improve my own skills or allow me to be more efficient... or inspire others!

So what am I trying to prove? Are there better editors/IDEs out there and is there a language better suited for what I do? I do this shit on a regular basis, whether it's getting a different keyboard, trying a new language or dicking around with automatic provisioning... I just want to get better.

There are very few things more effective than experimenting because you fail continuously... failure == good! It allows us to learn, the more you fail, the more you learn (assuming you accept your failures).

Choose the right editor/IDE

Just because someone tells you VS code is great, doesn't mean that it is... or isn't. You need to find out for yourself what works and what doesn't.

When I'm behind my desktop I don't want to let go of my keyboard because moving my arm 10cm to my mouse and back feel inefficient and potentially ergonomically problematic. So in this case I want to use an editor/IDE that allows me to do everything with my keyboard. I've also extended this to my browser with spatial navigation. Then again if I'm on a Macbook I'm less bothered by this as the touchpad is so damn fantastic. That said in the end I still prefer a split keyboard + no mouse when coding for more then an hour.

I've used a lot of different editors and IDEs and even the ones that sucked terribly have been a worthwhile experience. I'm not saying one is better than the other, I've always enjoyed coding and the tools were the enabler. But I have matured and with that realised what the enjoyment of coding is... the coding! Anything around it is just an enabler and should STFU unless spoken to.

Automation is key

Over the years I've convinced myself I've become a better coder. Regardless of whether that's true I've automated the hell out of my dev work so I can focus on coding (and yes, I do see the irony). If I press "save" on my code, within a second I know for a fact how good or bad my code is and whether I can push it up.

How?

Syntax highlighting, because duh!
Linters & Formatters, let your editor handle that shit
Automatic test runners, :w -> see unit & integration tests purrrr... for a second
Code coverage, fuck the statistics, but seeing which lines aren't tested means you can make a split-second decision on whether to care
LSPs, instant feedback on your code is wonderful
Scripting, Bash is wonderful and even though I was sceptical I'm starting to see the benefit of Lua in Neovim
Version control, knowing what changed is half the battle, merging and rebasing is the other half
AI, Copilot and others are an enormous time saver, especially when you're doing more of the same. That said, with learning Go I've realised that, although a big help, I still yearn for the documentation to really understand how things work. In coding understanding why something works makes you better, not copy/pasting a solution from stackoverflow (or having a LLM do it for you).

Note that CI is crucial in the next phase, whether in a pipeline or as a pre push hook, ensure you run automated code & security scans, end to end tests, builds, rebase checks and any other automated check that could potentially prevent your PR from being merged

Use a proper OS

I don't care what you use as long as it doesn't need a reboot every other fart and actually does the thing it needs to do when you want it to. I'm not saying install $linux_distro or go buy a Macbook but consider this:

Every second wasted on twiddling your wiener because you have to wait on something, is a second not coding as a boss

What's the best language?

Well as per usual: it depends. Just don't think for a second your language is a Swiss Army knife. But... feel free to try it and fail because that is a valuable experience... again, assuming you acknowledge your failure.

I've used quite a few languages, some I hated... some I hated even more... I even attempted to create my own at some point? Why? Because Bash is such a shit show I wanted something... less shit. It was called... KISS for obvious reasons. But I ended up abandoning the project when I bumped into CoffeeScript as that was super close wrt syntax and package management. It just wasn't a Bash replacement, but who cares I had a new toy!

And now I'm enjoying Go, because? I don't know it just feels right... everything I want to do just works as I expect it to. Kudos for Ken, Rob and Robert for really nailing it. But that just means it's a good language for me. I've fought with too many languages over the years and in the end it may mean you're not gonna be friends and that's ok.

Back to lesson 2: experiment, try out a couple languages... build a side project in some language and figure out what you like and hate about the language. For example, I've always hated interfaces, they seemed... reversed... and guess what? Go flipped them around and they're amazing! Equally Bash as a language is wonderful... to a certain point... once you reach that point: stick everything in /dev/null and walk away. I found out by experimenting with multiple languages why I didn't like them and how and when they can be useful... and most importantly: fun to code in!

More brains == smarterer

It doesn't matter how smart you are, the collective brain knows more. Talk to people, do pair programming, listen to senior engineers, listen to junior engineers, DevOps, QA and Database engineers. They will all have interesting stories and experiences that you can learn from. No point in falling into the same traps as they did... well actually, in some cases it is essential to fall flat on your face as some things can't be taught.

You can learn a lot from other people and how they solved things and you should use that to push it to the next level, stand on the shoulders of giants and all that... but also try to understand what and why they did and not just accept that what they did is right. Really understanding the layer you're building on, helps you to build things better.

The hardest thing is probably accepting that what you build is shit... whether it's someone else showing you the light or you come across some project that does what you're building but better, do a final commit & push and stop. But it was not a waste of time tho! You have learned a lot and you can use that in your next project... for which undoubtedly someone comes along to tell you it's shit, so you know... fuck other people's opinions!

Make your boss work for you

Your boss has 1 job: enable you to be as efficient as you can be. And contrary to popular belief this means your boss needs to invest in you. Obviously there isn't a money tree growing in your company but investing a couple bucks can create an enormous efficiency gain. Consider your boss gives you a crappy chair, desk, laptop, mouse, keyboard and which saves the company $2000 one-off. You get a problem with your back and guess what, 1 month in and the company already wasted more than they saved because your productivity went down the drain.

But you are the one that needs to make your boss aware. You feel the physical pain and/or mental pain of the inefficiency, your boss doesn't. Your boss just doesn't understand why shit's taking so long. If you have great boss they'll regularly check-in to see how they can help you being an even better version of yourself, if you have a good boss they help you when you ask them and if you have a terrible boss they ignore everything you say. In the latter case, find another job. In the former cases, understand what pains you (and your team) and help your boss enable you!

One of the guys in my former team kept harassing me to go to Slack because Teams was shite. And while I felt his pain as well, it was his tenacious attitude that convinced me to get budget and get it sorted. It was one of the best moves for him and the rest of the team.

Conclusion

Whether I'm coding like a boss or just feel that I do, it doesn't really matter. What matters is that you make the miles. You don't get good at something by staring at it or letting others/AI do the heavy lifting. If you want to be a boss, do the work! Try new things, stick with it for a couple years, learn, move on and rinse and repeat.

And take your time! It's not gonna happen overnight and it's not gonna happen by itself. But above all: enjoy coding!

My ever-growing list of editors

Norton Commander & PE2, thanks to my dad for having this setup back in the day as it helped my managing that shit ton of BATch files when I was about 10...
- Fuck... I just realised I've been doing shell-scripting for 30+ years 🤦
Notepad / Notepad2 / Notepad++, this is fine...
Borland C++, it was really good back then... not sure how well it aged tho
Visual Basic, I can only remember a lot of buttons that didn't really work and you ended up doing it in code... in true micros~1 fashion
Borland Delphi & Kylix, I wasn't overly impressed but it did the job... Kylix (aka run Delphi in wine) was terrible tho
Vim, I've spend a lot of time in Vim and we go way back! Yet I did abandon it
Atom & Sublime, I wasn't happy with Vim, so you try things... good things... bad things...
VS Code, This is what I settled on after Vim... why? It did things... a lot of things and unlike many other micros~1 products it did them well
Neovim, and here we are... back to Vim... or maybe I'm secretly longing for PE2?

WTF even is Software Engineering?

Matthijs — Wed, 24 Apr 2024 09:10:31 +0000

While figuring out why coding is so overcomplicated it occurred to me that the majority of it isn't due to the coding itself. But rather the whole SDLC is to blame. But what actually is that? And what should we be doing? And how do we keep it as simple as possible?

Waterfall

Back in the day we used to do waterfall, which has its pro's and cons... The projects we used to run were quite ok, at least we managed to meet the deadline with all required features and the quality was good enough. Now I'm not here to promote waterfall (although Iguazu is absolutely stunning) but it does nicely illustrate what is needed for software engineering:

Why is this relevant? Whatever your methodology, spend the fucking time! Don't skimp on analysis, design, dev, QA or ops... it will bite you in the arse!

Agile

Now fortunately we moved to a more iterative approach where we can evaluate what we've built more frequently. As said, you still need to spend the time but the big difference is that it's a lot more intertwined. Especially QA, deploy and run have become an integral part of the cycle... and honestly it's fucking awesome!

This is an indication of how it could look... it kinda implies Sprints but a more Kanban style approach would work equally well. Most importantly ensure everyone is involved on a continuous basis...

Team work

For me the best part about agile (aside from it being called ASD) is that it forces you to work as a team. Everybody has to be communicating with each other otherwise it's not gonna fly. I can't stress this enough:

PO, Architecture, Dev, UX, QA & DevOps all need to be fully aligned!

Any meeting you have on a feature, from conception to deployment, make sure everybody is in it. And for the love of god, take the time to discus... assumption is the mother of all fuck-ups. Even if you think everything is clear, it isn't!

Requirements

I like requirements analysis as a means to determine what is needed as it ignores the question of how something gets implemented. Don't let a PO come up with a solution, that's what UX, Software & DevOps engineers are for. Sorry PO's, no it's not your job... by all means raise suggestions and examples of how things can be solved but leave it to the team to come up with the how and jointly validate it meets the requirements.

Also please ignore the customers' cries that "it has to work like this otherwise it's useless" because that ruins the product... think about all the other customers and really distill what the underlying problem is... what is required?

Reporting

And the first requirement to consider is:

As a Product Owner, I must receive usage information for feature X, so that I can validate it's useful to our customers.

Normally we leave this till the very last moment and consequently don't implement it... but please please please do this first, you want to prove something is useful or not... cuz if it isn't... BIN IT! There's nothing worse than useless crap in your product... not only is it cumbersome for your users but it also has to be maintained.

Architecture

This may very well be the most important piece to allow the whole thing to work... but it deserves a whole separate post... or even a series... or rather go get a proper architect and consider what is needed for your organisation, cuz there is no one-size-fits-all.

That said, there are some pointers:

Like software your architecture should be flexible... it's a balancing act between solid guidelines and change to facilitate the ever changing requirements
Reducing dependencies and compartmentalization helps to create a more sustainable environment
Hire an architect, someone who knows its shit and actually has time to solve things in the long term... when you build a house you don't just throw builders at it, there is a structure

DevOps

You'll eventually need to be able to enable a feature in production, but there are a whole host of things that need to be sorted before that:

Logging for monitoring & incident management
- Like reporting this is always considered last, don't make that mistake!
Automatic provisioning of your infrastructure
- Doesn't matter whether you do cloud or on premise, automate it
DX... Developer eXperience is a thing
- Enable your developers to focus on their core task
Automatic validation of code
- Code scans, QA, linting, the whole nine yards
Automatic deployment to various environments
- If you need to manually login, you're doing it wrong
Feature flags for manual enabling of features
- This is your actual go-live, not the deployment to production

In case this isn't clear yet, DevOps is the fundamental backbone of everything the teams does, not just ops. The more you can automate the better... There's a reason we're moving to Platform engineering.

Design

Less is more, KISS... we as users already got too much shit being thrown at us, we don't need more. So keep the UX as simple as possible, distill till you nailed it.

Also from a technical/architectural perspective try to keep it as simple as possible. Design it so it's easy to implement and have as few dependencies as possible. This does however imply an architecture that facilitates compartmentalization so features don't bleed over into one another.

There's a lot more to be said about design but that's defo a topic for another day!

Coding & Validation

These 2 things have become so intertwined (at least in my twisted mind) that I think we shouldn't be considering them as separate disciplines. When you've built a brick wall, you don't just walk away... you check whether it's according to spec. Do the same with the code.

I'm still not sure what the best approach is when it comes to validation but a substantial part involves the dev... or inversely the QA engineer is also to a large extent a dev. That person may not per se write the unit tests but it makes sense to have tests written in the same way so they can be created, used and improved together. Keep in mind that tests are a ridiculously valuable part of development, it can make your life so much easier!

But don't make the mistake of assuming Dev & QA are the same person! They have a distinctly different focus and you don't want to have devs grade their own homework.

So how do we KISS?

You will need to do all this, however begin as simple as possible and build from there:

Define & implement a base architecture
- Spend time on this please and ask for help
Define how you analyse & design feature with the team
- Tickets, whiteboards, design tools, tech specs, whatever floats your boat as long as it's clear to the whole team
Define your reporting requirements and implement basics
Setup basic automations for coding & validation
- Simple things like checking in your .vscode directory is already super useful
Setup basic automatic infrastructure provisioning & deployment scripts

Stick to the basics, don't make it too big... just make sure you at least start.

Rinse and repeat

Use frequent retrospectives to adjust course and do bigger sessions every couple months to look at the fundamentals.

Continuously evaluate how well you're doing
Find standardisation opportunities in everything you do (design, coding, QA, DevOps, architecture, everything!)
Automate the fuck out of your SDLC

Nasty ass code

Matthijs — Sun, 24 Mar 2024 10:53:21 +0000

So I was trying to come up with a way to speed up the initial start time of Pipeliner... and I did it! But it is one of the most nasty ass pieces of code I've written in a long time... and here is why :)

Background

But first a little bit of background. The project is intended to simplify things (like all code we write I guess :)) and as per my previous post I like to KISS. So instead of having to deal with dependencies I wanted Pipeliner to auto include the relevant files.

The initial setup was a bit of a blunt instrument, but it worked. It would simply include all .sh files using the source command and all functions were available. Naturally the code base grew and this method would also take longer and longer. To the point where it took 1 whole damn second to start a script! ARE YOU KIDDING ME?! 1 WHOLE SECOND? UNFUCKINGACCEPTABLE!!!

So I had to come up with something new... which I did... and it's nasty... very nasty!

The "code"

#!/bin/bash

Files_Pre_Import_Classes() {
  files=$(Files_Get_Class_Files)
  for file in $files; do
    functions=$(grep "^ *[A-Za-z0-9_]\+ *( *) *{*" $file | sed -E "s/ *\( *\) *\{.*//")
    for function in $functions; do
      if type -t $function > /dev/null 2>&1; then #function/command already defined
        continue
      fi

      eval "$function() { source $file; $function \"\$@\"; }"
    done
  done
}

Line 1: #!/bin/bash

Well it doesn't get any nastier than this now does it? Bash (or at least sh) is one of the oldest, if not the oldest, scripting languages around. If there were ever a red flag to stop doing what you're doing then this is absolutely it. This shit was conceived in the late 70s... hardly anyone reading this was bourne back then!

Although interestingly shell scripting is still around and is probably growing in popularity because of all the DevOps/Platform/provisioning shit we're doing. So how bad could it be... insert dumpster fire meme here

Line 6: grep... AND sed

I love regex... if there was ever one brilliant way to simplify and at the same time ridiculously overcomplicate your code: REGEX FTFW! It is so elegant yet so terrifying... that I try to infect as many people as possible with them. Honestly they're soo much fun!

But here's the most troublesome part about them... the dialects. Most typically use PCRE, but not grep... or sed. Well at least not by default and even if you could convince them... don't expect it to work on MacOS and Ubuntu. So yeah lets stick with it being all over the place.

Line 7: for function in

Yeah lets loop through a list of functions... if you see this kinda code, run the hell away! There are very few usecases to deal with classes, functions and/or variables in a dynamic way. And you know what's coming next...

Line 12: evil

Often misspelled as eval, the evil command is the Devil... on a bad day... when just kicked in the nuts. Any time you think you need evil, throw yourself off the highest building in the vicinity... it'll likely end better than continuing whatever ridiculous thing you were doing.

Why is evil such a bad idea you ask? It allows you to do things the language isn't designed to do... so don't fucking do it! Honestly don't use it! I can't repeat it enough, you shouldn't need it... And if you do, you're probably trying to do something you shouldn't be doing it the first place.

The big problem with it is that it has an enormous potential for unintended side effects... and nasty ass security holes! When you use evil you want to do something dynamic, so you'll have at least 1 variable in there... you must ensure the values are "sane", i.e. do NOT trust user input.

Imagine my regex's above are a bit brittle (which is quite likely since grep+sed suck balls), what if I defined a function like:

NastyAssFunction() { { echo } ; sudo rm -Rf / ;

The only thing that prevents this from wiping your harddrive is the .* at the end of the sed statement. And yes, this is an invitation to come up with a way to break this code because I'm not 100% convinced the code is solid.

So what does it do?

Honestly this is the best part :) For each function definition it finds (in any .sh file) it dynamically predefines a function that:

imports the relevant .sh file
- which in turn will overwrite all predefined functions with their real definition
call the same function again with the same arguments so it executes using the real function definition
any subsequent calls to the function will use the real definition going forward

There is so much potential for failure, it's insane. For starters a function calling itself is likely to cause havoc just for the sake of it being recursive. And yes the first version did in fact royally fuck things up and ended up in an endless loop :) TBH I'm actually surprised it even works, depending on how the language implements imports & recursion it's likely that something like node would just keep calling the predefined one... assuming it's even possible.

Conclusion

In order to make things simple we often need to resort to complicated mechanisms. Although this particular implementation can potentially be made less terrible, the problem it's trying to solve is a difficult one. And you could argue that a dev should just handle it, but why? Why should we be bothered with mundane repetitive tasks like dependency management? We can automate this shit... or at least we should be able to...

The big question is: should we be sticking nasty ass code in our code base? I can guarantee that someone (likely me) is gonna run into issues with this. So is it worth the hassle or should we KISS? Or why doesn't whatever language simply handle this for us? If I use some namespace can't it just figure out where it comes from and auto include the relevant dependencies at compile time?

And for the record: I'm still considering whether to leave the code in or not...

Why is coding so ridiculously overcomplicated?

Matthijs — Mon, 11 Mar 2024 10:14:44 +0000

Don't get me wrong, it's not difficult... it's just way more fucking complex than it should be.

I'm coding some framework atm and decided to do it the right way... you know picking a language (and version...), choosing the right paradigm, doing TDD, creating CI/CD pipelines that trigger automatically when you raise a PR but can also be ran locally (oh and of course setting up github/azdo/bitbucket/whatever), choosing a license and prolly a whole lot more that I don't even realise. The only thing I didn't bother with (yet...) is code coverage. And all that before writing a single line of code.

And then totally unrelated I wrote the following script:

$ vim ~/bin/aur

#!/bin/bash

git pull

makepkg -i

And kept thinking how elegant and readable this is... and how I could royally fuck it up if I would do the right way.

Disclaimer

Just to be clear, this post has no point whatsoever. It merely raises a whole bunch of questions and maybe some solutions... or rather asks the reader (yeah that's you) to come up with solutions and hopefully share them.

Why do we do all this?

Honestly software engineering (aka coding) is an complete intertwined shit-show, which is so easy to dive into (Hello, World!) that everybody think they can do it... and consequently think they know better. So much so that people that never wrote a line of code are telling devs how to do their job. Which is probably the first hint at why we setup such an elaborate maze of tools, practices and processes...

Accountability

If something breaks, it's the dev's fault... not the PO for writing up a half-arsed feature or QA for not testing that 1 in a million scenario that he/she didn't have time for... or the CEO that doesn't want to spend more on their bread and butter.

Yeah that's right, software is your USP these days! The only way your gonna have an edge over your competition (in most businesses anyway) is to have the right tools and if those tools don't exist, you'll need to create them. You can have the best product/service in the world but if you don't have the software to back it up, your competitors will overtake you in an instance. That said, wouldn't it be nice if we could do it cheaper? Or at least smarter, cuz otherwise so could the competition...

Anyway, we're all accountable for the software we create, but we also need to be able to be accountable for it. So how can we be accountable for something ever-evolving and so complex that we can't even begin to understand what can possibly go wrong?

Over the years we came up with a whole bunch of things (ASD, CI/CD, DDD, FP, XP and the list goes on and on) in an attempt to solve the problems we faced. But what actually are those problems? And why do these solutions also create an equal amount of new problems? And why is there so much crap that I need to understand to write 1 line of code?

Fluidity

Probably the biggest problem that people generally tend to miss is the fluidity of software. When you build a (physical) house, it's pretty much fixed once it's done. You wouldn't decide the next day to add a swimming pool to the top-floor... and if you did, there would be at least 20 people telling you that, although awesome... it's a stupid fucking idea. In software however, the consequence of putting in a swimming pool isn't that it's gonna collapse and kill everyone in the building. It will weaken the foundation a bit but hey what's another bit of technical debt?

A fundamental part of this however is the ever-evolving nature of software. It's never finished and it never goes in the bin. Once a line of code is committed, it will likely stay there for the coming 10 years. And the problem with that is you didn't consider how that big-ass pool is gonna affect it, as no-one told you about the pool... or even considered it. As a matter of fact that 1 line of code may inspire someone to suggest that, if we can do this... we can also build a pool, right? What we create is often the inspiration for the next thing, potentially taking it in a completely new direction. But is the foundation strong enough for this?

And there is also the matter of all the legacy crap we keep carrying around. How do we ensure that that keeps working as expected? Cuz even though we wanna bolt new shiny things on top of it we can't loose those old (formerly shiny) things. Back in the day coding was a lot more like building a house, we'd do it once and a year later we'd build an improved version of it, having ample time to validate the old crap... not anymore.

Resilience

Although related to the fluidity in an architectural sense (how well does it cater for change?), resilience in software also relates to how well it runs. We expect software to always work but develop it in the narrowest possible conditions... "it works on my machine". And that's partly why a dev will always say it should work. It's so complex that dropping the exact same code on another machine typically will fail spectacularly!

So how is it that we created something so complex that we can't even predict whether it will work, let alone how well. Which is pretty impressive as everything we do is at the end of the day a very binary choice. But why than can't we deliver on the expectation that it always works, regardless of the conditions?

We need ensure all prerequisites are exactly met and otherwise it simply won't work. Tools like Docker will help us with that but there's still an endless amount of variables that we don't control... or even consider. Chaos engineering is one approach of making things more resilient but that's a requires a pretty hefty investment. Also it assume your software works, but what does that really mean? That it runs on your machine / prod cluster given the exact right circumstances? What if I want to run it on a new test cluster? How much shit would I need to setup before I even can start throwing a simian army at it?

Scale

If you write a quick little bash script like the AUR building example in the intro you can afford to ditch all the best practices. Or at least it's relatively safe to assume it's not gonna get extended or used anywhere else or by anyone else. But the bigger the stakes the more important such factors start to become. Lets say you want to provide a AUR building SAAS platform, that piece of code at the top is probably gonna be in there somewhere... but you might also wanna consider a microservices architecture... among 20000 other things.

It so depends on what you're end goal is on how "well" your code should be written. And the terrible truth is that half of the time we're figuring out the end goal along the way. So how can we make a proper judgement of how solid our code needs to be? Especially with a PO breathing down your neck who wants to get the feature out asap... and then bitches 2 weeks later that the next feature is taking too long cuz you need to clean up the mess of the first feature. So how can we write good enough code that don't have to rewrite/bin 2 weeks later? Or should we be writing throw-away code? And if so is there an architecture that actually facilitates this? And would the business even accept that? It is at the end of the day our IP, right?

Security

Another important (and royally underestimated) reason why such an overcomplicated mess of crap is needed, is security. We put locks on our doors to prevent unauthenticated and/or unauthorised people from coming in and additionally we also create secure briefcases to carry important information from A to B... and figure out how to deal with lock pickers and continuously monitor if our building is still up-to-date with (literally) today's standards. Or at least we should.

So how do you write secure code? How do you ensure your dependencies are secure (remember log4j?)? The long and short of it is: you can't... at best you can write software that takes more effort to break than the value gained if someone would break in. In other words the bigger the pot of gold your software is protecting the better security you need.

But half of the time people don't even know that the code they're writing is full of holes. And you can't really blame them as it's such a vast and complicated topic that fully understanding, in addition to all the other crap you need to know, is nearly impossible. So how do we create secure code then? Without having know every last little best practice or implement code scanners (and understanding and dealing with the results)... Or should we just deal with it in relation to the scale? i.e. initially the pot of gold is pretty small so who cares? But it would be so nice if it could be secure by default... like resilient by default...

Conclusion

So lets wrap this up for now. Normally you'd put some nice lessons learned here but there are none... other than coding being overly complex... but we kinda knew that when we started.

Here are a bunch of questions that I think we should consider... and that I might consider in future writings:

How can we be fully accountable for what we build?
- In other words how do we create control over what we build?
How do we deal with the ever-evolving nature of software?
- How do we stay in control over what we've built and what is still to come?
Do we just start building and scale when needed?
- Or can we easily build for scale?
How can we build secure enough software?
- Or can we make it 100% secure by default?
Should we be proud of the vast amount of crap we created in the last 70+ years?
- And how do we condense all this in 1 person's mind and expect them to create wonders?

Lastly, what if we had a greenfield? How would we deal with these problems? Could we do something radically different?