DEV Community: Johannes Scharlach

How I Stay Up To Date

Johannes Scharlach — Sat, 10 Apr 2021 12:27:31 +0000

I've managed to stay in touch with what is happening in the React world, the Node.js world and also keep on updating my engineering management skills. So recently some colleagues asked me to share my sources.

Learning New Skills Quickly

Whenever I want to learn a new topic, I try to find a hand full of domain experts – people who are really top notch in this field – and learn from them. Usually by following them on Twitter, reading their Blogs and subscribing to their newsletters. And then I practice. It's incredible how quickly you make progress when you have some direction from domain experts and put in time and effort to practice what you now know. Just 2 weeks of this make it possible for me to start having in depth conversations about the topic.

Oren Ellenbogen has described a very similar approach at a conference talk. I fully recommend watching this.

Twitter

Right now my most important source of info is Twitter. Here I have a few people I'm following

React & Node.js

Technical Excellence & Tech Entrepreneurship

Newsletters

With my newsletters I like to have a mix of content from individuals who write their own blog posts and curators who link to many different blogs. Keeping updated with the content of an individual allows some consistency and I understand their references to previous content. Curators allow me to open my mind to new content continuously

Kent C. Dodds has a focus on testing & React. You can subscribe to his newsletter at the bottom of the page.

SoftwareLeadWeekly by Oren Ellenbogen is helping me stay up to date as a manager and tech leader. Oren also has a book, which I found ok but it didn't influence me too much. His mailing list contains info which is more geared towards managers, but I believe that any engineer profits from that knowledge.

LeadDev also has a great newsletter (at the bottom) focussed on all sorts of tech leadership topics. They also organise some wonderful (virtual) conferences which I previously attended.

Stefan Judis has a very humble tone in his newsletter. He writes stuff which is just fun to follow and very relatable.

X-Team has a curation of usually technical documents. What I find interesting is that they highlight blog posts as well as useful GitHub repositories.

From Engineer to Manager

I've previously written about even more resources which help with the transition to becoming an Engineering Manager

Cover photo by Scott Evans on Unsplash

Getting into Engineering Management: Useful resources to start thinking like a manager

Johannes Scharlach — Thu, 08 Apr 2021 12:02:01 +0000

Everyone’s path into engineering management is different. For me there were a couple of resources that I wish I had started with very early and other items that were more useful later down the road.

Reading Material – books, newsletters, blogs

Read Immediately: The most Actionable Resources

Software Lead Weekly a great weekly newsletter that curates useful blog posts and tweets around engineering management. For me, getting a regular newsletter in my inbox is a good starting point to build a habit of reading about a topic (like engineering management in this case)

The Making Of A Manager by Julie Zhuo. Julie joined Facebook straight out of university as a software engineer and today leads Facebook’s design team. She had to learn fast and make mistakes, so that we don’t have to.

Radical Candor by Kim Scott. Kim worked at Google and Apple and has learnt how to receive and give honest and candid feedback. It is the single most important book on how to act.

17 reasons NOT to be a manager by Charity Majors. Not only does it help you figure out if this role suits you, but also it shows many of the options you can provide your senior engineers that are wondering about their options. There are lots of fun manager activities that senior engineers can help you with and you will be more successful when you share those responsibilities with the right people.

Important Growth Literature

The Manager’s Path really highlights the different kinds of roles that exist in an engineering organisation and what is expected of whom.

The First 90 Days is great literature when your role changes. You probably have a role change where this is useful at least once a year when your responsibilities shift or your team changes.

First, break all the rules is a book that focuses on what makes the difference between an average manager and the best. Are you looking to join the elites? You need to do things differently.

Extreme Ownership. This book was not only fun to read, it also teaches a big lesson on how to step up and show ownership. You hate fingerpointing? Follow the principles outlined by the navy seals who wrote this book. It’s very American.

Building Effective Teams

Useful tooling

Atlassian has lots of useful plays that you can go through with your team. This is how you get the team to really own problems together. Not sure where to start? Do the health monitor. As a Manager I have learnt a lot about what’s working well in the team and what isn’t. Sometimes there are no surprises for me, but team members become aware of problems.

Another great resource is Icebreaker.video. It is software that helps you organise events in which a large group of people can authentically get to know each other. I’ve used it for our quarter kickoff and got really good feedback on it.

Having great 1:1s

For me 1:1s are always about either coaching people (which is when I listen to what’s working well and what isn’t to give feedback about how the person can do better) as well as building trust and building a connection. To learn about a person, you can ask questions for example from this list.

For the first 1:1 with anyone, I like to ask these questions.

But at the end of the day, 1:1s are a lot about coaching and I've become a lot more effective at doing them ever since I picked up The Coaching Habit.

Giving candid feedback

The only kind of feedback that works is what the recipient chooses to hear and accept. What helped me is to make sure that

I provide feedback in a non-threatening setting. Usually in private, most of the time in person/video so that I can see the other person's reaction and put things into context
Feedback needs to be candid. When you provide it, you're speaking from your feelings and beliefs, not from a version that is bending the truth.
Especially if it's tough feedback, put it into perspective. Does this person being five minutes late to every meeting mean that you think less of them as a person? That you're planning to fire them over it? Make sure feedback for small improvements is seen as such and feedback about behaviour that may cost someone their job is seen as such, too

Furthermore I follow a method of communicating my observation, my impression and my wish. I do that by answering (in this order)

What did I see and hear?
How did that make me feel?
What's my wish?

Sometimes it's hard to be specific with your wish and that's ok. You can wish for a different feeling without giving tips on different behaviour. You can wish for continuity in case of positive feedback. If you're not comfortable sharing, you can even skip the wish altogether and you will still have provided valuable feedback.

Example: An employee regularly shows up late for meetings that involve the entire team and it's affecting team morale. My feedback might look like this

I noticed that in the past weeks you often showed up late for our meetings while all your colleagues are waiting for you for five minutes. It made me feel like you don't think the meetings are relevant for you or your time is more important than your colleagues'. I wish you'd be on time for meetings where you're expected and you would help make meetings more relevant for everyone involved so that we all make good use of our time.

The person receiving this feedback might not accept the entire part of the feedback, but they will know what you noticed and they will have heightened awareness of the impression it leaves on others.

What else? What are some more resources which are useful to get into engineering management?

The Ideal Developer: Bored, Frustrated & Full Of Energy

Johannes Scharlach — Wed, 04 Dec 2019 17:54:59 +0000

If you're working in a fast-moving environment, you probably know what I mean when I tell you: Your tools will always feel like they are outdated, some of the work that you're doing seems mind-numbingly dumb but it's necessary for the company's success and none of your processes works really smoothly.

I've personally been in those situations and wasn't happy with the state of things. It feels like you're wasting a lot of time and energy.

But I also believe that this kind of boredom and frustration can be a blessing in disguise. It can make you one of the most productive engineers.

Waiting For Management To Resolve The Issues

Olivia is working as a Backend Software Developer. She has just been asked to setup a customer account in the database again. This time it's a complex setup, so she will need to update a few different tables. Luckily she's done this before so she knows what steps need to be performed. There is no documentation that she could refer to, which is also why nobody else was assigned this task.

She will make sure to have 30 mins of uninterrupted time to do the setup. She hopes that management will prioritise automating this work in the future.

Does this sound familiar? Have you been in a situation like Olivia and waited for management to prioritise the automation of some boring and brittle task and somehow it never came up? But you know that the day management will finally prioritise the automation of this kind of stuff, you have hundreds of other little jobs that should be taken care of, too.

There are tons of reasons why automating these small tasks doesn't get prioritised by management:

"management" isn't a single person – it might not be clear who is responsible for this kind of improvement. Is it the product manager or an engineering manager?
your manager might not know that the problem exists – this happens even more often if the task is more technical
your manager might know about the problem, but might not have a good idea on how to solve it, because they don't experience it hands on
this little account setup task is to small to receive any priority between other high-value items
there is no clear customer value associated to automating this account setup
prioritising a generic "automate stuff" initiative is too vague and doesn't feel like it's urgent at the current stage of the business.

And while all of these sound like excuses for management to not have their act together, the person suffering is you. You're the one who ends up doing this boring work that should have been automated a long long time ago.

Boredom Leads To Creativity

When you're bored, for example because you're performing a dull task, your mind tends to wander. You have some extra brain cycles and will start to think of dozens of different ideas. While you're doing the tedious account setup, you think about a beautiful admin page you should have where customers can be set up by their account managers. Or this kind of provisioning could be fully automated by connecting the application to your company's sales CRM. Or maybe you just think about what you might want to have for lunch today.

Doing a boring task allows your mind to meander and come up with lots of creative ideas. Creative thinking is a great gift that you can use – e.g. to come up with a proposal on how the setup could be improved, so that next time it will only take Olivia 5 minutes to take care of a complex account.

Frustration Can Be A Motivator

3 months later and the situation has barely improved. Product has a whole admin section in mind, which will take care of the account setup, too. But there are new high value features on the roadmap that need to be delivered as soon as possible. Unfortunately Olivia can barely work on those features, because every day she has to help with the setup of 1 or 2 customers and about once a week she has to do some investigative work to figure out why some of the accounts not working correctly – is that related to an error in the setup?

Olivia is frustrated. She has been doing the manual setup for months now and a solution is still not prioritised.

I've been in this situation and you may have been there too. Everybody around me knew that things could be better and some tasks could be automated, but there was simply no priority allocated to this topic. Did nobody care?

I've found this frustration to be and incredible source of motivation. Sure, frustration is dreadful at first, because you know that things could be better than they are, but combined with some boredom, frustration can be used to find solutions.

Being frustrated can help you talk to your boss about the problem and that it needs to be addressed. It may help you to start talking about the creative solutions that you've found through boredom. And it also means that as much as it's within your own control, you will improve the situation. In Olivia's case it may be as little as writing some documentation about the steps she's taking or automating the setup for simple accounts in a little script.

Build Tooling To Improve Your Situation

I'm a big believer that developers don't automate as much as we should and it's hurting our productivity. If Olivia takes 30 mins of her time to automate some of the account setup, she will profit from that tooling very quickly. Being motivated and under time constraint allows developers to start out with the bare minimum to improve their current situation without loosing focus.

If you manage to make your situation just 5% better every day for a month, at the end of that month your situation will be 2.65x as good as it was in the beginning. That is a gain of 165%. And you can achieve that by just being persistent in improving things little by little.

Change Processes

When you're unhappy with a certain process and find it frustrating, chances are that others feel the same way. Take that energy that's building up inside you to change something. Tell people about what other options you see for an improved process and make a group decision to improve it.

Changing behaviours and processes is hard work – use your frustration with the status quo for good to convince others that there is a better way. Being frustrated with the status quo also allows you to have a no-ego relation with your proposed solution: Maybe someone else comes up with a better path forward and you can embrace that, because in the end it's the status quo that you're frustrated with and that needs to change.

Being Frustrated Is Normal

I've met many people that were able to tell me: As long as I'm complaining, you know that I still care. Once I've stopped complaining, you need to start worrying.

In a fast changing environment it is normal that processes and tools that you've previously established are constantly outdated. And there are tons of competing priorities at all times. I've become happier since I realised how much my changes and improvements were appreciated by the people around me, because 99% of the time, you're not the only one suffering.

And sometimes when things seem frustrating everywhere around you, it helps to pause and find the good sides. The things that work and that you're grateful for, because in most environments those exist, too.

Why I Write

Johannes Scharlach — Wed, 04 Dec 2019 17:12:00 +0000

Lately I've decided to write a lot more. Here are some of the reasons that convinced me to pick it up.

1. I Want To Practice Writing

Writing is like riding a bicycle. The most important trick to get better is to do it every day.

If you try to find out what good writers do to improve their writing, it's one thing that they all have in common: They write a lot. Forcing myself to create lots of written content is a way of teaching myself how to write better.

And in the end writing a post is a lot like building a product. If you're only making it public when you're fully happy with it, you've waited too long. So I tend to put an effort into starting to write and publishing a post within 2 days.

2. I Can Share My Posts With My Friends And Colleagues Easily

I'm regularly discussing different aspects of my work that I've formed opinions on. This can be my hiring process, custom tooling, or on-boarding a new developer to the team. I would like to give everyone the most well-structured version of that info possible. Sharing a blog post that I've crafted allows to share that content more easily.

3. Writing Helps Me Grow

Since writing requires me to reflect on my thoughts and actions, it allows me to learn something new from my experiences and structure my thoughts on a topic. It's an important way to grow and become better at what I do.

The content I write can capture my thoughts in that moment, while the reflection that's happening during writing is what helps me grow and mature my thoughts.

What other reasons are there to write?

A Hiring Process That Works

Johannes Scharlach — Tue, 03 Dec 2019 20:31:03 +0000

In the last 2 years I've hired and interviewed dozens of candidates. With the support of recruiting professionals, senior software leaders and developers that have previously worked at places such as AWS I was able to design a hiring process that works both for the candidate and the hiring manager.

How do I know that it works? Because 100% of candidates that I've made an offer to in the last year have accepted it and were very happy. And many of those that I didn't make an offer are still keeping in touch.

The 5 Step Interview Process

As a hiring manager, I'm directly involved in 5 steps of the process. But it starts one stage earlier.

Step 0: Interest Based Recruiting

The very first step is made by my recruiting partners. They reach out to developers and show a genuine interest in helping these people figure out what they want to do next. The recruiters ask about interest and what items are important in a new job. If the candidate's profile matches what I'm looking for and the job description matches their preferences, we proceed with the next step.

Step 1: Get to Know The Candidate (20-30 mins)

I want to get to know the candidate and also want to offer insights into the company and what I do at the company.

A candidate will be eager to join a team if the hiring manager establishes a certain level of trust during the interview process. Similarly, the hiring manager needs to trust a candidate in order to feel enthusiastic about the potential hire. As a hiring manager, building that trust is what I'm looking for in this 20 minute interview.

My interview consists of 4 sections

I give a short pitch about the company and my history at the company (~5 min)
The candidate presents what they have recently been doing, mentioning some examples (10-15 mins)
Together we explore what is important to the candidate and what the company is able to provide. (2-5 mins)
The candidate is encouraged to ask questions (3-7 mins)

I've found a total of 20 minutes to be enough to cover all of these topics if you're meticulous. Sometimes it feels like time flies or there are many questions and it's easy to spend more time, so I like to have the option to extend to 30 mins if necessary.

I've also found that asking Do you have any questions? only rarely produces any actual questions, while asking What questions do you have, for example questions about the company, the team, their working process or the role? and nearly every candidate has an important question on their mind. As managers in our every day job, it's our duty to show our active listening skills and ask specific questions that will provide us with good information. It makes sense to apply these techniques also to hiring. There is lots of info out there on how to ask better questions.

Step 2: Assess Technical Skills (60 mins)

As a manager, I've stopped leading the technical interview. Instead I will ask a senior developer to conduct it, while I sit in and take notes. For 1h we will try to dive deep on all topics that will affect the day-to-day job that we're interviewing for. We care in particular about the topics & skills which the candidate has mentioned on their CV. It is well understood that everyone has different experiences and strengths, so we try to focus on the candidate's strengths as well as covering the basics such as working with source control & in an agile process.

In a successful interview, I have learned something new from the candidate. If they have used a specific library or concept that they feel comfortable explaining, that is almost guaranteed to win this round of the interview and it can easily outshine deficits in other areas.

Step 3: Witness The Applied Skill (2-3 h)

Explaining a concept and being comfortable using it are two sides of the same coin – yet both should be checked. We like to conduct pair programming interviews at this stage, because it resembles how we work in a realistic environment. A senior developer (usually the same person who did the technical interview) will spend about 2h with the candidate to build something from scratch or bug-fix an existing open source project.

At this stage you see how a candidate handles feedback, how much you enjoy working with them and what kind of work they prioritise, given the 2h time limit.

The session ends with the candidate presenting what they were able to accomplish and what they would have done next if they had more time. During the pair programming session, the senior developer acts as a collaborator, not an interviewer. We've done the technical interview already before, so what we primarily want to know is what it feels like to work with this person every day in a realistic environment.

Step 4: Establish Cultural Aptness

Next, the candidate will meet the entire team (sometimes part or all of this happens before step 3). They get to know the people that they will work with moving forward. This is the first step to on-boarding them to the team.

I tend to have this structured as 20 mins with the designer, 20 mins with the product manager, 30 mins with the remaining developers (that haven't been involved so far) and 1h of lunch with the whole team.

Why not Cultural Fit? Because in an industry that's so dominated by white males, it's easy to fall for biases that end up with hiring more white males. To build a diverse team, you have to hire people that don't look and act the same as your existing team and focussing too much on fit you may end up favouring the wrong items. Instead cultural aptness makes sure that hiring this candidate leads to the right cultural mix.

What I'm looking for is to connect people in a way that allows them to judge: is this someone that I would like to spend 8h of my day with, 5 days of the week? The candidate as well as the team profits immensely from such a session. The candidate can fully picture the team and environment in which they will be working while the team gets excited about a new person joining, too.

Step 5: Making The Offer

Finally an offer should be extended to the candidate. If you're truly excited about someone (as you should be), then as the hiring manager you should be the one to reach out with the offer. This can be a short 3 sentence email, stating the salary, vacation policy and any core benefits. But an email from the hiring manager shows how much you care, because it's not your job to message the candidate.

If you're rejecting a candidate that has spent significant time interviewing with you, I also find it important to give details what went wrong. You don't need to mention every detail, but honesty is appreciated and candidates will be thankful. You may want to work with HR on this, since there can be legal implications when you mention why someone was rejected.

How To Ask Good Questions & What To Look For

It's become apparent that asking good questions is core to give meaning to the interview.

Allow The Candidate To Present Their Best Self

A candidate that has already done exactly what you're asking them to do will be bored in this job. So allow the candidate to present what they did, rather than what you want them to do. It will be easy to see similarities and differences, so that you can judge if they will be able to learn quickly enough. Only if you allow them to present their best self can you truly see the potential of the candidate.

This also means that you need to put effort into creating an environment that is realistic. Whiteboard interviews are very far removed from the every-day situation that a candidate will be in. You will test a candidate's nerves, but not their actual productivity. Through things like pair programming you see how comfortable they are in their own editor. Of course using Google/DuckDuckGo is allowed! More senior candidates know what to search for more easily, that's what makes them senior.

Always Ask For Examples

Candidates tend to sense what the interviewer is looking for and give the "correct" answers. This makes it difficult to judge if someone has learned their lessons through experience or simply read a few good articles on the internet. Being able to apply the theory and put it into action is a core competency to look for.

By asking for examples you will find out how a person really reacts in certain situations. The conversation will also be a lot more engaging if I ask you about the last time you had to optimise an SQL query, rather than when I ask questions about how PostgreSQL indices work.

Gently Test The Depth Of Knowledge

This applies in particular to senior candidates with 10+ years of experience. They will have seen a lot of different technologies & problems and will be able to scratch the surface on almost any technical topic. What helps is to ask for follow-up questions to explain more details. E.g. when we're talking about PostgreSQL optimisations, why did adding an index work? What kinds of indices do exist for SQL databases and how are they different? What is a btree anyways? And what's a scenario where this kind of index would not work?

With such a line of questioning you'll quickly find out how deep a candidates knowledge is. When they have extensive knowledge of the topic, they will be able to explain with a whole lot of context. It is often easier to ask these questions with superficial knowledge than to answer them.

But this is also where an interview can quickly become very uncomfortable. Remember that you are trying to allow the candidate to present their best self, so if you see that you've hit a dead end, move on to the next topic.

Good Talent Moves Quickly (And So Should You)

It is tempting to think that as a hiring manager you don't want to seem needy and shouldn't reply too quickly. You may also want to be able to compare a candidate to others and those people still need to move to the next stage.

Don't do that. Great candidates have long found another job by the time you can compare them to 2 or 3 others. Allow them to move to the next hiring stage as quickly as possible. If an interview went well, spend the next 5 minutes providing feedback (I usually communicate that via the recruiter) & figuring out when to schedule the next step. There is no feeling that's greater than being needed by the company you're interviewing with.

Sometimes it's not possible to move quickly – you may have doubts about an unusual candidate's profile and you may need to sleep over your decision or there may be budgeting questions that need to be clarified first. In those cases you can usually provide a timeline for when you'll be following up with a candidate to manage expectations appropriately.

Once you have found the right candidate and they did accept an offer, on-boarding begins. I've written about that before.

3 Lessons I Learned About Group Decision Making

Johannes Scharlach — Thu, 28 Nov 2019 08:44:46 +0000

Over the past years I've helped make many changes and improvements at my job. Those reached from project prioritisation to architectural solutions, changing a style guide, introducing a career ladder and many more. In all of these cases, forming consensus in a group was required to make the decision. I call it Group Decision Making. Here's what I learned.

1. The Change Needs To Be Clear

Decisions are always tied to a change, which is why I'll refer to changes a lot in this post.

When you're pushing for a change, it helps to acknowledge that you have a unique perspective that not everyone will share out of the box. I found a couple of questions pretty useful to find a shared perspective in a group.

What Happens If You Do Nothing?

For most decisions the default option is to do nothing and leave things as they are. Try answering the following questions:

What's the best thing about the current solution?
When we stick to using it, what is the worst case scenario we could be in a year from now?
Is there anything you can categorically not do with the status quo? (this applies to only few cases)

It helps to answer these questions for yourself as doing so will help you understood the status quo well. You might find out that you need to put more effort into researching the way we landed at the current situation. This is necessary to make a good decision on how to move forward.

If you can, publish your perspective to the wider group. This allows everyone else to weigh in, so that you can hear concerns and problems early.

What Problem Should Be Solved?

It's not always easy to put into concise words what you're solving. Addressing what problem shall be solved leaves for the largest amount of misunderstanding. I tend to think about it as something directional, describing with examples what will be possible. I've found it helpful to ponder

Who will benefit from the change?
What is the time horizon? (How soon will someone profit through the change & how frequently)
Does this change enable radical new opportunities? (e.g. better deployment tooling makes it easier to manage more & smaller micro-services and is therefore one of those enablers)
What is out of scope to be solved with this change?

Often when you get people excited about a change, they may bring up a couple of other problems that they would like to see changed, too. This can sometimes lead to scope creep and your change proposal may lead nowhere when it's trying to solve 1000 different problems. Therefore it's important to draw the line between what items should be improved and what items should not.

What Solution Are You Proposing?

Name your solution. After you've described the status quo and laid out the problem, you have everyone's attention to present your solution. It's particularly great if your proposed solution has a name that people will remember.

How Would You Implement That Solution?

You don't need to have the answers for this on day 1, but answers for how the solution will be implemented are critical to gain everyone's agreement. Who is willing to take the cost of making the change? How will it be rolled out? In a small team this may all be trivial to answer, but in a team of hundreds of developers responsibilities need to be a lot more clear.

What Alternatives Exist?

You know about alternative solutions if you've thought about a problem hard enough. The work you put into this depends on how big the change is. Changing an eslint rule might require a one sentence answer while changing git branching workflows may require 5 minutes of explanations why some other options are not worth considering in as much detail.

2. Changes Require Determination And Effort

This seems obvious now, but I had to learn that the hard way. Changes don't just happen even when everyone wants them. Changing habits & tools requires hard work from someone.

A Champion For The Change Needs To Drive The Effort

Chances are that if you're reading this, more often than not you want to champion a change. The champion will facilitate the decision, ensure that the right people are in the room to drive it forward and make sure that the change is documented appropriately. They can inform you about the consequences of doing nothing, the scope of the problem being solved, the proposed solution, the implementation of said solution and the available alternatives. Often the champion also drives the option or options that are being considered as solutions, but it can also work that they act purely as a facilitator.

Split Between Discussion And Decision Meetings

There needs to be a time to hear everyone's concerns and discuss them and there needs to be a time to make decisions. I've found it very productive to split that into two sessions: One where floor is open for discussion and one where the focus is on making the decision.

Imagine you haven't clarified if people are in the room to make a decision or to have a discussion. You'll easily end up in a situation where one person is trying to push for the decision and another is blocking that decision because not enough has been discussed yet. If you set a clear meeting agenda that describes wether the meeting is about having a discussion or making a decision, the whole group can come together much more easily.

Drive Quick Decisions With TOMASP

It can help to have a certain urgency in making decisions to avoid change fatigue. Change fatigue happens when you talk about a change over and over again with nothing to show for it. At some point people stop believing that it is ever going to happen.

The TOMASP Decision Framework can help tackle such an issue by forcing you to make decisions more quickly. This leads to less risky decisions and better agility.

3. Trusting Teams Make Better Decisions

Simon Sinek has a great story about trusting teams, which explains much of why trust makes such a big difference

After all, only in a trusting team can you receive the feedback that's necessary to address everyone's concerns. Only then people will make suggestions without fear of being called stupid. And only then can you truly know how people really feel about a change.

Choosing Good Defaults: Boost Your Productivity

Johannes Scharlach — Tue, 19 Nov 2019 18:59:09 +0000

If you've read one of my previous blog posts, you'll know that I love tools. I even love creating my own tools.

Over the time I've found out that the most impactful decision you can make is all about defaults. This is my decision framework.

1. Think About First Time Users

If you've done anything with webpack a couple of years ago, you know what I mean. Getting started was one of the hardest parts, because in order to get anything done, you needed to create and understand a complex configuration.

Good defaults make it easy for first time users to get started. If you choose your defaults well, the tool "just works".

2. Make Functionality Discoverable Through Defaults

If you're hiding useful settings in configurations and CLI flags, most of your users will never discover that the functionality even exists. E.g. if your tool can self-upgrade, then doing that should probably be the default. 90% of your users will never read through the documentation, so the default is how they will use your tool.

3. Make It Clear How To Turn It Off

Boolean flags for CLI tools are particularly difficult to turn off. Is it --no-cache or --cache=off or maybe something entirely different like --prefer-online? My experience is that when possible you should avoid the negative CLI flag by choosing the opposite expression, --prefer-online in the above case. If there is no good such expression, make sure you document how to turn the flag off.

4. Provide An Escape Hatch For Power Users

Your power users will quickly get tired of specifying the same flags over and over again. They might need a configuration file to save their settings. Or just have a pre-configured version of the command in an npm script so that people can run npm run start for your regular users and npm run start:minimal as an alternative.

5. If the Tool Is Internal, Start With Default On

If you're unsure about a new configuration, then start with turning it on by default. People will quickly tell you if that was the wrong approach and you can adjust it then. Embracing the concept of fail fast that will give you the quickest feedback if the setting is useful, how it can be improved and if it's not useful at all, you can simply swap the default and carve a new release.

Bespoke Tooling: Building your own hammer

Johannes Scharlach — Mon, 18 Nov 2019 20:56:36 +0000

There are lots of awesome tools out there that will help you automate mundane tasks. But there are plenty of reasons why you would want to use custom tooling, too.

Why Custom Toolkits Are Necessary

The reasons I've seen for custom tooling are plenty:

It may be just to wrap some other tools and create your own zero-config toolkit from that.
I've been in situations where a specific business use case needed to be validated with high certainty, but the test data was unreliable, so we built our own mocking server.
I've been in the situation where the same 3 steps for testing my code changes were necessary over and over again – automating those 3 steps allowed for a development experience with quicker feedback loops and ultimately made me faster.

Automation Pays Off More Quickly Than You Think

There is an infamous XKCD post that shows how quickly automating a mundane task pays off

The tricky thing: You barely notice the things that take between 1 and 15 seconds, even if you do them 50 or 100 times per day.

For me personally the big aha-moment was when I started using prettier. It showed me how frequently I spent energy on formatting code. Until then I never considered it a burden to format my code – I love well formatted code so I found that an activity worth spending my time on and always thought I would be doing that just naturally while writing code. Once I was set up to use prettier, I started writing much code in a single line and had prettier format it all for me on save. Suddenly all my mental energy was focussed on the code itself and not its formatting.

Copy & Paste Mixed With Search & Replace is not Tooling

For a while when we created a new micro-service, we would go about it the following way:

copy & paste an existing deployment file
search & replace the name of the micro-service
adjust any additional configuration that's service specific (e.g. database connections)
copy & paste this file for the other environments
make environment specific adjustments
wait for a code-review for someone to double-check your deployment file
apply the deployment file in the test environment
test if the micro-service works as expected
repeat 7 and 8 for the other environments

For us a big milestone was the auto-generation of these deployment files. Suddenly it was impossible to make copy & paste mistakes. Creating "another one of those", in our case a worker deployment, was possible with zero config. A potential source of error was completely eliminated! The important thing about zero config isn't that you're avoiding a config file. It's that you're avoiding knowing about that file and making mistakes with it.

Search & Replace is easy when you need to do something once. But every time you need to repeat this process, you need to make sure you didn't miss anything and need a complete review.

Automating this process with real tooling suddenly made it easy to create a new service. Something nobody would ever need to think twice about.

Good Automation Tooling Compounds

Once the file generation was automated, it became easy to build on top of that for other things, too. Suddenly it became simple to automatically deploy the service. We gained the confidence to automatically deploy it to all environments very quickly.

Later on we would know how to automatically build different deployment files, depending on exactly what kind of service we were talking about. We were able to build on top of that to automatically update configurations for all services. And we were able to build on top of that to improve how we were handling secrets – something we had previously spent many hours debugging.

When you slowly build your toolkit, you can make sure that every helper you write does only one thing and it does it well. That allows you to compose those tools. And more importantly, it makes things easy to do that were previously hard, like creating a new micro-service.

Making the Right Thing The Easy Thing

I love taking shortcuts. If I can leave out some detail, I will. I know there are many like me. But I also know that the shortcut often has a price: You might encounter technical debt. Most of us have seen that situation when tests were skipped, but there are countless other examples when the developers new better and still took the shortcut.

Tooling can make the right thing the easy thing. The way I made sure I would write tests? I made it easier to write a test than to test my service manually! Any call would have 2 phases: input to data system and data system to output. Once I realised that, I made certain I would easily generate a JSON file for input (same file for manual and automation test!), mock the data source (this part was actual work) and use snapshot testing to check the output. 10 seconds to write a simple test case. 10 more for every corner case.

When you make the right thing the easy thing, people will go down that route.

The 3 Rules Of Bespoke Toolkits

Pick a routine task
Automate one and only one thing about it
Do it in a way that encourages doing The Right Thing

Then Repeat.

Great packages like yargs, execa, fs-extra and many others will help you build that toolkit.

Awesome Tools That Saved Us

Johannes Scharlach — Fri, 15 Nov 2019 20:32:49 +0000

In 2017 we were 5 developers maintaining 160 repositories. It felt like tech debt kept piling up and like we would never be able to do productive work outside of maintaining existing projects.

Luckily there are a long list of great tools out there that saved us from drowning in maintenance work. We chose to automate every step of the way and these are the great tools that made it possible.

GitLab

GitLab is able to offer pleasant source code hosting, deeply integrated with a flexible and powerful CI/CD solution. And the best thing? You can use it for free – at least the community edition. It can be as simple as running terraform apply to get your own gitlab instance running. (This does link to a production ready setup of GitLab, using a cluster of servers, so be aware of the cost of that.)

Jest

Delightful testing that just works out of the box. With snapshots that allow for quick yet effective tests for simple cases.

Prettier

Formatting your code doesn't feel like a lot of work but it's something you have to do all day & every day. When you can delegate that to a tool like prettier, you can focus your attention on business logic and code structure, something the machines can not do for you (yet).

`standard-version`

Releasing a new version should be simple. standard-version makes sure that every time you release a new version of your package, the change log is generated automatically and added to the repository.

commitlint

The above mentioned standard-version works well when your commits formatted so that the full changelog can be autogenerated and structured accordingly. Commitlint will make sure that you don't accidentally forget to adhere to the correct commit format.

Renovate

It's not much fun to keep your dependencies up to date. It doesn't feel like you're doing much productive work and requires you to check if a new version is available in the first place. Renovate does much of that for you: The tool is able to keep many dependencies up to date, it's highly configurable and is able to create pull requests against your repositories as dependencies are updated. You can see my favourite configuration in this gist.

Lerna

Lerna allows you to manage multiple related packages in a single repository. Our custom data processing framework fireant was made up from multiple components – the runtime fireant-core, the adapter to AWS SQS and to Google PubSub (you can read about how we tried to switch once, the deployment generator, tooling to quickly run & test fireant locally during development and create-fireant-worker, a tool that made it very easy to create a new worker & deployment and a couple more. Initially all of those items had their own repositories with tight dependencies between them. Lerna allowed us to manage these related packages in one repository while separating their different concerns clearly in terms of source code structure as well as production bundles.

Slacker

Unfortunately this is not a public project, so I can't link to it. We built a little ChatOps script that sends a message to one of our Slack channels, every time a new version of any of our packages was published. Since publishing always occurred in the GitLab CI (see above) and always contained a changelog, we were able to reliably post the latest changelog and keep the whole team informed.

Our Custom Toolkit

I can't imagine that everyone knows all of these tools in and out. Luckily most of them just work out of the box once you have your repository set up. And in order to make it easy to set up a repository with them, I introduced our custom dev-scripts, inspired by Kent C. Dodds' kcd-scripts. For now, I'll let Kent explain why custom toolkits are great.

4 Tips for Onboarding a New Developer to the Team

Johannes Scharlach — Wed, 13 Nov 2019 21:43:10 +0000

I've hired nearly a dozen members to my teams in the last year. The process of on-boarding was sometimes more and sometimes less successful. Here are some of the things that worked for us:

1. Assign a Buddy

Everything is easier when you have an experienced guide. In a new job, a person who's been working at this company for at least a few months can be great at this. While I've never formally assigned a buddy, it clearly pays off when a new starter has someone that they work with closely from day one. The manager is not a good buddy, they are usually too busy.

The good news is there is lots of flexibility in who can be a buddy: I've seen good buddies that worked in different teams and had different responsibilities. It is also ok to assign a more Junior person as the buddy to a new Senior hire. Buddies can take you to lunch, introduce you to the right people or even just help you find the bathroom.

2. Make On-Boarding the New Hire a Job for the Whole Team

I realise this sounds like I'm contradicting my previous statement, but I'm not. In the first week, a developer will need to figure out what the people around them are doing. Make sure that the whole team can introduce themselves as experts. Alice can tell your new hire about Section A off the app, Bob about Section B, Charles will tell her about Section C.

This helps your existing team reflect on what they are working on and the new hire knows whom to come to with questions.

3. Spend a Lot of Time On 1 on 1s

In the first 4 weeks, a new hire will have tons of questions. If you're anything like me, you're busy for most of the day and that doesn't seem particularly approachable. In the first 4 weeks it is essential that you have reserved at least 30 mins per week for 1:1 time with your new hire where they set the agenda. And you need to make sure you spend a lot more time with someone more Junior, 30 mins works for an experienced Senior.

Afterwards you can reduce it to 30 mins every 2 or 3 weeks, but in the beginning is when you will learn most about your new hire: How they like to receive feedback, if they prefer to come to work early or work late, etc.

4. Have Them Deploy to Production in the First Week

If your deployments are small and low risk, make sure that your new hire's first contribution lands in production in the first week. When you're taking a new job, you're very worried about messing up your first task, so try to make it as easy as possible to succeed. This will instil confidence in your new team member and teach them about many possibly mysterious processes. If your process doesn't currently allow for developers to deploy their own code, that's fine. Just make sure that the first contribution lands in production quickly and successfully.

Bonus tip: On-Boarding Starts With Hiring

In recent months I've asked my whole team to interview candidates. These complement some deeply technical interviews with only 1 or 2 interviewers. Your team should know what's important to their new colleague and if it's someone that they can imagine working with. When your team is involved in the hiring process, it will be easier to build trust between the new hire and the existing team.

Next I'll write about hiring.