Smart goals don't work for software developers. Focus on this instead.

Alex Booker - Dec 21 '22 - - Dev Community

Learning to code takes a lot longer than most people think!

When things take a lot longer than you planned for that's when you start to feel like you are behind and risk quitting.

It's a dangerous mindset to get into.

Even though some people learn to code and find a job in 3 months, it takes most folks 12 months or more!

When you accept it might take a year to learn to code well enough to be considered hireable you also accept you cannot rely on motivation to keep you on-track.

365 days is too long to rely on motivation alone.

You need a plan!

Settings goals sounds like a good place to start, but it doesn't matter how SMART they are. I know from experience - goals almost never work for new developers.

When I was teaching myself to code, I struggled to set attainable goals because I could never predict how hard I would find a new subject and, therefore, how long it would take.

That's around the time I discovered a powerful productivity hack in the book Atomic Habits called systems and it completely changed the game for me.

  • 🎯 A goal tells you where to score
  • ♻️ A system tells you what you need to do every day to move forward and actually score and win

Systems involve daily routinesrulesfail-safes, and habits you practice daily to move forward in a broad direction you value.

This post will break down some of the key ideas in Atomic Habits with lots of examples and stories specific to developers.

First, let's take a closer look at why goals rarely work for new developers specifically.

Why goals almost never work for new developers

Common wisdom says to get what we want in life, we should set smart goals, but they almost never work.

So what's this big conspiracy against goals?

There are 2 big problems:

  1. Goals lock you into a destination at a time when you're learning lots of new information.
  2. Goals reduce your happiness until the next milestone

Problem #1: Goals lock you into a destination

Let me explain with a brief but familiar example.

Say you're new to web development.

You might arrive at a goal like "learn HTML in two weeks."

You read HTML is a fundamental skill for web development and an excellent place to start. Since apparently you can teach yourself C++ in 21 days, two weeks to learn HTML sounds reasonable enough!

Except after a day or two, you realize it makes much more sense to learn HTML and CSS together.

You are now at odds with your goal.

What do you do?

You're either going to:

  1. Stick to your goal in the face of new information and wait weeks to implement what you've learned
  2. OR you'll go back to the drawing board immediately, set a new goal, and probably repeat the same mistake again and again

When you are new to development, you just don't know what you don't know. How, then, can you reasonably expect to make set achievable goal and estimate how long it will take?

Goals can be useful in simple, narrow, predictable pursuits. Goals are terrible for long-term endeavors like health and professional success. This is because change happens so fast.

Adapting in the face of new information is an admirable trait (and the recipe for success) but constantly failing at your goals because you didn't know any better is demoralizing over time. It can lead to imposter syndrome. There has to be a better way.

✅ Solution Goals are rigid pursuits that shut off your awareness of other opportunities. Systems are flexible and leave you open to be curious to new and better ways of doing anything.

Problem #2: Goals reduce your current happiness

When you're working toward a goal, you essentially say:

"I'm not good enough yet, but I will be when I reach my goal."

"Once I reach my goal, then I'll be happy. Once I achieve my goal, then I'll be successful."

The problem with this mindset is that you're teaching yourself to always put happiness and success off until the next milestone is achieved.

Learning to code is hard (if learning to code was easy everyone would do it and companies wouldn't pay so handsomely) but to have the best chance at long-term success it should be enjoyable as well.

✅ Solution Commit to a process instead of a goal. Enjoyed the present moment, and improve at the same time!

Enter systems.

What is a system?

If you want better results, forget about setting goals. Focus on systems instead.

Goals are "reach it and be done" objectives.

Systems are what you do on a regular basis with the general expectation of improving.

Here are two examples from Atomic Habits and one of my own:

  • 🏉 If you're a coach, your goal is to win a championship. Your system is what your team does at practice each day.
  • 🏃🏻‍♂️ If you're a runner, your goal is to run a marathon. Your system is your training schedule for the month.
  • 🖥️ If you're a developer, your goal is to become hireable. Your system is the study schedule that you follow each week.

👻 Letting go of goals can be uncomfortable

In Atomic Habits, James Clear makes the point that winners and losers have the same goal and therefore the goal isn't what makes the difference.

Every team in the World Cup has the same goal - to have the best score at the end of the game and eventually win the tournament but it would be ridiculous to spend all game looking at the scoreboard.

If England ignored the score the entire time and instead focused on a better process or strategy they might still be in the World Cup!

It's this powerful idea that if you focus on your input every day the score will take care of itself.

Systems involve daily routinesruleshabits, and fail-safes you practice daily to move forward in a broad direction you value.

Let's break down these 4 tenants of systems in the next section 👇🏻

Daily routines

Instead of waking up and wondering "what do I feel like doing today?" take the feeling out of it and explicitly state when, where, and how.

For example:

"I will learn module 4 of Scrimba's Frontend Developer Career Path from 5pm-7pm after work every day."

Try to anticipate what might interrupt your routine and come up with "if-then" plans. For example:

"If I am too tired from work, then I will listen to a podcast instead."

Rules

We all live by certain rules, and I don't necessarily mean laws!

For example, it was ingrained in me as a child never to eat dessert before savory food or wear shoes in the house.

Consider what rules you can live by to make you more likely to succeed long-term.

The two-day and no zero days rules are excellent places to start:

  1. Two-day rule Never skip the thing you're trying to accomplish more than two days in a row.
  2. No zero days. It's better to make some progress. Any progress, than do nothing at all. Even if it's one GitHub commit.

Since these are rules you need to hold yourself to you have to agree with them on some fundamental level.  These days I agree it makes sense to get your nutrition before indulging something sweet but I wear shoes in the house if I want!

Make sure it's a rule you can keep because if it's too easy to break, the rule doesn't mean anything.

With systems, you're not trying to beat yourself into submission. You're making a plan that leans on your strengths and counterbalances your weaknesses for long-term gain.

Habits

Systems involve habits (or streaks) that keep you moving forward in a direction you value.

When I was learning to code I made a habit of committing to GitHub every day:

A screenshot of Alex Booker's GitHub profile

My mate Alejandro literally had to fend off recruiters after completing another type of streak called #100DaysOfCode!

If you're anything like me, you'll find that it's hard to break the streak once you get going 🔥

🌱 The tenants of a system work in harmony

On days I genuinely couldn't focus, I would follow the no zero-day rule I mentioned before and tweak a README or fix a one-line in one of my GitHub projects enabling me to continue my streak. With a few exceptions, I wouldn't let myself get away with this two days in a row (two day rule)

Fail-safe

By failing to prepare, you are preparing to fail

A fail-safe is a way to keep yourself accountable that does not depend on motivation.

A screenshot of the 'Go Fucking Do It' home page

Go Fucking Do It is a novel website where you set a deadline and a price. If you fail, you pay.

Now that wouldn't work for me personally!

When I was learning to code, I found an accountability buddy instead.

If we made an event in the calendar, I would go no matter what because canceling goes against my values.

The verdict

Are all goals bad?

No.

In particular a North Star is a type of overarching goal that guides you and shows you what broad direction to move towards.

But breaking down an uncertain and windy journey like learning to code into goals is a losing game. You will never estimate things well at this stage and goals put off happiness indefinitely.

Tell me if this sounds familiar:

  • Sometimes I would stick to books that weren't working for me because I set a goal to finish them.
  • Other times I would make goals to build 4 projects for my portfolio but lacked the experience to scope and estimate how long they would take
  • I would follow the advice that sounded good but hurt my progress. For example, I remember setting a goal to learn C++ because apparently, "good developers know how it works under the hood" After a week of messing around with bloody pointers, I knew in my gut this wasn't working for me, but I pushed through anyways because I thought if I didn't I lacked discipline 🤷🏻

Setting goals takes energy and time. Energy and time you could spend, uh, learning to code!

When you are always looking forward at the gap you need to close, you fail to appreciate how far you've come:

It can be disheartening at times and even lead to imposter syndrome. You will arrive at your destination more smoothly if you focus on the process instead.

Systems changed the game for me and if the success of Atomic Habits is anything to go by,  they will probably work for you too, so why not give it a go?

And don't forget to tell me how you got on!

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .