In the fast-paced world of software development, why reinvent the wheel when you can just copy-paste someone else’s? We live in a copy-paste culture, where solving problems often means borrowing what already works.

And that’s exactly what npm packages and tech conference talks have in common. Both are shortcuts. Both exist so you don’t have to reinvent the wheel. Let’s explore how these two seemingly different worlds share the same philosophy of borrowed brilliance.

We all know the CSS blinds meme, right? Or the CSS is Awesome text that exceeds the box? These seem to appeal to many developers these days, perhaps even more than in the past. We've started leveraging JavaScript or TypeScript-oriented frameworks and features, while relying on Tailwind to help us style our interfaces.

We've drifted away from one of the main pillars of the web: CSS is not a main focus anymore but an afterthought—something to slap onto a bit of interactive code. Leaning on these frameworks can lead to lower maintenance and more up-to-date knowledge of CSS.

In the wild world of software development, just like in thermodynamics, entropy is always lurking. Understanding these scientific principles can give us some insights into taming and improving our codebases.

Let’s throw on our lab coats and dive into how the laws of thermodynamics can jazz up our approach to software development! 🧪

Vue adopted a Single File Component philosophy, which has some benefits over splitting concerns, which you can read up on in the official Vue Docs. From a SFC philosophy, you’d want everything that relates to your component in a Single File. So let’s explore this take with our component tests as well, because why would your tests be any different than your scripts, template or styles?

We’re going to leverage a feature that Vitest offers, out of the box, to a Vue example code base. Bear in mind that this approach would be applicable to other implementations that leverage Vitest just as easy. Also, this is a thought experiment.

Software development is a craft and we can follow many routes to achieving a specific goal. Having this freedom allows us to create simple solutions for very complex problems. That same freedom has a flip side, where very complex solutions can be applied to very simple problems!

To be clear: I don't think anybody purposefully sets out to create complex solutions to simple problems (unless part of an artistic discovery). I think it is a sign of lack of understanding of a certain domain or technology. I also think there are several strategies you can apply to reduce complexity!

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.

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.

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.

As a mentor via CodingCoach.io I'm currently working my way through the 21 Days of Code coding challenge by Lighthouse Labs with my mentees. I thought to share our findings and resolutions here, as well as offer some perspective on these events.

Firstly, I kind of like this iteration (we've previously did a similar coding challenge side by side). We're following a storyline involving the Mayor of Codeville and face different kinds of challenges. It's nice to have some context and not simply solving problems. I think this is a really engaging way of keeping interest and motivation.