DEV Community: Daine Mawer

The Rise of No-Code and Low-Code in Frontend Development: Opportunity or Threat?

Daine Mawer — Thu, 30 Jan 2025 22:00:00 +0000

Frontend development is no stranger to change. From monolithic structures to component-based architectures, the field has continuously evolved. But the rise of no-code and low-code platforms has introduced a new kind of disruption—one that promises faster development cycles, reduced costs, and a lower barrier to entry for non-developers.

So, what does this mean for developers? Are these platforms a tool for collaboration or a potential threat to the profession? Let’s explore.

Breaking Down No-Code and Low-Code

No-Code Platforms

No-code platforms are designed for users with zero programming knowledge. They provide intuitive drag-and-drop interfaces for building web apps, landing pages, and workflows. Tools like Webflow, Bubble, and Zapier fall into this category, enabling users to achieve rapid results without touching a single line of code.

Low-Code Platforms

Low-code platforms, on the other hand, are geared toward those with some technical knowledge. They allow for custom scripting and integration with existing systems. Platforms like OutSystems, Mendix, and Retool aim to empower developers and technical teams to build complex applications faster by combining visual development with traditional coding.

While they cater to different audiences, both no-code and low-code tools are reshaping the software development lifecycle in profound ways.

Why Developers Should Care

The adoption of no-code and low-code platforms is being driven by a few key trends:

Faster Time-to-Market: Businesses can test ideas and launch products at a fraction of the time traditional development requires.
Empowering Non-Technical Teams: Teams like marketing and operations can take charge of building their own workflows, reducing dependencies on engineering.
Cost Efficiency: Smaller startups and businesses can save money by building MVPs without hiring large development teams.

For developers, these platforms introduce both opportunities and challenges. Let’s take a closer look.

What Does This Mean for Frontend Developers?

1. A Shift in Role

No-code and low-code platforms automate repetitive tasks, enabling developers to focus on more impactful work. Instead of coding UIs or workflows from scratch, developers can step into roles as technical architects who oversee integration, scalability, and customization.

2. Bridging Technical and Non-Technical Teams

These platforms bring non-developers into the fold, requiring developers to work more closely with them. This collaboration introduces new challenges but also enhances problem-solving and team alignment.

3. Customization and Extensibility

Even the most advanced platforms have limitations. Developers play a critical role in extending the functionality of these tools by writing custom components, APIs, or integrations that meet unique business requirements.

4. Focus on Scalability and Performance

No-code solutions often struggle with scaling and optimization. Developers are essential for tackling bottlenecks and ensuring that applications can handle growth effectively.

Where No-Code and Low-Code Fall Short

Despite their benefits, these tools come with challenges that developers are uniquely positioned to solve:

Limited Customization: Prebuilt components can hinder flexibility, especially when building applications with unique requirements.
Scalability Concerns: Many no-code platforms lack the robust infrastructure needed for high-scale applications, leading to performance issues.
Vendor Lock-In: Migrating away from proprietary platforms can be costly and time-consuming, creating long-term dependencies.
Security Risks: With non-developers building applications, there’s a higher risk of misconfigurations that introduce vulnerabilities.

These shortcomings highlight why developers remain indispensable. Platforms might handle the basics, but the hard problems still require expertise.

How Developers Can Embrace No-Code and Low-Code

Instead of viewing these tools as competition, developers can leverage them to streamline workflows and enhance productivity. Here are some ways to embrace the rise of no-code and low-code:

Use Platforms for Prototyping: Rapid prototyping with no-code tools can save time and help validate ideas before committing to full-scale development.
Focus on High-Value Work: Automate repetitive tasks with low-code solutions and dedicate your time to solving complex problems.
Become a Hybrid Expert: Learn how to integrate no-code platforms with traditional development stacks to build more powerful applications.
Guide Non-Developers: Act as a mentor for non-technical users navigating these platforms, ensuring proper configurations and scalability.

Final Thoughts: Is This the Future of Frontend Development?

No-code and low-code platforms aren’t a threat—they’re a tool. They won’t replace the need for developers, but they will reshape how we work. By automating the mundane and empowering non-developers, these platforms free up developers to focus on high-impact tasks that require expertise and creativity.

If you’re a frontend developer, now is the time to adapt. Learn how these platforms work, experiment with them, and position yourself as an enabler within your team or organization.

The future isn’t about choosing between no-code and traditional coding—it’s about leveraging the best of both worlds.

👉 Read the full version of this article on my website

What’s your take on no-code and low-code? Are they an opportunity for growth or a disruption to the developer ecosystem? Let’s discuss in the comments below!

Using CSS Custom Properties with Fallbacks for Efficiency

Daine Mawer — Tue, 14 May 2024 12:00:00 +0000

By now, most of us are accustomed to using CSS Custom Properties on projects. Since its introduction in 2017, CSS Custom Properties, also known as CSS variables, have optimised the code we work with and allowed engineers a finer degree of control when managing values within rules.

CSS Custom Properties can be tricky to deal with and aren’t always as intuitive as one might hope. However, when used right, they can significantly reduce boilerplate code and keep things efficient, making our work more productive.

While the approach below is not perfect, it works well when writing CSS for building projects.

Why Use CSS Custom Properties

As far as my experience goes, I can only think of three possible reasons to implement a CSS Variable:

We want to use a given value in more than one place,
We know that a value will change in the future and want to reduce our efforts for refactoring,
We need to store dynamic values from JS execution.

With this in mind, we can be more assertive about our use cases. Point 3 is less of a concern for this article, but points 1 and 2 are essential. Let's illustrate this using the familiar HTML button element.

The Infamous Button

Buttons are notoriously tricky to style consistently for such a simple HTML element. Perhaps it’s because they have several different states and applications, regardless - it's usually the first component we Frontend Engineers take on when it comes to a fresh build. Let's have a look at how we could write the style for a button using CSS Custom Properties:

:root {
 --color-primary: purple;
 --color-text: black;
 --color-text-inverted: white;
 --color-border: gray;
}

.button {
 --button-bg: var(--color-primary);
 --button-color: var(--color-text-inverted);
 --button-border: var(--color-border);

 align-items: center;
 background-color: var(--button-bg);
 border: 1px solid var(--button-border);
 color: var(--button-color);
 display: inline-flex;
 line-height: 1;
}

As far as this example goes, from a technical standpoint, it’s great. It’s clean and straightforward and would get a 👍 from me in a code review. But could we optimise it further? Well, yes.

The var() function in CSS is pretty nifty…we’re used to using it in a somewhat one-dimensional way by just rendering out a value; however, it can be more dynamic. The way to do this is by using a fallback value.

If we considered the above example, we could rewrite it like so:

:root {
 --color-primary: purple;
 --color-text: black;
 --color-text-inverted: white;
 --color-border: gray;
}

.button {
  align-items: center;
  background-color: var(--button-bg, var(--color-primary));
  border: 2px solid var(--button-border, var(--color-border));
  color: var(--button-color, var(--color-text-inverted));
  cursor: pointer;
  display: inline-flex;
  line-height: 1;
  padding-block: 0.875rem;
  padding-inline: 1rem;
}

This is far cleaner and will lead to the same outcomes as the previous example - with less boilerplate code. Overriding it in a variation makes each locally scoped CSS Variable (effectively) optional. We can easily now optionally define the variables defined in .button as separate variations:

.button:where(.button-secondary) {
  --button-bg: orange;
  --button-border: teal;
}

.button:where(.button-tertiary) {
  --button-bg: teal;
  --button-border: orange;
}

Although this technique is not revolutionary, we care how many lines of compressed text are heading over the wire. The less physical memory a CSS file takes up, the better, which ultimately translates to how many lines of CSS exist. In the first example, we’re looking at almost double the amount of code to achieve the same thing in our optimised example.

This compound effect has an influential impact on performance and further improves readability and developer experience. If you'd like to play around a bit further, feel free to fork the following Code Pen: https://codepen.io/iamdainemawer/pen/NWmQZMz

Support

Since April 2017, according to Google Baseline, this feature is well-supported across all major browsers. If you're interested to learn more about Baseline, read my post about Google Baseline and Its Impact.

You can check for browser support by adding the following statement to your CSS stylesheets:

@supports(--css: variable) {}

Resources

What Is Google Baseline and Its Impact?

Daine Mawer — Sun, 28 Apr 2024 20:57:35 +0000

What Is Google Baseline and Its Impact?

For years, web developers of all experience levels have relied on caniuse.com to understand the support of a given feature. This scenario extends to determining backward compatibility or to determining which of the modern browsers supports cutting-edge improvements to web specifications.

In 2023, Google introduced Baseline to the web community. Baseline aids engineers in determining whether certain features or APIs are safe to use in production-grade web applications. It’s an important platform for interoperability, and considering Google spends a lot of time improving web best practices, it is a very much needed tool to help engineers produce more consistent and efficient experiences.

Why Google Baseline?

Browsers are constantly evolving, with vendors releasing updates monthly. With more individuals contributing and working on specifications than ever before and a far more transparent dialogue between the main browser vendors (Safari, Firefox, Chrome, Edge), it's become increasingly difficult to track which new features are stable across the landscape.

Considering the above, as new features are released into browser engines, engineers are often left with an incredibly short time to ramp up, refactor or even strategically plan to introduce new features into their code bases.

More importantly, as Google is often one of the platforms that push front-end technology forward, it has admittedly accepted that it is partly to blame here. It’s one of the reasons the Chrome team came up with web.dev and developer.chrome.com, as Chrome is often the first browser to land cutting-edge technologies. This has also led to further documentation and conferences on interoperability (see web.dev and interop).

New features mean documentation, and Google has made strides to ensure MDN has the relevant documentation for newer technologies as they arrive in Chrome.

Closing the Vendor Gap

As much as this is great, from Google's perspective, engineers have one very important struggle: the behaviour and consistency of features across vendors and browser engines. This has been a pain point for most engineers, requiring complex planning and solutions often to overcome a particular browser engine's lack of functionality.

For the last two years, the solution has been Interop 2022 and Interop 2023, a conference and community that helps bridge the gap between browsers to provide a more consistent and performant web. Google's notion will continue to yield fruit as the years go by.

What is Baseline?

Baseline will become the universal flag of acceptance across browsers and help engineers determine what is fully stable across the landscape and browser vendors for the most recent two versions of each browser.

This allows us, as production teams, to explain to stakeholders how browser support is tied to Google Baseline, which will shortly exemplify reliability and understanding.

How Does Baseline Work?

Baseline is already integrated into MDN, web.dev and caniuse.com.

Baseline also plans to provide a way to see what has become stable across all browser vendors through a year-on-year approach. In 2023, for instance, you can read the following article on web.dev to get an idea of what is considered stable, and supported in the last two major versions across all the browser vendors: Baseline 2023 | Blog | web.dev

It’s important for us as engineering teams to keep up with these changes and not get too stuck in old ways that lack the motivation to improve and make our approaches to solutions inefficient.

Importantly, Baseline has two labels:

Newly available: the feature is finally interoperable
Widely available: 30 months have passed since the interoperable date.

Baseline considers the major browser vendors to be:

Safari (macOS and iOS)
Firefox (Desktop + Android)
Chrome (Desktop + Android)
Edge (Desktop)

Effect on Engineering Teams

Perhaps the biggest benefit to engineering teams is that Baseline and its contents remove the guesswork and research required to implement new features. For instance, a Frontend Engineer may want to leverage CSS Grid's new sub-grid feature.

This new display mode helps engineers define a grid within a grid to have more refined control over layouts. Heading to caniuse.com tells us there’s a global usage percentage of 87.42% - pretty decent, but then we need to go see which browser vendors support / don’t support / partially support the feature.

CanIUse now displays a Baseline badge which tells us that this feature is “Newly available across major browsers”

Likewise, if you review the documentation for sub-grid on MDN you’ll see a similar banner:

Finally, if you review the sub-grid article on web.dev, through what was introduced to Baseline in 2023:

This is intended to make it evidently clear that the latest two browser versions across vendors have full support for the feature.

A Word on Evergreen Browsers

This is a topic that I find we do not talk enough about. For most modern users gone are they days of manually updating browsers. Chrome, Firefox, Edge auto update automatically. Safari can be a bit of an outlier in this case. Safari generally updates once a year on each new Mac OS X update, though that is not always a guarantee.

Regardless, more users than ever use the latest version of browsers. Although we should ensure the features we built to degrade gracefully or progressively enhance, it’s less of a fundamental consideration these days and more of a luxury assumption. Landing somewhere in the middle here has always worked out well. It’s worth remembering before shying away from using features that could save time, money and focus.

Useful Links

Understanding Chromes Coverage Panel

Daine Mawer — Mon, 27 Nov 2023 05:36:17 +0000

When we work on complex projects, JavaScript and CSS often get the jump on us. Before we know it, thousands, if not tens of thousands, of bytes are being transferred and executed in the browser - most of which we do not need to load.

What is Code Coverage?

Code coverage derives from a computer science concept called "test coverage". From Wikipedia:

Test coverage is a percentage measure of the degree to which the source code of a program is executed when a particular test suite is run.

A program with high test coverage means that more or all of its source code gets executed during unit testing, implying that the code base would have a lower chance of undiscovered bugs.

Code Coverage is different when it comes to JavaScript and CSS. Of course, you can still write unit tests for JavaScript, but within the context of the browser environment, JavaScript and CSS coverage mean the following:

CSS: what percentage of CSS gets utilised when it loads into the browser? More precisely, what percentage of nodes from the CSSOM get matched to nodes in the DOM?
JavaScript: what percentage of JavaScript functionality is executed by the browser?

If we determine just how much of the referenced JavaScript and CSS assets are utilised by the browser, we can refactor or reimplement files to be more conscious of what they try to achieve on the page. If we only load the JavaScript and CSS required for the page, this reduces bundle sizes, transfer sizes and overall Paint time, leading to a great user experience.

Auditing Code Coverage in Chrome

Many Chrome users must be aware of the Code Coverage panel in DevTools. To view it, open DevTools, go to the context menu, click "More tools", and select "Coverage".

When the panel opens, you have two options:

Reload the page with a Code Coverage Audit
Record code coverage attributed to your interactions.

After each audit, the panel will list all JavaScript and CSS-loaded resources. Clicking on a line item will display the source code with a vertical bar down the left. Sections of the bar will be coloured green or red.

Code blocks will be highlighted in red or green when reviewing the Sources panel for each request. Any code block highlighted in red is code that got loaded but not executed by the browser. The line item will also summarise the Total Unused Bytes and a percentage measure of unused code.

How to handle poor Code Coverage

Handling poor Code Coverage can be a challenge. It's hard work and may lead you down a path of a complete refactor. I grimace at the word "refactor", so let's chat about some higher-level wins first.

CSS Wins

Several tools are doing an excellent job of ensuring 100% CSS Code Coverage. PurgeCSS (leveraged by Tailwind) does a great job of removing unused CSS styles. You can implement PurgeCSS into any tech stack, so you are not married to Tailwind if you're not a fan.

Even WordPress Gutenberg released a nifty filter for only loading Block Library CSS when a block is on the page.

Using more modern CSS approaches can yield incredible results in the React space. You can leverage CSS Modules, Vanilla Extract and Linaria to help reduce the impact of unused CSS.

JavaScript Wins

There are some minor wins in the actual execution of JavaScript. Optimising code for a high percentage measure is about what approach you're taking to the feature you're trying to build and when and how that feature gets executed in the browser. More often than not, it boils down to planning and architecture.

It's worthwhile looking into recommended performance best practices like Route-based Code Splitting, Tree Shaking, Dynamic Import, Facade Patterns and Import on Interaction/Visibility.

Build Tool Wins

Webpack is a sophisticated build manager that aids in code-splitting, tree-shaking, and other JavaScript wins that can, without a doubt, speed you along on the coverage front. As this space constantly evolves, keep looking for newer versions of build tools or even new build tools offering more performant features.

Dead Ends / Not Worth The Effort

When it comes to gaining a high percentage measure with code coverage, two scenarios that will stop you dead in your tracks are:

3rd-party JavaScript and CSS
Frameworks and Libraries.

Generally speaking, we have little control over how third-party scripts execute. In this case, we only have three options:

retain the script,
remove the script,
determine a way to defer the script execution.

Frameworks and Libraries are more complex. Removing unused code from even the fastest frameworks is only sometimes possible.

It's also essential to understand where the necessity of this fits in concerning the state of performance on your site. There's no need to optimise everything if it doesn't yield valuable results.

Planning and Refactoring

Technology stacks and architectures are your friends here. Each technology stack will expect something slightly different from you when selectively deciding how to deliver code that receives a high code coverage percentage.

High Code Coverage is a gateway (in the long term) for bullet-proof performance. Ensure JavaScript code gets written to best performance practices. A well-moulded build configuration and careful planning of site features can also bolster successful attempts at increasing code coverage.

Conclusion

High-percentage code coverage is a great way to ensure a lightweight and performant website. Many tools are available to help you identify, audit and remediate code that may have poorer-than-expected coverage across your site. Remember that your options become limited as soon as you buy into 3rd-party scripts and complex frameworks/libraries.

The chances of 100% code coverage across both CSS and JavaScript are likely unrealistic. You may also have an incredibly complex site that warrants large payloads, making attaining impactful code coverage more difficult.

Set Up NextJS with Storybook using Monorepos

Daine Mawer — Mon, 20 Nov 2023 06:10:45 +0000

A monorepo is a repository containing multiple related resources managed from an individual repository. Using NPM workspaces, we can build dynamic component libraries that numerous applications can consume, all retained in one version-controlled repository.

Introduction

Monorepo's have been gaining traction over the years. Having worked with them for over a year in production environments, I can say one thing: they beat git submodules!

A typical monorepo will contain multiple packages and projects that are closely related. We can work more efficiently using a monorepo in a way that allows us to move away from:

initializing git submodules (a repo within a repo)
linking local packages from other locations on the disk that must be updated and installed.

NPM supports workspaces, which effectively allows for a monorepo structure. You'll need to use NPM v7 and above to set up a workspace.

Recently, I embarked on building a suite of components for a NextJS project. I wanted to ensure that I could actively develop components (facilitated by Storybook) so that my NextJS projects could consume those components.

Historically, NextJS projects have always supported a components folder. However, NextJS restricts this to the application itself. I aim to treat my component library like any other 3rd-party library I'd want to import into my projects. An architecture of this manner is easily achievable using a mono repo.

Initialise Project Structure

Our first step is to set up a project structure supporting a monorepo. Create a folder where your monorepo can live:

mkdir my-monorepo && cd my-monorepo

Great. Our next step is to create a package.json file. We can bootstrap one quickly by running the following:

npm init -y

That should produce the following output:

{
  "name": "my-monorepo",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

Let's add some items to our package.json before installing dependencies. We'll need to add a workspaces key. Doing so informs NPM where our projects and packages sit.

NPM comes with a nifty command for adding workspaces; run the below commands and follow the instruction wizard that each command outputs:

npm init -w ./packages/component-library
npm init -w ./projects/monorepo-site

Executing the above will run npm install for you as well.
At this point, we will see our first fundamental differences between a traditional repo and a monorepo:

A package.json exists in the root and within every "workspace." You may notice that there is only one occurrence of node_modules and package-lock.json. Now, all workspace dependencies get managed from the root folder.

Next up, we'll look into how to install workspace-specific dependencies.

Install dependencies

When installing package or project dependencies, we can still leverage npm install - however, this needs to be run from the root folder and requires that we pass a -w flag to the command. Let's run through installing NextJS.

npm install --save next react react-dom -w monorepo-site

Run the command above from the root of your project folder, where node_modules and the package-lock.json can be found. The only thing to call out here is that the value passed to -w must match the name field of one of your project or packages package.json. In this example, the name field of projects/monorepo-site/package.json is monorepo-site.

If all was successful, you should see the dependencies added to projects/monorepo-site/package.json.

"dependencies": {
    "next": "^13.0.6",
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
}

Repeat this process for any necessary dependencies in packages/component-library as well.

Setup Components and StoryBook

Please note that this is not a tutorial on how to get set up with Storybook.

Let's take some steps to get Storybook set up correctly. We'll also create a dummy component to verify that our setup works. As StoryBook isn't a dependency of either packages or projects, we can install it in the root of our monorepo:

npm install --save-dev @storybook/react @storybook/manager-webpack5 @storybook/builder-webpack5 @storybook/addon-postcss

Let's also add the build commands to the root monorepo package.json:

"storybook": "start-storybook -p 6006",
"build-storybook": "build-storybook"

Next, we'll need to create the .storybook folder; let's do this and add it to the root of the monorepo. You'll want to add two files to this folder:

main.js
preview.js

main.js is where we configure StoryBook's settings:

module.exports = {
    "stories": [
        "../packages/component-library/**/*.stories.jsx",
    ],
    "addons": [
        {
            name: '@storybook/addon-postcss',
            options: {
                styleLoaderOptions: {},
                cssLoaderOptions: {
                    modules: true,
                    sourceMap: true,
                    importLoaders: 1,
                },
                postcssLoaderOptions: {
                    implementation: require('postcss'),
                },
            },
        }
    ],
    "framework": "@storybook/react",
    "core": {
        "builder": "@storybook/builder-webpack5"
    }
}

In our main.js file above - we tell StoryBook where to look for component stories. We also include the @storybook/addon-postcss plugin that supports PostCSS. The extra options you see listed above enabled PostCSS Modules. The last two keys: framework and core, allow us to configure StoryBook to use Webpack v5.

In preview.js, add the following:

export const decorators = [
    (Story, context) => {
        return (
            <div style={{ padding: '1rem', display: 'flex', justifyContent: 'center' }}>
                <div>
                    <Story {...context} />
                </div>
            </div>
        );
    }
];

The preview.js file allows us to customize the appearance of stories without affecting the component logic itself. Hence, the name "decorator". I've just added some basic styling here to center the button.

Next, we need to flesh out our Button component. In package/component-library, add a new folder called Button; in that folder, add the following files:

Button.module.css - handles the styling of the button
Button.stories.jsx - handles the button story
Button.jsx - the button component itself

You can find the contents of these files in the repo. Great, we need to see if we can import our component into NextJS.

Setup a NextJS project

We need to return to NextJS quickly to tie everything together meaningfully. First, add a pages folder to the NextJS site and the scripts needed in package.json to build NextJS.

To add the scripts, go to projects/monorepo-site/package.json and replace the current scripts field with:

"scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
}

In the pages folder, add an index.js file with the following contents:

const Home = () => {
    return (
        <main>
            <h1>Hello! This is a NextJS + StoryBook Monorepo</h1>
        </main>
    )
}

export default Home

Add the Component to NextJS

Now, it's time to import our component into NextJS. Let's import the button into projects/monorepo-site/pages/index.js:

import Button from '../../../packages/component-library/Button/Button.jsx'

When you run npm run dev, you'll likely run into an error. NextJS does not transpile ES6 JavaScript from node_modules or any other local folder outside its reach.

To get around this problem, configure a property in next.config.js called transpileModules:

export const nextConfig = {
    transpileModules: ['component-library']
}

Note that the workspace name, component-library, is passed, not the path to the folder on the disk. You'll need to restart your dev server.

Your custom Button component now lives in NextJS and StoryBook and can be iterated upon and tracked in the repo!

You may run into trouble with NextJS asking for React v18 if you use NextJS 13. This tutorial was written using NextJS v12 and React v17.0.2

Additional Scripts for Convenience

To run our build commands, we'd have to cd into every project or package. Doing so can be time-consuming, so let's add the following scripts to the package.json found in the root:

"scripts": {
    "build": "npm run build --workspaces --if-present",
    "dev:monorepo-site": "npm run dev -w monorepo-site",
}

Let's run through these two commands as they differ slightly. Running npm run build in the root will allow us to fire off individual build scripts in all workspaces. If the build task isn't in a package or project package.json, it will simply skip it.

If, at some point, this particular example scaled to have three production sites, all with a build command, we could run npm run build from the root, and for each workspace, the build task will execute. Pretty nifty!

npm run dev:monorepo-site is slightly different - this command targets one workspace and fires off the script defined within that workspace (as long as it exists). Doing so allows us to spin up the dev server for monorepo-site from the root without navigating to the folder.

Conclusion

Let's review where we're at:

We initialized a monorepo structure using workspaces in NPM
Set up a component library and production site with StoryBook and NextJS.
Added scripts that will make our developer experience more accessible to manage.
All our dependencies get managed from the top level, and we do not have to pull in other repos or git submodules.

At this point, we could easily add a new site project or extend our component library. We could also add other packages that may deal with custom server functionality, CMS integrations, or API support. The possibilities are endless. Now it's time for you to try!

Announcing the CrUX Site Validator

Daine Mawer — Tue, 07 Mar 2023 05:11:54 +0000

Over the past few years, I have worked closely with various performance tools. One issue I often encounter is whether a website is in the CrUX. To clarify, one can run a PageSpeed Insights report to determine this. However, this can be problematic for workflow reasons when creating strategies for clients.

If a client's website does not meet the eligibility requirements for the CrUX, it becomes challenging to aggregate and visualise data without the help of the CrUX.

What is the CrUX?

The CrUX or Chrome User Experience Report is the official dataset for Google's Web Vitals program. All data is collected from Google Chrome users worldwide as long as users have opted in.

There are also eligibility requirements for sites that make it into the CrUX, such as traffic volume and other factors.

Tools like Page Speed Insights and Search Console use the CrUX to show your site's performance against real user metrics.

CrUX Validator

I have developed a straightforward tool that uses the CrUX API to verify if a site is in the CrUX. You will receive an immediate response if the site is not present in the CrUX. However, if it is, the tool includes direct links to the PageSpeed Insights Report and the CrUX Dashboard for that URL.

You can check out the tool here: https://dainemawer.com/tools/crux-checker.

10 Proven Techniques for More Effective Code Reviews

Daine Mawer — Tue, 21 Feb 2023 04:28:26 +0000

Introduction

Any engineer will tell you performing code reviews is as normal as breathing air in the tech world. Code reviews are integral to the software development lifecycle by ensuring quality, standards, team collaboration, knowledge sharing and learning.

As much as we know that code reviews are mandatory, the jury is out about how best to dish them out. A code review, in many ways, becomes an intersection of human and machine collaboration. Humans debate and collaborate to better the machine code to ensure its intended function.

It's this very intersection where the problem begins. Humans have a hard enough time conversing with each other, never mind talking about code that a machine is barely intelligent enough to process. Often, code reviews can become personal, offensive and filled with dread. They can hold up sprints or project deadlines due to stubborn and egotistical mindsets or cause panic in those who don't understand the intended feedback.

Fortunately, there are ways to overcome these challenges, so here are ten techniques for giving, accepting and working with code reviews:

Perform Multiple Reviews Per Feature

One giant misconception about code reviews is that the code should only be reviewed once. It's like arriving at your destination without knowing how you got there. Whereas it's not feasible or efficient to constantly check the same code, it is valuable to be close to the development of that feature on a daily or weekly basis.

This helps you, as the reviewer, understand what the engineer submitting the code review is trying to achieve; it outlines their thought process and uncovers their struggles.

I would suggest regular check-ins regarding code reviews, perhaps when a feature is 25% or 75% complete. This gives you multiple opportunities to course correct if need be. Junior developers will also appreciate the guidance, as it will feel like you're building the feature with them.

As time may not always allow for three rounds of detailed review, doing a brief check-in via a Draft PR for the 25% and 75% milestones may be worthwhile. A thorough review can be performed when the submitting engineer thinks the feature is finished.

Define a Clear Process

Before launching into feature development, defining a straightforward process for code reviews can go a long way. This may involve:

Who will perform code reviews?
What automated tools will be used?
How often should a code review take place?
What activities will take place during the code review?
What are the steps to submit a code review?
Who is responsible for assigning tickets/code reviews to relevant engineers?
How should developers prepare their branches?
What merge strategy should be used?
Should branches be deleted after merging?

It often helps to define a document that outlines these questions and their answers to help make the team more efficient. Once all members agree on a process, follow it and try not to change it too much.

Always communicate with the team when there's a process change and ensure complete alignment and understanding.

Focus On Code, Not People

All too often, code reviewers can leave borderline insulting, offensive or rude comments on PRs - written language can be conveyed and interpreted in many different ways, depending on language barriers, culture, and the general mood/sensitivity of the engineer submitting their work.

Feedback like this can often come back as "too direct" and does not contribute to a cohesive working environment. When addressing feedback on a code review, try to:

Keep it light-hearted, kid around a bit, or use emojis.
Be empathetic.
Suggest, rather than instruct: "Perhaps it would be better to…" rather than "You must stop doing…."
Avoid blameful or aggravating language: "A better understanding of the CSS cascade would help make this code more efficient" instead of "You don't understand how the CSS cascade works".

Treat every feedback item as a learning experience for the engineer having their work reviewed. Likewise, as the code reviewer, every feedback item you leave is a teaching moment.

Ask Questions; Dont Assume Mistakes

One thing I've found particularly useful in the past is asking a question instead of calling out a mistake. This disarms the situation immediately as your intention is clear; asking a question is less aggressive than pointing out that the code submitted needs refactoring. Asking a question can take many forms:

"Can you explain to me how this function works?"
"Why is this value a String on line 117 but an Array on 120?"
"What is the purpose of this variable?"

Asking questions disarms the engineer who submitted the request and helps you understand the logic better. The reviewee will feel like they are teaching you, increasing their self-confidence.

Leverage Automated Tooling

Perhaps the most critical point on this list is that as a code reviewer, you do not want to spend time calling out code mistakes that could have been caught with linting tools…especially if the project has them set up already.

Many platforms offer integrations for automated tooling to run in CI/CD pipelines that can make this a breeze. Github, for instance, allows you to run automated tasks through GitHub Actions, which can fire on pull requests or git push.

You can also use tools like Husky or Lint-Staged to run linting scripts on only the code that has changed on the branch. This way, code styling, best practices and silly errors can be caught without needing a human eye.

Of course, automated tools can't catch everything, but I would consider them for the following:

CSS Code Styles
JavaScript Code Styles
Framework Best Practices
Unit Testing
Performance / e2e Testing

Encourage Open Communication and Dialogue

The hierarchical nature of code reviews (reviewer vs reviewee) can inherently stall open communication. The code review format isn't a comfortable platform for clear communication, either. Whereas issues and problems can be easily pinpointed and called out in code, the details may need to be taken offline.

While having these conversations, it's essential to gauge the following:

How much time you're spending mentoring, teaching and explaining the issues found in the PR?
The openness of the reviewee. They also have to take the code review process as a learning experience and not get too conscious of the feedback provided.

Actively encourage the challenging of opinion in a way that keeps open dialogue consistent. Less senior team members need to be encouraged to challenge opinions respectfully. This can be done in a 1:1 session or as a team feedback session if the reviewee feels comfortable.

Do More Than Review

Believe it or not, there is more to code reviews than just reviewing code. A thorough code review means that, as a senior engineer, you take a vested interest in the submitted code. This may include:

Pulling the code down locally and running a production build.
Testing the feature in the browser, validating the technical approach and ensuring it meets product stakeholder expectations.
Performing some light but meaningful QA on the feature.
Suggesting improvements and providing options for optimising.
Thinking ahead and determining if this feature could have a domino effect across the project.

Be aware of these extra responsibilities. As the reviewing engineer, you give the thumbs up for when this code is merged.

Use Code Suggestions and Examples

Often, our understanding of feedback can differ from engineer to engineer. This is mainly due to experience; some senior engineers see things more clearly than others.

In the past, I've received feedback that I haven't entirely understood or that's made me hopelessly lost. Sometimes the feedback required a subtle refactor or update to logic I did not completely understand.

If a reviewing engineer had provided a clear example of what they wanted to see, I could have been far more efficient in my duties. GitHub has a great feature called Suggested Changes, allowing reviewers to suggest code updates in line with commented feedback.

Linking to related examples, educational reading, articles or blog posts can also help achieve positive and sought-after results from reviewees in a way that teaches them and allows them to improve.

Don't Sweat The Small Stuff

Sometimes, less experienced engineers get stuck on the things that matter the least. Whether that is tabs vs spaces or how to name variables or functions. Some things don't matter as much as others think they do.

As a senior engineer on the project, you have the authority to override this. However, it does become a case of "choosing your battles". It's not efficient nor practical to have back and forth on how a constant has been named.

You need to learn to let certain things go.

This can be dependent on the technologies or frameworks used. As a general rule of thumb, always prioritise the issues that could cause the most damage in the long run. Naming conventions and other callouts can be tackled later if they do not directly affect the functionality or cause code styles to erode on lint.

Implement a Code Review Check List

A code review checklist is an essential and effective way of ensuring consistency within each PR. Nowadays, many manual tasks are mainly automated through tests, so you know that a particular task succeeds or fails when a PR is created.

For other more abstract items, though, a checklist in the PR description can go a long way. You may want to include the following:

A link to the task ticket.
A description of the technical approach or solution.
Links to designs.
Screenshots of the feature.
Instructions on how to test.
A section to confirm functionality, address doubts etc.

If every engineer takes the time to fill in this section consistently, it provides a meaningful database of progress over time. This can be useful when uncovering where a bug originated. In GitHub, you can use PR Templates to implement a pre-defined setup when a PR is created.

Conclusion

Ensuring more effective code reviews can be a difficult learning curve for senior and junior engineers. Once mastered, engineers can change the direction and output of a team by following simple and tested communication techniques.

Remember to communicate openly, provide direct feedback on the code, not the person, perform thorough reviews beyond "just reviewing code", and leverage automated tooling to save you from searching for remedial mistakes.

This article originally appeared on dainemawer.com. If you liked this article, please follow me on Twitter at @daine_mawer.

4 Tips for Properly Using the Return Statement in Your Code

Daine Mawer — Mon, 13 Feb 2023 04:57:06 +0000

The return statement is an often overlooked programming paradigm. It allows you to specify a value to be returned by a function and signals the end of its execution. Using this statement properly can ensure your code runs smoothly and may prevent unexpected bugs. Here are five tips for using the return statement effectively:

Use the return statement to end a function or method

The return statement signals the end of a function or method. When the return statement is encountered, the function immediately terminates:

function sayMyName(name) {
  console.log(name);
  return;  // end the function
}

It's worthwhile noting that the return statement is affected by ASI (Automatic Semicolon Insertion). This means that you cannot create a new line after the return statement is called:

/* Incorrect - would return nothing and flag an error. */
return;
name;

/* Correct - would return the value of name. */
return (
 name;
);

Return a value of the correct data type:

When using the return statement, make sure to return the correct data type of the intended value. If you fail to return the correct data type, your program will behave unexpectedly and may result in errors. This is due to a feature of JavaScript known as Type Coercion.

Look out for my articles on Using TypeScript and Getting Started with JavaScript Unit Testing to learn more about how to work around this pitfall confidently.

function add(a, b) {
  return a + b;  // correct - returns a number
}

function subtract(a, b) {
  return a - b;  // correct - returns a number
}

function multiply(a, b) {
  return `${a} times ${b} is equal to: ${a * b}`;  // incorrect - returns a string
}

Return a value that is appropriate for the function

When writing functions, it is essential to consider what information you need from your data and how it can affect your code. For example, if your function needs to calculate the average of a list of numbers, returning the sum of those numbers would not be correct.

Make sure you carefully consider what information you need when writing functions and how it can affect your code.

function average(numbers) {
  let total = 0;
  for (let number of numbers) {
    total += number;
  }
  return total;  // incorrect - returns the sum of the numbers, not the average
}

function average(numbers) {
  let total = 0;
  for (let number of numbers) {
    total += number;
  }
  return total / numbers.length;  // correct - returns the average of the numbers
}

When writing a function, it's important to be intentional about the following:

What the function is intended to do

What data the function is intended to return

Is the data returned immutable?

Use multiple return statements if necessary

Sometimes, you may want to return a value immediately if certain conditions are met. This would apply to using if statements, as well as switch statements.

function options(option) {
  switch(option) {
    case 'DnD':
     return 'do-not-disturb';
   case 'Silent':
     return 'silent-mode';
   default: 
     return 'no-option-selected';
  }
}

function getOptions(option) {
 if (option === 'DnD') {
   return 'do-not-disturb';
 }

 return option;
}

In the options function above, we can omit the break keyword, along with a temporary variable to store the value if we explicitly return within a case - this makes code more readable and saves memory.

In the getOptions function, we can also always ensure that we return a value regardless of whether a condition is met. If the condition is true, it will execute the return statement within the if - if not, it simply ignores that statement and returns the value of option

By following these tips, you can use the return statement effectively and ensure that your code runs smoothly and correctly. Proper use of the return statement is an essential part of good programming practice, and taking the time to get it right can save you a lot of headaches in the long run.

You can read more about the return statement on MDN.

This blog post was initially published on dainemawer.com. If you liked this article, please follow me on Twitter at @daine_mawer.

Waking Up Early: A Crash Course for Software Engineers

Daine Mawer — Tue, 07 Feb 2023 07:24:57 +0000

Introduction

Let's rewind the clock to the 27th of March, 2020. A year that changed a lot about life as COVID descended upon each and everyone one of us. That day, a Friday, was the first day of the hard lockdown in South Africa. Like many of you reading this article, I was shocked and wondered how long I'd be left to survive the jail sentence handed down to me.

On the Thursday afternoon before lockdown struck, I was in a bookstore and picked up "The 5 AM Club by Robin Sharma". I was instantly intrigued. I had read one of Robins's books (The Monk Who Sold His Ferrari) some years before and enjoyed his storytelling. I purchased the book and read it through the first weekend of lockdown.

I had heard about the concept of the 5 AM Club multiple times leading up to that point, always knowing it was something I wanted to find out more about. Adapting to the 5 AM Club gave me a sense of control, considering how much of my life was now out of my control.

I wasn't born a night owl. In fact, by 4 PM, I'm usually pretty useless to the world. However, waking up has always been easy for me. I have boundless energy in the morning and, to be honest, quite enjoy the peace in the world during the early hours of the day. I know, right? It's the complete antithesis of what software engineers are accustomed to.

What if I told you, though, that following the practices of the 5 AM Club has helped me gain two promotions over two years, learn new technologies and languages, and even set up a side hustle or two? There are many benefits to waking up early, both professionally and personally, and I intend to convince you of them!

What is The 5 AM Club?

So what exactly is The 5 AM Club? First and foremost, it's a book. However, I would say it's now closer to philosophy or methodology. The 5 AM Club follows the 20/20/20 rule, as set out in the book:

20 minutes of intense exercise
20 minutes goal setting
20 minutes learning a new skill

While the premise of The 5 AM Club is based on these three tenants, once you understand the reasons for each tenant, you can easily change, arrange and update them to suit your needs or align with your goals.

As the Dalai Lama said: "…know the rules well so that you can break them effectively."

Waking up at 5 AM allows you to make space in your day before the world gets busy. The 5 AM Club has gained popularity among business leaders and entrepreneurs, and it can be elegantly applied to the careers of software engineers. Let's discuss some of the significant benefits of practising The 5 AM Club.

Benefits of the 5 AM Club

Achieve your career goals: in my own experience, I leveraged the 5 AM Club to achieve my career goals. In 2020, I was a humble Senior Front-end Engineer; a year later, I became a Lead Front-end Engineer and, one year after that, an Associate Director of Front-end Engineering. This was a choice I made, dedicated to my career. Luckily, good fortune came into play, but I used my early morning hours to go the extra mile at work, and it paid off.
Balance your personal life: not everything in life is about work. Your health, relationships and family are just as important. I don't have kids, but I have a committed relationship with my partner, two dogs to look after, and a house to run. You can use the early hours to spend time with your partner, exercise together, take the dogs for a walk, and plan travel/life goals.
Learn a new skill: another great way to leverage the 5 AM Club is to spend time learning new skills. Whether that's a new programming language, a new library or a tech stack, even dedicating an hour a day to learning something new that will help your career or personal life can take you very far and make you more valuable in your position.
Increase productivity and efficiency: as I had focused on my career, waking up before everyone else allowed me to get a jump start on my day. I would deliver project requests or feedback before anyone had even woken up. Code reviews were done before my colleagues were awake, and I could solve difficult bugs in solitude. Trust me; this makes project managers love having you on their team and makes you stand out as an overachiever.
Improve your health: you can also dedicate the early hours to improving your health. Coupled with intermittent fasting, you can get a head start on weight loss, exercise, planning meals or researching healthy alternatives. In my experience, it allows me to catch waves or run 10km without feeling the pressure of needing to be available on Slack.
Start a side hustle: software engineers have a tremendous competitive edge over many would-be entrepreneurs - they can build and execute websites or applications for free! This makes starting a side hustle easy enough if you have a great idea. The other problem is time, which the 5 AM Club solves. Consistency is key; dedicating an hour or two a day to your side hustle can pay huge benefits in the long run.

Breaking Old Habits

Perhaps the most challenging part of achieving "5 AM Club" status is breaking the habit of waking up late. This barrier to entry is difficult for most people, never mind tired software engineers who have been staring at a screen and debugging complex logic problems.

Recent studies show that it takes around 28 days to break a habit. Thus, if you're serious about breaking your sleep cycle, it's going to take nearly a month to get used to waking up at 5 AM. This wasn't all that hard, as South Africa has relatively mild seasons. Don't get me wrong; winter is still cold, so I would not advise you to begin forming this habit in the dark. Wait for summer to arrive and let the sun help you out. It's far easier to rise with the sun than without it.

Be patient with yourself, and begin with the 20/20/20 method. It's far easier to get used to than dedicating yourself to one direct benefit, as listed above.

Conclusion

The 5 AM Club has many benefits that can help software developers improve their health, advance their careers, balance their personal lives and help them achieve greatness. Breaking the habit of waking up late will be difficult, but you'll soon reap the benefits of this widespread practice.

The 5 AM Club is a way of gaining control in a chaotic and disruptive life for all of us. It's a philosophy and practice that can take you as far as you want. Buy the book, read it and start waking up early!

This blog post was initially published on dainemawer.com. If you liked this article, please follow me on Twitter at @daine_mawer.

4 Surprising Benefits of Intermittent Fasting for Software Engineers

Daine Mawer — Sun, 22 Jan 2023 20:04:25 +0000

Introduction

I spent the last few months of 2022 integrating intermittent fasting into my daily routine. Fasting has gained popularity over recent years as a way to improve health and well-being. In essence, it's a behavioural pattern that requires individuals to only eat for specific "windows" during the day. I've been experimenting with the 16/8 plan; this means I do not eat food for 16 hours a day and then eat pretty much what I want (within reason) for an 8-hour window, which finishes around 20:00.

Effectively, you land up cutting out breakfast and a morning snack. Intermittent fasting has been shown to have several benefits for the human body.

Software engineers, plagued by the stereotype of poor eating and collecting bad habits, can uncover some surprising benefits to health and lifestyle when incorporating fasting into their daily routine.

In this article, I'll run through four essential benefits of intermittent fasting and how they can add value to your life.

Increased Cognitive Function

The most significant benefit of intermittent fasting is improved cognitive function. When you fast, your body increases the production of a protein called Brain-Derived Neurotrophic Factor (BDNF), which is associated with improved memory and learning. As any software engineer will tell you, memory and learning come in handy when writing complex code. Software Engineers rely heavily on their mental sharpness and problem-solving skills to do their job and stay on top of their game. More than that, fasting has been shown to increase focus and concentration.

I'm an avid fan of Dr Andrew Huberman's Podcast, Huberman Labs. He has done a great episode on the Effects of Fasting & Time Restricted Eating on Fat Loss & Health if you want to discover more scientific details about intermittent fasting.

From my own experience, I feel like I've experienced improved mental capacity and function for months now. For the first week or so, you are distracted by the "hunger" feeling, but your body eventually adapts. When you feel that tinge of hunger, it's not always because you're hungry - generally, it's because you haven't had enough water, or it's habitual.

Better Time Management

Perhaps not a direct side effect of fasting, but a benefit nonetheless is the change in time you feel when you begin fasting. You'd be surprised by how much time you spend thinking about, planning and making food during the day. As fasting limits that window to 8 hours in 24 hours, what you eat and when you eat it is dramatically reduced to a small window - generally lunch and dinner.

After a few weeks of fasting - your cravings for unhealthy snacks disappear, and the amount of time you spend eating and planning snacks/meals reduces dramatically. I've always been a morning person, so I've found that fasting helps me keep my morning routines and rituals incredibly streamlined and focused.

When you re-focus the time you spend thinking about food, on food items that keep you full longer - nuts, avocado and Low GI items you can stay full longer, eat less, remain healthy and feel better.

Less Stress and Lighter Mood

A direct result of fasting is that your body produces less cortisol. Cortisol is a hormone that is generally associated with stress and anxiety. If your body is making less of it, you should naturally feel a reduction in both symptoms. As a double-whammy, your body simultaneously increases the production of endorphins (the happy hormone) which can lift your mood and make you feel happier.

Although I cheat to a degree with my fasting routine (I have black coffee with a bit of honey when I wake up) - I've also found that fasting has helped me curve my need to drink too much coffee every day. 4 cups of coffee, in terms of caffeine, mainly after noon is enough to heighten anyone stress/anxiety response. I'm down to 2 cups daily and don't drink coffee past 1 PM.

I've also found that my afternoon sugar crash has disappeared. I noticed this within the first few days of fasting. I have always struggled with the afternoon crash; feeling sluggish, tired, and lethargic was a reality around 4 PM every day. I now feel much better, and though I don't feel like I have "more" energy, I think it's sustained more these days.

Multiple Health Benefits

I'm not a medical professional, and I'm sure for everything I list here, there will be an argument against it, but some documented health benefits of controlled, intermittent fasting are:

Weight-loss

Reduced inflammation

Lower blood pressure

Improved cholesterol levels

The benefits will vary from person to person, and other than weight loss, I have yet to track the other 3 with any seriousness. I think these benefits are less about the fasting itself and more about the fact that you are simply consuming less "bad" food or food that your body can't use.

Conclusion

Intermittent fasting is a journey - you can decide whether it's the right fit for your lifestyle. Through my own experience, I've found it to provide considerable benefits to my routine, not only physically but mentally, as well as financially (buying less food, fewer snacks etc.).

Fasting has many potential benefits: reducing inflammation, lower stress levels, weight loss, and overall well-being. For software engineers who sit all day, focused and passionate about their work, fasting is a valuable practice to introduce into your day-to-day that doesn't require significant commitments or time to see actual, healthy results.

I'll stress again that I have no medical training and that you should consult your doctor before introducing intermittent fasting into your routine.

This blog post was initially published on dainemawer.com. If you liked this article, please follow me on Twitter at @daine_mawer.

How to Motivate and Inspire Individual Contributors

Daine Mawer — Thu, 19 Jan 2023 22:00:00 +0000

Introduction

Individual Contributors play an essential role within a development team and organisation. Engineering managers are in charge of leading and managing Individual Contributors to successful outcomes while ensuring workplace happiness. More importantly, as most engineering managers were once Individual Contributors, they are uniquely positioned to relate and empathise with the individuals working in their team.

As each contributor brings their personality to the table, engineering managers sometimes need to adjust their approach to motivate and inspire them when workload increases or pressures build up.

This article will explore five strategies engineering managers can leverage to inspire and motivate Individual Contributors.

Setting Clear Goals and Expectations

Individual Contributors must know what is expected of them. This helps people feel secure and gives them a purpose within the organisation. Once expectations are set, individual contributors can begin to understand their roles and determine how they can contribute to the entire team's success.

Using SMART goals: Specific, Measurable, Achievable, Relevant, and Time-bound can help guide Individual Contributors to deliver real value on time.

While project goals are important, personal goals are equally important. You must always be conscious as an engineering leader that individual contributors have ambitions to learn and master technologies that may or may not be related to the current stack they’re working on.

It's worthwhile setting yearly personal goals so that they feel like they are working towards progressing their career objectives, not just the company's business goals.

Providing Ongoing Feedback and Support

Continuous and positive feedback helps individual contributors thrive in their position.

Feedback can be given daily, weekly or monthly through several activities such as:

Async check-ins on Slack
1:1 Meetings
Quarterly Goal Realignments

Creating a solid rapport with Individual Contributors can help make this process smoother. Ongoing support can help Individual Contributors better understand their strengths and weaknesses and allow engineering managers to step into mentorship positions when and if needed.

The most important part of this process is keeping your word as a manager. Don’t commit to helping Individual Contributors meet their goals if six months go by and you haven’t spoken about it once. A level of trust and dependency should be held in the utmost regard. When things get tough, Engineering Managers must remain calm and guide Individual Contributors to the best possible outcomes.

Furthermore, sometimes Individual Contributors have bad days. Support, in this case, may have nothing to do with work and business goals. It may require you to show more empathy and understanding than usual.

Encouraging and Supporting Career Development

It should not be taken for granted that Individual Contributors’ have their own career goals. These goals may often not, or potentially never, align fully with the purposes of the company they work for. Engineering managers must respect that. Showing genuine interest in an individual's career development can naturally motivate them.

Company policies can go a long way to aiding engineering managers in such goals:

Professional Development budgets
Paid / Sponsored conferences and trips
Encouraging up-skilling in fields that benefit the individual and the company
Assigning them responsibility on projects that will help them develop their skills.

Whereas having conversations about career trajectories outside the current company may feel awkward and inappropriate, Individual Contributors will likely move on at some point in the future. Their position under your supervision will provide them with skills and experience that will encourage them later in life, so you should treat any Individual Contributor in a way that their tenure with you contributes positively to their career.

Recognising and Rewarding Contributions

Recognising and rewarding an individual's hard work can increase morale and motivation. Recognising is more important than rewarding. Public recognition in front of peers or non-technical stakeholders of the company can go a long way. It should be noted that recognition applies to more than just

great code:
great teamwork,
going above and beyond, and making a concerted effort to improve, can all be recognised in a meaningful way.

Hard work and that extra 10% should always be respectfully valued as it highlights Individual Contributors who are passionate about their roles and responsibilities.

Fostering a Positive and Inclusive Work Environment

Attempt to keep dialogues and hard conversations positive and inclusive. Transparent communication across teams and hierarchies can ensure individual contributors feel respected and included in everyday business and technical decisions. It brings team members closer together and breaks down cultural and personal barriers.

Encourage an environment of making mistakes that can be learned from and address team feedback as often as possible. Perhaps most importantly, if you, as an engineering manager, can establish a well-knit and robust community within your engineering team, it will encourage Individual Contributors to work hard and want to work.

These are the beginnings of great, grass-root company culture - something which is highly sort after in the tech industry and often separates good companies from great companies.

Conclusion

By ensuring Individual Contributors are inspired and motivated to come to work with a positive attitude and a willingness to work hard, the entire business can experience successful delivery of value. Setting SMART business and personal goals for Individual Contributors can help them navigate what's expected of them. Providing ongoing feedback and support can help them feel secure and that someone is on their side if they encounter a challenge.

Furthermore, creating a positive work environment and celebrating success can help Individual Contributors feel recognised and valued.

This blog post was originally published on dainemawer.com. If you liked this article, please follow me on Twitter at @daine_mawer.

5 Qualities That Make You A Hireable Senior Engineer

Daine Mawer — Thu, 13 May 2021 05:58:22 +0000

As we grow in such a fast-paced industry like technology, we often lose sight of what it takes to get hired. That statement is both true and false. Some of us find ourselves spending long tenures of time at specific companies while the rest of us jump ship rather frequently in order to find greener pastures.

Through countless hours of learning, failing, and succeeding we eventually reach a point where we are autonomous enough to proactively solve our own challenges. Be that engineering features, tackling a backlog of bugs successfully, or aiding more junior members of the team. These are some of the key points that differentiate less experienced engineers from those who are more experienced.

However, what does it really boil down to when we label an engineer as "senior"? What should companies be looking for when they advertise the position? And, what qualities should you display in order to grab the attention of recruiters and/or HR departments?

Here are 5 qualities of senior engineers that I look for and more importantly, rely on:

1. Arrive at a problem, with a solution.

One of the biggest red flags I see amongst teammates is when an engineer does not come to the party with solutions to a problem. Regardless of whether the solution is correct or the best possible solution for that problem. It's the mindset of providing a solution when faced with a problem that becomes an outstanding quality in a teammate.

Coming up with your own solutions means that you've given thought to the challenge, in a constructive and pro-active manner. Rather than admitting defeat straight away and declaring "I don't know".

I can almost guarantee you that the majority of your peers probably have either come across the situation you face or know someone who does, so they're not stressed about the fact that you didn't arrive at the expected outcome, you just showed a willingness to and that's what counts.

2. You acknowledge your imposter syndrome.

Everyone has imposter syndrome, everyone. It just occurs at relative degrees. When someone new to web development faces a difficult learning curve they think to themselves: "I will never understand this". It's the same thought and gravity as that of a more experienced engineer thinking: "I have no idea how to write this function in the most performant way possible" or "I have no idea how to ensure that this code runs asynchronously".

In my opinion, the voice inside your head that tells you you can't do something needs to be countered by a voice outside your head that tells you, you can. That voice can be from a mentor or member of a community that you respect. The most important part of dealing with imposter syndrome is acknowledging the fact that you and I both have it and it's okay because it helps push us to do things we don't think we can do.

3. You dive into the unknown.

Perhaps one of the most daring parts of being a senior or lead in a tech company is taking ownership and responsibility for code features that you have very little experience with.

It can be a real struggle, and there will be times when you feel completely hopeless and paralyzed with confusion. There is always light at the end of the tunnel and there will always be someone who has either been through the same thing or knows how to implement what you're working on.

It's important to carry on leading in a situation like this.

Saying: "I don't know how to do this...", followed by: "I'm going to time-box it to 2 hours and see where I land up" or "We should bring in person x to help provide clarity" ensures transparency when it comes to dealing with the situation.

4. You don't know everything and admit it.

I haven't spoken much about technical skill here as that can be learnt with repetition and motivation. If you dedicate yourself to learning a new concept or language you will eventually overcome the learning curve and beat it.

Far too often, companies "go fishing" and look to hire engineers that appear to know almost every computer language available today. No one actually wants to hire that "unicorn".

Good leaders hire those that can apply their knowledge and skills to challenges. You don't have to know everything about Webpack or Node, or React. Working knowledge is important, and you cannot do your job without it, but every discipline will present a challenge you have no idea how to solve and if you can admit that you are far closer to overcoming it.

Furthermore, if you never admit that you don't know how to do something, it burns resources, time and patience. 3 things that are very precious.

5. You give out and can take criticism.

One of the quickest ways to grow is being able to consume criticism. Be that good or bad. When people identify your shortcomings in a way that allows you to grow and not feel like you've failed, it presents you with an opportunity to better yourself alongside your peers. Sometimes it's really hard to hear, but if you can take it in your stride you will see tremendous amounts of respect headed your way.

That being said, the way you give out criticism is also really important. No one likes to feel criticised, and the way you handle constructive criticism in code reviews or retrospectives with peers and junior members of the team really shows your worth as a contributing member and leader.

Today, for just a moment, grab a coffee and think about these 5 points in your career journey. If you place focus on them you will undoubtedly see that your position in a team starts to mould and change, for the better.