I start all my 1on1s with a "traffic light check-in": Both me and the team member rate our current mental state and stress level:
Only after both parties have checked-in, we can decide to drill deeper on causes for anything that's not green or decide to let it be and focus on the other points on our agenda.
If you notice that team members are stressed, and the next 1on1 is too far away, immediately reach out to them directly. First, dig deeper into the issue at hand. Listen closely (or read in async environment) to their problems, don't go immediately into problem-solving mode.
In case of stress sources outside the work environment (e.g. personal crises), remind them that work can wait and offer a health day.
If the source is part of a work project, you can slowly enter in problem-solving mode. I find it most helpful to first "ease the pain" by helping to renegotiate scopes, finding help or delegating tasks away from them. It's crucial to follow this up with a learning, though. Use the next 1on1 to drill deeper on how to avoid these stressful situations in the future. Maybe there's a communication or planning problem, maybe a training or better reviews are needed.
The final aspect to decrease stress levels in your team (and company) is destigmatizing it. Admit when you're stressed openly. Explain simply what you're going to do about it (taking a day, saying no, ...). Model the behavior you'd expect from your team. Admitting to stress can be perceived as a sign of weakness. If you don't clearly take a stand that it is not, your team won't learn from it.
]]>In a cross-functional initiative, we've teamed up with other client teams (Android, iOS), the product team and the support team to identify the most important workflows in our products. Workflows that should never break to ensure a baseline user experience. They range from login and signup, to paid upgrades and basic app functionality like creating tasks or posting threads. Defining these workflows in a cross-functional manner has helped to take the whole picture into account and zoom-out from frontend-only concerns.
After having identified a set of core workflows, it's important to make sure they never break. For this, we run the test suite on every PR. No change is allowed to break a test, and the team gains maximum confidence that their changes are relatively safe to apply.
It's in the nature of end-to-end tests to be flaky (with Cypress less so, but it can still happen). Sometimes they're working reliably, and occasionally, you get a test failure. It's important to be very vigilant about each flaky test. A test failure should be treated similar to breaking production. Drop what you're doing, look at it and fix it. At least that would be the ideal way. The day-to-day of engineers looks different: in most instances you'll re-run the test suite, everything passes, and you forget it ever happened (you have more important stuff to deal with anyway). This is a slippery slope to go down.
One of the worst things you can do is start merging changes, although the test suite failed. At that moment, you might brush it off as "it's just this flaky test, totally unrelated to my changes" – but what you're really doing is opening the door to merging PRs with failed status checks and undermining the trust in your test suite. If you're low on time and notice flaky tests hampering the shipping frequency of your team, comment the test out. It sounds radical, after all you're loosing a test and, hence, confidence in the correctness of your changes. On the other hand, how much confidence did a flaky test really provide? Log the broken test somewhere and try to fix it as soon as time allows. This way you'll never get into the habit of merging PRs with failed status checks.
]]>We're building layout primitives and other components of our design system in Storybook. With that approach, we can constantly iterate on them and share them easily. Building components in isolation is a game changer for building truly reusable bits of UI, as you think about their API first and are not constrained to a single use case as during feature development. Iterating on your components is important. Be it based on feedback from your design team or feedback from developers using them or in the worst case from users discovering bugs. You likely won't be able to hit the perfect implementation on your first try.
An often overlooked system to increase visibility and adoption of your design system is to deploy it. Even if it's not public, it should be accessible to everyone in your organization. With Storybook, we can easily export a static version and host it in a S3 bucket. This can be adapted to whatever other host or technology you're using, this is not about the technology but the approach of sharing it widely. On every push to our main branch, we have an automated CI job that builds and deploys the newest storybook, making sure it's always up-to-date. This has the added benefit of ensuring that our Storybook never breaks through (unrelated) changes. We would at least notice the CI failure.
Sharing a link to your Storybook makes it dead simple to ask for design feedback during development, and also gives everybody the opportunity to discover and play with our design system components.
]]>When improving any of our workflows or when switching an existing task from a Pipeline to an Action we're faced with the problem of asserting whether the CI is working as expected. We could use the "YOLO" approach: merge our changes into main and iterate on them there until they work. But that's rarely a nice or professional approach and causes too much noise and frustration for everybody involved.
When looking around for solutions to this problem, most people recommend using nektos/act. Act can run GitHub Actions locally and allows you to test whether your workflow runs as you expect it to. Unfortunately, in our most recent use case we couldn't use act as we needed to access repository secrets which were not available locally.
Instead of succumbing to the YOLO workflow, we use another ingenious approach: while developing the Action we change the trigger to run on the pull request:
name: GitHub Action Workflow
on: pull_requestInstead of running only when there's a new tag or a new push to a certain branch, we tell the Action to run on every PR. This way, we can push changes to our PR until we ensured everything works correctly. After that, we change the trigger back to the actual value, clean up the PR and ask for a final review before merging it with quiet conscience.
When the code of your action works correctly (verified through solution 1) you might want to check that it behaves correctly under different circumstances and with different parameters. To do this, you can add a ˋworkflow_dispatchˋ to your triggers. Doing so will create a button in the GitHub UI which you can use to run your action manually and even supply it with various input parameters. Check the official announcement blog post
# simple case, no inputs
on: workflow_disptach
# with inputs
on: workflow_dispatch
inputs:
logLevel:
description: "Log Level"
required: true
default: "warning"We ask people to work 40 hours per week – and that's plenty. I firmly believe people should completely disconnect over the weekend whenever possible. Properly resting and recharging will do more for your productivity and concentration than constantly being online, checking emails and messages on Saturdays and Sundays.
A lot of productivity articles have been written on the topics of weekly reviews and planning rituals – and doing them on Sundays. While I'm a firm believer in such rituals, I don't think you should sacrifice your Sunday morning or afternoon for them. The temptation to quickly check your emails, send that quick response or take a brief look at the newest pull requests is too big – and can easily become a huge time sink that keeps you busy for multiple hours.
The solution to this seems obvious in hindsight: do your rituals on Friday before leaving for the weekend, or on Mondays before starting your day. Doing these routines is important for your personal productivity, and hence, they should be important for your company. There should be no excuse necessary to do them in your regular 40 work hours. Preparing your work is work.
]]>With ts-node we can run node scripts in TypeScript.
commander.js enables us to write interactive scripts with ease. Adding options, short hands and documentation for scripts becomes a breeze.
The final thing added to our tool chain is inquirer.js which allows us to ask for user inputs and confirmation in scripts.
To use this tech stack in your next mini-project. Initialize your new project with npm init and then run
npm install --save typescript ts-node commander inquirerto install all required dependencies. To use modern syntax that you're used to from Frontend development (i.e. ES modules) add the following to your tsconfig.json:
{
"compilerOptions": {
"esModuleInterop": true,
"resolveJsonModule": true
},
"include": ["your-script"],
"exclude": ["node_modules"]
}Especially, as a developer, it's easy to lose yourself in all details – and it's so much fun to do so. It might start with a harmless dark & light mode toggle, and while you're at it, you start writing your own CMS or component library. Been there, done that.
Try to remember every time you're tempted to tweak your setup that it is the content that should shine. Most people won't care about your setup, they care about your content.
To keep myself in check, I collect all the ideas for improvements for this blog in a dedicated Todoist project. This way, nothing is lost, and I won't get distracted from my original goal. From time to time, I'll allow myself to indulge in these optimizations and cross off tasks on my to-do list.
]]>This blog uses Next.js to produce a static HTML export using next export.
The posts are written using Markdown. Metadata of each post is managed with gray-matter, which is a YAML block at the top of each file containing things like the title, excerpt and published date.
For coherent styling, this blog uses Tailwind CSS. The code is authored using TypeScript.
On every push, the blog is deployed using Netlify's GitHub integration.
If you want to kick-start your own blog, I can recommend starting with the official Next.js Blog Starter with TypeScript. It will get you going fast and doesn't come with a lot of complexities.
]]>console.log('Hello World!')
Welcome to Henning's Blog. I'm Henning, Head of Frontend at Doist and working from Hamburg, Germany. I'm going to use this space to write about a couple of different things:
Since 2017 I'm working remotely for Doist. Doist is a fully remote-first and async-first company. Since starting here, I'm bullish on working from home and can't imagine ever trading my freedom and productivity for long commutes and open-plan offices. I'll share helpful tips and tricks on how I and we at Doist make remote work, work.
A couple of years ago, I switched from being an individual contributor and became a manager. While I never stopped contributing (and don't think I ever will) I've a couple of learnings to share on remote leadership. Especially, leading multidisciplinary teams and handling time zone differences. My team is currently 13 people strong and spreads from the west coast of America to Hong Kong / Perth – pretty much as remote as they get.
Although my role is management, I still try to spend a third of my time getting my hands dirty on actual Frontend work. I'm going to share different learnings on how to be a multiplier of your team's productivity. Occasionally, I'll share interesting challenges from the front*(end)* that we've faced and solved.
]]>