DEV Community: Kevin Peters

On launching hackathon.camp

Kevin Peters — Sun, 17 Sep 2023 12:11:53 +0000

Creating a side project is always difficult. hackathon.camp is the 4th project that got to a state where I could show it to other people. And by now it is the best idea I had executed. But we are struggling. Let us look a bit back.

The idea

I organized two internal hackathons at my previous company — Klarna. It was always a big struggle. I needed to fight for the budget, figure out the theme of the hackathon, scheduling, communications—everything. And the biggest problem of it all: Collecting ideas from participants and assigning people to specific teams. Like what happens if a participant decides to not show up, because of reason XYZ.

It was time-consuming and it sucked. I disliked the part about reassigning the team and ensuring everything was working. In bigger corporations, lots of processes are involved that just block you from executing the hackathon. People could not even create their repositories sometimes, so you would need to step in and create them for them. Lots of manual work.

By creating this project, I scratched my itch. And considering how many companies are organizing hackathons internally, I was sure I could get some traction.

Working together

This time I did not want to start something alone again. So I asked some friends first to join. We have started building and we got another friend in the boat. We are 3 now, but our work styles and ethics are slightly different. Difficult to manage, especially when there is a startup without much vision. Just a project to get something done, in front of customers and without much supervision. It is a difficult environment and people cope differently with it. Sometimes it is important to just do things, even if the things are boring to work on. Just do it.

Taking shortcuts

Building a startup requires a lot of hard work. And there are so many other competitors out there. It is a competitive environment. And to be ahead of the competitors you have to be quick. With my experience from past side projects, I caught left rich lots of components of the past. For example, user interface components, common backend packages and utilities, landing pages, forms, and much more. All of these parts sped up the process of generating hackathon.camp a lot. But what even helped more was the fact that we use technologies that we were knowledgeable about: Chakra UI, React, and Next.js.

Another tool I can just praise not enough is render.com. I can recommend this platform to deploy your application. It is simple to use, mostly automated, and just works. It is a better Heroku. And I recommend skipping AWS because this technology is just too overblown to create a simple startup. Of course, if you know AWS well, it might be the better choice for you. But if you are just a basic developer then we recommend using render.

A user call and marketing

One interesting thing I wanted to learn during the project was to use a cause and do sales and marketing. My initial strategy was to find leads on LinkedIn and it was relatively easy. The strategy will be covered in another blog article. Getting out there as a developer was quite weird but as soon as you get responses to your messages it feels amazing. And the feeling is getting even better once you receive an invite for a call or you are inviting someone to be on a call to show your product to them.

The first user call was with the CTO of a startup from Switzerland. I, as a small founder, was nervous but I tried to ask as many questions as possible because that is what I have read on other resources on the Internet. You are supposed to let the other person talk and lead the conversation by asking many more questions and listening to the users and what is their problems and what they struggled with. This is a common technique taught in the book "How to win friends and influence people" by Dale Carnegie. The interview was mainly regarding the Hackathon they have organized. We received many great insights that shape our product today and we have built one relationship with a customer which can become important in the future. I know I can recommend getting out of the shell as a developer and organizing user calls. It is a nice experience and it will teach you a lot.

Developing is a technique of just writing something on your computer and seeing the results immediately. It will give you rewards instantly. User calls are a bit different. You will not receive immediate gratification directly after the call but you have to build the relationship further to close the sale. An interesting topic to learn but also really difficult to master.

On top of that, I also forced myself to do a bit of marketing. Because of the status of our sales on LinkedIn, we have built a LinkedIn page with lots of content. Marketing has the same problem as sales, you do a lot of work but you do not see an immediate effect. We are trying to push this a bit more shortly and try to get better at marketing and sales. After all, we want to make the project successful.

"The launch"

Getting the project live was the highest priority. Considering what is MVP-worthy is a really difficult question, especially if you are working with other people. But what works most of the time is to just release the product and see how it performs.

Launching a project also feels weird. We were planning to go big on launches, but planning them is a big job. If you consider posting to Product Hunt, Indie Hackers, or Hacker News you will always have to adjust your messaging and the style of the message based on the audience you are writing to. Launches take a bit of time so we have decided to not launch yet, even though we want to change that. We think the ideal pace is to launch every time and post consistently on different platforms. So we definitely should have improved the situation around that and launched more often. A mistake on our side. We hope to launch our product soon though and share the process of launching our tool.

Working next to full-time jobs

This whole side project was created next to our full-time job. It is difficult especially if you have other responsibilities. It is taking a lot of time and you can get yourself burnt out quickly. So let us look at some of the issues.

Time management is probably the biggest problem of them all. After all, you work at least 8 hours per day during a full-time job, and managing a side project is difficult. Other people within the projects are waiting for reviews or decisions to be made. It is difficult to work in async and get things shipped. Often, you need to rely on yourself and just ship it by yourself, overgoing your colleagues. This might feel wrong but a startup or side project is a fast-moving construct that needs to be optimized for speed.

Regarding time management there is also one tip that always worked for me: Try to find some time every day. Even if it is only 10 or 30 minutes. It will help to build your muscle to build the project and efforts will stack up over time. It will also help you with context switching because of the limited time you will try to get stuff done.

Another problem with working so much is the motivation, especially when you work in a group and team members work different hours and different amounts of time. It can get discouraging to motivate your co-founders at all times and also find their motivation. Some days you just feel like not working, but will have to push through. It is difficult and you should find joy through other activities as well. The side project should not be the main part of your identity. Enjoy life outside as well.

Trying to get traction

And the most difficult part for engineers, getting traction. Of course, there is always the possibility of going viral but with B2B products the probability of this happening is quite low. So what did we try to get some traction?

One technique we have used is to outreach to people on LinkedIn. You do not need the sales navigator or something similar. Just use the LinkedIn search for a term that is related to your project. In our case, that was an “internal hackathon”. Companies like to post about their internal events to promote good company culture. A good company culture relates to having happy employees and makes the company attractive to potential candidates. After all most companies want to grow and showcase how great they are to work for.

With our lead magnet, we normally try to reach out to people and ask them about their experience with hackathons. What are their pain points and what do they wish would exist for helping them to organize the next hackathon? This is just the first touch to potential customers. If the talk about hackathons is going great, we are focusing on getting potential users on user calls. We had a handful of those user calls already. They are probably the best use of a founder's time. You can learn a lot about how other companies are working and actually what problems they have. Do not try to sell your solution immediately to them. But try to make a natural conversation around your product as well.

We have also launched some campaigns on polywork which was super successful so far. It got us in touch with some really interesting personalities that can help to accelerate the growth of hackathon.camp even more.

Nevertheless, we will have to branch out our opportunities a lot more. We are not seeing the traction we want to see yet, and still do not have a paying customer. But we will get there! I am sure!

The future

Soon, we are focusing a lot on traction. Reducing friction and working on marketing. With those focus points, we estimate that we will hit a paying customer soon. Our pricing is not too big of an ask we feel and our platform is ready.

One thing we will focus on soon is launches on other platforms like Hacker News, and Indie Hackers. It will enable us to get some more backlinks and showcase the platform to a wider audience. We will also focus on content marketing via blogging which has shown great success so far, even with a single blog article that we have published so far.

Overall, we hope to get the platform somewhere. We think it will save hackathon organizers and employees countless hours that they can spend on other things. To be more productive.

3 hackathon announcement email templates

Kevin Peters — Thu, 07 Sep 2023 09:20:16 +0000

Organizing a hackathon is time-intensive. And especially communicating it. Organizers spent many hours crafting messages for internal communication like announcing the hackathon, finding ideas, announcing winners, and many more.

One of the first emails that will send around is the announcement email before the hackathon. In this blog, we will present you with three templates for you to just copy and paste for your hackathon announcement email.

Let us discover what is important for a good announcement email in the following chapters.

Prerequisite

To announce a hackathon you will have to plan your hackathon. We have discovered this topic in "What is an internal hackathon? -> How to organize an internal hackathon" that you can explore. But in short, you will have to figure these things out first before sending an announcement email:

Finding a theme for the hackathon
Figuring out a budget for the hackathon itself

These steps can be only done if leadership approves this idea. So talk with your C-level to bring this idea up. Hackathons are good to market your own company externally or can be used internally to bring people together and increase the average tenure of employees.

What should the hackathon announcement email include?

The hackathon announcement email should include many pieces of information. It is generally split into three parts:

Introduction about the hackathon
Call to action
Additional information

This structure is taken to attract the employees first to the hackathon. The introduction should clearly state the benefit for the employees. It should also mention what the hackathon is about, the dates and what is happening - at least a rough plan. This should answer the following questions

What is the hackathon theme?
When does the hackathon happen?
Where is the hackathon happening? Is it remote-friendly?
What is the main prize?

After that, the employees might have caught enough interest. In the email, you should include a call to action now. Ideally, this is a link to a form where people can sign up. With hackathon.camp you can use the internal form tooling to let people instantly sign up for your hackathon. It is optimized for no friction and supports Google login and SSO for your organization.

After the call to action there is more additional information that you can include in the email:

A link to the rules
What are all the other prizes?
Are there any other restrictions regarding ideas or teams?

Answering all those questions should result in a clear and good announcement email.

Alternative channels to send the announcement

The announcement should be also sent out to alternative channels within and outside the company. Let us start with internal channels.

Team chat

The announcement should also be made public within your team chat. Most teams are using Slack or Microsoft Teams. In channels that are targeting the right people, the announcement should be made. Most often, these are the #general channels or similar.

And when you are at it, feel free to also create a hackathon channel where people can ask questions and get more information about the hackathon.

Internal team meetings

The hackathon should be also announced in internal all-hands meetings. Meetings where everyone in a company somehow participates. With those meetings, you can even target specific departments like engineering or marketing if you are looking for a certain set of people that should participate in the hackathon.

Social Media

The hackathon can be also used for marketing. You might wonder in which way. Your company is likely to have a profile on different social media channels like LinkedIn or Facebook. On those, you can share that your company is organizing a hackathon and it might be a great opportunity for people to apply to your company. You can showcase the nice company culture you have because hackathons are fun events for the employees usually.

The Hackathon Email Templates

In this chapter, we will present the email templates for your next hackathon.

Hackathon Email Template #1

This template is quite a short one. It is ideal if not everything is fleshed out about the hackathon and you just want to generate signups.

Hey {{Insert company names employees}},

We are excited to announce the first hackathon, and invite every one of you to participate! The hackathon will be a 2-day event where you have the chance to participate in a project proposed by one of your colleagues or by yourself. It does not matter if you are an engineer, sales representative, or marketer. In a hackathon, everyone is needed.

The hackathon's theme will be "{{Insert theme}}"
Date: 16-29 of May 2022
Location: Berlin (In-office), San Francisco (In-office), Remote

Early pre-registration form

To be eligible for the submissions, bounties, and prizes that will be announced soon, please register above. We will announce the rules soon.


Thanks, {{Insert name}}

Hackathon Email Template #2

This template is mostly used if you want to include a lot more information in the hackathon announcement email. It is a bit longer and takes a bit longer to read.

Hey <Insert company names employees>,

Our <next/first> hackathon is happening! What is a hackathon you might ask? We will organize an internal company event where you can get together with colleagues, from random teams to deliver a small-scoped project. No matter your background, you will find a spot.

The hackathon will evolve around the topic of <insert theme> and we are happy to invite y'all to this event. Some data about the hackathon:

Date: <16-29 of May 2022>
Location: <Berlin (In-office), San Francisco (In-office), Remote>
Slack Channel: <#hackathon-2022>

<Early pre-registration form>

Prizes include:

<Swag for every participant>
<Each participant of a winning team of a category will receive $1000 in an Amazon gift card>
The rules around the hackathon are the following:

<Teams can consist of a maximum of 5 people>
<Committee members are not able to join the hackathon as a participant>
<You will have a budget of $500 per team to spend on food or other third-party costs>
<All projects must be submitted via hackathon.camp>
<...>
Thanks, <Insert name>

Hackathon Email Template #3

This is an email template that includes a FAQ section as well.

Hey <Insert company names employees>,

We are pleased to announce that a hackathon will happen soon. The hackathon will be themed around <insert theme>. Everyone in this company can participate. It does not matter if you are an engineer, designer, or sales representative.

Date: <16-29 of May 2022>
Location: <Berlin (In-office), San Francisco (In-office), Remote>
Slack Channel: <#hackathon-2022>

<Early pre-registration form>


Frequently asked questions

What is a hackathon?

A hackathon is an event where small teams of random internal colleagues will work together on a project to ship it. In the hackathon, multiple teams will participate and there will be winning teams for different categories that will receive prizes.

What are the rules?

The rules of the hackathon will be published shortly. Sign up or follow the slack channel linked above.

What are the prizes?

Each participant of a winning team will receive a <USD 75 gift card from Amazon>.


Thanks, <Insert name>

What is an internal hackathon?

Kevin Peters — Wed, 06 Sep 2023 06:17:29 +0000

An internal hackathon is an event that you hold in your organization internally. The event builds around the idea of creating projects together with smaller groups in a limited time frame. There will be winning projects with prizes and many cool other activities during the hackathon.

Internal hackathons usually aim to bring employees closer together. They can help form a bond between employees. Ideally, they can contribute to a better company climate and could also empower people to stay longer within your company.

Ideas for themes of an internal hackathon

Finding a theme for an internal hackathon can be pretty challenging. First of all, you have to decide what kind of hackathon you want to create. There are two kinds:

Business-oriented
Fun-oriented

Both forms of hackathons have their advantages and disadvantages. Business-oriented hackathons normally involve the product or project your team is working on. The biggest advantage is that your colleagues spend time with your product and build solutions around or on top of it. This kind of hackathon brought many cool new ideas to companies like Spotify. Spotify, for example, organized many “hack weeks” which are a type of hackathon as well. In these “hack weeks” the company mostly focuses on building internal solutions to make the life of employees at Spotify easier or to improve the customer experience. You can see this in the article “Dogfooding developer products: gathering insights from internal hackathons”. Most themes focus around internal tooling, the usage of one internal product, or streamlining internal workflows or processes.

Fun-oriented hackathons, on the other hand, mostly cover generic topics with their main purpose being bringing the company together. These are not so much about moving forward business-wise, but increasing employee happiness.

Most fun topics are about something that excites employees, ranging from something technical like Crypto to movies. Social applications that connect people are often built in these kinds of hackathons. Projects within fun-oriented hackathons can still include projects that benefit the company though. For example, people could create an app or web app to connect people for lunches or other activities.

How to organize an internal hackathon

Organizing a hackathon is tedious and time-consuming. A hackathon organizer's tasks usually include:

Finding a topic for the hackathon
Preparing marketing material to attract participants for the hackathon
Creating a form to collect ideas
Sending out a form to every employee to collect their ideas
Sending out a form to every employee to gather their team or project preferences
Organizing and assigning teams
Getting feedback and reshuffling teams
Scheduling the whole hackathon from an opening presentation, when teams work on their projects, pizza breaks, and other activities during the hackathon up until the hackathon end
Assigning meeting rooms or creating virtual meetings using zoom, hangouts, or other platforms for the teams
Providing all the tools needed to work on projects like GitHub repositories, Figma projects, and similar
Creating an opening presentation and holding the opening presentation
Organizing food during the event
Collecting all ideas at the end in form of a presentation or similar
Organizing a presentation where each team can showcase their project
Organizing voting can happen in different ways. For example with a jury or open voting by the whole company
Figuring and handing over the prize for winning projects

As you can see the process of organizing an internal hackathon is quite extensive. Us from hackathon.camp recommend taking at least one month to prepare for the hackathon alone. You can speed up the whole process by using our tool though, as we provide templates for most of the communication you will be sending out and automate everything about the process from team assignments to voting.

Another tip is to find multiple hackathon organizers. By splitting the workload of the organization you will keep yourself sane and can get a smoother experience during the hackathon. Make sure that everyone knows what their tasks are, though.

Team organization and keeping the teams up to date with the schedule is something you should spend some time on. These tasks are often the most time-consuming activities, especially when done wrong. Try to assign teams before the hackathon starts. This will ensure that teams can talk together before the hackathon and can expect to work in a group together right away rather than spending trying to find the “perfect” group.

Keeping up with the schedule of the hackathon is also really difficult. Most people do not check a schedule actively, so it is part of the organizers' responsibility to keep the participants up to date. You can do this by publishing a schedule way ahead of the hackathon, ideally in some kind of calendar view. When changes to the schedule happen, like when food deliveries take longer than expected, resulting in subsequent hackathon events being delayed, send a message to every participant that the schedule has changed. Ideally, give the participants some extra time to work on their projects.

Things not to do during the hackathon

As a hackathon organizer, do not participate in the hackathon. You are there to organize, answer all the questions about the event, schedule the milestones, and collect all the data regarding the hackathon. Be there for your employees help them however you can. If someone does not want to work on a specific project you have assigned them to, help them find another solution. There is always a solution!

As we mentioned earlier, do not wait until the main day of the event to organize teams. It will make the process much easier if you plan and assign teams in advance. Another thing we have seen that work well at hackathon.camp is to set some rules, but not to be too restrictive. This is important to keep participants moving within a set of boundaries while allowing them to use their creativity to find good and interesting projects.

6 examples of Bias for action for Software Engineers

Kevin Peters — Thu, 20 Jan 2022 22:14:39 +0000

Bias for action is a principle that appears in many leadership principle lists of companies, like Amazon. Let us explore what it means and how software engineers apply this principle.

What is Bias for action?

In business, time is money. Many judgments and acts can be reversed and do not need in-depth research. Risk-taking is something that is appreciated.

As software engineers, we have to take risks, decisions and need to judge decisions all the time. This depends of course on seniority and your current level, but in any job as a software engineer - even if you do not work at Amazon - you will show this principle.

The principle can also be described as a calculated risk. Not every decision will be the right one but with a bit of data, you can measure the risk of each option for doing a specific task. If the risk is acceptable you should be open to taking any path that leads to completion of the task, ideally with the lowest friction. If it was wrong, then change.

The characteristics making out a person that fits this leadership principle are consisting of different things. For once, we have the doer. When considering "Bias for action" people that are not scared of doing mistakes will show this leadership principle more. They are willing to do certain things without overthinking. They take the risks required which other people might not take. Additionally, they will also have the courage to own the outcome when taking an action. If the action might lead to failure, they are there to fix it, iterate, improve and maybe iterate based on the action. True ownership.

Which companies use Bias for action?

Next to Amazon there is GitHub who is uses a similar principle called "Ship to learn". It is similar to the details of "Bias for Action" by Amazon. So here is a short list with all the companies using this principle:

With a lot more companies adapting leadership principles "Bias for action" will become more important. Companies also get more technical and analyze the impact they have, making sure that you can pivot from your initial decision if it does not work out. So let us check what software engineers can do in detail to show this leadership principle.

Situations for Bias for action

As a software engineer, you might ask yourself initially where you show bias for action. It is really difficult when you think about it but there are a lot of opportunities and day-to-day activities where you show this principle.

During arguments

A situation where it is quite common to use "Bias for action" is in discussions with the team. It could be any discussion on how to implement a specific feature. Or talking about a past decision on what went wrong. Often, participants in the discussion do not focus on the actions they can take from the discussion but because they like to discuss. In these situations, the leadership principle can be applied. Disagreeing and focusing on actually taking an action, even if you do not agree with it necessarily.

Decisioning Process

As mentioned in the last chapter, most decision processes will be decided based upon discussions. In any way, as software engineers, we will also have the ability to make decisions ourselves. Especially because as a software engineer you will most likely have access to the data to make the decisions. If you know in a meeting that a discussion might help to take any action, but to take a really good decision it will take a bit more time to gather data, delay the decision. The action will be to get more data to make sure whatever action you will take, will make the whole process a success for your customer. To the person or organization, you are writing software for. Push for this principle.

Helping people to make decisions

When you think about discussions, you mostly think about yourself and how you interact in the discussion. But it is also important to put yourself into the other participants' perspective. If you understand the other person and make sure their voice, their concerns, and their decisions are well respected, it is the first step to making good decisions. You can help to convince them of your ideas by giving them a little nudge, to rethink approaches. For example, this works well with gathering data on the problem and presenting it to them. It might make them rethink their decision and take action instead of just arguing with the team.

How do you measure Bias for action?

If you read this article you probably want to know what you have done which relates to this principle. But first, let us check how we can measure Bias for action. It is probably one of the leadership principles that is the most difficult to track. But what you can do is create a brag document every week or month and write down the situations when you took a risk rather than waiting out on deciding something. The more detailed timeline you have of the discussion and decision processes the easier it will get for you to summarize where you acted based on this principle.

Another good tip is to keep a brag document with getworkrecognized and keep records of when you showed a bias for action so you can reference it in the future. With getworkrecgonized, you can keep a diary of all your achievements at work.

Examples of how to apply Bias for action

Programmers show bias for action most of the time by default. But pinpointing specific examples in your career is always feeling difficult. In the following section, we list some examples where bias for action can be shown.

Solutions

Coming up with a solution to solve a problem can be applied to many problems. It can be a technical problem but also a team problem, but we will discover them later in this chapter. In general, solutions should be built minimal. When a problem arises try to focus on thinking of an MVP - a minimum viable product. So to say. A better term would be probably a minimum viable solution that fixes the problem.

Feature Discussions

Discussions about product features are probably the most common one for software engineers to be involved in. For example, it could be a simple discussion of which user interface is better and should be chosen for the next feature. A lot of preferences come into play here like personal experience with UI and experiences at your old company how they have done things. Most of the time an A/B test can help with actually choosing the right UI. Instead of arguing which UI is better, focus on actually choosing a metric that will help you to see which is the better UI.

Another example is purely technical feature discussions. For example, like choosing the right database type for your new application or service. For such decisions, the principle "Bias for action" might not be applied because database migrations are difficult to do in the long term. So you should be still open to listening to other people's opinions but decide on the best long-term solution. Be careful of the risks of your decisions. Note them down.

A different situation can occur during sprint planning with your team. Which feature should you focus on? Normally sprints are taking 2 weeks and there is a goal for the sprint to achieve. People hesitate about what to choose normally and what has the highest impact. Gather data on the impact and effort to finish the different projects, which are also called epics in some companies. With that, you can measure the risk of actually delivering a feature within a sprint and measure the outcome.

Team Issues

Most modern and agile teams follow some sort of sprints. What most of the sprints have in common is a retrospective at the end of each cycle of the sprint. During this meeting, the participants discuss the last cycle and what can be done better. But more importantly, they discuss concrete actions that can improve the team's health and performance. The focus should be on actions rather than discussing the issues. Sometimes though, discussing the issue will clear up specific arguments, so feel free to discuss from time to time, but push the participants of the meeting to take action and remind them that sometimes it is ok to disagree if you have any action and can measure the success in future retros. Especially if the issue is not critical to running your current team's processes.

Mentoring

An engineer will have many opportunities to mentor other employees in the company. More junior people need a helping hand from time to time with easy but also difficult problems. More senior people need guidance on how to navigate the product the best, how to contribute, and what are core parts of the code are.

During mentoring it is important that you can tell the other person that you do not know everything and if you get into a situation where you do not have an answer to a question, you can simply answer you do not know. But it is important to also give them the feeling that if they fail with their actions, failures are appreciated because you can learn from them. This is the most important part. Push them for a decision soon and let them reevaluate if it does not work out. An important part though is to encourage them to also gather some data around their issue, and see if what they thought is right, is working out.

Meetings

The principle can be also shown in meetings. As we learned in the discussions chapter before it is important to take action from a meeting. What you can do to push this action-taking and make it quicker is to just research some data regarding the meeting before the actual meeting. Take 30-60 minutes the next time before a meeting and gather data around the issues that will appear. It will help to drive your meeting forward. And even if the meeting does not go in the direction of actions, take an action to gather data around the issue to see if there is any impact. We also wrote another article on how to structure your meetings.

Documentation

Writing documentation comes short most of the time for developers. A problem that many software engineers have is that they can't put themself into another perspective. So the reader of the documentation will suffer. It is good to create some personas for your documentation and then write the documentation.

It's important to roll out this documentation quickly and gather feedback. Most of the time some documentation is better than none. Take action and write that piece of documentation everyone is needing. For internal customers or external customers.

Summary

Bias for action is a weird leadership principle. It is not clear immediately how this principle is actually manifested in your work and especially in interviews at Amazon, it might be weird to answer this question. Find one of the examples above in your work and prepare them for the interview. And feel free to track your work with getworkrecognized. It will help you to figure out your actions towards "Bias for action".

How to Apply Amazon's Leadership Principles as a Software Engineer

Kevin Peters — Wed, 05 Jan 2022 07:39:26 +0000

Amazon is one of the biggest companies in the world. Their core products of them are their marketplace and AWS, a cloud computing platform used by the biggest companies in the world. AWS is also the product that generates the highest profit margins for Amazon.

As a software engineer at Amazon, you are challenged every day. It is expected that you deliver results and apply the leadership principles in every day's work. Even when you are not working at Amazon, you can apply these principles to your job. Share them with your colleagues to create a more collaborative and productive environment. So let us explore some tips on how you can apply the leadership principles.

The 16 leadership principles

The principles at Amazon are the DNA of how Amazon works. The 16 principles make sure that everyday life at Amazon is going smoothly. A simple example is discussions on how to solve a problem. A team gets consists of many people and different experiences. Of course, disagreements will occur at some point. To solve these arguments employees at Amazon will reference the leadership principles during a discussion to solve the arguments. Foremost some should state that discussions in technology companies like Amazon are always looking for actions. Discussions can evolve but should reflect in tasks that can be executed to discover the topic more like gathering data or solving the problem. This can be based on the leadership "Bias for Action" for example.

The current leadership principles consist of these 16 right now:

Customer Obsession
Ownership
Invent and Simplify
Are Right, A Lot
Learn and Be Curious
Hire and Develop the Best
Insist on the Highest Standards
Think Big
Bias for Action
Frugality
Earn Trust
Dive Deep
Have Backbone
Disagree and Commit
Deliver Results
Strive to be Earth's Best Employer
Success and Scale Bring Broad Responsibility

You can find an older version of this list also on our career ladder explorer. The list of principles included 14 principles in the past years. But since then Amazon added two more principles "Strive to be Earth's Best Employer" and "Success and Scale Bring Broad Responsibility". The list can change from time to time, but the most updated list can be found on Amazon’s site.

To understand how the leadership principles can be used for software engineers, not just at Amazon, let us have a look at the next chapters. We will explain what software developers spend most of their time on and how leadership principles can be applied to the different work.

What do Software Engineers spend their time on

Software Engineering is mostly understood as programming. Writing code to fulfill business requirements. As software engineers, we do a lot of other tasks as well like the following

Meetings, management, and operations

Product Decision Discussions
Technical Decision Discussions
Writing Documentation
Organizing technical work
Planning technical projects
Work on reporting metrics, building dashboards
Discovery work to come up with new feature proposals
Interviewing

Code maintenance

Fixing old TODO comments
Making sure the system is reliable
Code Reviews

Testing

Tests as code
Manual tests
User Tests

Security

Testing for security problems

Writing Code

Creating new features
Fixing bugs

So we have a wide range of topics that a Software Engineer needs to deal with. Some topics depend on what team or company you will work for. But in general, these are the duties of software engineers. Do you miss anything? Happy to add them. Feel free to email getworkrecognized@gmail.com. So how do we apply the leadership principles to the different activities?

How to apply the leadership principles during the day

As we have seen in the last chapter, software engineers deal with a lot of duties during their job. Let us look at some examples and use cases for Amazon’s Leadership Principles.

Creating new features or Fixing bugs

This is hands-down coding most of the time. During coding, Software Engineers can apply multiple leadership principles. Let us look at some of them.

Invent and Simplify

Coding is most often consists of two activities: Changing existing code or adding new code. Both ways of working will contribute value and opportunities to invent new coding patterns or simplify the existing code. You could add some new coding pattern that makes the code easier to extend in the future. That is most of the time the main reason for this leadership principle to be applied.

Insist on the Highest Standards

When creating new features or working on refactoring code you should make yourself accountable for the highest standards of code. After all, code is most of the time read, rather than writing. So make sure to put you into the perspective of a new hire and ask yourself if the code is understandable for them.

Deliver Results

Making changes to the code is difficult. Try to aim for a specific amount of Pull Requests within a month or so. When creating Pull Requests make sure to do incremental changes. It is ok if a Pull Request is not complete, but smaller and easier to review. Split up your Pull Requests so you deliver results more incrementally.

Product and Technical Decision Discussions

A big part of the life of a software engineer is product and technical decision discussions. Normally they consist of you, the team, the engineering manager, and the product owner. The product owner is optional when it comes to technical decisions. But in general, these discussions come up most often and require actions that will solve the problem. Of course, the decision process can be rigorous, but Amazon tries to keep the discussions short based on leadership principles. Let us look into how.

Are Right, A Lot & Customer Obsession

As a software engineer, you will have a headstart in discussions with two simple things. Use the product yourself and gather data before the discussions are happening. Gathering data will result in backing your arguments and that you are right about the outcome.

If you do not have the data, then try to make it an action out of the discussion and reschedule the discussion. You will show ownership of the issue and customer obsession to solve the customer’s issue.

Think Big & Frugality

When thinking about new features or technical decisions, always ask yourself: How will this work in 3-5 years? Ask yourself and make a plan and discuss with the team what they think. It is important to get feedback but also write down what you think so it is manifested somewhere. Write a product proposal document with a 5-year plan. It will help everyone.

Nevertheless, it is important to move fast. And moving fast can be achieved with frugality. Not developing the whole feature or 5-year plan but doing a short-term solution. Leaving the long-term solution for later.

Disagree and commit

This is probably the most controversial leadership principle when it comes to discussions. Humans are opinionated. Especially software engineers. I was part of discussions where discussions drifted away far too much because of specific technical or product decisions. Sometimes it is better to just disagree and say "whatever" and follow the decisions of your peers. After all, we can track the results and see if they are satisfying or even A/B test your opinion to see if it would work better. Everyone is open to feedback after a decision, and you should be too.

Writing external documentation

An underestimated skill as a software engineer is to write documentation. Writing is difficult. Writing clear documentation is even more difficult. There is good guidance out there to write good documentation like the guide by divio: "The documentation system". But what is even more important than the structure are some other things that are related to the leadership principles.

Customer Obsession & Dive Deep

Good documentation can be written easily. But how do you know what the customer needs? You have to do the research. Watch the customer using the product you are working on. This is difficult from time to time. Especially when working on an internal product, but even then it is possible to just listen to a customer. See their struggles and get feedback on what could be improved. Any pain points. Document them and write proper documentation about them. Obsess with the customer, try to make sure every customer will understand how your product should or can be used.

Ownership

Software engineers hate to write documentation. Everyone does, maybe except technical writers. In any way, as software engineers, we should own documentation and make sure it is always in an exceptional state. And I do not only mean the API documentation, but also the general documentation on how to use the product. Make sure you gather feedback and iterate on your documentation to make it more useful.

Earn Trust

A big part of writing documentation is actually to gain the trust of the customer. With proper documentation that includes Tutorials, How-to-Guides, Explanation, and References you make sure the customer is earning trust in your system, understand edge cases, and is, in general, more likely to integrate the product.

So what did we learn from this? Make sure to write documentation in your daily life as a software engineer. Spend some time every week to write something, either for your team or externally, so your systems are more understandable.

Planning projects

The higher you are on the software engineer career ladder, the more important it gets to lead projects that affect your team and company directly. Leadership is a general skill but is composed of the leadership principles at Amazon. By following some of the leadership principles you will be a great leader in making sure smaller projects will get delivered.

Ownership

By planning and executing projects you are showing ownership already. Make sure everything will work out as expected and collaborate with your contributors.

Bias for Action

When owning a project, you are required to take decisions. This can be challenging. But take action instead of waiting and discussing. As long as you track the outcome of your actions and make sure it performs well, you will be fine. Everyone can fail with the actions, the important part is to realize it was a mistake and fix those decisions.

Frugality & Deliver Results

A core principle when planning projects is to plan them minimalistic. It is expected that you deliver a project. A smaller project is delivered quicker by nature. Keep the scope small so you and your collaborators, if existing, can deliver quick results. It is a lot better to roll out a project and gather data on how it performs rather than never releasing it.

Success and Scale Bring Broad Responsibility

You have finally finished the project. Now it becomes time to measure your success. The metrics should have been defined at the beginning of the project.

Summary

We have just listed some examples of how the leadership principles can be applied to your day-to-day work. If you want to get to know how to apply them in detail, have a read on how customer obsession can be applied for example. Try to apply the leadership principles. Reference them in some of these situations and make sure you stay productive. But the principles have an even more important meaning at Amazon.

Leadership Principles in Performance Reviews

At Amazon, Performance reviews happen yearly. A big part of the reviews is the self-review and the peer feedback you or your manager will receive. They are all based on leadership principles. Peers will have available a matrix for each leadership principle and the level. They will then choose the strengths and weaknesses of your past work performance.

This process is really difficult though. Think about writing a self-review of your past year’s achievements and base it on the leadership principles listed in this article. You will struggle, I will struggle, we all will struggle. Our human brains are limited. You simply can’t remember all the things we did. And that is where a brag document becomes important. I am keeping a journal in getworkrecognized of all achievements I have reached. I can tag the achievements with a tag and get a summarized version of what I have achieved and relate it to the leadership principles. Quite useful for the self-review. But where it gets even more important is when you ask for peer feedback. Your colleagues might not even remember what they did themself, and will even more likely forget what you have done. Send them a brag document with all your achievements listed in a compact form and you will get better feedback for sure. If you are unsure what a brag document could look like, have a look at our 3 brag document templates.

Once you get rated on your leadership principles the manager will decide if you get to put up for promotion or not. In most cases, they are required to write a promotion case, where they can reference the brag document again, which will be great for you because less work is required to get you the well-deserved promotion.

If you are not working at Amazon you can still make sure to follow the advice with the brag document. In any case, it will help you with the promotion in your current company. People like writing documents that underline a need for something. Think of the product/feature proposals I mentioned before. These should be manifested in a document as well, so you can reference them in the future and make sure the right decision will be taken - which should be your promotion.

So, this is how you can apply the leadership principles of Amazon at your current job, even if you do not work for Amazon. Amazing, is not it? It will make you a more productive and high-quality developer with an eye for the right thing.

2021 in Review

Kevin Peters — Fri, 31 Dec 2021 10:49:30 +0000

Lots of stuff happened in my life and I hope 2022 will be better. Let's revise what happened and what my goals are for the next year.

Blogging

In 2021 I have released the following blogs:

Some of them are quite good for SEO like "The Best Tech Companies in Berlin 2021" or "Remote MDX with Next.js", but the blog is not growing as much as I want to. I might need to invest some time into the blog again next year. I have the feeling I could write a lot about my career and general career development in the EU. I am helping a lot of my friends these days with getting their careers up to speed so it might be helpful to share these other things as well. What is definitely coming in the next year is to write another blog article about the best tech companies in Berlin, since I work at one of the biggest ones hiring here now. That post will be interesting.

Sadly, I also stopped writing my monthly reviews. This was probably caused by starting my new job which I will talk about later. But I want to update you, people, again, so I will decide to write quarterly reviews.

Goals for 2022

Write a blog about the best tech companies in Berlin 2022 (0/1)
Do a Quarterly Review (0/4)

My Career

My professional career developed a lot this year. I left Klarna and joined Stripe this year. I am really thankful for my time at Klarna but after nearly 3 years it was time to discover something else. Stripe is similar to Klarna in many ways, but also entirely different. Especially when it comes to compensation because I almost 2x mine. But how did I get around that?

Last Christmas, I was seeing a position at Airbnb being opened in Berlin. I asked around and found a nice recruiter who was able to tell me more about the position. I started doing Leetcode. It was lockdown. It was difficult. But it was worth it. Leetcode is an online platform to train your algorithm skills. I can definitely recommend using this platform and also subscribing to the premium version of it. You will get access to a lot of problems and even lists of interview questions that companies are using in real interviews. It will prepare you in a nice way. And the money is worth it. The offers you will receive at bigger companies will outshine the subscription cost.

The Airbnb interview was tough, probably the toughest I ever had. And yeah, in the end, I got rejected. Airbnb is my dream company but it's fine. I needed to keep my head up. In those months I really realized how much I needed to change my company, so I applied a lot to other companies. My resume almost always got me interviews at bigger companies. So that was kind of easy. I might write a blog article about that exact one. But anyway, I got interviews at GitHub, MongoDB, Stripe, Datadog, and Wayfair. All of the interview processes were really well, but the quickest was Stripe. It was also the most aligned to me I had the feeling because I was using Stripe for side projects before and their projects seemed really interesting.

After interviewing I got an outstanding offer and accepted it right away. The team was looking amazing and the project was interesting - even though a bit secret back at that time. But I can say it now. It is Stripe Tax. It is amazing because I can use some background from my knowledge at Klarna where I dealt with taxes as well. But in any case, starting at Stripe was amazing, but it deserves a blog post on its own. What I like the most though is how much trust you get working there. You can really move the needle yourself if you have the right ideas.

On top of that, I helped my friend, Julius, by referring him, to join Stripe as well. I helped another friend to get another job and I helped a mate from India to get an offer by Klarna where the person will relocate to Germany at the beginning of next year. It makes me happy to see other people succeed. I reviewed several resumes this year as well and overall I feel like I give back to the community that got me where I am today. I am super thankful for all that. Thank you to everyone who supported me in the past years and who I can support.

Side projects

I worked a lot on my side projects but without any success. I have to accept it and keep moving. But let's get into details.

A category that does not fit this chapter exactly is my Twitter growth. At the beginning of the year, I just passed 500 followers and wanted to reach 1000 at the end of the year. I also did not reach that but I got another 100 followers. Something I can build upon. I will spend some more time next year regarding Twitter growth I think, sharing more stories of my side projects.

So now to the individual projects.

caseconverter.pro

I invested some time into the project this year like refactoring a major part of the application, the case conversion. I invested time into the blog as well, but it did not pay off. The search intent is simply too low I think and without a lot of backlinks I would not reach the growth necessary to ever make it profitable. I guess I will sell it. I learnt a lot but it's time to say goodbye.

linkedium.com

Another project no one ever heard of probably. At the beginning of this year I was streaming on Twitch. I created a new project around the same time called linkedium. I never launched it or published it. The MVP was broken most often because I waited for LinkedIn API access. I got it in the end but lost motivation especially because there are alternatives out there like PostDrips (https://postdrips.com/) where the founder is doing an amazing job. Maybe I will look into launching it this year and just reverse-pitch people reaching out on LinkedIn with the tool, because its the right target audience.

getworkrecognized

The traffic of the project is rising and rising which is cool to see. My SEO efforts finally show off. I wrote three blog articles with good success and traffic is rising as well because of that. I have created three blogs in the whole time:

I have also extended the career ladder source of the project which is quite cool, and that also contributed to the traffic.

A major problem though is to convert traffic. I thought by introducing a free trial I could boost the users signing up at least to get more feedback and it resolved in getting more users. But most of them simply signed up and then did not use it. It is sad, but it made me realize the users probably do not need a tool for tracking, or most engineers who this tool is targeted to are not in the need for using it. I have also included upsells in the blog posts and in most of the webpages which still are not clicked that often. I do not think changing them will change the output of the blogs. The problem lies in the search intent, no one is ever googling how to track their work unfortunately.

When it comes to marketing I have tried to make LinkedIn posts, a product hunt launch that resulted in almost 40 upvotes but no MRR. I have launched the project on hackernews as well without any upvote or any traction. It is difficult to find communities where people are participating and look to actively grow their careers. I was thinking of creating my own and might do so as well to grow the project a bit, but more on this now.

The future of the project has been something on my mind for a long time. I could not grow it substantially this year despite some efforts. And I believe in my new project tooltipr.com a lot more. There is simply more potential there and I feel more aligned. And I want to try some different more promising projects as well, so I have a plan. I am ready to sell the project, but first I want to grow traffic. For that, I want to publish at least twelve more blog articles during the first three to four months of 2022. A difficult task, but definitely possible. The target is to hit 2000 users per month tracked in Google Analytics. I also want to finish all pages in the footer, so the website looks complete. Additionally, I might plan on creating a discord server for the career growth of developers. Giving tips about how to get a promotion at their companies and how tracking their work can help. The community part is a bit not sure yet, but I will see what I can do about it.

In the end, the plan is to sell the project. What amount? I am not sure, maybe someone is willing to pay something for it - It is a low cost to host it ($10 per month) and with a bit of improving the marketing and sales pipeline someone could make a profit from the project. But if I can’t grow it till mid of the year with the actions I planned, I am not sure I will ever have a product-market fit.

tooltipr

This is my most-invested project right now. It is a tool to create corporate glossaries that can be directly shown via tooltips in your browser. I find it fascinating and it is super easy to use and a lot easier to market. I can go the B2B route, rather than going the B2C route with getworkrecognized. It is a lot easier to market and gets traction with such projects. So let us look at the stats:

We can see that search traffic and so on have not been really high, but I have some strategies around that. So let us discover what my plan is for tooltipr in specific.

First of all, we have blogging. The need for corporate glossaries is quite easily achieved these days: Excel Sheets or Google Sheets. This is working for most teams, but it is a hassle. Employees lose the link to the document and do not bother looking it up again. Getting frustrated. And this is the topic I need to explain in my blog articles. Search Engine traffic for these kinds of keywords is not high though, so I will need a distribution plan which I will share for the build-in public movement as well. I think this is one of the most important parts. I will also blog about the technical nature of tooltipr and how I have solved problems with writing a browser extension for example. There might be some useful information for other people to get hold of.

For tooltipr, I plan to release eight blog articles in the first 3 months of 2022. It will be extremely difficult to manage all of that, but it is needed especially because I have another Sales target to hit with the project. I hope to increase traffic nonetheless and also get some more email newsletter subscribers.

Another marketing effort is to showcase the project more in direct cold emails. I have the plan to build glossaries for smaller companies operating in niches with a lot of acronyms. For those companies, I create a glossary page like this one (https://www.tooltipr.com/glossaries/runpanther) that they can use already. It is presenting the tooltipr solution in the right space already, contributing value to the companies without even asking or contacting them. With this, they will be more likely to even try out the full solution. I might need to work on the upsell message on the page, but I am sure this will work. The goal for the quarter is to write 50 emails (at least ten companies), reach out to target users with this approach, showing them the public glossary page they can use and how tooltipr can even enhance the experience.

On top of that, I still need to launch tooltipr in various communities, be it on Reddit or on other public pages. I will get some backlinks based on that which might lead to some sales hopefully.

General

I realized I suck at Marketing, Sales, and distribution of content. I need to improve with that in the future to be successful with creating profitable side businesses. So I am starting an initiative to start 2022 right: #100daysofmarketing. I am holding myself accountable on Twitter to do one thing every day, in the morning ideally so I cannot escape from the reality which is content creation and marketing, or cold emails.

So what are my goals for Q1 around side projects:

🔨 Create a sell listing for caseconverter.pro
🔨 Build a distribution plan for blog articles for getworkrecognized
🔨 Create 12 blog articles for getworkrecognized
🔨 Create a discord server about career growth for getworkrecognized (optional)
🔨 Launch tooltipr on hackernews and in other communities
🔨 Create 8 blog articles for tooltipr
🔨 Send at least 50 emails or LinkedIn messages to at least 10 companies with predefined public glossaries
🔨 #100daysofmarketing - this includes writing content, sharing content on social media, or writing cold emails
🔨 Tweet once every day in the #100daysofmarketing challenge

If I still have time, I also plan to work on some new ideas I have. The projects will be based around Excel and/or Google Sheets because I got kind of hooked into tables recently and I think the market is a lot bigger in comparison to the projects I worked on before.

Of course, there are overall goals for 2022 as well. They consist of the following:

🔨 Reach $100 MRR
🔨 Have fun at Stripe
🔨 Write 5 blog articles about the Software Engineering Career

And that's it for now. Have a nice start to the next year. 2022 will be better!

3 free Brag Document Templates [Google Docs]

Kevin Peters — Tue, 14 Sep 2021 06:53:18 +0000

Brag documents are an effective way to get recognized by your manager and peers for your work. It will help you to get promoted or simply get a salary raise. Getting a template and what to write into that is difficult, that is why we have prepared some templates for you. All of the templates are free and can be accessed via Google Docs.

You might be a startup that is trying to set up their performance evaluation processes to finally create alignment for leveling and ranking within the company, or simply a worker who wants to get a promotion. A brag document can help to convince your manager to get promoted.

How to work with the templates

Open the URL of the template, you can find them in the next chapters
Press on File → Make a copy
Fill the document with your data
Send it to your manager, ideally discuss it in a 1-on-1 meeting and see if you can reach for the promotion

Brag Document Template #1: The general one

Template Link: "Brag Document Template 1: For Everyone"

This brag document is made for every profession. After a short introduction on where you describe yourself in a short profile, you will jump over to defining the goals from past years. If you do not know what goals you had a year ago, feel free to write down what the company’s goals were.

Once those are written down it is time to think about your past year’s performance. What tasks have you done that impacted the key metrics of the company? Most people struggle with this but think back, month by month what you have done.

Then write down what the situation was, without describing what you have done and how the situation was impacted. All that and you will have a good overview of what your performance looked like.

Brag Document Template #2: Software Engineers & More

Template Link: "Brag Document Template 2: Software Engineers & Tech"

This brag document is specially made for Software Engineers but can be used for other professions as well. It is also written based on the popular article "Get your work recognized: write a brag document" by Julia Evans. It will go through your Goals, Projects, how you have collaborated with colleagues and how you progressed the company. Overall it is super focused on software engineers that have clear projects on what they work on and surely this cannot be found in every job that is out there, but if you have some structured way of working towards some KPIs this template might be for you.

The only chapter that does apply to Software Engineers is "Design & documentation". Ideally, you skip this chapter from the template to make it a generic one that works for everyone. But in general, this template is really popular as it was featured on Hackernews with more than 300 upvotes.

Brag Document Template #3: Based on Leadership Principles

Template Link: "Brag Document Template 3: Leadership Principles"

This brag document template is the best if your company works with Leadership Principles, also called operation principles in some companies. You can find a big selection of leadership principles in our free Career Ladders Explorer.

The template is structured quite simply. You have three sections that are like the following:

Good Leadership Principles/Actions
Room to improve based on Leadership Principles
Outlook

The important thing to consider in this template is to overweight the good parts and leave out the bad things. Ideally, you should have started with listing "okish" achievements and getting to the best achievements, then starting with the worst parts where you need to improve and top it off with improvements that are possible for you to reach in the next performance review cycle.

In the final self-evaluation section try to focus on reasons why you should get promoted. Most of the time the main reason should be that you act on the next level already when it comes to leadership principles. And write as well that you want to get promoted now, because of all your achievements and your output.

Other brag docs

Do you have any other brag documents that you want to share? Feel free to shoot us an email at: getworkrecognized@gmail.com. We are happy to have your template listed here as well and we are looking to extend this collection of brag documents soon.

8 examples to show Customer Obsession as a Software Engineer

Kevin Peters — Sat, 21 Aug 2021 15:41:46 +0000

Customer Obsession is manifested in many of the career ladders of the top technology companies. But why is that and how can you, as a Software Engineer, show this principle right now at your current job?

What is Customer Obsession?

Customer obsession is a principle that describes your effort to make your customer happy. It can be applied to almost all positions in a world where you are working on problems that not only you have. This goes from end-customer-facing roles to internal roles where your customer is another employee.

To make your customer happy there are different methods you can apply to make it work. The most important one is to know what your customer wants and for that, you have to be able to put yourself into the customer’s perspective and try out the work you have been doing from that perspective. See where you can improve things and be proactive with your actions to make the customer love your work.

Who is using Customer Obsession as a Leadership Principle?

The biggest technology companies are actively using this principle:

A lot of companies have made this principle a core principle of them, and that has a reason. Within the last 10 to 20 years our software was getting closer and closer to the end customer. Everyone has experience with top-notch experiences provided by big apps like Instagram, Facebook, TikTok, or Uber to name a few. They just work, as expected, and without any problems. Why? Because the customer loves them.

So let us jump into the examples.

Examples you can do to show customer obsession

Practicing customer obsession is difficult on day to day basis as a software engineer. This is because they do not have everyday contact with the customers of the product they create. But there are many indirect touchpoints, you can have. Let us discover them!

Supporting the customer when needed

Ever got asked a question by your support or salesperson in the company about a customer problem? This is a big opportunity to show customer obsession. Try to understand the salesperson or the support person first. Listen. And ask a lot of questions. And also if possible get to the direct words of the customer. Once you have gathered enough information you can answer questions quite easily, but get the whole picture first.

In bigger companies, you are mostly shielded away from direct customer feedback, and your product owner will probably talk to you regarding the "customer’s" problems. Make sure that the data backs this up, and that this is something the customer wanted.

Seek to understand the customer

In the example presented before you could see already that you should be able to understand the customer by listening to third parties like someone in the company. But now let us go one step further. Someone in the company will have calls with customers from time to time. Ask them to join from time to time. Maybe once per month for an hour will work out. But this will be a worthwhile hour, you will learn a lot. And in these sessions, take notes of what the customer wants, how they think, and how you could affect them with your work.

Think ahead, exceed customer’s expectation

Features and bugs are normally driven by the customer. A customer wants something to be done in your company’s product or found a mistake blocking their workflow in one way or another. The special skill to have now is to think more ahead, especially for features. The customer requests a feature, but the problem might be that the customer wants to achieve a lot more than they requested. To solve this, you need to think like the customer and think what are the next steps for this feature. Is there a relation or can it be made easier? For example, if you do frontend development it would be a simple idea to count the clicks till a customer will achieve what they wanted. Is there a way to reduce the clicks for the customer by prefilling fields in a clever way like they have used it last time, or based on other suggestions? Or when it is a backend problem, you can put extra focus on error messages and guide the customer to a solution or what they should have done instead. Most errors are simply describing only the state, good errors will give hints what the customer should do instead.

Put yourself into the customer’s shoes

As we have learned in the last examples you will have to get a feeling of how the customer is seeing your product. This is difficult:

If there is any secret of success, it lies in the ability to get the other person's point of view and see things from that person's angle as well as from your own. - Henry Ford

But no problem, you can learn it. Listen to the customers and use your product. Write down the smallest things that are problematic for you. Wrong colors, wrong behavior, and whatnot. You will get a feeling of what the customer "could" feel. Not all humans, and also not all customers, are equal. Some see one thing as a problem but others look at different problems. Try to understand each perspective. It will be golden for your whole career.

Find Problems within your product

As we mentioned before, finding problems and barriers in your product is worthwhile. From now on simply spend 1 hour with your product every week where you write down annoyances when you are using it. Gather these thoughts and present them to your product owner or create tickets for these problems.

Find data to understand customer satisfaction and loyalty

A problem most companies have with customer obsession is that it is not measured. Most companies just have abstract KPIs like revenue or user numbers. But what impacts the customer obsession is probably two metrics:

Customer Churn
Customer Satisfaction

Both can be measured. Customer churn is easy to measure but customer satisfaction is difficult. For this, you could work together with your product owner to send out surveys to the users of your product every month. If response rates are low, invite them to an "interview". People love being interviewed instead of being just a data point. But work on getting these metrics and make sure the company is using them for product development.

Create documentation for your customer

Earlier we mentioned that customers ask questions and have demands. A problem is mostly that customers are not dumb but cannot find the answer they are looking for. This can be a user experience problem but also simply because there is no content. So what can you do? It’s easy, write documentation and guides on how your product can be used. For example, if you get asked a question twice by internal teams, write that question down in a FAQ and share it with your team and company peers.

If it is external even write some documentation for them. Most of the time something is better than nothing. A big point should be made that documentation is hard to write. A good guide can be found here though: The documentation system. Read through this guide and make it a goal to write down questions in a FAQ and provide documentation.

Look at competitors how they make the customer happy

Good artists copy, great artists steal. - Pablo Picasso

With that quote, it becomes clear that it is fine to look at other customers and how they show customer obsession. For example, just simply look at competitor’s documentation and write down why it is better to use them instead of your company’s product. The same can be applied to everything else, like how APIs are designed, how many clicks you need to get to the result the customer wanted, or when your customer is an internal person, how you present them with a solution that should be of high quality. So spy on your area of work on how competitors are doing, what they might do better, and what you can improve for your customers. Copy the good parts.

Understand what customer problems might appear in the future

Outlook is a big part of the higher you want to climb the career ladder. Employees that can establish a vision on behalf of the customer are golden. Based on KPIs and data from existing customers it should be clear already what is needed in the future. Formalizing this data and bringing the company or even team on the right track is important. Especially when it is about revenue and how the product could generate more profits for the company. Have a look at customer support requests and other data and see if you are observing trends in the whole industry that could be a business opportunity, whether it will be a completely new product or just a new feature. But with enough data, you can present it to your product owner to get validation and lead a project that will be successful. But more importantly, you will tackle the problems of customers that they mostly do not even recognize yet.

Conclusion

We hope we could give you some ideas on what you can do as a software engineer to do when you want or need to show more customer obsession. After all, there are many more examples of how you can show customer obsession. If you want to have a free lifetime license, feel free to reach out to us with an example of how you showed customer obsession at your job.

I am not Getting Promoted at Work - How to Escape the Endless Loophole?

Kevin Peters — Tue, 17 Aug 2021 20:00:33 +0000

Everyone in the workforce has some drive. For most employees, it is the payment at the end of the month that makes them work in their job. A lot of people are also doing their job because they love it. But in our capitalistic world, the salary of a job is an important aspect for every one of us. Because of inflation, our cost of living is rising nearly every year by around 2%. This also would mean that everyone working should get a 2% raise every year, right? Unfortunately, this is not the case for every employee. Some companies just hand out raises for promotions and similar things. Getting promoted is difficult. A lot of companies have structured plans on how to get promoted, which requirements need to be fulfilled to get to the next level. But it is not the case for every company out there making it a frustrating experience to not get promoted even if you might think that you are worth the promotion. In this article, I will explain how you can get over this and finally work on your promotion hands on. After reading this article you will have an actionable plan on what to do in the next week, month, and year to get to the next level in your job.

Get over your frustration

Do you read this article after getting denied a promotion the last time? We all know this feeling sucks. But you need to get over this feeling. See it as feedback and that you might be not ready yet. Yes, there are always other jobs and of course, you could apply for the targeted position in another company. But it won’t improve your immediate current situation. It sucks, but it is what it is. You cannot change the past, focus on the future.

Speak to Your Manager

The first thing after a failed promotion that you should do is seeking a conversation with your manager. In a lot of companies managers and their employees maintain regular 1-on-1 sessions. These sessions can be informal but most often employees talk about their growth there and the manager is supporting the employee in this regard. If your manager is not supportive, you can still ask the right questions on how to get actionable results. Make sure to say that you want to get to the next level but first review your current position. We need to make a reality check.

For example, you could ask what are the current expectations of your position to see how your manager reacts. They usually show emotions and say what you need to improve on. If they do not, try to ask generic questions like what is the focus of the company and how can I provide value towards this goal for example. Now when coming to the expectations and goals, make notes. Share these notes with your manager so you are on the same base on what should be achieved.

Define Goals

In the previous chapter, we have learned that you should try to find the talk to your manager and figure out what they expect from you directly or indirectly. After the meeting, you should revisit your notes and figure out what the goals would be that you can contribute to the company to achieve the goals. These notes should be defined in Objective Key Results (OKRs). Objective Key Results are defined by having an objective, measurable goal. This is because these goals should be trackable over a longer time frame. A goal like “Need to learn more about Topic XY” is not a good OKR because no one can track objectively how far you got with achieving this goal. If you have such generic OKRs it might be worth it to always split them down into individual OKRs. For example, you could do different processes to achieve the overall goal “Need to learn more about Topic XY”:

Finish the course … by End of April (0 out of 14 chapters done)
Read the book … by End of June (0 out of 8 chapters)
Apply principle … 6 times by the end of August
…

With going into more details you can always find measurable OKRs. Even if it sounds stupid, it will give your manager and peers some overview of how well you are doing inside the company. Every OKR should also be linked to one of the leadership principles of your company if they exist. You can read how Klarna’s Leadership Principles work in another blog article.

After figuring out what the goals are, discuss them with your manager. Present them and ask for validation. Your manager might think you are over motivated or something but just says you want to have a track that you can follow to advance your career. Also, talk with your manager about how realistic the goals are. I would always give a lower estimate than what you have initially thought because overpromising is never working out in the way you want it. Underpromise and overdeliver is where you can shine and exceed expectations.

Track the goals

Now that Objective Key Results are defined, you can start working on them. It is hard to keep track of your work. Getworkrecognized offers a solution by reminding you via email notifications to track down on what you have done. Creating this backlog takes a lot of continuous work, but when you finally want to look back at what you have achieved you can create an easy overview. For example, in our application, you can see the log of your past weeks notes easily like this:

In general, we also recommend summarizing your goals regarding the OKRs once per month. It will give you an easier time to summarize goals on a large scale.

Speak to Your Manager...again...and again

After tracking your work notes for 2-3 weeks, you should talk to your manager again. Bigger companies might have scheduled 1-on-1 sessions between managers and their employees. If you do not, ask your manager if they have a time slot of 30 minutes left per week. Normally they agree to this and you can organize the meetings normally. Review the notes you have done before the meeting for 10-15 minutes and point out things you are struggling with. In the 1-on-1 session ask your manager how they can help you or would behave in your situation. Always see it neutral and review what your manager said also. Have an open mind. Also, from time to time, mention your achievements and how the OKRs are getting followed so your manager is not just seeing the asking/demanding side of yourself.

After having 1-on-1s for quite some time you should see progress in your notes. It could be hard to visualize but one indicator is how much in percent you are close to finishing your OKRs. Another way to visualize your achievements is by tagging your notes and run analytics over them. Different graphs could help you with how frequently you are working on different topics. getworkrecognized provides these graphs out of the box. Just keep your notes in our application and you get some graphs like the following for free:

Act Like you are on the Next Level

After having your OKRs defined, regular 1-on-1s, and being on track towards your goal, it is time for the next phase in your career. In one of the meetings with your manager, you should speak about what the expectations of the role above your level are. A lot of companies have a career matrix ranked by different levels and different areas.

Find the full table here: Google Sheet Example - Career Matrix

As you can see there are different topics and different levels. Assuming you are a Level 1 Engineer and aspire to get promoted to Level 2, you can have a look at the different topics. If you are strong already in Communication, have a look at the responsibilities and key areas that you could apply already. Create some OKRs regarding these requirements to act on the level. If you have room during your work left, even follow these principles of the targeted level.

Review Your Actions

As you read already in previous chapters, reviewing your actions is mandatory throughout the whole process. Reviewing the actions is hard though. A technique that helped and is supported in our application is tagging the notes. Every action you take regarding an OKR or even in a generic way can be tagged with a specific label. These labels are normally the company values or leadership principles. An example could be the Klarna Leadership Principles, that are also described in more detail in one of the recent blog articles.

Customer Obsession
Deliver Results
Let the team shine
Challenge the status quo
Start small and learn fast
Courage
Hire and develop exceptional talent
Detailed thinkers

The leadership principles differ from company to company, and some companies do not even have a vision or these principles. In these cases, you can look through a collection of different company frameworks since a lot of them are also quite generic. In our application you can find the LinkedIn 2020 Leadership Principles that include the following principles:

Creativity: Employees need to be creative. The ability and focus on bringing up new ideas let companies strive and grow. Creative people are contributing massively to this. Persuasion: For companies, it is important to share the “why” behind decisions so everybody is onboard and pursues the common goal. People can also question the “why” that is supported, but communication to colleagues and stakeholders why the “why” might not be the best reason is encouraged.
Collaboration: Working in a team motivates everyone. Every colleague is trying to be the best but also praising other people’s successes is an important part of the team culture. It increases trust and improves the productivity of the whole team and the company.
Adaptability: Businesses and companies are in constant change. During the digitalization age more than ever before. Employees need to adjust to new situations, team changes. This requires an open mind, professionalism, and the will to change according to the situation.
Emotional: Emotional intelligence is the ability to perceive, evaluate, and respond to your own emotions and the emotions of others. This describes how you react to other people’s opinions but also how you can present your thoughts to other people in a recognizable way.

These principles are quite generic and can be applied to most jobs and professions. Tagging your notes will help you to keep the notes organized somehow and this will be useful later on.

With tagging the notes you can also create better reviews. Most often the leadership principles contribute to specific OKRs defined in the process before. Connect them and see with your notes how these notes might be related to the OKRs.

The review cycle should be something you can also plan. Getworkrecognized recommends summarizing your notes monthly. With this monthly review, it will be also easier to focus on more important goals during your Self-Review or Performance Review. It will exclude unimportant notes but also highlights your most impactful contributions.

The monthly reviews can also be used in the 1-on-1s with your manager to discuss progress on the OKRs. In general, they will help you to have an overview of your biggest achievements helping you in your whole career.

Ask for your Promotion

One important of every promotion is starting the process. Companies normally do not want to give out promotions since they do not get a lot of value out of the promotion itself. It is expected for most employees to act on the next level already for getting to the next level. When the company is not appreciating this, not increasing the salary they can play with their employees, letting them do work outside of their responsibility additionally to what they get paid for. Companies most often act in their interest and deny or delay promotions to keep the pay of their employees low and increase profits of the company overall. Because of this process, an employee should be always showing the desire to get promoted and speak up. Otherwise, you might get ignored and left behind. Take your shot.

Preparation

As we learned previously, you should always ask for your promotion by yourself. But preparing for the promotion is an important part that should be done before actually requesting the promotion.

The first two steps are described in earlier chapters: Tracking your Work Achievements and Tagging + Grouping the notes. The Review is also mentioned in the last chapter. After all of this, you can go through your work achievement notes again and create a good Self-Review or Brag sheet. This document is the baseline for your promotion. It should include all major achievements but also weaknesses. We wrote a guide already on what to focus on while writing this document. Basic learnings are:

Structure by KPIs or Leadership Principles
Start with the "bad" things, give a good last impression
Write an outlook

The Talk

After preparing your brag sheet or Self-Review, you can contact your manager. Instead of asking for a regular 1-on-1, you can ask them if they have more than 30 minutes to review your current work. Regarding this talk, you can also say that you prepared a summary of all the work achievements you have reached in the past time. Link your brag sheet or Self-Review. Then wait for the talk.

Start the talk like a normal 1-on-1. Ask some soft questions first and get more serious over time. Try to bring up the promotion topic quite fast in the meeting. Something along the lines that you are doing work that is exceeding expectations heavily and you are acting already on the next level. A promotion would be the right next step for you so that you can even try to grow more and impact the company even more in a positive way. Now your manager will react. Pay close attention to their words and how they are laying these words out. If they are happy with you, they will promote you. Ask about a salary increase and all the legal stuff as well. If they react negatively ask why they do not want to promote you and what is missing for you to get promoted.

After the Promotion

If the promotion was successful, hey congrats. If not, work on the things that your manager has told you. One thing that stays always there is to write down your work achievements because work is getting forgotten quite quickly. Use getworkrecognized to have an efficient way to do this. Try now!

From Junior to Senior Software Engineer at Klarna in 2.5 years

Kevin Peters — Mon, 31 May 2021 12:23:50 +0000

A promotion to senior level in a software engineering career brings many benefits: More compensation, more responsibilities, and a better position in your career progression. Getting promoted is difficult though. But let me tell you how I have applied simple tips and tricks to get promoted to senior-level at Klarna, one of the technology companies in Europe.

After graduating from university in 2017 in Germany, I found a job based on an internship done during graduation. A small startup. But after 1.5 years I could not see my career progressing so quickly and growth opportunities were rare. So I decided to look around and after many rejections, I got an interview at Klarna. I do not know how but I completed the interview and got an offer and was hired as a Junior Software Engineer.

A reason I wanted to join Klarna was that finally, I would have many other software engineers around me that would teach me how to build products at scale. In startups, the requirements for a software engineer are completely different from what big companies want. You need to focus more on the product. Have to tinker with marketing and work closely with Sales. It is a great opportunity for most people since you will learn a variety of skills. In the end, the dream of most software engineers is to work at a big company. You will have more dedicated time to actually focus on engineering and of course, the money is better as well.

So let us look at what my progression at Klarna has been like.

Career Levels at Klarna

Klarna is really good at telling at which stage in your career you really are. They have a detailed career ladder based on different metrics. These metrics are symbolized through 8 Leadership Principles:

Customer obsession
Deliver results
Let the team shine
Challenge the status quo
Start small and learn fast
Courage
Hire and develop exceptional talent
Detailed thinkers

Based on these leadership principles there is a matrix that is built up similar to something like this:

Level 1 - Customer obsession:

An employee can put themself into the shoes of the customer
An employee understands how working on specific tasks helps customers

Level 2 - Customer obsession:

An employee is able to create tickets based on customer’s needs
An employee deeply cares for the customer and builds features that overdeliver on the scope of the ticket

There are of course a lot more levels for employees at Klarna. Currently, employees range from Level 1 to Level 8, where for Software Engineers level 1 is Junior and level 3 is senior. Further levels are harder to achieve and split up into an Individual contributor or management path which will be discussed later.

Initial rating during the hiring process

During your interviews with Klarna, you will get rated against these principles. Klarna’s interview process is quite standard in the technology industry and is built similar to this:

Recruiter call
Homework task, Leetcode-style questions
On-Site, normally a review of the homework task + additional whiteboarding problem
System Design
Behavioral Interview with the hiring manager

During this process and based on your resume you will get rated. Is this process fair? Might be, but you always have the option to negotiate your level at that stage. Especially the round about system design will decide how you get leveled.

Personally, I had little to no experience with system design tasks before since working in a startup did not expose me to such things. Luckily the system-design-primer guide exists that you can learn with and excel at those tasks.

Promotion rounds

As within every bigger company, there is a promotion window at Klarna. It appears to happen once to twice per year, even though the process is currently changing. But the windows are build up the same. Normally you start a conversation with your manager first when the promotion window is coming up (1-2 months before) and in that conversation, you have to feel if your manager is willing to put in your promotion request. Once this is validated you can ask them in the same meeting if it would be ok to send out feedback for a 360-degree review. This means that you send out a form to all your colleagues and they rate you. Of course against the leadership principles. This can take some time!

Once you have received all the feedback you gather and summarize it and present it to your manager. Your manager then has to decide if they put you forward to the next round of the promotion process. If they decide on it, then you have to basically write a short elevator pitch on why you should get promoted. That should be really short and be readable within a minute. Once that is done, the control is out of your hand. The promotion case will be discussed in a bigger group of engineering managers and stakeholders. Once approved you will receive your promotion.

I went through that process twice and what really helped me was reminding my colleagues of what I have done in the past 6 months or year. Most of the employees forget what they have done themself in the past period so they will definitely not remember what you have achieved. For this, I track my work on a daily basis, and before sending out the form to collect feedback I am summarizing my achievements in a small brag document. 1 to 2 pages long. This will help my colleagues to remind them of where we actually worked together. This brag document I will attach to the form to collect feedback so the colleagues have an easy way to fill out the form.

The career path for a software engineer at Klarna

The engineering paths in Klarna are described quite clearly. As a software engineer, you will rise through the ranks from junior to senior normally with a focus on management but also contributing characteristics. Once reaching the senior level you will have to learn what you want to do in the future life. Stay on the individual contributor path or go into management. Both paths are valid approaches. Up to senior-level, it will not really make a difference on what you focus on, you need to have a substantial amount of skills within core engineering but also management.

Opportunities I took

So how did I rise through the ranks? As there is a system with rising through the ranks, you can game the system of course. There are different parameters that you will work on during the promotion process but it is, of course, an individual approach.

Once I landed at Klarna, I realized people give a lot of thought to leadership principles. If it is about product decisions or just how to implement a new feature. The leadership principles should be applied. A good way to see that is in the discussion. If someone’s decision is violating the leadership principles a lot of people will argue against that decision. In general, it is driving the development at Klarna forward. So make use of these leadership principles in discussions.

Follow the career ladder

As said before, Klarna focuses a lot on Leadership Principles. In my first promotion/feedback round I got a lot of stellar feedback, but also a lot of points on what to improve on. I had a lot of 1-on-1’s with my manager to focus on my growth goals. For example, we discussed what I could do within the next month regarding development work that will help me. At the beginning at Klarna, I struggled with the “Let the team shine” principle a lot. I did not had ideas on how to present the team. So my manager proposed different things:

Join a group outside of the team for voluntarily work like maintaining third-party libraries used by the team within Klarna
Or joining the engineering blogging or open-source group

I decided on the second step and quickly checked what is needed to get to the next level to fulfill these requirements. I represented my team within those meetings, but also myself.

But also on the team side, I got assigned to interesting tasks that helped me to grow. Working on creating new services and making sure they are scalable to millions of requests. I got put together with more senior engineers to do pair coding with them, but we also include mob programming within our team, a technique where the whole team gets together and codes something.

These things really helped me to go from level 1 to level 2. For the transition from level 2 to level 3 the circumstances are a bit different. You have to work on different categories that are mentioned now.

Lead the Team

When reaching level 2 and trying to get to level 3 another skill is getting a lot more important: Leadership. What does this mean? As a senior engineer Klarna expects from you two important things basically:

Can you influence the product and lead implementations that your team creates or you come up with?
Are you teaching people to code in a well way and can make developers at Klarna more efficient?

All of these things can be tackled and be focused on. Once I reached level 2 I put a lot of focus on that. I introduced the technique of creating technical design documents in our team. These are documents that sketch out the feature and architecture. They also lead the conversation about trade-offs of implementations and are living documents for taking decisions with the product manager. It helps us to get a clear mind about a feature. Once that is done it is collaboration time with your product owner on creating JIRA tickets for that feature. Once tickets are estimated and assigned, maybe go over them with the assigned person to help them understand each part of the ticket. Be descriptive in the ticket descriptions and help to give pointers on what to look out for. This is especially useful for team members that are new to the team. What I always like to do is pasting the paths of the core files that would need to be touched for the files. Based on that even junior developers would be able to code the feature mostly independently.

This gets us to the next point as well: Leading developers. To get to level 3 at Klarna you have to support the engineers in your team. It is more a job of educating and pair coding with them. Give them space and the right tips and the right time. This is important for your team level. But it can get even more important outside of the team.

Opportunities outside of your team

As mentioned before, teaching developers to be more efficient outside of your team is also a huge priority to get promoted to level 3. Next to it, it becomes important that you work together with people outside of your team. This will eventually bobble up to other engineering managers that you are doing good work with their engineers. There are different activities like changing code for other teams and so on. Just receiving recognition. I did it a bit differently.

Within the Domain

At Klarna, we have a concept called domains. Domains are small subsections of the business. For example, we have a merchant domain that just deals with the merchant-aspect of the business but also a domain for the Klarna app. Some are more B2B focused, some more on the B2C side. Overall you can say the teams work closely together but each team has its own KPIs. But what becomes more important are the domain KPIs. Your team’s KPIs will be looked at by some people but if you made larger contributions to the domain’s KPIs people will start recognizing you.

For example, in our domain, we are using a monorepo. A big repository that holds almost all services used in our domain. Improving this monorepo helps everyone in your domain to build better products and focus on features and implementation rather than infrastructure. I found many tasks like that, like creating a project to automatically update package dependencies throughout the monorepo. This will give you exposure to a wide audience and will make your case for promotions stronger.

Open Source

Most of the technology companies promote open source in one way or the other. For Klarna it was always the plan to open source part of the software to give back to a community of developers. The process was not there, so the company initiated a group regarding open source at Klarna. This group was the catalysator to set up a workflow, make sure legal requirements are met, and promoting open source when possible. I joined that group initially and build up the processes and many more things regarding the topic. For example, we wanted to have an incubator set up where projects live in private first before getting open-sourced. This and many other smaller projects helped me work with various other engineers and get recognition. I even presented the results of a hackathon during an engineering all-hands meeting in front of the hundreds of engineers working at Klarna, challenging but rewarding.

Blogging

Branding is really important for Klarna. It blends in with their leadership principle called “Hire and develop exceptional talent”. Blogging about the technology used at Klarna will help with hiring in the long term because it will create some kind of trust in people applying. The biggest companies blogging about their technology are probably:

All of them succeed because of great engineers that get hired. And part of the reason might be the blog as well. By sharing technological information you can create an environment of learning and discovering new things.

I helped authors within Klarna to create blog articles. I found ideas and asked if people would be willing to create a blog article regarding some interesting topics. I helped them with graphics, copywriting, proofreading, and many other things. And here is the important part again: I worked with other engineers. They will know about me and their manager will most likely also know about me by then. A better standing for me in the company.

Be proactive, Think ahead

A big part of my promotion rounds was that I was proactive in my action, plans, and projects. It all starts with asking for feedback. I prepare other people to remember what I have done so they can give me feedback in an easier way. I focus on my weaknesses and try to improve them actively.

In general, I was also looking at what the company’s or domain’s KPIs were and how they played with the KPIs of our team. I challenged my product owner a lot and made it clear that I want to work on certain things because it will help the company in the long term. I also had the opportunity to join a temporary team dealing with major support problems that were brought up at the domain level. It was great exposure to a new development space, I worked again with many new people, but most importantly, we solved the domain’s problems in record time. It was stressful but rewarding and the promotion was part of it. Look out for teams or projects that will help the company grow. Do not just sit there and grind the tickets you are assigned to.

Write up your achievements

An important part of my journey was gathering feedback and having strong evidence of my achievements. How have I made this possible? I wrote it down.

Writing is an essential skill in your career but keeping a work diary is not difficult. Just at the end of every day write up what you have done throughout the day. Remind yourself of your weaknesses and how you improved them. Keeping these notes will be super important. With getworkrecognized, I tracked more than a year of work notes and it helped me to write my self-review but also receive stellar performance reviews from my peers.

A simple system I have used is to track all work but tag the notes. Assign them to the leadership principles Klarna has, and you will see where you have to grow or where you need to focus on in the next weeks a bit more. Make a plan and put some tasks around that into the sprint or your upcoming weeks.

The #1 tip to familiarize with new JavaScript codebases

Kevin Peters — Fri, 28 May 2021 09:04:06 +0000

The #1 tip to familiarize with new JavaScript Codebases

In my years as a software engineer, I have probably looked at hundreds of codebases. Too many to count. I struggled a lot with understanding where the relevant code is most of the time. Normally, asking for help what I should look for and guidance in tickets will bring me forward. Slowly and surely I will understand what the code is doing. And you will too. Some people are better at this and some people will be slow. No shame. Most code is complex. But I found a simple tool that will make it easier for you. It is called code-complexity and you can use it as the following code snippet shows:

npx code-complexity . --limit 20 --sort ratio
# You can also use --filter '**/*.js' to use glob patterns to filter files

It will return an output like the following:

file	complexity	churn	ratio
src/cli.ts	103	8	824
test/code-complexity.test.ts	107	7	749
.idea/workspace.xml	123	6	738

This will show the biggest and most changed files. The likelihood that these files are crucial for understanding the application is quite high. Read through them and understand them. What this data means in detail will be explained in this blog article now.

Complexity and Churn

In this chapter, I will explain to you the concepts of complexity and churn when it comes to code. It is the baseline to understand the technique we are using here to improve your understanding of a codebase.

What is Complexity?

Complexity can be defined in different ways. The level of nesting of functions is normally used as a measurement of how complex code is. Code with small functions and composed behavior is normally more readable and easy to understand. So we could say that complex code also consists of a few functions that are far nested and it is mostly true. Nesting is hard to track though so we could find another metric somehow.

With long functions normally there comes large files as well. People tend to put everything into one file if they also put a lot into one function. So in theory we could take the lines of code as a measurement as well. There are a lot of utility packages out there that solve this problem. One of these tools is called sloc. It will output the number of lines of code within a file. But do not use it directly. The tool I mentioned before includes this by default.

So in conclusion we can say complex files are either super nested or super long. One of these things normally comes with the other so that’s great to hear because analyzing the length of a file tends to be easier than nesting.

What is Churn?

Churn is a bit more complicated to explain. But let us start somewhere. A churned file is a file that has a lot of changes. But what does this mean?

A lot of changes to a file happens when yeah, a lot of people have changed the file. But how can someone measure that? The git history is telling us how often a file was checked in. So we can make sure with that how likely a file is to be changed. Normally this means files of this type are the main point of the application. A problem that occurs though is that often there are configuration files included here, but you can simply exclude them for this analysis.

What can Complexity + Churn teach us?

Now, after learning what complexity and churn mean, we can focus on the combination of them. Files that normally charge a lot but are also really complex should be normally refactored. And most of the time, with that, it is natural that these files might be the core of the application. The basic logic is written in them directly or in files related to that. So let us check how we can analyze that further.

Checking the files in detail

My technique to check the files in detail is quite simple. I first look over the file and check what the exported functions are called. Ideally, I write them down. Internal functions are firstly not important to understand. Once I have an overview of all the exported functions I foremost check if there are any unit tests. If the functions have parameters as well, then I will try to write them down as well. With TypeScript or Flow types, this gets, even more, easier to get an overall feeling of the structure.\

Unit tests are a good first approach to see how the functions are working. To understand functions you probably just need to look at the input, the function name, and what it is returning. In most of the cases, types even support you with that, and unit tests will show you edge cases for the function and how it can be used. So that’s mostly enough to understand the function. At least if you know the programming language. If you want to get deeper into the function feel free to, but you do not have to do that. Why? Explained in the next chapter.

Why do not understand every detail?

Understanding a function in detail can be important. But during onboarding, a lot of other things are more important. You will not be able to understand every bit of the application within a short time frame, but understanding the core parts should give you a track of where the core logic of the application is executed.

With that knowledge, you can jump into the first issues for you. Ideally, the team has prepared smaller tasks in the codebase to give you a nice onboarding experience. If that is not the case, ask your manager or senior engineers in your team if any of the current issues is suitable for you. Make sure to transmit your gained knowledge of the codebase though so they understand your knowledge level.

A good idea for the first issue is also to do pair programming with other software engineers from the team. Make sure to tell them that you want to type mostly and they should be more of supervisors so you learn how to navigate the codebase by yourself. Because of that guided onboarding or easier tickets, you do not have to jump into details. The details of the code will be discovered now during the implementation phase of fixing bugs or adding features. The more tickets you will do the more you learn about the codebase in detail. But look back at churn and complexity because it can change over time.

Debugging the details?

Having to work on the code base now will also involve another bigger thing: Debugging. With your first tasks, you will probably learn already how to run the application locally, run unit tests, and integration or E2E tests if these exist. These become vital once you implement the feature because adding tests will make sure your application is working as expected. Often these tests cover a lot of code though and are kind of abstract. In these cases, you have to learn to debug your code. Because most of the tests are being run in a Node.js environment we will have a quick peek into how to debug Node.js-based applications. Most engineers use console.log to debug and it is completely valid. But if you need to follow larger structures of code I can recommend using a proper debugger. JavaScript and TypeScript support the debugger keyword, nevertheless, it is a bit tricky to run your test suite and have a nice debugger experience because within Node.js it is a bit difficult to spawn a browser instance’s developer tools and connect it to the program. Another option would be to use your IDE or Editor to connect a debugger supported by your coding user interface. For example, Visual Studio Code supports debugging Node.js applications directly in the IDE. A guide on how "Node.js debugging in VS Code" can be found here.

Debugging is an art in itself. You should get comfortable using breakpoints and what the debugging functions "step over" and "step into" mean. These will be extremely helpful when debugging nested functions.

Some examples

In this chapter, I will go through some codebases with this technique to explain where the main core of the application is and how the process mentioned above can help you to get familiar with the code base quicker.

Blitz.js

Blitz.js is a framework built on top of Next.js. It describes itself as the Ruby on Rails for JavaScript/TypeScript. The team is working for more than a year on this framework and it would be quite interesting to see where the core of their logic is being placed.

The first step, of course, is to clone the repository to a local folder and then run:

npx code-complexity . --limit 20 --sort ratio

This will output the following table:

file	complexity	churn	ratio
nextjs/packages/next/compiled/webpack/bundle5.js	91501	1	91501
nextjs/packages/next/compiled/webpack/bundle5.js	91501	1	91501
nextjs/packages/next/compiled/webpack/bundle4.js	74436	1	74436
packages/cli/src/commands/generate.ts	228	28	6384
packages/cli/src/commands/new.ts	177	35	6195
packages/generator/src/generators/app-generator.ts	235	23	5405
packages/generator/src/generator.ts	283	19	5377
packages/server/src/stages/rpc/index.ts	184	28	5152
packages/server/test/dev.test.ts	190	27	5130
packages/core/src/types.ts	160	28	4480
packages/server/src/next-utils.ts	176	25	4400
packages/generator/templates/app/app/pages/index.tsx	240	18	4320
packages/server/src/config.ts	116	37	4292
packages/core/src/use-query-hooks.ts	184	22	4048
nextjs/test/integration/file-serving/test/index.test.js	3561	1	3561
examples/auth/app/pages/index.tsx	210	16	3360
packages/cli/src/commands/db.ts	75	44	3300
.github/workflows/main.yml	132	24	3168
packages/cli/test/commands/new.test.ts	141	19	2679
examples/store/app/pages/index.tsx	181	14	2534
packages/display/src/index.ts	158	16	2528

As you can see, there are a lot of unrelated files that could be filtered out like the compiled folder but for an initial analysis, this is enough.

We can see multiple directories being important here:

packages/cli
packages/generator
packages/server
packages/core

If we get a task we would at least know already where to look for related code. Initially, I would try to understand the packages/core files to understand what they are doing. Understand the tests if they exist and then you should have a good grasp of what Blitz is doing.

React.js

React.js is a frontend framework that almost every web developer knows by now. What most people do not know is how the codebase is structured and what are the core parts. So let us have a look at it.

npx code-complexity . --limit 20 --sort ratio

Running the command will lead to the following result:

file	complexity	churn	ratio
packages/eslint-plugin-react-hooks/tests/ESLintRuleExhaustiveDeps-test.js	7742	51	394842
packages/react/src/tests/ReactProfiler-test.internal.js	4002	95	380190
packages/react-reconciler/src/ReactFiberWorkLoop.new.js	2373	139	329847
packages/react-reconciler/src/ReactFiberWorkLoop.old.js	2373	114	270522
packages/react-dom/src/server/ReactPartialRenderer.js	1379	122	168238
packages/react-reconciler/src/ReactFiberCommitWork.new.js	2262	71	160602
packages/react-devtools-shared/src/backend/renderer.js	2952	54	159408
packages/react-reconciler/src/ReactFiberBeginWork.new.js	2903	53	153859
scripts/rollup/bundles.js	760	199	151240
packages/react-reconciler/src/ReactFiberHooks.new.js	2622	56	146832
packages/react-dom/src/client/ReactDOMHostConfig.js	1018	140	142520
packages/react-reconciler/src/ReactFiberHooks.old.js	2622	50	131100
packages/react-reconciler/src/tests/ReactHooks-test.internal.js	1641	74	121434
packages/react-dom/src/tests/ReactDOMComponent-test.js	2346	51	119646
packages/react-dom/src/tests/ReactDOMServerPartialHydration-test.internal.js	2150	49	105350
packages/react-noop-renderer/src/createReactNoop.js	966	109	105294
packages/react-reconciler/src/ReactFiberCommitWork.old.js	2262	46	104052
packages/react-reconciler/src/ReactFiberBeginWork.old.js	2903	35	101605
packages/react-reconciler/src/tests/ReactIncrementalErrorHandling-test.internal.js	1532	62	94984
packages/react-refresh/src/tests/ReactFresh-test.js	3165	29	91785

What we can see here is that two sub-packages are probably the most interesting to understand:

packages/react-dom
packages/react-reconciler

Understanding React Fiber and how react-dom's partial renderer is working will give you a good idea about React's architecture. A good thing about the code within React is that it is well documented with comments even though it is complex at first.

Venom - A TypeScript Client for Whatsapp

Venom is a library to interact with Whatsapp. You can send messages via this library and do many more things. It is a bit more practical because on such applications you will work mostly in your day-to-day job. So let us run our usual command:

npx code-complexity . --limit 20 --sort ratio

file	complexity	churn	ratio
src/lib/jsQR/jsQR.js	9760	5	48800
src/lib/wapi/wapi.js	474	44	20856
src/api/layers/sender.layer.ts	546	36	19656
src/lib/wapi/store/store-objects.js	362	24	8688
src/controllers/initializer.ts	178	48	8544
src/lib/wapi/jssha/index.js	1204	5	6020
src/api/layers/retriever.layer.ts	171	29	4959
src/types/WAPI.d.ts	203	24	4872
src/api/layers/host.layer.ts	258	17	4386
src/api/layers/listener.layer.ts	206	21	4326
src/controllers/browser.ts	141	29	4089
src/controllers/auth.ts	192	21	4032
src/api/model/enum/definitions.ts	589	6	3534
src/api/whatsapp.ts	95	30	2850
src/lib/wapi/functions/index.js	97	24	2328
src/api/layers/profile.layer.ts	82	22	1804
src/lib/wapi/business/send-message-with-buttons.js	323	5	1615
src/api/layers/group.layer.ts	115	14	1610
src/api/layers/controls.layer.ts	76	20	1520
src/api/model/message.ts	114	11	1254

What we can see here is that there are these directories which are from importance:

src/lib
src/api
src/controllers

As we can see from the src/lib directory, the files included are automatically generated. Ideally, we can filter them out but for now, let us look at the other files.

We can see that src/api/layers/sender.layer.ts and src/api/layers/retriever.layer.ts are not complex but have a lot of changes. So every time a feature is added or deleted these files are touched. These are the core files of the application and understanding them will give you a good grasp of how the codebase is structured and what you should focus on.

Where does this technique come from?

This technique of analyzing a codebase originally came from a book that handles refactoring large codebases via a process: Software Design X-Rays by Adam Tornhill. It is a great book and teaches you a lot of ways to structure your code and what parts are worth refactoring. A great book. I think every software engineer should have read it at some point because it will help them to understand a codebase differently. With working on a project, people will get familiar with different parts of the software and of course, they will have their special "area" of code where they are super comfortable. If this code is good and understandable is another question though, that this book tries to answer.

Based on the refactoring efforts, we can also use the knowledge to see which parts of the application are important. Hopefully, I explained this in this blog article to you.

Other Languages

The tool code-complexity is closely coupled to JavaScript and TypeScript-based codebases. For other languages like Java, C#, Python, or PHP there are other tools, but one tool that is generic and works for most of the codebases is code-maat. It is a tool created by the author of the book mentioned in the chapter before.

With that, you can analyze a software project as well and come to the same conclusions as mentioned in the blog article.

Conclusion

I hope you liked this article and made your life a bit easier. Coming to a new code base is difficult and especially with the ever-changing JavaScript world, it is difficult to follow. With the tools and processes presented in this article, you might have an easier time actually fit well into a new codebase. Feel free to share this article with your workers and also tell them about the techniques you are using. Most of the developers I know do not know about the churn and complexity analysis and it might be really helpful for everyone. So share it!

Personal branding as a Software Engineer

Kevin Peters — Mon, 22 Feb 2021 09:18:51 +0000

Personal branding as a Software Engineer

Recently at work, a tool was discussed that would rate the GitHub profiles of employees and applicants. The tool is probably not ethical to use - that was concluded but a discussion happened around another perspective: Will a good GitHub profile make you a better developer? Let us have a look at this problem and see how you can apply some simple things to pimp your GitHub profile and make yourself more valuable.

GitHub and the job market

GitHub is a platform to host code. But for many people, it is becoming social media. Discover new trends, follow new people, and watch other projects. See what other people are working on, how often they commit code, and many more things.

GitHub's main use case is to store code. But all the other factors play a lot bigger role these days. You can kind of compare it to your CV. A nicely designed CV will convince more hiring managers to hire you. Having your CV with multiple pages or unnecessary content will probably contribute to a rejection of a job. A CV should be short and convince the hiring manager that you can add value to the business than the salary they would pay you. That is the main incentive for a company to hire you.

The job market is getting more competitive every year though. More and more university students want to get a job in the computer science field, but also with the rise of Bootcamp graduates the market for entry-level jobs increases the pool of available talent. You can see that easily by inspecting the entry-level job descriptions, requiring multiple years of experience in technologies that will not be taught at universities. Hence, these Bootcamps were created to fulfill the market needs. To understand how this affects the market we have to look at the market needs though.

Currently, companies are looking for a wide range of Software Engineers. Mostly senior-level engineers. But why? The answer is quite simple: They do not want to train Software Developers and instead let them build their product that can be also maintained for a long time. If you leave fresh graduates to this, it might work, but most often wrong decisions will be made that will be learned from, but for many companies, this is bad, because it could mean that they would need to invest in long-term even more money. Short-term gains but long-term losses. For the junior-level developers, this is the perfect environment because they can learn from their mistakes. Startups like to have this risk more often, but also pay worse. But join a startup if you like this. The case that was described before will mostly apply to companies where engineering is not a first-class citizen. Simply not a tech company, where engineering is an expense rather than a business opportunity.

What are companies looking for?

Larger companies, including FAANG (Facebook, Apple, Amazon, Netflix, Google) and similar, are more open to hiring junior-level engineers. Why? Simply because they have the resources by having more trained senior-level engineers that know how to teach other developers the "right" way of doing things. These companies bind employees with stock options to the company for a longer time, so the tenure is worth it and the employee can contribute more to the revenue than they are costing.

So as you can see, the market for junior-level developers looks quite bad right now. But there are some things you can act on: Your marketability. To understand what falls under this, let us look at the different companies and their needs again:

Startup small, < 15 people

The employee can build software fast, build prototypes
Employees are comfortable to touch different work areas like Sales, Marketing, Product and similar
The employee should have good marketability skills to promote themself but also the product

Startup medium, >=15 people

The employee can build software quite fast, build prototypes - but should be maintainable for longer than a year
Employees are comfortable to touch some different work areas like Sales, Marketing, Product and similar
Marketing skills get less important

Normal Company

Tech is not so important, employee should be able to maintain current software
The employee should be able to add features from time to time, no huge time pressure normally
Other skills won't be required

Big Tech Company

Tech is best paid and the powerhouse of the company, innovation is driven by tech
The employee is challenged to contribute to the product as much as possible, innovating
Product focus can be also completely technical, like compiler-focused. Just increasing performance and so on
Other opportunities like Marketing can be taken but will be challenging

So the different companies have different requirements. How can someone junior convince these companies to hire them? Normally, the most important part of all companies is experience. Internships, real-life projects, and past full-time positions. During university or after your Bootcamp you can look for internships. The entry bar for these kinds of positions will be far lower than full-time junior positions, and most of the companies will transfer the internship into a full-time position after. But even then, you will probably compete with multiple hundred other applicants. So how to stand out? This brings us back to our original discussion: GitHub.

GitHub will be used to check your ability to code. But what do hiring managers check? Let us bring into the position of the hiring manager. They do not have a lot of time and they know how "good" software projects look like. Mostly, when you are new to a project you expect some guidance on what the software is doing and how to run it. you. Make sure the README includes examples, simple setup instructions, and more and more examples. Do not just focus on the text, but include rich media like images or videos into the README. Make sure you get the copyright and many more things. I will write a guide on how a good README looks like.

Otherwise, a big part of your GitHub profile is the profile page. You see different things like basic account information that you should fill out. Use a good picture where someone can see your face. This will make sure people interact with real humans. Furthermore, the profile page includes three more components: a custom profile README, which is optional but good to have. You can find some documentation here: GitHub Docs | Managing your profile README. Also, make sure in this README why a company should hire you! Make sure to explain how you can contribute value to their company and increase the revenue and profit of the company. Something along the line:

I am a Software Engineer with a focus on Frontend Technologies. In my projects, I used several growth hacks for the user experience to increase engagement and drive users to the project. I know basic SEO terms that can help you with the marketability of your product. Feel free to check out my projects below:

Project X Y (JavaScript, Node.js, TypeScript)

Project Z (Java, …)

…. I am currently seeking new opportunities. If you want to work with me, feel free to message me via email.

This copy will make sure that you spike interest in the hiring manager. It will drive them to the projects. With perfect README's you are doing good about that point.

Another thing recruiters or hiring managers might look at is the contribution graph. But honestly, it is not a good metric to look at. It is nice to have but should not have a direct impact on your employability.

GitHub as a Networking Tool

Most software engineers look for growth. They want to become senior-level, earn more money and have a more easy life. Or they want to grow to develop their solution. There are so many things. But what is important to understand is that most of these things can just be done within a team. Creating a startup is incredibly hard. You would have to focus on multiple fronts like Marketing, Sales, Product, and Engineering. The complexity is immense and working with other people is important. To get other people to work with you, you must know them. One opportunity would be GitHub. Be open to contributions and work with other people. For example, during Hacktoberfest, you could prepare your projects for contribution. I will write a detailed guide on that. But in short: Create a good README for contributors, that is targeted a bit differently, create easy-to-understand issues, and stay open for any request. During hacktoberfest just tag your repository and issues with the required issue and you will soon receive many contributions. Ask for feedback but also connect to the people. Ask for a follow on Twitter/GitHub/LinkedIn just to keep in touch. These opportunities will pay off at some point. And even if not, you are passively building an audience that will help you to find cool positions since you never know where the people will end up working at, maybe Google, Netflix, or a startup you like.

The network effect at GitHub is huge. So, use it. There are so many opportunities to connect with people as long as you are providing value somehow to each other.

Other Platforms

There are many other platforms where you can connect to other professionals. Social networks are probably the biggest. Twitter, Facebook groups, or LinkedIn. Just sign up and see what fits you the best. There are also a lot of other communities like Discord servers, IRC channels, and similar communities that you can join for free. Try to provide value on these platforms and you will see your network growing slowly but surely and opportunities will arise out of this.

Conclusion

Even though the discussion in my company that I told, in the beginning, was pointed out a different issue, it shows that your personal brand as a software engineer is of enormous importance. Employers will actually care about your GitHub somehow and networking is more important than ever these days. So make your GitHub profile great 🎉