I'm a huge fan of <a href="https://www.cypress.io">Cypress</a>, it's become a core part of my stack over the last few years. If you're not familiar with Cypress, it's an end-to-end testing solution which allows you to write descriptive and behavioural integration tests against your application.
Part of it's appeal is it's &quot;pluggable&quot; architecture, allowing developers to extend Cypress. A leader in the accessibility tooling arena is <a href="https://www.deque.com/axe/">Axe</a>, and what really helps with this use case is the Cypress plugin <a href="https://www.npmjs.com/package/cypress-axe">cypress-axe</a>.
After integrating Cypress and <code>cypress-axe</code> into your project (I won't cover this here as the <a href="https://www.npmjs.com/package/cypress-axe#installation">docs</a> are complete enough), you get access to a special method on the main Cypress object: <code>cy.checkA11y()</code>. Calling this in your Cypress test means the test case will fail if it encounters a <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">WCAG</a> accessibility violation.
Combined with Cypress' default functionality of being able to use your application like a real person, you can supercharge your CI/CD pipeline to catch things like accessiblity errors earlier in the development lifecycle.
I use <a href="https://vercel.com">Vercel</a> to host and deploy most of my websites for a myriad of reasons, but for this exercise we're really interested in the <a href="https://vercel.com/docs/concepts/deployments/environments#preview">preview environments</a> feature, allowing us to deploy potential changes to a safe testing area before merging these into the main codebase and deploying to production.
Using GitHub actions as a CI/CD platform, you get the standard benefits of being able to run your actions against an isolated pull request, and with a bit of <a href="https://github.com/mikefrancis/nosh/blob/main/.github/workflows/regression.yml#L26-L32">fiddling</a> I've managed to introduce a <code>regression</code> step which will (crucially) wait for the Vercel &quot;preview&quot; deployment, then point my Cypress tests at this URL for testing. I've since turned this into a <a href="https://github.com/mikefrancis/vercel-cypress">GitHub action</a> which you may use.
I can then see if anything in the current pull request has broken anything crucial: functionally or accessibly (or both!). With this kind of confidence in my CI/CD pipeline, I could set up something like <a href="https://kodiakhq.com">Kodiak</a> to automatically merge things like security updates. I really like this quote from <a href="https://twitter.com/kentcdodds/status/977018512689455106">Kent C. Dodds</a> about testing, and try to use this as a guiding principle for testing as a whole:
<blockquote>
The more your tests resemble the way your software is used, the more confidence they can give you.
</blockquote>
As someone who has trouble with visual technology (I'm colourblind), I try to bake in an accessible approach to product development by default. It can often be an afterthought, which can jar with things that have already been designed or developed. Involve accessbility as early as you can (and at every stage) of your product design/development process 🙂

Accessibility

Automated accessibility testing

Since January 2021 I've moved from being an Individual Contributor (IC) to an Engineering Manager (EM). As a Technical Lead I'd had a lot of exposure to EM concepts so it's been a fairly gradual transition but I feel like after 6 months in the role, it's time to do a bit of introspection about what the role means to me.
<h2>Priorities x3</h2>
When starting out, your manager may define your priorities like this (in order):
<ol>
<li>People</li>
<li>Team</li>
<li>Company</li>
</ol>
For transparency I've seen this list in different orders in other blog posts and it's probably different at other companies and levels of seniority but, for me, this is what works and helps me prioritise my day. I like how it goes from most to least atomic.
If I'm struggling to prioritise things in a busy period or after some time off, I can ground myself by reminding myself of the order I should approach things.
<h3>People</h3>
My primary job is the support and growth of people. I took this job because I'm a people enthusiast - I love working with people, especially supporting them and finding them opportunities to grow. The tools and heuristics I need to do this are (and not limited to):
<ul>
<li>Regular 1:1s, giving regular feedback</li>
<li>Performance reviews, setting short/long term goals</li>
<li>Mentoring/coaching/sponsoring opportunities</li>
<li>Training courses &amp; materials</li>
<li>Hiring activities</li>
<li>Onboarding materials</li>
</ul>
If I get any free time, you can bet I'm looking through my 1:1 notes and cross-referencing with the above; questioning to see if there's anything I'm not already doing for the people in my team.
<h3>Team</h3>
Once I'm confident the people are as happy as they can be and their careers are being developed with realistic goals to strive towards, I can turn my attention to the team.
Teams are all very different - different sizes and compositions with different purposes and tenures - so this is where it gets a bit subjective. The main question I ask here is are we on track to achieve our goals as a team? Or at least moving the needle in the right direction and having a positive effect. Personal goals are often much more abstract and different to team goals; a personal goal might be &quot;Contribute 1 module to our Terraform repo&quot; whereas a team goal might be &quot;Quantify all our team's infrastructure as code&quot;.
This is where things like creating automated reporting can be a great investment of your free time, so it's easy to see where we have cause to celebrate being on track, or might be off track and can course correct. Having a good grasp of SQL from your IC days can help with querying things in a database/warehouse.
Cultivating the relationship between yourself and the Product Manager/Owner (PM) is a key part of looking after the team. If the last 20 years of Dilbert cartoons is anything to go by, Software Engineers can classically view this person as someone adding unnecessary scope and complexity, not wanting to focus on things like Technical Debt or Security; communicating these as focus areas is your job, just like the PM is looking for any Product opportunities and doing their job - Lara Hogan's <a href="https://larahogan.me/blog/team-leader-venn-diagram">Team Leader Venn Diagram</a> is a tool I go back to time and time again to ensure we're not stepping on each other's toes. Constructive disagreements are fine, maybe even healthy, in this relationship but any unwanted friction here is probably a signal there's a breakdown in communication.
<h3>Company</h3>
As a more junior EM this is where I spend the least amount of time. There's plenty to work on in this area, like creating/updating progression frameworks, working on hiring initiatives etc.
My main focus will be continuing to build up the foundational skills above (People &amp; Team), and with experience I'll get more and more chances to tackle something at this level - hopefully pairing with more experienced EM(s).
Yup, pairing still happens at this level - yay!
<h2>People are very different</h2>
Kind of goes without saying really but in all my preparation for moving into this role (the carefully crafted 1:1 documents, setting up meetings, reading many books) nothing can really prepare you for the budding emotional investment you will need make in your reports.
Some reports will need very little of your time. Check-ins and 1:1s are usually a nice exchange of pleasantries, a check if there's anything on our shared agenda and if not how they are performing against their short and long term goals, and anything else I can help with.
Other reports will require more of your time, they will (rightly) question any and all decisions which they feel do not hold up to their high standards. They will ask you to co-create detailed plans about how to get to the next level. You may need to help them micromanage their own workloads through tough periods when things go off track. They will have other things happening in their lives which (it's easy to forget sometimes) is not work, and may need a hand navigating it.
As a manager it makes it very unlikely that 2 days will ever be the same, which is diverse and stimulating, but also means you need a few hats to wear and to make sure you've got the right one to hand.
<h2>Be organised</h2>
One thing I've found as I've taken on more direct reports and got involved in projects at the company level, or during busy periods such as performance review season, is it doesn't take a lot and suddenly you can feel overwhelmed with things to do, and this is surplus to the most important parts of your job - taking care of the people on your team.
It's therefore crucial to be hyper-organised and get into a regular rhythm of when you do things - check your email, check Slack/Teams/whatever, even going for lunch, as things can easily slip the net.
There's a great section about this in <a href="https://www.amazon.co.uk/Become-Effective-Software-Engineering-Manager/dp/1680507249">Become an Effective Software Engineering Manager</a> by James Stanier that does a great job of explaning the tools and approach needed, but it essentially boils down to:
<ul>
<li>A well structured calendar</li>
<li>An all encompassing to-do list</li>
<li>A lot of self-discipline</li>
</ul>
With these basic tools you can abstract away your self management, freeing you up to make the most of any free time.
<h2>Having free time is fine</h2>
Once I'd finished onboarding into my role and navigated my first performance review process, I found myself with huge gaps of free time in my calendar. As an IC, I would welcome this precious time to contribute to the delivery of a project, or start planning ahead. However as a manager this time made me quite anxious - what was I supposed to do in this time? Once I'd actioned all my actions, checked in with everyone and made sure there were no issues, being completely honest, I had no idea what to do.
Fortunately, my manager had some great news for me. This is completely normal and this free time is your fallow time. It's time to maybe go for a walk or pour a coffee and think about:
<ul>
<li>Are your reports truly ok? Is there some reading between the lines to be done?</li>
<li>What do your reports need next to grow? What's on the horizon?</li>
<li>What does the future of your team look like? Can you prepare for any of this now in a favourable way?</li>
<li>What does your own future look like? Are you happy? Where do you need support?</li>
<li>And many, many other reflections that may pop into your head!</li>
</ul>
Let these thoughts form and come back to work armed with enhanced purpose.
<h2>Free time is precious</h2>
This is true for both you and your reports. As an IC I would encourage people to respect the <a href="http://www.paulgraham.com/makersschedule.html">Maker's Schedule, Manager's Schedule</a>; I try to do the same as a manager. As a manager it's rare that I need focus time (it's mainly seasonal, for writing performance reviews or planning workshops etc.) so I try to bend my schedule (such as regular 1:1s) around the best time for my reports.
However once you've completed all your regular tasks, don't forget to carve out some fallow time for yourself, to keep stimulated and ready for the next iteration.

yeshi-kangrang-iuqxv7kFj64-unsplash

6 months of being an Engineering Manager

While perusing Twitter I stumbled across the following video by Lee Robinson:
<a href="https://www.youtube.com/watch?v=R59e1Vl5lO8">10 Next.js Tips You Might Not Know!</a>
If you use Next.js or are just generally interested in it then I highly recommend giving it a watch, there's some great tips which as someone who has been using Next.js for a few years I personally was not aware of.
One of the things Lee covers in his video is replacing <a href="https://reactjs.org">React</a> with <a href="https://preactjs.com">Preact</a> at build time.
<h2>Why would you do this?</h2>
Preact is a a much smaller alternative to React with virtually the same API. The main differences are that Preact does not come with a lot of the experimental features that are built into React, such as Suspense and Concurrent Mode. If you don't use any of these or the more advanced features of React, then you have a good case for swapping it out with Preact.
You could go all in with Preact in development too, but by swapping out React at build time means:
<ul>
<li>You still get to use the familiar React API and ecosystem in development</li>
<li>The change is incremental and easier to remove if you spot a problem</li>
<li>Bigger bundles are generally not a problem in development (React itself even has a development mode which is much larger than the production build) and you'll still get the smaller bundle size at the end</li>
</ul>
Sounds good doesn't it? I gave it a try and this website is now running on Preact 🚀
<h2>Get started</h2>
The good news is there are only really 2 steps to this process, the first of which is installing <code>preact</code> and <code>preact-compat</code> as dependencies:
<pre><code>npm install preact preact-compat
</code></pre>
Or if you're a <code>yarn</code> user like me:
<pre><code>yarn add preact preact-compat
</code></pre>
Once installed we then need to tell Next.js when it compiles that we'd like to swap out React for Preact by using Webpack's <a href="https://webpack.js.org/configuration/resolve/#resolvealias">aliasing</a> feature.
If you don't already have a <code>next.config.js</code> file, go ahead and create this and add the following:
<pre><code class="language-javascript">module.exports = {
 webpack: (config, { dev, isServer }) =&gt; {
 if (!dev &amp;&amp; !isServer) {
 Object.assign(config.resolve.alias, {
 react: 'preact/compat',
 'react-dom/test-utils': 'preact/test-utils',
 'react-dom': 'preact/compat',
 });
 }

 return config;
 },
};
</code></pre>
If you do have a Next.js config file, just make sure it contains the relevant <code>webpack</code> configuration from the above.
And that's it!
I highly recommend doing this as a reversible task on your codebase (like a Pull Request) and if you're using Vercel or Netlify to build Pull Request previews then you should be able to give your website a check to see if anything has broken.
If all is well then you should have shaved a considerable chunk from your main bundle (~20kb).

Photo by <a href="https://unsplash.com/@cadop?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Mathew Schwartz</a> on <a href="https://unsplash.com/s/photos/speed?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a>

Technical Leader, Software Engineer & UI Designer based in London, UK.
Currently building and scaling broadband for good at Cuckoo.

Latest Posts

Automated accessibility testing

6 months of being an Engineering Manager

Next.js + Preact

Technical Leader, Software Engineer & UI Designer based in London, UK.Currently building and scaling broadband for good at Cuckoo.

Latest Posts

Automated accessibility testing

6 months of being an Engineering Manager

Next.js + Preact

Technical Leader, Software Engineer & UI Designer based in London, UK.
Currently building and scaling broadband for good at Cuckoo.