petermakowski.io

Balancing innovation in software engineering teams

2022-07-24T22:00:00Z

Software engineering as a field of constant change

Software engineering is a relatively new discipline and for that reason alone we should question its fundamental axioms on a regular basis. We do not seem to be in a place where we have good, fairly future-proof answers for most problems like older disciplines do. Practices such as extreme programming or micro-services created massive disruptions in the field not so long ago and things do not seem to have slowed down, with the advancements in machine learning creating another major shift being just one example.

As software engineers, we need to periodically review and question assumptions left over by previous eras. On a more practical level, this means maintaining a healthy discipline in encouraging experimentation and change. There's nothing quite like the fresh eyes of a newcomer in the moment of seeing a project for the first time. That's why rotating developers between projects can be a very valuable strategy for keeping things in check.

The inherent value of experimentation

We should also recognise the value of experimentation in and of itself. All mammals have the play circuit in their nervous system which is often the birthplace of new behaviours, biologically speaking. In humans, the playful pursuit of curiosity allows the discovery of ideas and solutions that could not be found otherwise. In software engineering teams this can take the form of regular hackathons on side-projects - but even better if it's allowed within the main product to a certain degree as it's sometimes difficult to translate knowledge from hackathons to real projects.

Experimentation is particularly important in the current era of obsession with productivity. The narrow field of view that's a result of such a mindset certainly has its place at work but can lead to pathology if not kept in check and combined with a broad field of view that's associated with play.

To allow and encourage play in your team you need to ensure their psychological safety. Nobody will want to play if they're worried about a predator that might be lurking around. That's why it's important to keep a healthy attitude towards mistakes made by the team. With true innovation, mistakes will happen.

The risks of stifling innovation

We need to recognise experimentation as something that has value in and of itself and a requirement and a sign of healthy software teams.

Doing things as they used to be done is easy. It's low-risk. If a project fails, it's less likely it will be blamed on the old way of doing things. They did work for so long, and it's not likely attention would be drawn to them as a cause of failure. Often something else gets the blame, like the lack of time ("we did it this way because we didn't have time for major changes") or the need for consistency.

Teams are often afraid of bringing too much chaos into the system as it makes things less predictable. That's the inherent nature of change. Things destabilise for a while until a new state of equilibrium is reached. This is required for growth.

The exact amount of change versus stability can be a subject of debate but it's safe to assume software engineering will require more innovation than other, more established fields as it still lives on the edge. Not allowing for a degree of innovation can not only lead to boredom and or/burnout of certain team members but ultimately failure of the product.

It's a balancing act

Innovation is great, but you can have too much of the good thing, and both the lack of innovation and the lack of rules can be a sign of dysfunction. Too much innovation can cause a lot of stress, especially for team members that are more resistant to change. It should be approached with caution and be kept under constant review to make sure the right balance has been reached.

Balancing innovation brought on by new ideas and the stability of established ways of doing things is a complicated dance. And although it's hard to say what's the right balance between the two and will most likely depend on the circumstances, one thing is for certain - you need them both.

Enzyme encourages bad testing practices

2022-06-13T00:00:00Z

Enzyme encourages testing implementation details. This is bad practice and such tests can do more harm than good.

Typical enzyme test

it("displays a spinner on load", () => {
   const wrapper = mount(<EditComponent />);
   expect(wrapper.find("[data-testid='loading-details']").exists()
   ).toBe(true);
});

False positives

Tests that do not fail when you break the functionality are said to return a false positive. Arguably, the test above can never return a "true positive" as it's not even testing anything that's relevant for the end user. Even if the loading-details test id was added to the DOM, we'll never know for sure the expected loading indicator (like a spinner icon with a "loading" text) is returned by this component.

Even worse, it's possible that even the data-testid="loading-details" itself never appears in the DOM and this test still passes. This could happen if the underlying component doesn’t render the data-testid prop. Enzyme lets this test pass because it’s testing component instances instead of the output of these components - the DOM nodes.

False negatives

Refactoring should be encouraged and easy, with tests serving as an extra layer of confidence giving you immediate feedback if the application's functionality remained unchanged. This test can also break after doing some refactoring - giving you a false negative. All this test cares about is the test id which mean this test could fail even if the component still returns a loading spinner with a correct text (what's visible to the user).

Such tests do more harm than good

What's the point of writing tests in a way that doesn't give you confidence the application still works as expected?

All you're doing is giving yourself a false sense of security and creating more work whenever you need to make a change.

Just hit publish

2022-06-09T22:00:00Z

Some time ago I've set myself a goal of publishing 2 blog posts a month. I was hoping that writing more often would help me become more comfortable sharing my opinions publicly and allow to flesh out my ideas.

I failed at reaching that goal. I haven't published anything in months, in fact.

That's why I decided to hit publish on something raw and unfinished. That's the most I can do today. And that's okay. For someone that constantly questions the point and validity of every attempt to say anything publicly it could be considered an achievement in an of itself.

And that's why I feel proud I've hit publish today.

Quick introduction to Testing Library queries

2022-02-27T00:00:00Z

Testing Library queries can be a little confusing at first. This guide should help you get started writing tests without having to know all intricacies of different queries.

Which query should I use?

It's best to query elements by their semantic role and name^[1]. Query by text only if the element you're looking for has no semantic role.

<button>Save</button>

❌ getByText("Save")

✅ getByRole("button", { name: "Save" })

Looking for a single element?

use getByRole

Looking for multiple elements?

use getAllByRole

Testing that something doesn’t exist?

use queryByRole

Testing Library queries in more depth

If you're interested in knowing more about the queries it's useful to know how their names are constructed.

You can divide all queries into 2 main categories:

get - throw an error when no match is found
query - don't throw an error when no match is found (useful when you expect something not to be on the screen)

The categories above can be divided further into 2 subcategories:

Single element queries

getBy, queryBy, findBy
throw an error when more than 1 match is found

Multiple elements queries

getAllBy, queryAllBy, findAllBy
do not throw an error when more than 1 match is found

Finally, the above can be combined with
role, text, labelText, placeholderText to construct an actual query.

Testing user interactions

It's best to use @testing-library/user-event, a companion library that provides advanced simulation of browser interactions.

The 3 user-event methods below are really all you need
(most of the time):

click
type
selectOptions

By default, many semantic elements in HTML have a role; for example, <input type="radio"> has the "radio" role. You can check an element's role by opening developer tools and accessibility properties. More on this in Using ARIA: Roles | MDN ↩︎

Blog post ideas

2022-02-02T00:00:00Z

This is going to be a dynamic post, more of a note to self really, which I will keep updating.

User-centric testing with Testing Library
New year new blog system - how and why I replaced gatsby with 11ty
How I made MAAS UI navigation more accessible
Code review best practices
How to test websites accessibility with a screen reader (VoiceOver)
How to improve accessibility score of your website in 5 minutes
Building X with Web Audio API

Personal development

How to deal with the imposter syndrome
How to improve your motivation - on negative and positive motivation, nature of satisfaction
How my dog made me a better developer
On the importance of downtime
Learning to let go (when to say it's okay to abandon a project/goal)

On the edge of psychology/philosophy

Philosophy/ethics for developers
Summary of my presentation on personality

Random thoughts

How to pick your dog's name

Idea stolen from Robin's blog. Thanks Robin!

How I built a musical instrument controlled via hand-tracking running in a browser in 24 hours

2020-06-15T00:00:00Z

Do you know that feeling of overwhelm just before starting a challenging project followed by urge to procastrinate? I do, too. That's a place I found myself in when I nearly gave up the day before TotallyMoney Big Hack.

I've never participated in a Hackaton before. Wasn't sure what to expect. I don't need to give myself even more work, I need a break from coding, I thought. I thought it's going to be lots of effort with little reward. How much, in fact, can you do in 24 hours? Not enough for it to be worthwile, I thought. I couldn't have been more wrong.

Let me start from the beginning. Given my musical background and that I work as a Front End Engineer I decided to build something with Web Audio API. Building a synthesiser from scratch seemed exciting. Initially it was meant to be a one-man job, but soon after I announced my idea, 2 colleagues joined in. Idea evolved to building a synthesiser with a step sequencer.

We started by discussing what approach we want to take, decided to use a combination of TypeScript and JavaScript and a simple 2-dimensional array to hold the state of the step sequencer.

A piece advice for anyone participating in a hackathon: TS can initially slow you down, not a good thing for a project to be built within 24 hours.

I'm at my best when I work alone, but this was a good reminder of how energising, and stimulating working closely together on an exciting project with other devs can be. One of my front-end colleagues at work shared a video inspired by Theremin (musical instrument played without without physical contact) saying that these are his expectations for this project. I'm sure this was partly a joke, but I thought of it as a challenge.

That made me think, surely, in the age of machine learning, it can't be that difficult to track user's hand with a webcam and then translate that position to some sort of an input for the synthesiser?

Well, it appeared that there already was a library for prototyping real-time hand detection in the browser (handtrack.js) making this task pretty straight-forward. Having already built core audio functionality for the step sequencer it was easy to plug it into it, and there you go, you've not only got a step sequencer, but also a theremin that you can play right in your browser!

You can try it here: TotallySynth.
TotallySynth on Github.

Just be careful with volume when using headphones! Also it's pretty buggy - it was built in a day, after all!

Hack Day happened to be one of the most exciting moments of my career as an Engineer recently. It reignited my passion for coding and reminded me of the value of human connection at work. If you're wondering if you should participate in one, just do it. Maybe it won't change your life, but might give you the reason to finally write that first blog post that you've been wanting to write for months.

petermakowski.io

Balancing innovation in software engineering teams

Software engineering as a field of constant change #

The inherent value of experimentation #

The risks of stifling innovation #

It's a balancing act #

Enzyme encourages bad testing practices

Typical enzyme test #

False positives #

False negatives #

Such tests do more harm than good #

Just hit publish

Quick introduction to Testing Library queries

Which query should I use? #

Looking for a single element? #

Looking for multiple elements? #

Testing that something doesn’t exist? #

Testing Library queries in more depth #

Single element queries #

Multiple elements queries #

Testing user interactions #