DEV Community: InsideOut

Supercharge your CSS with Tailwind

Adam Smith — Mon, 04 Apr 2022 13:40:30 +0000

Supercharge your CSS with Tailwind

Not often in the web development industry do we find tools that truly lead to a paradigm shift for our ways of working. Perhaps you've discovered this when adopting a new language; a few aha moments later and the purported benefits make sense. Some JavaScript developers have discovered this with TypeScript, for instance. There's a learning curve, but the benefits are suddenly all the more real upon a visit to an older JS-based codebase. The new way of working feels like home

Today, I'd like to discuss CSS. Innovations with stylesheets in recent years have focused on tooling and compilation, somewhat independently from innovations in other areas of the stack. Whereas most of us no longer write HTML, many do still write CSS. I'd like to cover the reasons why writing your own CSS is unproductive, and champion an alternative approach to styling.

Tailwind is a styling framework which provides bitesize classes which allow you to style your HTML entities without having to maintain a separate stylesheet. In this article, I'll discuss how the functional CSS ideology can improve productivity and consolidate the styling approach across a front-end team.

CSS

CSS has been around for a while. With applications nowadays like React Native and Electron, its once-limited reach now stretches far. No matter where we look, we can safely say that Cascading Style Sheets is widely adopted.

The problem with vanilla CSS, I'll argue, is that it is deceptively simple. It attempts to do too many things. The syntax is undeniably flexible and the way one experienced developer forges their CSS may look almost alien to another experienced developer. You may be able to relate to this on a more personal level if you've had to dig through your own CSS in the past and wondered "just what was I doing there?".

Writing your own CSS inherently has many disadvantages, which in general reduce productivity due to repetition and/or a reduction in intelligibility:

Writing your own class names - takes lots of time and many selectors will never be reused
Trying to match/replicate the structure of your components in styling code - the source of truth should be your components, not your styling
Vendor prefixes - a cat-and-mouse game of keeping up with browser engines, polluting your codebase at the same time
Hacks to get ordinary bits of CSS to work - many hacks are required (especially for Safari)
Mobile breakpoints - pollutes your codebase with media queries at many different breakpoints
Specificity and !important - having to order your styling in a certain way, and just one !important breaks the cascade
Value repetition - lack of native support for variables

Existing approaches

Over the past twenty years, a number of approaches have been developed to both better organise your CSS and also process styling in a different way. Let's examine the compilation of CSS and a common naming convention (BEM).

Pre-processors

Between ten and fifteen years ago, the advent of CSS pre-processors like Sass, Less and Stylus was revolutionary. You could write your styles in a composited way, saving much repetition and scope for error. You could also have variables in CSS, for the first time.

In the simple case, you could transform this kind of CSS:

nav {
  background-color: lightgray;
}

nav li {
  padding: 2px 5px;
}

nav li a {
  color: lightblue;
}

Into this:

nav {
  background-color: lightgray;

  li {
    padding: 2px 5px;

    a {
      color: lightblue;
    }
  }
}

This compositional format shows the relationship between the selectors more naturally, like you'd see child components returned from a parent component in React.

With the pre-processors, you can shrink your CSS and increase reuse through variables. In almost all working cases, it will be an improvement above vanilla CSS. There are also implementations now, via PostCSS, that add vendor prefixes for you. The major drawback is, of course, that you have to compile your CSS beforehand; usually done via part of your tooling such as Grunt or Gulp.

And also, your implementation would still suffer from many of the aforementioned core disadvantages of writing your own CSS, such as writing class names, replicating your structure, hacks and mobile breakpoints.

BEM

Block Element Modifier is a common naming convention which subscribes to the idea that all CSS rules should be divided into blocks, sub-blocks (called elements) and variants (called modifiers). For simple applications, BEM can work rather well when you get used to its philosophy and the class names.

This is an example of a modifier rule name:

.nav__link--selected

Which looks interesting, if you've never seen that syntax before. Quickly, however, you'll find that the names get quite long:

.legal-cookie-banner__accept-or-reject-button--disabled

You'll naturally come to points where:

An element should be split out to become a block
Some elements naturally have their own elements
Some modifiers might naturally have sub modifiers

And so on. There are actually a plethora of different approaches with BEM. It's arguably more a way of thinking than a watertight specification. Atomic BEM (ABEM) is one, for instance. The issues boil down to:

Names generally become long and unwiedly
The structure of your HTML is very strongly replicated, making it difficult to change and refactor
Developer rules and approaches to block-element-element-modifier tend to vary a lot
Nesting BEM in SASS/Less/Stylus can drastically reduce replication of block/element names but reduce intelligibility

BEM is a fairly old-school approach nowadays, though still common. It still doesn't address many of the core issues of writing your own CSS, and is essentially just a naming convention.

Tailwind

Tailwind is a framework that provides many small bits of CSS which are put together like lego. This approach is referred to as functional CSS. Instead of writing your own classnames, you are provided with pre-made classes which you can use in your HTML in combination to quickly achieve styling.

The beauty of the system is that you can mix and match prefixes, which make it easy and standardised to add states like hover, active or focus, mobile styling and the pseudo-selectors before and after.

Rather than providing off-the-shelf components like Bootstrap and Semantic UI, Tailwind merely provides the small building blocks to assist in building your own components. Much like Normalize.css, Tailwind strips out the default styling browsers apply to all elements, such as buttons, input fields and more.

Let's dive into the major concepts of the framework.

Piecemeal

The core concept of Tailwind is the provision of utility classes, which are really like blocks of lego. Here is an example of a simple link with an underline:

<a href="#" class="text-underline">Click me</a>

This uses the text- utility prefix. Remember that Tailwind strips out all default browser styling, so links by default will not have an underline or any colour. The text- utility prefix here groups together related CSS rules. Let's see another one in action by adding a blue colour to the link:

<a href="#" class="text-underline text-blue-500">Click me</a>

We can add colours to most utility prefixes, such as text, bg, border and more. Tailwind supports a number of out-of-the-box colour names, and shades, from 100-900. Let's also add some padding:

<a href="#" class="text-underline text-red-500 px-5 py-2">Click me</a>

The prefix for padding is simply p- and the value represents fractions of a rem, e.g. p-1 represents 0.25rem of padding on all sides, equivalent to if you'd written padding: 0.25rem; in vanilla CSS. Most importantly, you can also use:

px to indicate padding in the x-dimension (e.g. top and bottom in CSS terms)
py to indicate padding in the y-dimension (e.g. left and right in CSS terms)
pt, pr, pb and pl to indicate padding in the top, right, bottom and left directions

And, you are not just restricted to using Tailwind's rem fractions, you can also use:

-px to add one pixel to the dimension you want, e.g. py-px to add one pixel of padding to both the top and bottom
Square brackets, e.g. p-[5px] to break out of Tailwind's design system, for those pixel perfect changes (JIT mode only)

Finally, let's add a border to match the colour:

<a href="#" class="text-underline text-red-500 px-5 py-2 border border-current">Click me</a>

The -current suffix is quite useful in Tailwind, and instructs the system here to use the same colour as the text for the border. We can also add rounded corners:

<a href="#" class="text-underline text-red-500 px-5 py-2 border border-current rounded">Click me</a>

And if we wanted to make the border corners very rounded, like a pill, we can use one of Tailwind's stock size classes, which are xs, sm, md (default), lg, xl, 2xl:

<a href="#" class="text-underline text-red-500 px-5 py-2 border border-current rounded-xl">Click me</a>

These stock sizes also work on text sizes as mobile prefixes, as we will see next. And that's a very simple example of how the utility classes work.

Mobile styling

You could think of base classes being mobile-first. Write your styling representing the smallest screen size, and add Tailwind's stock size classes as prefixes to change the styling at particular breakpoints. For example, if we wanted to have the default text size for a paragraph of text to be text-xs , but we wanted to bump up the font size to be text-sm on tablets and larger displays, we can simply write it as follows:

<p class="text-xs lg:text-sm">
  Some lovely text.
</p>

Here, lg represents a breakpoint for all screen sizes that are at least "large" size, which by default is 1024px. If we then wanted to make the text even bigger on huge displays (1536px and higher), we can use:

<p class="text-xs lg:text-sm 2xl:text-md">
  Some lovely text.
</p>

Here, we don't have to worry about polluting our codebase with media queries. We can just quickly indicate when a particular property should change depdending on the screen size, using the same familiar stock sizes we use for text size, border radius and more.

Customisability

Not only does Tailwind provide a wealth of off-the-shelf utility classes, the framework allows us to modify the default assumptions it makes for properties such as colours and sizes. For instance, you could create an xxs size for text, or a 4xl responsive breakpoint, if you wanted to.

Tailwind implementations usually have a tailwind.config.js file associated, which allows you to either replace whole properties of a class family (e.g. bg for backgrounds), or extend them. Importantly, you don't have to write out or deal with lots of boilerplate code just to change one tiny thing.

One of the most recent additions to Tailwind was "just in time" mode. This allows the PostCSS compiler to "tree shake" the implementation by inspecting the exact classes that are used in your document, drastically reducing compilation time. It also allows you to break out of Tailwind's design system, using square brackets, which you may have noticed earlier. This allows further - pixel-perfect - customisation in a way that is declarative and dependable.

Adoption

Here at InsideOut, we've found that Tailwind has improved our speed of prototyping and development. We can now quickly produce front-end screens without having to worry about maintaining an unweidly companion stylesheet that doesn't align to our components. Our React components are the source of truth for the shape of the end solution, and Tailwind prevents us from "recreating" any of that shape in styling, promoting component reuse, not classname reuse.

Despite Tailwind's wealth of utility classes, there have been rare occasions where we have had to create a few of our own custom classnames. In our base css, for instance, we had to create one at the start to define a custom height for our pages that takes into account the height of our nav bar. We also have another one to make a nice-looking link. For our production-ready internal dashboard, this is the totality of our custom SCSS so far:

.custom-h-full {
    height: calc(100% - 3rem);
}

.custom-explicit-link {
    @apply underline;
    @apply text-blue-500;

    &:hover {
        @apply text-blue-600;
    }
}

And that's it. We adopted a convention of using the prefix custom- to make it obvious when reading the classnames on a component that there's a bit of styling that is ours in there.

The other convention we found useful quite quickly, in the context of our React components, was grouping Tailwind's utilities into related classes, as shown below:

        <div
            className={`
                absolute top-0 left-0
                flex items-center justify-center
                rounded
                w-full
                h-full
                bg-yellow-100
                opacity-90
            `}
        />

Here, we can see that on different lines we've grouped:

Positioning
Display (and flex properties)
Borders/rounding
Width
Height
Background
Opacity

If we wanted to add a border here, it would be placed neatly on the third line. This makes it clearer to read than this:

<div className="absolute top-0 left-0 flex items-center justify-center rounded w-full h-full bg-yellow-100 opacity-90" />

When it's hard to know what's going on. Especially if a future developer comes in and adds more classes at the end.

Final thoughts

Obviously, Tailwind doesn't aim to translate CSS rules into classes directly, because that would be quite verbose, and wouldn't solve some of the core issues in CSS I outlined at the start of this article, like mobile styling. Tailwind also doesn't aim to solve everything with providing off-the-shelf components. It merely provides a shorthand way to quickly style your components without having to remake the component structure every time in CSS code.

One of the main hurdles here at CSS was learning the Tailwind lingo. A lot of the utility classes provided are remarkably simple and intuitive, such as p for padding, m for margin, bg for background, and so on. There are occasions where the naming is slightly different, e.g. align-items: center becomes items-center. But these have not been a big issue at all. The naming feels faithful to the original paradigms in CSS, which made learning Tailwind fairly straightforward. It differs, of course, from other approaches like Semantic UI where the classes read like an english sentence, but feel farther away from actual CSS.

At times the team has felt as if Tailwind is still very much a work in progress. Support for JIT was added in version 2.0, and we adopted it during that major release cycle, with a variant of Tailwind which was compatible with our version of Create React App. JIT required PostCSS 8.0, which CRA has only begun supporting recently. As such, beforehand, there were some extra hoops for integration. We've tried to upgrade to version 3.0 recently but had to roll back due to some impassable webpack issues.

Overall, we do feel that Tailwind has made a positive impact on our front-end development, and will continue to use it for future projects. We're confident that it's a production-ready framework, and are glad to say that it's made responsive development a breeze. We don't have to care any more about specificity, media queries, writing our own class names or browser hacks. The barrier to entry has been fairly low and the productivity boost has been quite high. Tailwind has been a boon to our development stack, and we're looking forward to developing with it in our next project.

Assessment of E2E testing a mobile app with Appium

Michael Paulsen-Forster — Mon, 04 Apr 2022 11:55:10 +0000

What is End to End Testing?

End-to-end (E2E) testing is a technique that tests the entire software product, as well as all of its systems
(Katalon, 2019).

End to end testing is vital to mobile app and software development, as it allows the software to be tested in a simulated, real life scenario (Software Testing Help, 2022).

The main purpose of E2E testing to test the application from the outside, just like a user would, without knowing anything about the internal functions of the software. This makes E2E tests a form of black box testing.

Another feature of E2E testing is that it tests lots of different parts of the system to make sure that they are all working together once connected, this is known as integration testing.

Why E2E Testing?

E2E tests assess the whole system and the software in its entirety, examining multiple subsystems together, all with one single test. For example, an E2E test would examine the user interface, interaction, navigation and API (unless mocked) and it will act as an integration test.

As well as offering an examination of the full system, E2E tests are the most effective way of testing how a user will use an application, without requiring a real life user. High-priority user flows, such as signing up or creating a booking, have to be repeatedly scrutinised, in order for the application to work correctly. This can be time consuming and repetitive. However, with the use of an E2E test, the flow can be simulated and interacted with in the same way that a user would, whilst verifying that all parts and subsystems within that flow are working as they should.

E2E testing is a great way to establish that your application is working, without having to put in the time to manually test.

E2E Testing Setbacks

Although E2E tests will test many subsystems in one test, it will not fully test these subsystems, only the parts used in the test. It’s also possible for the same test or user flow to fail for a scenario.

It can be very hard to tell what the problem is when a test fails, as the error could be in any part of the whole system being tested.

It’s hard to cover edge cases in E2E tests as this will take a lot of time to run the test and possibly restarting or reinstalling the app. E2E tests can also be unreliable, with the setup often being difficult and time-consuming

These tests are bound by the app limitations, the same as a user. This includes waiting on the loading screens, having to login before testing, using the API and only seeing onboarding screens once. Whilst there are a number of setbacks with E2E testing, the benefits do outweigh the setbacks, and the opportunities for E2E tests are impressive.

What can we do with E2E tests?

Although many E2E tests will consist of simple instructions, there are many interactions with the app and device that can be simulated through E2E tests.

A simple test will usually consist of:

Pressing a button
Typing text into a text box
Waiting for a new element or screen to be shown

However, with the use of other tools, more specific and more complex tests can be run. For inspecting elements, you can read text, element size, css style and tell if an element is visible on the device's screen.

For touch interactions, you can tap, double tap, type, pinch, scroll and flick.

For finding elements, you can look for a group or list of elements, this means you can iterate through every element in a list and set the test to interact with all of them.

Using Appium lets you write these tests in your chosen programming language. This also lets you combine these tests with if statements and loops, making it possible to have more complex tests that can handle different situations.

Device interactions are also possible. It’s possible to set the internet speed to test specific flows and features with a slow internet speed. You can also toggle airplane mode to see how your app performs when offline.

Other device interaction you can use include simulating shaking the device, locking / unlocking the device and accessing clipboard. You can also add and delete files.

The scope of the E2E test is almost without restriction, as long as you know how to code it!

What is Appium?

Appium's philosophy documentation summarises what Appium is pretty well:

Appium is at its heart a web server that exposes a REST API.
It receives connections from a client, listens for commands, executes those commands on a mobile device, and responds with an HTTP response representing the result of the command execution.
The fact that we have a client/server architecture opens up a lot of possibilities: we can write our test code in any language that has a http client API.

Limitations of E2E testing

One limitation is that to easily interact with any UI element in your app, a prop must be given to the view, most used is the "accessibilityLabel" prop, in which every element should have a unique ID.

Your tests are bound by the same rules as a user is. This includes having to log into the app before being able to access other screens, some screens not being viewable for certain types of users and only being able to view onboarding screens once. There are ways to get around this, by re-installing the app or by logging in with a different account.

E2E tests take a long time to execute, compared with other types of tests and they are hard to setup and can be very flaky.

It's hard to find what causes an error when a test fails. And lastly, time is needed for the maintenance of these tests, as the app changes. This requires a developer who is both familiar with the app and the E2E tests.

Future Work

One of the best features of E2E tests is that they can be run as part of your CD/CI pipeline, in the cloud, using a cloud device service, of which there are many options.

This lets you have these E2E tests executed every time you want to merge a branch or after running a build to give you much higher confidence when merging or releasing a build.

Whilst E2e testing has many benefits, the ideal testing solution includes a full test suite of unit, integration and regression tests combined with dependency injection. This is the only way that you can have full confidence in your tests.

We trialled a 6-week project cycle and here's what happened

Maximilian — Wed, 09 Mar 2022 09:31:02 +0000

At InsideOut we've been managing our workload in a Scrum-based environment where we have 2-week long sprints and 4-sprint long iterations, but we recently switched to a project-based workflow and we've found several benefits.

The old way: Scrum-diddly-umptious

Each developer has a pre-set number of tickets that they aim to complete by the end of each sprint. Each ticket has a number of points that indicates its complexity, not time required to complete. The theory here being that if each ticket were scored by time taken, this would change per developer, whereas a complexity score is immutable. If a non-urgent issue or bug pops up, we add a ticket to the 'backlog' which will be picked up in a future sprint. Equally, tickets that contribute to a larger project (like a new app feature, or a new app entirely) will be written up and added to the backlog. These tickets may be prioritised if the project has a deadline.

Sprint iterations are a collection of 4 sprints so we can assess our longer-term productivity, but also plan and work on longer-term projects. All sprints are managed via a Kanban board.

Ok, so what's the problem?

There wasn't anything inherently wrong with this approach. It worked for us in that we were getting a lot of work done, and the methodology was agile in as much as we were only ever a maximum of 2 weeks away from working on something new. For the wider business, this meant that if a non-critical bug was spotted, or if there was a small feature request that was provably important, we could work it into our next sprint.

There were, however, 4 main problems with this approach.

1. Bigger projects took longer.
Our sprints always comprised of several types of tickets ranging from support, bug fixes and data reports, alongside tickets that contributed to larger projects. This inherently meant we were unable to focus on any single project and our time and attention was always split.

2. Requests came in thick and fast.
Because we were only ever a short amount of time away from new tickets, the wider business was more than happy to add to our workload regularly. For every request that came in, we would have to assess a solution and potentially add a ticket to our backlog, thus splitting our attention even further. Also, if you've ever written up tickets, you'll know that to do it properly requires some thought and time. Hence, we would often end up doing 'quick things' there and then which ended up being unaccounted for and distracted us further still.

3. Meetings.
On top of our daily stand-ups, we had sprint planning meetings every Friday. This involved going through our backlog of tickets and work out what needed to be prioritised in the next sprint. It also involved discussing and pointing each and every ticket. We tried to keep these meetings down to an hour, but they naturally always overran and sometimes even took up a whole morning.

4. Under appreciation 🎻😭
As is often the case, the wider business doesn't see all the work we do. This is inevitable. But with this Scrum approach, our work felt even more obfuscated as the smaller, more technical things were being done but not necessarily understood, and the larger, more visible things appeared to take far longer than they 'should'.

The new way

We have trialed, and intend to continue using an 8-week work cycle that's comprised of a 6-week project and a 2-week 'wash up' period.

Project cycle

A select few members (the best suited to the project) will be put on The Project Team. It is up to The Project Team to start and finish a project within 6 weeks. This means that by the Friday of Week 6, the project has been released to production and is in the customers' hands. The project can be anything from an internal product (the most recent being a new dashboard built in React) or a new feature for our mobile app that will be released as part of our regular app-store updates for our clients to use.

The rest of the engineering team during this period will support the wider business with support requests and bug fixes etc - i.e. smaller tasks that do not belong to a larger project but still have to get done.

Wash Up cycle

The 2 week Wash Up period is where we debrief the project and look for ways to improve the next project cycle. We can also use the time to add things that may have been missed in the project cycle, whether because they were out of scope or we ran out of time and they didn't affect the core functionality of the product. These 2 weeks are also used as Kaizen time, as well as planning the next project. It's important the projects are planned properly as the condition of any project is that it gets delivered in 6 weeks. This means that we need to properly assess ths scope of each project and ensure that the Project Team is not overstretched or, indeed, slacking ;)

How does a project get chosen?

In the 2-week Wash Up period, any engineer can advocate for a new project. They don't necessarily have to take the lead on a project they advocate for, but it's often the case that they do. It means that the developers are actively encouraged to look for areas of the business that can be improved, but also advocate for things they may want to work on. Projects also get put forward by other areas of the business where they spot areas that need improvement in their department. Ultimately, the projects get given the green light by the CTO and CEO.

Disadvantages

I'll get the downsides of this approach out of the way first, as I'm a big fan of this new approach and I'm honestly struggling to find many downsides.

1. Less agile.

It takes longer for requests and business support issues to get done as we are now dealing with an 8-week block of time, instead of 2. However, there are still engineers on hand to deal with these requests, so it's not like nothing can be done in these 8-weeks.

2. Not everyone has a project!

It is the case that developers not on a project, arguably, have less fulfilling work to complete as they're working through tickets just like before. Having said that, people might prefer grinding through tickets and might hate projects, so it's all swings and roundabouts!

3. Smaller things may get skipped... maybe.

I can foresee a situation where smaller issues do not get resolved if they're not important enough. The wider business might find this methodology more frustrating than the old way of working, however, it's actually good that developers aren't wasting their time on things that are not urgent. Smaller issues are likely to get resolved in a project cycle where an entirely new feature or product gets built that's better than any fix that could have been applied during a sprint thus, in the long run, the business is far better off even if it has to suffer minor niggles for slightly longer.

Advantages

Let's do this...

Speed. Big projects are completed and delivered quickly. Projects of the size we're able to complete within a 6-week project cycle used to take us at least 12.
Higher standards. Developers are able to work on the project intensely and properly without distractions. This has resulted in better code quality and better infrastructure design.
Planning. The wider business knows that they will have a product in 6 weeks. This makes their scheduling and planning far easier and more efficient. It also means they don't have to continuously ask the engineering team about updated delivery times.
Visibility and appreciation. The wider business can see the results of the developers' work. We deliver features and products that the wider business can see and use every 8 weeks, without fail. This has made the engineers feel more appreciated and look more accomplished.
Fewer meetings. We don't need to sprint plan every Friday. We don't need to micro-manage and change things around to suit the latest requests that come in during each sprint cycle. This means more time for development and actual work!
Fewer requests. Because the wider business knows what we're doing and how long it will take, we don't get inundated with requests. We are left to work on our project. This, of course, leads to less distraction and a better result.
Responsibility. Not everyone wants to be a manager or run a team, but if you do or you'd like to try it, being a lead on a project is a perfect way to get your feet wet. As a Project Owner, you will have the responsibility for ensuring the scope of the project is achievable and, more importantly, that the project gets delivered on time.
No micro-management. Because each project is run by a Project Owner, the project gets run in any way the Owner sees fit. This means you get exposed to different ways of working when you're not an owner, and you can trial and experiment with different ways of working when you are. On top of this, it also allows for each member of the team to work the way they like. The best way we've found so far, is for the overall 'to-do list' and timeline to be visible to the whole team, but a person's individual tasks to be managed in any way that person sees fit. This means you're not stuck working in a way that someone else's brain works, you can choose your own tooling and methodology - something that I find efficient, educational and rewarding.
Education. As a Project Owner, you could put yourself on areas you want to progress in. For example, if you're mainly a backend engineer but want to do more front end work, put yourself on the front end and elect another backend dev to work with you! So long as the project gets delivered and to a high standard, this is an excellent way of learning on the job and improving your abilities.

Summary

To sum up, with this new way of working, the engineering team are getting through bigger projects more quickly, more efficiently and to a higher standard. Less time is being spent on the minutiae of day-to-day business and the wider team has a better understanding of what the developers are up to, and a better appreciation for what the developers do.

This is a way of working that we certainly intend to continue with. We and the business are really happy with the results and, as a developer, it's more rewarding and more fun!

Kaizen: Little and Often

Maximilian — Tue, 08 Mar 2022 08:55:35 +0000

Introduction

I'm going to explain what Kaizen sessions are and how and why engineering teams have them. I'm then going to explain how and why the InsideOut Engineering Team incorporates Kaizen sessions and the Kaizen philosophy in a more unconventional manner.

What are Kaizen Sessions?

Kaizen Sessions are an opportunity for members of the engineering team to use a portion of their working day for self improvement. You may have heard of these sessions also be referred to as 'self-learning', 'self-study', 'self-improvement', 'innovation-time' etc. but the reason we at InsideOut use the term 'Kaizen', is because of the philosophy behind it that we try to adopt.

The term 'Kaizen' is a Japanese business term meaning 'change for the better', or 'continuous improvement'. There are a few different implementations of Kaizen, but for the sake of this blog post, I'd like to touch on the 5 core elements of the Kaizen approach:

Teamwork
Personal Discipline
Improved Morale
Quality Circles (groups specifically brought together to identify potential improvements)
Suggestions for Improvement

By keeping these 5 principals at the heart of an engineering team, one creates a culture not only of self-development, but co-operative development. That is to say, everyone feels supported and motivated to better themselves and each other.

Why have Kaizen sessions?

We all know how quickly technology moves and having the time to keep up with the latest tech is a big challenge. As such, it's common practice for tech companies to afford a given amount of time to members of their engineering team for 'self-learning'. This is both beneficial for the employee as it keeps their skills sharp and their knowledge up to date, ultimately, making them more valuable in their own careers, but also to the employer who, in turn, will have sharper engineers at their disposal, as well as engineers who feel valued by the company.

InsideOut vs. The World

The amount of time given to engineers for self-learning varies from company to company, but the most common schedules I've come across are one afternoon a month, one day a month, one day a quarter and one afternoon a quarter.

At InsideOut, however, we've upped this to one afternoon a week and it makes everyone happier, more collaborative (somewhat more competitive) and, importantly, more productive.

Let me explain...

We tried once a quarter and we tried once a month and they were both fine. Everyone looked forward to tackling their own projects and felt grateful for having the time to learn.

But...

Sessions spread out this far apart presented some glaringly obvious problems which, I would argue, made them next to pointless! In no particular order:

Frustration: We'd be left wanting to have learned more in the allotted time, and had to wait another month (or 3!) for our next learning opportunity.
Fatigue: We tried to cram as much as possible into a relatively short amount of time, meaning energy and productivity levels were noticeably down for the following day (and sometimes for the rest of the week).
Retention: It was difficult for us to retain what we'd learned due to the gap between learning sessions. It's far better to learn 'little and often'.
A lack of desire to learn something directly associated with current company-work. After-all, we all have things we want to learn and projects we want to work on that aren't necessarily associated with work!
An unfair 'urgent' work distribution. So, if something urgent came up that required an engineer, it's pretty unfair for that engineer to lose (potentially) a quarter of their yearly learning time to fix something.
A lack of desire to teach someone else something. Even though we wanted to, we were conscious that knowledge-sharing took up a large chunk of our self-learning time.

At InsideOut we feel like we've solved all of these problems and in doing so, found further benefits. In summary, we participate in weekly Kaizen sessions that start at 14:00 and span the rest of the day. At 14:00, the engineering team joins a video call and our aim is to spend about 60 minutes knowledge sharing where our target is for every person to bring something to the table - even if it's a question that they know another engineer has the expertise to answer and teach everyone. Afterwards, everyone goes away and progresses with their self-learning for the rest of the day.

The benefits we've noticed to this approach, amongst others, are:

Creates a culture of continuous learning and development (self-improvement).
Creates a culture of teaching and progressing the people around you.
Creates a culture of business improvements.
Gives each engineer the time to pursue a proper educational path, with better knowledge retention due to a 'little and often' learning approach.
Engineers are happy to jump on bits of work during Kaizen, should they need to.
Engineers are happy to prioritise a deadline they may have over their self-learning.
Engineers are much more likely to further their knowledge in areas directly beneficial to their work, with some choosing to alternate week-by-week between personal projects and work-related learning.
Engineers are happier in general and feel more appreciated and cared for.
Having one afternoon that's almost guaranteed to be slower-paced makes the team more productive and feel more rested for the rest of the week.

In other words:

The InsideOut engineering team are happier, healthier, more productive and more collaborative!

Conclusion

By having regular sessions like this, a culture of self-improvement, self-discipline and improving and helping others is almost guaranteed. We trialled it with a view to monitoring our output and seeing if our work got affected, and if so, by how much. The results were that our output measurably improved week-on-week, and moreover, everyone felt encouraged and supported to get better which made everyone happier and more achieved in their personal growth.

I'd highly recommend this approach for all engineering teams, not least because I consider it a win for both parties in a professional capacity, but because it's a huge win in a personal one. On paper, of course, the engineering team gets 1 afternoon 'off' a week, but we all know that what's on paper can often be a far cry away from reality.

Maximilian Coghlan
Full Stack Software Engineer at InsideOut