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>

mathew-schwartz-sb7RUrRMaC4-unsplash

Next.js + Preact

I tend to try to keep as much free-space on my computer as possible. I'm not quite sure why, but if development on a project I'm working on has stalled I'll make sure that source-control is up-to-date and delete the entire folder.
Fast forward a few weeks and, &quot;I wonder if I can use X library with this project?&quot;, or, &quot;I should probably tweak this bit of UI...&quot;. So I dive into the terminal, clone the project to my computer and begin working away.
Except I can't begin working right away. Like a good developer practicing <a href="http://12factor.net">12factor</a> I'm not storing my secrets in source control, so there's always a good 5-10 minute round trip of all the websites I need to retrieve my secrets from. Suddenly that quick thing I wanted to do just doesn't seem worth it, and inevitably it can stop productivity in it's tracks.
But there's a piece of software you're probably (hopefully) using right now which can make this a breeze. Your password manager!
A lot of password managers (<a href="https://www.lastpass.com">LastPass</a>, <a href="https://bitwarden.com">BitWarden</a>, <a href="https://1password.com">1Password</a> etc.) all have command line interfaces (CLI) which can be used to interact with your password vault. These are usually hosted on <a href="https://brew.sh">Homebrew</a> and are free to download. I use BitWarden, so the following command installs the CLI to my computer:
<pre><code class="language-bash">brew install bitwarden-cli
</code></pre>
Once installed, I can use the <code>bw</code> to interface with BitWarden. Great! Obviously most (if not all) commands require me to input my master password so it's super secure. Armed with the <code>bw</code> binary, I can then add the following to the <code>scripts</code> section of a Node project's <code>package.json</code>:
<pre><code class="language-json">{
 &quot;get-env&quot;: &quot;bw get item mikefrancis.github.io | jq -r '.notes' &gt; .env&quot; 
}
</code></pre>
This uses the popular <code>jq</code> CLI (also installed through Homebrew) to dump a BitWarden note with the name <code>mikefrancis.github.io</code> into a <code>.env</code> file, by running the following command:
<pre><code class="language-bash">yarn get-env
</code></pre>
So now rather than running around to different websites, grabbing API keys, I can just keep all these in a secure note in BitWarden. These API keys have no expiry so I only have to update these in one place.
This won't work for everyone but it's a pretty nice way of getting up and running quickly.

photo-1563370961-b01f7e9009e8

Speedy project environments

I've been fortunate in my career to have worked with some amazing folks who have each taught me a different aspect about technical leadership and management. Like many before me I try to emulate these people in my own day-to-day and &quot;wear the right hat&quot;.
By no means is my learning on technical leadership over (on the contrary, I feel like every month/quarter is a new beginning) but I've hit a point where I want to start documenting these slivers of advice and have something to refer back to. I'd urge anyone to do the same thing.
This will be a &quot;living&quot; blog post.
You may have arrived at this juncture in your career as:
<ul>
<li>The most senior engineer on your team</li>
<li>The only engineer in your team/organisation</li>
<li>The person bestowed the title of Tech Lead or Staff Engineer, etc.</li>
</ul>
Or another situation entirely 🤷‍♂️
It is likely to differ per organisation and industry, but technical leadership (for me) is being adept in the following spaces:
<ul>
<li>Programming</li>
<li>Architecture</li>
<li>Project management</li>
<li>Engineering management</li>
</ul>
I'll try to break down what I would expect to see from a technical leader in these spaces. It's important to note that these are all positions which would occupy a single person (or sometimes multiple people) so it's definitely a testing time but it gives you a flavour of what is to come if you would like to specialise in one of these areas. For example someone who specialises in Programming and has no particular interest in the other areas can progress to becoming a distinguished Individual Contributor. Technical leaders who enjoy engineering management and looking after people can go all-in on an engineering management track, etc.
<h2>Programming</h2>
It was quite difficult to pick a heading here. It's changed from Development, to Programming, then to Coding, and back to Programming. What I mean here is the nuts and bolts, writing and shipping code.
The difference as a technical leader is you need to, and I'll use the same terminology verbatim as it was first said to me as I've not found a better way of saying it, consistently nail everything you lay your hands upon. Codebases should be left in a <a href="https://www.britannica.com/topic/positive-sum-game">positive sum</a> state. Your work should be used as examples for the rest of the team. Leave <code>TODOs</code> but then make some time to go through and action these. Write tests that give your team confidence in being able to delete vast chunks of dead code. Improve the tooling on your project so it's quicker to ship code and makes feedback cycles shorter. Write detailed documentation and document debugging setups, and share all this knowledge with your peers and continually strive to make this better. Know &quot;where to look&quot;. Leave lots of constructive comments in code reviews and prioritise code review over everything else as it is often a blocker to release. Expedite work which unblocks your colleagues. &quot;Pull from the right&quot;, as in concentrate on getting things on the right of your Kanban board over the line, rather than starting new things and having lots of in-flight contexts to switch between.
Hopefully you have noticed that the amount of programming you are taking on now is decreasing, as you begin to explore other facets of Engineering, and well away from the critical path to delivery.
<h2>Architecture</h2>
You will need to be an expert in every domain node your team owns and have deep understanding of any adjacent nodes and be able to sketch these systems out on napkins/whiteboards when needed. You'll be able to visualise chunks of this architecture and, especially when planning something new, where your gap/hole exists and any constraints involved.
With your years of experience you will have developed a deep &quot;back pocket&quot; of best-practice, abstracts solutions which you can delve into when minds go blank. Does a solution already exist to a similar problem? Keep things which follow the <a href="https://en.wikipedia.org/wiki/Pareto_principle">Pareto principle</a> to hand.
Think in events and packets of data, and how these flow across your business. Security should not be an after-thought in these discussions, so try to keep a threat-modelling channel of your mind open or, even better, call upon a specialist who knows what they are talking about.
<h2>Project Management</h2>
This was the main thing that blindsided me about Technical Leadership. It should be Project Management with an asterisk though as it's more of a &quot;hat&quot; - please still let the product manager do their job. There's a <a href="https://tgvashworth.com/2016/07/20/technical-lead.html">great article by Tom Ashworth</a> which explains this role better than I ever could.
As a technical project manager you're going to be using the architecture skills mentioned above and apply them to a business need or requirement. When you do this hopefully a &quot;unit of work&quot; should appear, an example would be a task or a ticket (or maybe it's a collection of these things and it's something larger?). Can you measure the impact? Are you able to show this to your team in a simple, visual and digestable way to know if you're on the right path?
It's also your job as a technical leader to &quot;front-load&quot; your team with the learning you've done. Before the work starts, you'll have run ahead and scouted the area which you're hoping to have the impact in and hopefully noted edge cases and limitations before your team encounters these issues, and prepared or documented work arounds to unblock them. It's very hard to change things at the end of a project, even with the noblest of intentions, so I cannot stress enough how important this phase of a project is and that time should be set aside for it. If not you'll need to set time aside to deal with issues that pop up at the end, so adding the <a href="https://martinfowler.com/bliki/TechnicalDebt.html">cruft</a> multiplier to this means it's much more economical and efficient to do this at the start, rather than at the end.
Project managers are often the busiest people on a team, in terms of the amount of meetings and knowledge they have to consistently have at the forefront of their minds, so ask if you can help them out. My previous Engineering Manager (thanks DJMC) encouraged and gave me the freedom to pluck responsibilities from the levels above me even though I hadn't been granted an official job title, rather than waiting for cycles of performance reviews to roll around. It was in doing this I started to take on some of the project management tasks such as leading Agile ceremonies that would help take the burden away from our project manager but also allow me to make that step up.
<h2>Engineering Management</h2>
This is possibly the most alien part of technical leadership to Engineers. As <a href="https://twitter.com/skamille">Camille Fournier</a> writes in The Managers Path, a lot of the time you'll find a Senior Engineer moving into this role and it's important to acknowledge that you're starting an entirely new career as a manager; technical mastery will not really help you in this field as you will need to learn empathy and galvanising people for your cause.
I have very limited experience in this area but I'm on my path. Something I've found useful, which may sound slightly creepy at first, is creating a living document of notes for each person on my team and filling it with feedback which I collect whenever I notice something which deserves praise, shows growth or demonstrates company values - and also for things which could be improved. I find this always gives something to talk about in 1-1s and is great for performance reviews, and is better than digging through scribbled notes or trying to pluck thoughts from the top of my head.
I also don't exclude myself from this process. In the same folder I have the same &quot;brag&quot; document for me - <a href="https://jvns.ca/blog/brag-documents">Julia Evans wrote a great article about it</a>. If there's anything which I feel needs shouting about at my next performance review I'll put it in there. If I feel like I didn't really handle something particularly well, it goes in there too as something I can share with my manager and we can hopefully figure out how to use it as a stepping stone.
In turbulent times lead from the front. When everything is going smoothly lead from the back. Don't forget that in your own quest for career growth that others will share the same goals, so make space for them to become their own experts. Give Senior(ish) Engineers their own projects, ask them what they aren't sure about and support them. Check in with them regulary. Encourage them to read up on best practices and produce work to high standards. Pair with them on programming, but also if they want to present work to the wider company or community especially if they may need a hand with a presentation or public speaking.

Software Engineer & UI Designer based in London, UK. Currently building and scaling a modern, renewable energy provider at Bulb.

Latest Posts

Next.js + Preact

Speedy project environments

Technical Leadership