DEV Community: Simon Mannes

10 Great Questions To Ask To Become Familiar With a Huge Codebase

Simon Mannes — Fri, 14 Jan 2022 00:00:00 +0000

You've made it.

You got through the interview process, and now you’re part of a new team.

But as you get access to the repository, you’re overwhelmed. It’s huge. And full of stuff you know nothing about. So. Much. Unfamiliar. Code.

Ask Questions

Your mentor, colleague, or lead dev has created a meeting to walk you through the code base. Here are some questions to get the most out of that time:

Understand the goals
- “What are the goals of this project?”
- “What does this software do?”
Learn about the history
- “When did this project start?”
- “Who started it and how big was the team at first?”
- “How many people have worked on this over the last few years?”
Get to know the architecture
- “Which technologies do you use?” Go through dependencies, e.g. in package.json.
- “Did you do any major refactorings recently, or are you currently doing a major refactor?”
- “Which architectural concepts do you follow? What should I read up on?”
Find out more about their processes
- “What is your process regarding pull requests?”
- “Can you walk me through your release process?”

Apart from that, someone should take you on a tour through the codebase.

Your First Task

Your first task should be small and easy to start with, because:

You’ll need to get everything running locally
You’ll get familiar with the processes from assigning a task to merging a pull request
You won’t need to get too much into the code base

That’s it. Now you’re ready for your first big task.

3 Tips For Your First 3 Weeks

Three tips for your first few weeks:

Do tasks and ask questions.
Pair program whenever possible.
Let the team know how the onboarding experience was. Point to outdated documentation or unclear parts of the codebase.

Have a “Why Conversation” With Your Side-Projects

Simon Mannes — Tue, 26 Oct 2021 00:00:00 +0000

Taking a break from something allows you to see it more clearly.

It's the same with code, projects, and people.

If you return to a piece of software you have written 6 months ago, you'll think "how could I ever write this?" You'd do it differently now because you have practiced and learned.

Being away over the weekend makes me appreciate my wife even more when I'm back home.

And taking a break from a project is a great way to reassess the direction you're taking.

I did a summer break from my programming blog to reflect where I want it to go.

These are the questions I asked myself to find a new perspective on my blog during my summer-break from it.

You can use them on your own side-projects.

They work because you aren't doing side-projects for their own sake. You always have some goal with them, even if it's just "learning Flutter".

The Strategy: What × Whyⁿ × How

Basically, we need to find the deepest layer of "why", and then find a better solution for this why.

This is the general strategy:

What am I actually doing here currently?
Why am I doing this? What am I trying to achieve? What were my goals when I started this?
Why are these goals important? Why might they not be important?
How can I achieve the desired result?

Using The Strategy On My Blog

I don't want this to just be a boring lecture, so let's dive right into how I applied this to my blog.

What exactly am I doing currently regarding my blog?

Before the summer pause, I did 1 article every week, and 1 newsletter every two weeks.

The articles were from a variety of categories. In some, I shared my experiences as a software engineer or wrote about best practices. In others, I went deep into one technology, like my Gridsome framework series.

What are my goals with this blog?

Now, we need to find out the first layer of "why". The surface-level goals of this project.

From the top of my head, I have three goals with this blog:

Give something back to the dev-community
Get onto the radar of potential freelancing clients
Be googleable
Practice writing

Why are these goals important? Why might they not be important?

My whys for these surface-level goals:

Goal "Give something back to the dev-community"

Why:
- As a developer I use so much open-source stuff every day. Programming languages, libraries, frameworks, documentation, articles…. Everything created by other people, most often in their free time. This feels like I should give something back, too.
- And that is important to me because I don't want to profit one-sidedly from something, that's not who I want to be.
Why not:
- It's time-consuming and sometimes tiring.

Get onto the radar of potential freelancing clients

Why:
- Blogs are one of many ways to be found by potential clients. If you write a lot about a certain topic, hold conference talks about it, and write a book or two, people view you as an authority on that subject. That's a great way to get clients.
Why not:
- With typical project lengths of 3-12 months, I don't need that many clients. I already have a good network and receive many project inquiries every month.
- I also don't want to be a freelancer for the rest of my life. It's only one small step in my multi-year plan towards freedom.

Be googleable

Why:
- It's cool.
- It plays into the point above: being found by potential clients.
Why not:
- I'm not sure how much I value privacy. Once stuff is on the internet, you can't remove it.

Practice writing

Why:
- Writing is a very important and valuable skill as a developer, even more so if you work remotely.
Why not:
- I already practiced this a lot with my blogs and newsletters.

How can I fulfill these goals?

Last, we need to think about minimum viable solutions to achieve the goals from above:

Give something back to the dev-community
- One possibility here would be to only share deeper insights and experiences in longer articles.
- I could also donate to OS projects so other people can spend more time improving the tooling I use every day.
Come onto the radar for potential freelancing client
- This point is valid, but I think it's unnecessary to think about getting more (or better) clients at the moment. I don't plan on staying a freelancer for long, so I think 2-4 clients at standard market rates could be enough.
Be googleable
- A LinkedIn profile, a Twitter profile or a business-card-like website are enough for this.
Practice writing
- I already write a lot apart from this blog, e.g. NM newsletters.

So three of my four goals are no longer as relevant as before, and there are different ways to achieve the first one.

This gets me to the conclusions I took from this after-break exercise.

Changes to this blog

I only want to publish when I have to say something.

I know that quantity leads to quality.

But with over 185 pieces of content published on the web in the last 20 months, over 90 on this blog alone, I've done pretty well on the quantity side of things.

I really enjoy writing for and working on my second blog, Nerdful Mind. But I rarely enjoy writing for mannes.tech.

So, because of the why-investigation above, I'm conducting an experiment:

Only write about things I have fresh in my head (easy to write about), or topics I enjoy writing about (that are still relevant to this blog)
Publish at least once a month
Email this blog's list once a month
Write at one specific time slot every week and only write more if I want to

This experiment will run until February next year to collect enough data.

How you can check your side projects

What are you working on that takes a lot of time?

Do you know exactly why you're doing it? And why you're doing it the way you're doing it?

To find out, ask yourself the questions from above:

What exactly am I doing currently regarding X?
What are my goals with X?
Why are these goals important? Why might they not be important?
How can I fulfill these goals (more efficiently)?

If you enjoyed this and want to do me a favor, follow me on twitter @simon_mannes.

I also write a newsletter about mindfulness and personal growth for developers, check that you here: https://nerdfulmind.com.

Why Am I So Bad At Coding?

Simon Mannes — Wed, 01 Sep 2021 17:24:54 +0000

You started developing software a long time ago, but you still feel like you're bad at coding.

You're not alone.

Many developers feel this way.

But most devs are, per definition, around average. So you're likely a decent software developer.

The reason you still feel like you're bad at coding is that you're falling into one of two categories:

1. You're Having Impostor Syndrome

People have talked about this before, but developers are prone to the impostor syndrome. We feel like we've just gotten lucky in that test. The interviewer only posed challenges we practiced.

And nobody has asked questions yet that could reveal us.

Reveal that we don't know nearly as much as we should.

It could blow up at any moment.

Bullshit.

It can feel like this because:

We read blogs every day where rockstar developers from big-name companies write about all the crazy scalability challenges they solve and how they manage their 10'000-pod Kubernetes cluster. Yes, this may all be the case. But it doesn't negate your own challenges.
The pile of things to learn grows larger every day. And you can't be a good developer if you still need StackOverflow or editor autocomplete to know which braces you need for a switch-case statement, right? Right? Wrong. You don't need to know everything.

A good developer isn't somebody who knows everything and always finds the perfect solution on the first try. A good developer is someone who solves challenges, big and small, one after the other. Together with their team or with the help of random people on the internet. With a better-than-random judgement of what might work.

So if you have done a few projects and are working as a software engineer in a team, don't question your expertise. Just continue learning.

Remember: a real impostor would never question if they were an impostor.

2. You Don't Have Much Work Experience

Maybe you're not yet working as a professional developer.

Or you have just started a dev job.

This can feel as if you'll never make it to the "professional developer" side.

But remember this.

You have learned to walk, to speak, and to write, and billions of people have learned that before you.

And just as millions of people before you, you will learn to be a professional developer.

It just takes practice.

And practice.

And more practice.

Solving one challenge after the other.

So, What To Do If You Feel Bad At Coding?

If you are already a professional developer, I recommend you to:

Check out this RailsConf talk, which was one of the first talks around impostor syndrome for developers (money quote: "the funniest thing was my brain played this great trick on me: it told me I didn't have impostor syndrome bad enough to give a talk on impostor syndrome.")
Make (and keep) a list of every project you have completed and every challenge you have overcome - be proud of them and keep them close for the next time you feel down

If you're just starting out on software development, I recommend:

Check out Danny Thompson for motivation. He went from a job at a gas station to working for Google because he learned to code. And he is sharing his excitement with everyone else.
Keep doing learning projects. Apply for and prepare for a coding interview when you have done 2-3 personal projects.

If you liked this, you'll like my weekly newsletter even more! Each issue of Nerdful Mind contains one mindful idea, three reading recommendations, and one mindfulness exercise.
It's fueled by 7 years of software development and meditation experience, and will help you become a better sofware engineer and more content with what you do.

10 Ideas How To Manage Stress As A Software Engineer

Simon Mannes — Wed, 25 Aug 2021 09:05:25 +0000

Developing software can be stressful.

Deploying to production on a Friday evening, knowing the week isn’t over yet.

That deadline for a feature next week, which you haven’t even started yet because there’s no way to extend this undocumented piece of horror without breaking something else.

Or some outside party meddling with your project, changing directions and technologies all the time.

Stress adds up. From different sources and over time.

And you often have no control over outside influences.

But you control how you respond.

This list of ideas is about finding ways to:

keep your energy levels high
reduce self-created stress
free up your mental space

So let’s dive right in!

☕️ Take Breaks

Even though it’s called a “Sprint” doesn’t mean you should sprint all the time.
Breaks are important to maintain your energy.

Take small breaks every day, larger breaks every week, and huge breaks every few months.

A break doesn’t mean doing nothing.

It’s better to find the right balance between active breaks (sport, social, creative) and passive breaks (books, TV, chill).

There’s no one size fits all solution.

Find a balance that is right for you. Learn to recognize when you need a break. And learn to take a break when you need one.

✅ Don’t Take Things Personally (Esp. Code Reviews And Feedback On Ideas)

Feedback about code is just that: about the code.

If someone criticizes your work, whether it’s code, a presentation, or an idea you have proposed, yes, that can hurt.

But if you didn’t get personally attacked, all you received was feedback by someone who cares.

Everyone in your project team (hopefully) has the project’s best interests in mind.

So if you get lots of comments on your pull request, great!

You’ve got an opportunity to improve.

🎨 Have Hobbies Away From The Screen

Much of our work happens in front of screens.

Even more so when working remote.

It’s not that sitting in front of a computer is stressful per se.

But if a computer is everything you see all day, you’re missing variety for mind and body.

It’s important to do things off-screen.

So if you don’t already have a regular activity away from screens, try out new things until you find an activity you enjoy that doesn’t involve computers.

I struggled with this at the beginning of my career, but got much better. Simply through trying things out and finding something fun to stick with.

🏃‍♂️ Do Enough Sport

If I don’t move enough, after a few days I feel tired and have little patience.

Physical exercise is crucial to staying relaxed.

Just as your mind benefits from a mixture of high and low cognitive load, it also benefits from demanding physical activity.

Move a little every day and get your blood pumping a few times a week.

Whether you’re running, biking, doing body-weight exercises, Yoga, or weight lifting doesn’t matter if you have no other fitness goals.

Just do something.

🧘‍♀️ Practice Mindfulness

Mindfulness is a state you can practice.

It has many benefits, among them: staying calmer, having a higher stress resistance, a lower default stress level, more patience, and more compassion.

Take some time every day (or a few times a week) to meditate and do mindfulness exercises.

If physical exercises improve your physical health, mindfulness exercises improve your mental health.

☑️ Keep Tasks On A To-Do List, Not In Your Mind

Writing all to-dos down is one of the greatest methods for productivity and mental clarity I know.

I can barely imagine my life before Todoist, and I cannot imagine my life before learning about Getting Things Done (GTD).

While GTD has many rules, it’s ultimately a system to help you manage your life clearly and with confidence.

I adapted GTD and continuously adapted it to my own preferences.

Its most important lesson is to write every to-do you have in your head down in one place outside your head.

Then prioritize and get to work.

😌 Don’t Be Hard On Yourself (For Not Making Progress Fast Enough)

For some people (including me) this is difficult.

We make plans for what we want to achieve this week, that weekend.

During a workday, we imagine what we want to complete by the end of the day.

Then we achieve something, but not everything.

We feel bad.

It helps me to remember that there’s always more I could do.
More tasks I could complete and more plans I could make.

I had to learn to be content when I only finished my highest-priority task that day.

And if I didn’t complete it, it was probably too big for one day, anyway.

Don’t be hard on yourself. Be proud that you even did anything. That already sets you apart.

🤷‍♂️ Learn To Say “I don’t know, but I’ll find out and get back to you”

Some people get defensive when you ask something they don’t know.
They don’t want to admit they don’t know the answer.

Exams in school work this way. But our lives don't.

“I don’t know” and “I haven’t made an opinion on that” are perfectly valid answers.

As long as, in a professional context, you add “but I’ll find out/think about it and come back to you.”

You don't need to know everything on the spot and you're allowed to do research.

🙅‍♀️ Learn To Say No

It’s easy to say yes.

“Yes, I’d love to write that report.”
“Yes, I’ll finish that feature by tomorrow.”

But how often do you say yes and regret it afterwards?

If you say yes to something, you say no to all the other things you could have done in that time.

If you say yes to everything, your to-do list will grow to a point where looking at it will make you sick and you could never possibly complete everything without external help.

It’s okay to say “no”.

And it’s okay to say, “Not now. Can I come back to you when I’ve got the time?”.

😎 Accept That You Can’t Know Everything And Sometimes Need Help

Don’t feel embarrassed if you don’t know something.

Nobody knows everything
Everyone started as a beginner

If you stress out because you don’t know everything you need for a given task, relax.
You can just close this knowledge gap.

Find out if the internet knows anything relevant.
Read the documentation.
Ask your colleagues.

Good coworkers know this and give you the time and space to learn.

Great coworkers challenge you and give you the support you need.

Nowadays, there is so much more to learn than one human could ever learn in their lifetime.

Take one step after the other, in a direction you find promising.

Take A Deep Breath

Mindfulness helps me become a better software engineer.
Practicing mindfulness is for the mind like physical exercise is for the body.
For me, it improves clarity, focus, calmness and compassion.

Interested in more mindfulness content for developers?

⬇️ Subscribe to the weekly Nerdful Mind newsletter!

Subscribe to Nerdful Mind.

I'm also on Twitter if that's your thing.

6 Rules of Mindful Productivity for Software Developers

Simon Mannes — Fri, 20 Aug 2021 12:13:21 +0000

There’s always something to do.

In a typical project (and in life) there are always tasks you need to do, and tasks you could do. This can feel like you didn’t get anything done at the end of the day, even though you’re feeling tired.

If you’re searching online, you can find plenty of productivity rules. Some rules are similar, while others are complete opposites!

Mindful productivity is a way to work on what matters, focus on the present, and take breaks and time to recharge.

Here are six rules of mindful productivity that work for me (a software developer).

Plan Your Day

If you don’t know what you want to accomplish at the beginning of the day, at the end of the day you will feel like you accomplished nothing.

Always plan your day. Either in the morning or the evening before. The bare minimum is to look up which meetings you have, and to identify the most important task (MIT) that day.

Your MIT is the task you can do today that has the most impact on your goals (or the project’s goals).

For bonus points, you can schedule breaks and block focus time (see below).

Do Your MIT First

This is where the planning plays in your hands.

As hard as it seems, do your most important task first. Eat the frog. All other tasks are filler tasks that distract you from your MIT.

I notice that when my MIT is really hard or not very well defined, I drift off to do other tasks and get distracted. Practicing mindfulness enables me to notice this more often. It helps to remind myself that this is indeed the most impactful task I could do right now. That it really brings me forward with my goals.

If I continue to become distracted, it’s a sign that:

my task is not very well defined and that I need to plan it in more detail or break it up into smaller tasks
I need someone to help me with this
I need to take another look at my goals and if they are really important to me.

Breaking a task into smaller steps is the best way to “become unstuck” with a task.

Learn to be content when you only finish your MIT today.

Make Regular Breaks

A colleague of me is so focused during his work that he forgets to drink water and stand up. He needs to force himself or set a timer to remember to care for himself.

Even if you regularly stand up to get something to drink, or get up and stretch, we all benefit from more focused breaks. High-quality breaks with good timing.

High-quality breaks help us care for our mind or body. Do something good for your body and get something to drink (preferably water), stretch, or shake yourself. Give your mind a break by looking out of the window, or doing a mindfulness exercise to bring your thoughts back to the present moment.
Well timed breaks give you space when you really need it, not when you just want to avoid your task.

You know best how your current breaks are. Do you benefit from explicitly scheduling them? Or by picking a 1-minute “break-exercise” you do every break today? Do you need to focus not on doing more breaks but more intentional breaks?

Determine how you want to do your breaks and evaluate after a week. Then adapt.

Block Uninterrupted Focus Time

Does Slack impact your productivity? Or Teams?

How often do you check your email inbox?

Every bling calls for your attention and costs you a few minutes of productive, focused work. The constant stream of messages also increases stress. (See this article for more info.)

There are two types of work, deep work and shallow work:

Deep work is what only you can do. The work that you need focus and time for. Programming, for example.
Shallow work is answering your emails, messaging coworkers on Slack, and most administrative work.

Both are necessary. But both also need a different kind of focus. While most shallow work tasks only take a few minutes of your time, deep work requires hours of focused attention.

Take advantage of this by blocking uninterrupted time for focused deep work. When planning your day, block time, ideally 1-3 one hour blocks. At the beginning of those blocks, disable all notifications and set yourself to “busy” or “absent” in your chat applications. Close your email client.

Enjoy this quiet and focused block of time.

Do Your Tasks Mindfully

Mindfulness means keeping a moment-to-moment awareness of your thoughts, bodily feelings and your surroundings, without judging anything.

When you do your tasks mindfully, your focus is on that task alone. It’s okay when your thoughts drift. But as soon as you notice that your mind has wandered, return to your task at hand.

Mindful working also means no multi-tasking and no yak-shaving.

Learn to notice when you’re doing multiple things simultaneously, and when you keep changing the task you’re working on.

Notice this. Let it go. And return to what you wanted to do originally.

End Your Workday on Time

Recharging is important.

We heavily use our brains, and your brain needs time to recharge.

Especially as a software engineer, I don’t believe that we’re productive for 8+ hours every day. I do most of my best work in 2-4 hours. The rest is administrative work, helping co-workers, planning, and documentation.

Every profession uses their brain and their body differently, and every individual too! I believe that knowledge workers can achieve most of their results in much less than 40 hours.

So whatever your working hours, end your workday on time and go do something else. Use your time off to recharge, read, learn, do sports, cook, care for your family, or whatever else is important to you.

You know best if that’s something you already do, or if you should focus more on it.

Develop Your Own Productivity System

These rules are not hard-written. They are what works for me (and some other people). There exists no “holy grail” of productivity systems that works for everyone.

Try these methods out. Search online for more.

Find out what works for you. Some methods will feel better than others.

For personal productivity, it’s important to get the basics right:

Sleep enough: most people need around 8 hours of sleep every night.
Eat balanced: try to diversify your diet. Include some fresh vegetables and legumes. There are no hard rules, just eat balanced and not too much.
Exercise: find some sport or physical activity you enjoy. You don’t need to start running ultramarathons, but get your body moving and your blood pumping from time to time. 2-3 times a week is plenty.

Many people want to slap productivity hacks onto broken basics.

Get the basics right. Then find out what works.

Interested in more mindfulness for developers? Check out my weekly newsletter Nerdful Mind.

I'm also on Twitter if that's your thing.

Writing Code In Small Pieces - Vertical vs Horizontal Development

Simon Mannes — Sun, 27 Jun 2021 00:00:00 +0000

There are many ways you can write your code.

We have best practices and linters, opinionated frameworks and architecture patterns.

The very big and very small decisions. Stuff you decide on the team-level.

Then there's a middle ground. That's what happens while you implement a larger feature or a smaller service by yourself.

The result is what your team sees. But the process is how you develop that code.

Everyone has their own way of writing code, and I believe we can learn from each other if we share our internal processes more.

Some definitions to start:

Vertical development means you make a fully, end-to-end working solution first (however few features it has) and then extend it. Example: you set up a full Node.js Express server, then add a route to it, and then test everything together.
Horizontal development means you make one piece of the software work and then add another "layer". Example: You write the functionality for the "business logic" first, test it with a unit test, and then integrate it into a web server. This can also be done in a test-driven way.

This seems like a fuzzy distinction, but with a larger example it'll make more sense.

Writing a Tic-Tac-Toe Game

You can find the rules of the game here: https://ccd-school.de/en/coding-dojo/application-katas/tic-tac-toe/.

In summary, we're developing a terminal program that displays a Tic-Tac-Toe game in text form.
This program expects three inputs:

A coordinate like A0 or B2 for the player to place their symbol
next, which starts a new game
exit, which exits the program

After starting up, it automatically sets up a new game for the player.

When the player makes a move, the game AI directly makes the opponent's move (which can be as dumb or smart as we want).

Let's look at how we can implement this horizontally or vertically.

Vertical implementation plan

Going vertical, our goal is to get a program running with a terminal loop. We want to start it; it asks for input; on enter it prints new text and asks for new input. Ideally, the text is our initial Tic-Tac-Toe field.

Development now would go as follows:

You start researching how you can get a CLI with a terminal loop running
You implement it, showing the same output regardless of input
You test it manually

If you got this working, you can add state management, handling of keywords like new and field names like B1, add input validation, and so on.

Horizontal development plan

When developing horizontally, we start with the "business logic".
I'd use a test-driven approach and develop a class that manages our whole game state, takes inputs, and outputs the game text for the console.

Development plan:

Create a unit test that instantiates a class called TicTacToeEngine
Implement an empty class TicTacToeEngine
Create a unit test that calls a method called toString() on a new instance and expects the empty game state string
Implement the toString() override
Create a unit test to call a makeMove() method with an allowed enum (e.g. Moves.A0)
Implement the makeMove() method to pass the test
Create a unit test that checks calls makeMove() and then toString() and expects an updated state string
… and so on until we meet the specification from above

You can also create unit tests for invalid inputs, e.g. making the move "A0" two times in a row should throw an error. At one point, you should also write tests to expect an AI move (two changes) after making a player move.

When you got a fully working game engine, it is time to wrap it into a terminal app that instantiates a game on start (and on the new keyword), listens for input and calls the makeMove method with correct enums, outputs the state to console, and so on.

Why choose one development method over the other?

There are benefits to getting a fully working application as fast as possible. And there are benefits to having a small, tested, and reliable component ready for integration.

It comes down to preference and situation.

Horizontal development is only possible for small "horizons".

I prefer to start vertically by making "something" work, so I know where the different application parts interact and how the internal APIs look like. Then, if it makes sense (i.e. I have a well-defined component like a Tic-Tac-To engine), I go horizontally and implement one component fully.

🙏 Follow me on Twitter @simon_mannes

How To Fix Merge Conflicts in yarn.lock and package-lock.json

Simon Mannes — Sun, 30 May 2021 00:00:00 +0000

Merge conflicts happen.

With lock files, this can happen if you have different packages (or package versions) installed than in the branch you want to merge.

Fixing the package.json definition may take some work, but in difficult cases you can work together with the colleague who made the changes in the other branch.

But the yarn.lockfile (or package-json.log)? Oh my..

It's so long and may have dozens of conflicts for every single conflict in package.json.

The thing is.. You don't need to fix those merge conflicts yourself.

It is a file that's generated. Not written by a human.

Fixing merge conflicts there is a simple three-step process:

# 1.
rm yarn.lock

# 2.
yarn

# 3. 
git add yarn.lock

Replace yarn.lock with package-lock.json if you're using npm.

Make your developer life simpler. Don't edit machine-generated files by hand. Simply regenerate them.

6 Mindful Ideas to Be More Content As a Developer

Simon Mannes — Sun, 02 May 2021 14:56:26 +0000

What makes you content?

Life is so full of distractions and endless to-do lists, it's easy to forget what it's all about.

For me, the goal is not to be happy, but content.

You can be happy or sad. Both are part of our lives.

Contentment lies deeper within us. We can be happy and content or sad, but content. Both are ok.

Being content is often not about getting what you want (there are infinitely many things to want), but recognizing and appreciating what you already have.

Here are 6 mindful ideas that help me stay calm, clear, and content.

I hope they help you, too.

Take It Slow And Steady

There are infinitely many things to do.

Many tasks seem to take you closer to your goals.

But what does really matter? How do you spend your time best?

It doesn't matter how many tasks you complete. What matters is their impact.

Don't rush through your tasks. Ask yourself which ones really matter and how they contribute to your goals.

Time spent planning your day is time well spent.

Slowing down means to do fewer things overall, but more things that matter. To be less distracted and more conscious. Maintaining awareness and truly enjoying what you are doing.

You don’t need to hurry.

Just take one step at a time. And take your time to enjoy the journey.

I've written about taking it slow in issues Slowing Down – Nerdful Mind #22 and Slow and Steady – Nerdful Mind #36.

Be Compassionate With Others And Yourself

What is compassion?

Compassion is the feeling you get when others or yourself are in physical, mental, or emotional pain, and you get the motivation to ease that pain.

In meditation, we practice compassion with ourselves. We practice to let go of judging our own thoughts and feelings. We learn how we struggle and recognize that other people struggle in similar ways.

“It is said that we can't attain enlightenment, let alone feel contentment and joy, without seeing who we are and what we do, without seeing our patterns and our habits. This is called maitri – developing loving-kindness and an unconditional friendship with ourselves.” ― Pema Chödrön, When Things Fall Apart

Kindness towards others and kindness towards yourself are the same thing.

I've written about compassion in issues Compassion and Awareness – Nerdful Mind #12 and What Is Compassion? – Nerdful Mind #63.

Stay In The Present And Rest In Awareness

So many things call for our attention.

Social media, email notifications, coworkers on Slack, background noise. Memories of the past and fears of the future. Rather than doing one thing with focus, we're constantly switching from one thing to the next, and the next.

What is awareness, and why is awareness important?

Awareness is not the same as attention. When you focus on something, you give it your undivided attention. It fully absorbs you. Awareness means being aware of the context.

Awareness allows us to step back and see our thoughts as what they are: words and images in our minds. Our thoughts are not the truth. They may or may not be important. This is up to you to decide.

The psychological term for this is “cognitive defusion”.
Stepping back from the content of our thoughts, instead of getting caught up in them. Letting thoughts go instead of holding on to them.

“Let us not look back in anger, nor forward in fear, but around in awareness.” James Thurber

You can practice awareness everywhere, anytime. Not only during meditation but also when walking, writing code, or cooking dinner.

I've written about staying present in issues Mindful Throughout The Day – Nerdful Mind #32 and Awareness vs. Attention – Nerdful Mind #13.

Simplify Your Life

There's so much fuzz around simplicity.

But why?

Simplicity means less complexity. Fewer things to understand and fewer items to maintain. Fewer decisions to make and fewer distractions from the current moment. Ultimately, more peace of mind.

Simplicity means not only to get rid of things you don't need.
It means to remove the nonessential stuff in every area of your life and to focus on what matters most to you.

“Simplicity boils down to two steps: Identify the essential. Eliminate the rest” – Leo Babauta

I've written about simplifying your life in issues Simple Or Complex? – Nerdful Mind #9, Simplicity In Personal Life – Nerdful Mind #10 and Simplicity In Working Life – Nerdful Mind #11.

Be Playful And Stay Curious

Imagine you're going on vacation.

It's the first time you see this new place. Nothing is familiar. Everything is new. You're going for a walk, look around, and see the beauty that surrounds you.

When applied to any activity, we call this a beginner's mind.

Too often in life, we have a novel experience, enjoy it for a few days, and then it wears off.

In mindfulness, playfulness and curiosity create space to learn.

And in life, they open your eyes to the everyday beauty that surrounds us.

I've written about playfulness and curiosity in issues Playfulness And Curiosity – Nerdful Mind #42 and Being Curious – Nerdful Mind #62.

Accept Yourself And Others

What is acceptance?

For me, it's not passive resignation. It means to recognize reality and find ways to work with it. When something is now how you want it to be, acceptance helps you to stop complaining and start acting.

Yes, you sometimes feel you're not doing enough. Not making enough progress. Not being kind enough, not calling your parents enough, not being good enough at your job.

But you are enough. There's no point in beating yourself up over how you are. There is a point in recognizing what you want to change and finding a path to your goals.

The same with other people. You can't force other people to bend to your will. Accept that everyone has had different experiences, a different personality, different values, and different opinions.

Accept that other people don't see the world like you.

If you don't need to agree on a topic, why fight? Exchange your viewpoints and let it be if you can't agree.
If it's a topic you need to agree on, embrace the different views and try to understand them. Always assume best intentions. When you don't get to a shared point of understanding, try to find a solution that is compatible with all positions.
If you feel disregarded or hurt, say it. It's okay to go if you don't see another option to improve the situation.

Accept the way it is. Find out where this feeling of tension comes from. Let it go. Identify what you can control and what you can't. And find a viable path towards your goals.

I've written about acceptance in issues You Are Enough – Nerdful Mind #41, Leave Or Accept – Nerdful Mind #34, Accept Yourself And Others - Nerdful Mind #33, and Acceptance - Nerdful Mind #30.

Also Helpful: Quick Mindfulness Exercises

Mindfulness is a skill.

It means maintaining a gentle moment-to-moment awareness of your thoughts, bodily sensations, and surroundings, without judging anything.

And like every skill, mindfulness relies on practice.
Apart from meditation and meditative activities like Yoga, martial arts, and dancing, you can do small mindfulness exercises many times a day.

👉 Check out 7 mindfulness exercises developers can do every day.

If you liked this, consider subscribing to Nerdful Mind, my weekly newsletter about mindfulness for developers.

3 Ideas How to Use Whiteboards for Software Development

Simon Mannes — Sun, 28 Mar 2021 00:00:00 +0000

When I'm programming, I'm often making notes or scribble on paper or a whiteboard.

It helps me explore and keep track of my options.

For small or big architectural decisions (which we're making all the time), it's hard to keep all options to implement something and their pros and contras in mind.

Here are 3 effective ways you can use a whiteboard (analog or digital, or just a piece of paper) to improve your software engineering:

A mind map of options you have to implement something. If there are multiple ways to implement a more complex part of your application, you can use a classic mind map. Write your problem in the middle. Then add your solutions around it. Then add pros and contras. Having all known options and their implications visible makes the decision and the discovery of new options much easier.
A user journey with concrete steps. You can either write down the specific steps you want a user to take or sketch out the ui and annotate it.
An UML diagram, e.g. to keep track of event flows. The three UML diagram types I use most often are activity diagrams (to understand what happens when, in which order, and under which conditions), sequence diagrams (to keep track of the order of events, messages, and calls), and context diagrams (to get clear on who uses some software or is affected by it, and in which ways).

Follow me on Twitter @simon_mannes

3 Quick Tips to Convert Types In JavaScript

Simon Mannes — Sun, 14 Mar 2021 00:00:00 +0000

JavaScript has 6 primitive data types.

They are string, number, boolean, null, undefined, and symbol.

What's a symbol you ask? ECMAScript 2015 introduced them. They are a way to create globally unique values/identifiers with descriptions. This article does a great job explaining them.

And then there are objects. We will talk about them in another article.

Here are 3 quick tips for converting data to one specific primitive:

Boolean conversion. All JS values are truthy, except "", null, undefined, NaN, 0, and false. You can explicitly convert values to a boolean by using !!. !!0 === false && !!NaN === false && !!"" === false.
String conversion. Convert any primitive value to a string by adding an empty string. null + "" === "null". Since ES6 you can also use template strings for this: `${null}` === "null".
Number conversion. The primitive values string, null, and boolean can be converted to numbers with +. +null === 0 && +true === 1 && +false === 0 && +'0' === 0 && +'100' === 100.

You can also use the global methods String(), Number(), and Boolean().
They make your conversion explicit and readable.

Follow me on Twitter @simon_mannes

Terraform for Fullstack Developers

Simon Mannes — Fri, 19 Feb 2021 00:00:00 +0000

The more complex your infrastructure the more can go wrong.

Three important error sources are cloud provider outages, application errors, and human errors.

The level of resilience means the type and amount of failures with which a service still fulfills its purpose.

How to Improve Your Application Resilience

Here's how we can improve our own service resilience in response to each error class:

Cloud provider outages are when services your application architecture relies on fail, like the Amazon S3 outage or the Azure AD outage. But it's not just whole services that go down. Your database server or application server might also fail. You can improve resilience against these failures by working on your application architecture. This encompasses many small things such as request retries or database reconnections, and also bigger improvements such as using multiple availability zones or a multi-cloud setup.
Application errors are probably the best-known errors, and preventing them (or handling them appropriately) is part of your standard work as a full stack developer. Counter measures include most code-improvements such as proper error handling, request retries, using a linter, handling edge-cases and always checking for null-values.
Human errors can be devastating, and they a common reason for widespread outages like the AWS S3 outage above. Guarding your application against them is harder, but some counter-measures exist.
- Improve the way you work. Use code reviews. Pair program critical stuff.
- Automatically validate application configuration (the environment variables or config files) upon application startup.
- Automate your infrastructure setup and changes. Keep your infrastructure as code. This makes it easy to review and to keep in sync with your application needs.

The last point is where Terraform comes into play.

What is Terraform?

Terraform is a declarative tool for infrastructure as code (IaC). It's written in Go and developed with Open Source by Hashicorp.

This allows you to keep track of your infrastructure and configuration in a repository, to review it, and to spin everything up whenever you need it.

What I like about Terraform is that it is declarative. This means you write how the infrastructure should look like, not which changes you want.

The basic Terraform workflow is the following:

Write - Describe your infrastructure in the terraform configuration language
Plan - Get a preview of all planned changes from terraform
Apply - let Terraform apply all changes

How does this look in a real-world architecture?

A Real-World Workflow

A real-world workflow can look like this:

The terraform configuration lives in a repository separate to our application code (we have a multi-repo Microservices architecture)
Terraform's state lives in Azure Blob Storage (this allows for easy locking of that state when in use, which terraform automatically does)
When we need to change something with the infrastructure, someone on the team creates a branch with the infrastructure changes. This person makes sure that the terraform plan command shows a reasonable plan. They then create a pull request.
Someone reviews that PR. When everything looks good, the PR is merged and the repository's deploy pipeline creates a plan with the changes. This plan must be approved by a team member before it will be applied to our infrastructure.

Let's look into the three steps write, plan, and apply.

Preparing The Tutorial

We're going to release an official Node.js example application to Heroku.

We begin by installing terraform. Check the terraform downloads, or use brew install terraform if you're on macOS.

After installing you should be able to run terraform -v and get a result like Terraform v0.14.7. If the terraform command is not available, restart your terminal and check your PATH environment variable.

Additionally, you'll need the following Heroku credentials:

Your Heroku account's email address
Your Heroku API key, which you can find in your Heroku account settings

Write - How The Terraform Configuration Language Works

For our goal of creating a Heroku deployment with Terraform we need two terraform files.

One file that describes our variables (called variables.tf), and the main.tf file where we describe all resources we need.

Let's look at the variables.tf:

variable "heroku_email" {
  type    = string
  default = "simon@mannes.tech"
}

variable "heroku_api_key" {
  type    = string
}

This is how we define variables in terraform.

To set values for these variables, set the corresponding environment variables: TF_VAR_heroku_emailand TF_VAR_heroku_api_key.
Envivonment variables for Terraforn need to be prefixed with TF_VAR_.

If you don't set the environment variables, Terraform will ask you for their values when you run terraform apply.

Now let's look at the main.tf:

# Enable the heroku provider
terraform {
  required_providers {
    heroku = {
      source  = "heroku/heroku"
      version = "~> 3.2"
    }
  }
}

# Configure the Heroku provider
provider "heroku" {
  email   = "simon"
  api_key = var.heroku_api_key
}

# Create the app
resource "heroku_app" "simple_app" {
  name   = "node-example-mannes-tech"
  region = "eu"
}

# Create a heroku build
resource "heroku_build" "simple_app" {
  app        = heroku_app.simple_app.id

  source = {
    # This app uses a community buildpack, set it in `buildpacks` above.
    url     = "https://github.com/heroku/node-js-getting-started/archive/1.tar.gz"
    version = "1"
  }
}

# Launch the app's web process by scaling-up
resource "heroku_formation" "simple_app" {
  app        = heroku_app.simple_app.id
  type       = "web"
  quantity   = 1
  size       = "Free"
}

At first we need to enable the heroku provider (provider requirements documentation).
This is necessary because the heroku provider is not part of the hashicorp namespace, but the heroku namespace.

After that we initialize the provider (provider "heroku" {) with email and api_key.
The way to reference variables in terraform is by var.variable_name.

Then follow three Heroku-specific blocks.
The resources you need will depend on your project, and the available resource definitions vary with your Terraform provider.

For deploying our app, we first create the app, then create a Heroku build, and finally tell Heroku to spin up one free web dyno for that app.

Terraform automatically detects the dependencies between our resources when we reference one resource within another.
If you don't reference a resource but still need to wait for it, you can use the depends_on property to tell Terraform to wait.

Plan - Init and Plan Before You Apply

Before we run terraform plan we must initiate terraform, to install all configure providers.

Start with the command terraform init, which should give an output like this:

$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding heroku/heroku versions matching "~> 3.2"...
- Installing heroku/heroku v3.2.0...
terra- Installed heroku/heroku v3.2.0 (signed by a HashiCorp partner, key ID 49ACC74D80C7B012)

Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://www.terraform.io/docs/cli/plugins/signing.html

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

The init command creates a local directory (.terraform) with the used providers, as well as a local terraform lock file (.terraform.lock.hcl). the lock file makes sure that no two terraform apply commands mess with each other.
In an automated CI/CD environment you would put the state and the lock into a blob storage of the cloud provider of your choice.

Now is the time to run terraform plan:

terraform plan

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # heroku_app.simple_app will be created
  + resource "heroku_app" "simple_app" {
      + acm                   = (known after apply)
      + all_config_vars       = (sensitive value)
      + buildpacks            = (known after apply)
      + config_vars           = (known after apply)
      + git_url               = (known after apply)
      + heroku_hostname       = (known after apply)
      + id                    = (known after apply)
      + internal_routing      = (known after apply)
      + name                  = "node-example-mannes-tech"
      + region                = "eu"
      + sensitive_config_vars = (sensitive value)
      + stack                 = (known after apply)
      + uuid                  = (known after apply)
      + web_url               = (known after apply)
    }

  # heroku_build.simple_app will be created
  + resource "heroku_build" "simple_app" {
      + app               = (known after apply)
      + buildpacks        = (known after apply)
      + id                = (known after apply)
      + local_checksum    = (known after apply)
      + output_stream_url = (known after apply)
      + release_id        = (known after apply)
      + slug_id           = (known after apply)
      + source            = {
          + "url"     = "https://github.com/heroku/node-js-getting-started/archive/1.tar.gz"
          + "version" = "1"
        }
      + stack             = (known after apply)
      + status            = (known after apply)
      + user              = (known after apply)
      + uuid              = (known after apply)
    }

  # heroku_formation.simple_app will be created
  + resource "heroku_formation" "simple_app" {
      + app      = (known after apply)
      + id       = (known after apply)
      + quantity = 1
      + size     = "Free"
      + type     = "web"
    }

Plan: 3 to add, 0 to change, 0 to destroy.

-----------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

Our duty is now to look at the changes terraform plans to make, and determine if that sounds reasonable and is what we want.

You can specify an -out parameter like terraform proposes to store the plan and run that exact plan later.

Apply - Make Your Plan Reality

After checking the plan, it's finally time to run terraform apply:

terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # heroku_app.simple_app will be created
  + resource "heroku_app" "simple_app" {
      + acm                   = (known after apply)
      + all_config_vars       = (sensitive value)
      + buildpacks            = (known after apply)
      + config_vars           = (known after apply)
      + git_url               = (known after apply)
      + heroku_hostname       = (known after apply)
      + id                    = (known after apply)
      + internal_routing      = (known after apply)
      + name                  = "node-example-mannes-tech"
      + region                = "eu"
      + sensitive_config_vars = (sensitive value)
      + stack                 = (known after apply)
      + uuid                  = (known after apply)
      + web_url               = (known after apply)
    }

  # heroku_build.simple_app will be created
  + resource "heroku_build" "simple_app" {
      + app               = (known after apply)
      + buildpacks        = (known after apply)
      + id                = (known after apply)
      + local_checksum    = (known after apply)
      + output_stream_url = (known after apply)
      + release_id        = (known after apply)
      + slug_id           = (known after apply)
      + source            = {
          + "url"     = "https://github.com/heroku/node-js-getting-started/archive/1.tar.gz"
          + "version" = "1"
        }
      + stack             = (known after apply)
      + status            = (known after apply)
      + user              = (known after apply)
      + uuid              = (known after apply)
    }

  # heroku_formation.simple_app will be created
  + resource "heroku_formation" "simple_app" {
      + app      = (known after apply)
      + id       = (known after apply)
      + quantity = 1
      + size     = "Free"
      + type     = "web"
    }

Plan: 3 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

heroku_app.simple_app: Creating...
heroku_app.simple_app: Creation complete after 7s [id=node-example-mannes-tech]
heroku_build.simple_app: Creating...
heroku_build.simple_app: Still creating... [10s elapsed]
heroku_build.simple_app: Still creating... [20s elapsed]
heroku_build.simple_app: Creation complete after 27s [id=fe559e8a-0210-40b8-1111-aaaaaaaaaaaa]
heroku_formation.simple_app: Creating...
heroku_formation.simple_app: Creation complete after 1s [id=a472a2a0-26dd-49c5-1111-bbbbbbbbbbbb]

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

After generating a plan, terraform asks us to accept it.
When running Terraform in CI/CD you can tell Terraform to always accept changes and to use a pre-generated plan.

When the command finishes, you'll have a terraform.tfstate file with the current terraform state. If you open it you can find the URL for your newly deployed Heroku app.

When you make changes to your infrastructure, like adding more apps or databases, or increasing dyno sizes/numbers, you update your *.tf files and then run terraform init, terraform plan, and terraform apply again.

In real-world projects you will probably automate this process with your CI/CD infrastructure.

Next Steps - Should You Use Terraform?

Terraform is just a tool.

So, when is Terraform the right tool? Here are some reasonable use-cases:

Your infrastructure is more complex than simple web server + database
You use, e.g., a microservices architecture on Kubernetes together with various cloud services
You need to spin up your infrastructure multiple times, e.g. for multiple customers

Additional Resources:

🙏 Follow me on Twitter @simon_mannes

Why This Software Developer Practices Mindfulness

Simon Mannes — Wed, 10 Feb 2021 11:24:19 +0000

Sometimes it's hard to think.

You're stressed because you can't find the cause of bug #476.
Your mind is a fuzzy cloud because it's thursday evening and you've already had 3 exhaustingly productive hours today.

I know how you feel. Most developers have been there.

Practicing mindfulness can't prevent such situations.
But it can make you feel more at ease.

I started meditating years ago because it helped me deal with personal issues.
I kept going because it was giving me so much more than calm.

I started for the calm, and stayed for the contentment.

Let me explain how practicing mindfulness makes my life richer, and how it helps me now with my career as a software developer.

Less Stress and Anxiety

Mindfulness is being aware of your thoughts, feelings, and bodily sensations, without judgement.
You practice to see them clearly, and let them go.

I became aware of my own thoughts and feelings much sooner. This is immensely helpful when you have self-doubts or FOMO, feel stressed or anxious, or have impostor-syndrome.
You notice these feelings sooner, and let them go. Minimizing the time they distress you.

More High-Quality Focus

Noticing my thoughts has another benefit: noticing when I get distracted.

As software developers, we benefit tremendously from focused deep work.
Yes, when you're in the flow it's hard to become distracted.
But what about those 30 minutes between two meetings which you could use?

Mindfulness allows me to gently place my focus on the task at hand, without feeling stressed about it.

Also, when I notice I'm getting distracted more often than usual, it's an indication for me that there may be something improve:

Did I get enough sleep? Enough fresh air? Did I drink enough water?
Is the task well-defined? Do I know exactly which next step to take?
Is my environment helping me focus? Is it too cold or too loud?

Learning to observe your state of mind helps you to notice sooner when you become stuck, and allows you to improve your situation.

More Empathy

Programming is a social activity.
Not only because we mostly build software in teams, together with other people.
But also because all software, in some way or the other, is for people.
This quote sums it up perfectly:

Engineering is not the art of building devices; it’s the art of fixing problems. Devices are a means, not an end. Fixing problems means first of all understanding them — and since the whole purpose of the things we do is to fix problems in the outside world, problems involving people, that means that understanding people, and the ways in which they will interact with your system, is fundamental to every step of building a system. – Yonatan Zunger

When you practice being mindful, you learn about your own mind.
And you notice that all humans have the same feelings.
The same stress, anxiety, fear, contentment, or joy.
When you practice seeing your own mind clearly, you also practice to see other people as who they are.
To value them and their experiences.
You practice to be kind, humble, and curious.

Mindfulness Leads to a Higher Quality of Life

All in all, mindfulness gives me a higher quality of life.
Over the last few years it helped (and still helps) me to reduce negative feelings, improve my focused attention, and deepen my empathy.

The practice itself has a positive, calming effect that lasts for hours.

And I get to know better the person closest to me: myself.
My fears, desires, and the behavior of my mind.

When we get too caught up in the busyness of the world, we lose connection with one another – and ourselves. — Jack Kornfield

If you want to start practicing mindfulness, I recommend you to try out meditation. Give Headspace (or another meditation app) a try. Or try out live courses (online or in-person, when that's a good idea again).

But even if you don't want to start with sitting meditation, you can try out one of the many small mindfulness exercises.

Meditation is one possible mindfulness practice.
And there are many other ways to practice mindfulness, such as painting, journaling, dancing, or practicing martial arts.
Meditation itself can also take many different forms.
There is “classical” breathing meditation, walking meditation, visualization, mindfulness meditation, loving-kindness meditation ...

Meditation is a great way, but not the only one.
It doesn't matter how you start your journey.

Just start.

Liked this article? Check out my weekly newsletter about mindfulness for developers, Nerdful Mind. You'll get one idea, one mindfulness exercise, and three reading recommendations every Sunday.