Before we dive into the topic, a little bit of context would be necessary because we're going to talk about a solution that works for our organisation. Having context helps you in deciding if and what would work in your situation.

So at the company I currently work for, we cater to a big audience. As a big company, we also have a big stake in IT solutions to get our businesses running. A lot of our software and tooling is build in house.

Nobody that I know of is happy with endless repetition. Software has drastically improved any field of work where repetition takes place by facilitating a certain level of automation to ease all of our jobs. But when you’re implementing any automated process, there’s always a cost to consider.

The good news when working on software, is that cost is relatively low compared to effort. Since we’re working in a landscape that’s so very tightly coupled to the tools that provide automation, most of the automating is a breeze!

Everybody involved in software engineering knows that accessibility (or A11y) matters. And while we all agree that it's a good thing, we don't always prioritise it. I think we're long overdue in doing a better job. Or even better, consider it an intrinsic part of our basics.

A11y means the way that your product is, quite literally, accessible by any user. We can capture a11y in numbers, that beautifully translate into contrast ratios, tab orders, the amount of ARIA labels and whatnot. The most important thing to realise though is, that you should be aware that other users have other needs and maybe limitations that you should take into account.

Why do you test? Is is because you want to prevent errors on a deployment affecting the visitor? Is it because you simply want to know that the software does what it needs to do? Or maybe you want to get to know the software a bit better?

Hopefully, in this day and age, your main software tests are automated. Running before a commit, running in the deployment pipeline and running on a testing environment. Repetitive jobs need automation and testing fits that mantra very well. This article is relevant for automated testing, although for certain topics you could use a manual testing perspective as well. If you like.

So. You’re a small, medium sized or even large scale company. IT is an integral part of your business, whether it is a small scale application or an enterprise grade platform. Let me repeat that for you: IT is an integral part of business. You know this, because you’ve been doing IT for a long time, right? But. Are you doing it right?

Yes, you tick the SEO boxes and yes, off course you’re in the cloud (whatever the heck that is). You have backups 🤞. Nice! You even have a couple of scrum teams working together on your product. Extra nice!

I am working for Jumbo Supermarkten, which is a large grocery chain in the Netherlands. This family owned business started to venture into e-commerce at about 10 years ago with a very small team of developers. Currently, we've grown into an IT department that consists of over 450 developers working on all digital solutions. We've made some changes over time on how we manage our software. I gave a talk together with my colleague on this topic, so let's share the write up here.

So, if we rewind the clock the the founding of the Jumbo Tech Campus (JTC), where in the beginning the main purpose was to get started with e-commerce. What happened was that the team at the time did the thing that is most obvious with limited resources and a generic goal: they grabbed an off the shelf solution and started to implement it. This meant connecting to the existing brick and mortar stores, the delivery and storage APIs and whatnot.

Last week I had the opportunity to speak at VueJS Amsterdam ❤️ together with a colleague of mine. It was my first time doing a talk at such a big event and thought to share my journey, and give you considerations for when you will be giving a first talk!

Small disclaimer: I am by no means an expert in speaking, but that’s exactly why I think this post gives you insights for starting out. Also, the talk we gave was about a certain technology, but I think this article is generic enough to apply for any topic.

In software engineering, we can apply a lot of the psychology findings to their digital counter part. If we consider the broken window theory, it doesn't apply to the operating system, but to the state of code.

Let's go back to the source. From an article originating from 1982 ("Broken Windows") in The Atlantic by James Wilson and George Kelling.