With programming, the greatest challenge is often not the complexity of the language, but rather staying consistent and motivated through the learning process.

In order to stay consistent with your learning, you will need a lot of motivation and energy. The consistency with which you learn would help you to understand the complex concepts of any programming language and make the most of your time.

Having come from an absolutely non-technical background, I had to learn this late. After I took the first step into the transition, I struggled with everything relating to learning, particularly motivation.

This article will share the steps I have gathered over time to overcome my struggles with staying consistent and motivated.

Start Slowly but Maintain a Habit

In the early stage of learning, you might only have a few free hours that you can dedicate to learning.

This is because most people are just opening themselves up to doing something they have never done before. Also, they might have tasks such as a full-time job which take a better part of their daily life. Therefore, adjusting and making time for learning might not be easy.

At this stage, you don't need to be concerned about the amount of time you have available to learn in one sitting. The most important thing is making time for a daily study session, regardless of its length, and persisting with it in spite whatever crops up in the way.

Always Schedule Your Tasks

If you don't schedule your daily tasks, it's much easier to procrastinate and forget about them. It's easy to become engrossed in just one or few tasks and lose sight of the fact that there are other things you need to do. Often, this happens when you don't follow a set task list.

To prevent procrastination and forgetfulness, make sure you plan out your days by scheduling tasks. You can use the following tips as a guide in scheduling your tasks:

1. Think of all the tasks you would like to accomplish.

2. Estimate how long it will take to accomplish each task.

3. Identify your peak hours of productivity.

4. Arrange the tasks in order of priority.

5. Make sure to bundle similar tasks together to improve your productivity.

6. To stay organized, schedule these tasks on your phone or computer and use reminder and task applications.

7. Schedule complex or difficult tasks during your peak productivity hours.

8. Make time for unexpected events in your schedule and plan for them ahead of time.

Note that it is a good idea to schedule your tasks at the beginning of every week.

To learn more about how you can schedule your day for better productivity, consider reading this article by John Rampton, the co-founder and CEO of Calendar.

Join a Community of Learners

For most people, learning alone can be boring and tedious, and in no time, it can hurt your motivation. This is why having a community of like-minded people is always better.

This type of community will provide you numerous benefits, including, but not limited to:

• access to group study

• access to different resources to help with your study

• information on current technological trends

• getting feedback on personal projects

• an avenue to share your progress and measure your growth

Find out if this type of community exists in your area. Alternatively, if you are unable to find one, you can join a remote learning community instead.

The following are some of the remote communities I have personally found useful and consider to be of great value:

• 100Devs: The 100devs community is a nonprofit organization founded and maintained by Leon Noel, a teacher and Managing Director of Engineering at ResilientCoders. The 100Devs community provides free lessons in full-stack web development to individuals. You can join the 100Devs community here.

• 100DaysofCode: 100DaysofCode is an online challenge where people dedicate 100 days to learning a programming language of their choice. In order to participate in 100DaysofCode, you must devote at least an hour a day to learning. And after that, you post a completed task on Twitter with the hashtag #100DaysofCode.

• Kevin Powell Community: The Kevin Powell Community of active learners is a community on discord created and maintained by Kevin Powell. Kevin is a teacher and software developer with years of experience. You can join the Kevin Powell Community on discord.

• Commit Your Code: The Commit Your Code community is created and maintained by Danny Thompson. The community has a lot of active learners as well as experienced developers who are more than willing to help you with your projects and mentorship. You can join the Commit Your Code community on discord.

And of course the freeCodeCamp community has a supportive and friendly forum where you can ask questions and meet other developers.

After joining one or more of these communities, it is important to be on your best behaviour. Keep in mind to also be kind, provide value, and follow their rules.

Find a Study Partner

Being consistent and motivated may be hard even after scheduling your tasks and joining a study community. If this is the case, you might need a study partner.

You can benefit from having a study partner in the following ways:

• Makes sure you have accountability.

• You can set up joint study sessions.

• You can collaborate on joint projects.

• You might find mentorship.

• You can go through coding challenges together.

Use an Efficient Study Technique

Programming languages are generally complex. Unless you have an effective study technique, it will be difficult to understand the concepts and apply them in practical contexts. This can make you frustrated and lessen your motivation to learn.

If you're learning new concepts or a new programming language, here are some study techniques you might have tried:

• repetitive reading, otherwise known as re-reading

• highlighting

• summarizing or making notes

• cramming

But there's lots of evidence from prominent scientists and psychologists that has proven that these techniques are less effective when compared to other study techniques you can use.

To make the best use of your time and ensure you remember what you have studied for a longer time, try the following study techniques:

Active Recall

Active recall is a study technique that involves retrieving already stored information from your brain.

The mind is a vast storehouse or space; memories are objects stored in that space; and retrieving a memory is akin to searching for and finding an object in a physical space (Roediger, 1980).

Using this technique involves reading a topic once and then converting concepts and ideas in the topic you have read into questions and then testing yourself on them.

Spaced Repetition

This study technique, as its name suggests, involves spacing revisions of what you have learned by way of active recalling. This is in contrast to cramming, which involves memorizing all the concepts in a particular topic in a single sitting.

Essentially, spaced repetition helps you minimize the effect of The Forgetting Curve. It is a mode of learning by which you allow yourself to forget what you have learned. Then you try to retrieve those concepts from your brain by making active recalls at specific intervals over a period of time.

The forgetting curve hypothesizes the decline of memory retention in time. This curve shows how information is lost over time when there is no attempt to retain it. (Source)

Using the above study techniques will help you make sure that you are not spending too much time understanding and remembering any topic or concepts.

In addition, you will have more time to complete other tasks on your list, as well as the opportunity to learn new skills that will be helpful in your professional development.

One popular tool you can use to help with active recall and spaced repetition is Anki. Learn how to use Anki here.

To learn more about the use of these efficient study techniques, watch the video below:

Pomodoro timer

The Pomodoro study technique is ideal for people who struggle to concentrate on studying for a lengthy period of time.

One way to use this technique is to break your workday into 30 or 20 minute chunks separated by five minute breaks. These intervals are called Pomodoros.

Set Short Term Goals and Stay Focused on Achieving One Goal at a Time

Success doesn't happen overnight.

Trying to achieve too many objectives at the same time can be overwhelming. So it's always better to break your objective into shorter chunks of goals and focus on accomplishing one of the chunks or goals at a time.

For instance, let's say your goal is to be able to build a webpage with any of the popular JavaScript framework as a beginner. To do that, you'll need to learn various scripting and programming languages, tools, and skills. Here's what you should know to build a webpage:

1. Understand the basics of HTML.

2. Understand the basics of CSS.

3. Understand the use of semantic elements in HTML.

4. Understand the use of CSS Flexbox and Grid for layouts.

5. Try building a simple static website with what you have learned so far.

6. Start learning the basics of JavaScript.

7. Focus on building projects with your knowledge of HTML, CSS and the basics of JavaScript you have learned so far.

8. Start learning advanced JavaScript concepts such as Objective Oriented Programming, and Asynchronous Programming.

9. Solidify you knowledge on the advanced concepts by building projects with them.

10. Learn the JavaScript framework of your choice. React, Vue, and Angular are all popular choices.

11. Finally you can build your favourite project using the framework you have learned.

You might think that going through the steps above in the order they are stated would take you a few months. But it may take you much longer than that – and that's ok.

Also, don't try to skip any of these steps. Simply taking a crash web dev course likely won't be enough, and can set you up for disappointment and cause you to struggle much more than you would if you'd taken your time learning the concepts thoroughly.

On the other hand, making sure that you carefully go through each of the steps, one at a time, will help you to build the skills necessary to achieve your main goal. It will also prevent you from losing motivation, which is the likely result of having unrealistic expectations.

Don't be Afraid to Ask for Help

One of the reasons why people give up early when learning programming is because they encounter some sort of bug in their program that seems difficult to solve.

But you should know that no one knows it all when it comes to programming. Even software developers with decades of experience still encounter bugs they find very hard to solve on their own.

This is a major reason why collaboration is so important – even more so than developing your personal skills.

Whenever you find yourself in this situation, do not linger on the problem for too long. Use the internet to your advantage when searching for answers. In this regard, your best friend is Google. You can get the answer to almost everything related to programming on Google if you take your time and search deeply.

If you are unable to get the answer you need from searching on Google, then the next step to take is to go to the study community you belong to get help from others. They will typically be more than willing to help you, whatever the problem may be.

Take note of the following when seeking help from your community:

• Make sure to ask direct questions.

• Make sure your questions are clear enough to understand.

• Provide a copy of your code by putting them in a public remote repository such as GitHub or Codepen and provide the link to the repository.

Maintain a Healthy Lifestyle

I can't overemphasize the benefits of maintaining a healthy lifestyle. It will help your maintain energy and keep you fit for the next challenge.

There are several ways to maintain a healthy lifestyle, some of which are:

• Get regular exercise to help your cognitive abilities and general fitness.

• Don't sit for lengthy periods of time.

• Exercise your fingers regularly while you're studying.

• Keep your eyes off your screen at regular intervals while you study.

• Make time for your hobbies as a reward for your efforts.

• Ensure you always sleep well and get a proper amount of rest.

Conclusion

Programming is a marathon, not a sprint. If you want to achieve any level of success, you have to take your time and study consistently.

Taking the steps discussed in this article will significantly improve your chances of reaching your goals.

If you enjoy this article, then you should give me a shout-out.

Further Reading and References

1. Retrieval creates learning.

2. The forgetting curve.

3. Download Anki, a powerful tool for active recall and spaced repetition.

Have you ever had those moments where nothing feels exciting? You lay in bed thinking – is it me, or is my work that boring?

I have those days too. Some weeks I am charged up and determined to take over the world. Other weeks, I feel low, bored, and stuck, and I feel like I don't have the motivation to write even one line of code.

This article will discuss what to do when you are not motivated and how to manage procrastination.

What to do when you don't have motivation to work on anything

We must remember that motivation comes in many shapes and forms. Some days, motivation looks like creating art, whereas other days, it inspires you to create a blog post.

Some days motivation looks like going on a 7-mile hike, whereas other days, it is about taking care of yourself and working your butt off.

Acknowledge and appreciate each type of motivation and its form. Let it encompass you, take you on a ride, and bring you new experiences, joy, and fulfillment. Let yourself feel motivated – no matter what form it takes because motivation in one form bleeds into another.

Some days when I feel low, I pull out my paintbrushes, put on a Bob Ross painting tutorial, play my favorite show in the background, make myself a cup of tea, light a candle, and start painting.

It feels good to use this time to de-stress. I don't care too much about the quality – I care about how I feel in the moment. I feel relaxed, inspired, motivated, and like I am taking care of myself and feeling creative while I am doing it.

Even though I may not feel motivated to write code, I feel motivated to paint – and that's okay!

I then take that feeling to the next day, either to let my creativity work on my art or to help me create something else.

An important thing to remember is that motivation is fleeting. A burst of inspiration usually lasts 1 - 3 weeks. By only relying on motivation to fulfill your dreams and goals, you are not creating a strategy for being consistent.

What you need is discipline. You need a system of habits. A habit system keeps you going day after day and becomes part of your daily routine, even when motivation has left you.

What is a habit system, and how do you create it?

A habit system is a carefully thought-out daily routine of habits that take you closer to your goal.

It is a system of what you need to do, how long you need to do it, what ambiance you want to create before you do the things you need to do, and how you will put yourself in the right mental frame of mind.

For example, as a developer, think about what goals you have set for yourself? They may look like this:

1. This week: create a feature for a project you are working on.
2. This month: learn TypeScript
3. This quarter: release project
4. This year: be proficient in React and TypeScript, speak at a conference, and create one blog every month.

Now, think about how you will break down these goals into tasks, and by what deadline are you hoping to get it done. Work backward from that deadline, and see what tasks you can achieve in the short term to achieve that goal.

Here is an example of one of the above goals:

Goal: create a feature for a project you are working on

Deadline: 1 week from today.

Steps:

1. Research what I need – dependencies, stakeholders, assets.
2. What are the steps for creating this feature?
3. What are some open questions?
4. Who can help me?

Timeline:

Day 1: Research
Days 2 - 3: Development work + testing
Day 4: End to end testing + fixing any bugs.
Day 5: Deploy to staging env and get ready for demo.

The next step is to "make" the time to do these steps. You carve out in your calendar to make it happen.

Look at your calendar, and block out "focus time". This is the time when you will get these tasks done.

Next, create a system of "setting your mental frame". This is how you get yourself in the mood for getting work done.

My Habit System

I've developed my own habit system that I use to keep myself on track. I'll explain each part so you can adapt it to your own needs.

How to find ideas

Often, I don't feel inspired to do anything because nothing is on my plate to do. I may have a lot of items in the backlog that I could work on, but I haven't given much thought to any of those ideas. And because I haven't "brought them on my plate," they don't feel as exciting.

So I go through my backlog or idealist and see if anything inspires me to overcome that. If not, I will browse blog articles on dev.to, freeCodeCamp, or Medium to see if any trending articles inspire creativity.

If not, I will find exciting conversations on Twitter. If that doesn't work, I will open Udemy or YouTube and find something to learn.

If none of that works, it is a signal that I need to chill out and take time to myself. I give myself a "creative" break – go on a walk, listen to a podcast. When something does inspire creativity during this break, I will write it down.

How to set a timeline

Once I have a few ideas in mind, I will pick the one that excites me the most. I will put a soft deadline for me – often two weeks. Then I will work backward from the deadline and mark time in my calendar to work on that topic.

I usually set 1-hour slots in my calendar if my calendar is busy and longer if I have more time. Some weeks, I may only be able to carve out 2 hours, okay.

Once it is on my calendar, I will force myself to sit down and get myself ready for focused work hours.

How to set a mood

Setting a mood is crucial because having a good ambiance is vital for me and creates a stimulating environment. My stimulants are sound, smell, and sight.

Sound: I put on a lofi or focus playlist. This is the one I commonly watch.

Smell: I have candles and diffusers set up in my office to create a "focus vibe". Sometimes, when I need a kick, I will also use roll-on essential oils.

Sight: I feel most motivated when someone else is working with me or when I am outside in nature. This is why my work desk faces a window where I can see trees, wind blowing, leaves rustling, and birds chirping.

In the youtube video I linked, the guy is also working, which makes me feel inspired to work. It's like having a working buddy.

I created a Twitch stream and discord server for this reason. When sitting in my home office alone is not enough to motivate me, and I need external motivation, I go to a cafe. Lately, I have also been going to a neighborhood park to write, which has been very helpful in creating articles.

How to cut out distractions

This is very important to me because I have the attention span of a goldfish. If given a chance, I will merrily browse away on Twitter, keep clicking notifications, or keep scrolling on Instagram.

So during my focus time, I put my phone on silent, quit my email applications, and turn slack to Do not disturb mode. I tell myself that for the next 45 minutes, I will not look at my phone, answer emails, look at Twitter or open Slack.

If I need to stop getting distracted, I will log out of these applications. Out of sight, out of mind. 😄

How to get things going

At this point, I have got my idea picked out, my vibe setup, my drink in my hand, my music playing, and the only thing I need to do is start typing.

I begin my Pomodoro timer. I work in 45-minute sessions with 15-minute breaks. I use the video I linked above as my Pomodoro timer. My goal is that I should work through the whole video by the end of the day.

Once the bell in the video hits "ding," I am ready. I start typing whatever comes into my head. I don't care much about polishing the content or code in the first go. This is a first go anyway. I will come back and revise the code or content repeatedly.

The idea here is to get it going and get the juices flowing. It's all about getting your mind to dump all the ideas out on the page.

Don't forget to take a break

Once the timer is done, it's time to take a break. I force myself to get up, take a walk, go outside, make a new cup of tea, do an errand – anything as long as it is not scrolling away mindlessly on Twitter or Instagram.

This is the time for me to give myself a break. Sometimes towards the end of the break, around the 10-minute mark, I will check Slack, emails, or any urgent notifications on my phone. Sometimes, nobody needs me ☹️ so I get back to work for another 45-minute cycle.

Wrap it up

I realized during these sessions that to have continuity and be motivated in the next session, I need to know what I have accomplished, where I left off, and what I have to do next.

For this, I will make notes at the end of the sessions, usually a revision of the above outline – what I did, what open questions I have, what I need to do in the next session, action items, and people I need to reach out to for help.

And so, the cycle repeats.

Wrapping Up

I hope this article helped you get inspired to create a habit system for yourself to keep you on track.

If you would like to work together on Twitch or Discord, DM me on Twitter telling me what is your preferred work schedule:

1. 9 AM - 11 AM PST Weekdays
2. 9 PM - 11 PM PST Weekdays

In the next article, I will talk about what to do when motivation does not strike, no ideas come to mind, and you need to give yourself a jolt. Stay tuned. You can also receive notifications about the next article directly in your inbox.

Achieving a big goal like transitioning into a new career can be extremely challenging and overwhelming.

The amount of information isn't the problem. We have access to more information than we ever have. The problem is knowing how to effectively execute on the information available to us.

The more I progress in my life and career, the more convinced I am that the path to success does not lie in setting massive goals, and then cranking every day to reach them.

The path lies in choosing your goals, then designing simple systems built with small habits that will facilitate achieving those goals.

But one crucial component is to not measure your success when you reach your goal, but measure your success each time you successfully execute on your system.

This means that you are in a constant state of success instead of being in a state of failure 99% of the time with brief spurts of success.

This not only is better psychologically but leads to a higher likelihood of you actually achieving your goals.

In this article we'll go over how to apply this philosophy to the goal of getting your first developer job. Although I should note that even if you are already working as a developer, these strategies will still apply to anyone looking to build a more fulfilling, robust career.

This note is important, so I'll reiterate. We are not looking for short-term wins here, we are looking to design a system and build a collection of habits that you will continue throughout the life of your career as a developer.

These habits will allow you to not only land your first job, but as you progress further and further, they will help you grow your network, influence, and skills. The byproduct of this is finding work you enjoy that pays well, and having abundant opportunities at your disposal.

Most of the ideas here have been adapted from Tiny Habits by BJ Fogg, Atomic Habits by James Clear, and my own personal experience getting my first dev job without any experience or education.

I'm currently reading Tiny Habits right now and I really like the focus on simplicity here, so we'll focus a lot on Fogg's technique for this article.

Let's get to it.

Overview of the Tiny Habits Method

Very briefly, let's go over the philosophy and methodology of Tiny Habits. At its core, the system follows the idea that the best way to make consistent, lasting change is to make that change tiny – embarrassingly so.

Fogg argues that motivation is a poor tool to rely on when making lasting change. It fools us into thinking we can make significant change, because significant change is possible for a short time when we feel motivated.

The problem is that motivation doesn't last. So when the motivation wanes, you don't stick to the large, ambitious goal you set for yourself. Then you feel like a failure, so your motivation tanks more, and the cycle repeats itself for most of the big changes you want to make.

Instead, you should create the smallest possible action you can in working towards your goals.

So instead of trying to create a habit of doing 50 pushups per day, set a habit to do two.

Again, the idea rests on the habits being very very small. The point is that it should take almost no effort at all to do it. Then you instill the habit, and gradually increase the amount that you do.

As a general rule, the habit should take less than 30 seconds to complete.

Another crucial concept focuses on celebrating your wins immediately. You want to make the connection in your brains between successfully completing the habit and positive emotions.

It's cheesy, but I do a little mini dance every time I complete mine, a little something like this:

The other key component of creating Tiny Habits is the recipe. Tiny Habit recipes follow this formula:

After I [anchor action], I will [tiny habit].

This anchor action is crucial. This is a task that you already complete and that is already a solid part of your schedule that you anchor your new habit to.

It should be in the same location and have the same context as your new tiny habit.

So here's an example of a bad anchor and tiny habit:

After I take the dog out, I will floss one tooth.

Because the location and context are so different, this is unlikely to stick. Here's a better option:

After I brush my teeth, I will floss one tooth.

Again, I highly recommend you check out Fogg's book, Tiny Habits, for a much more thorough exploration of this method.

For now, let's look at how we can apply this method to launching a successful dev career.

Tasks to Focus On

We want to focus on three main components for building out our dev career:

1. Develop your skills
2. Establish an online presence
3. Start networking

Let's briefly go over these, and then we'll cover how to translate them into the Tiny Habit methodology.

Develop Your Skills

This one is pretty self-explanatory. You need to grow your development skills if you want to be a developer. The key here is to make sure you don't get stuck in tutorial hell forever.

Tutorial hell is appealing because following tutorials and courses does not take nearly as much mental or creative energy as building something from scratch does.

So you fool yourself into thinking you are learning when all you are really doing is copying what someone else did.

But building that out, having it work smoothly, and then seeing the finished product makes your brain feel good, so the habit solidifies and the cycle continues.

Here you want to start building the tiny habit of writing your own code and building your own things so you can replace that feedback loop with a more useful one.

Establish an Online Presence

Building an online presence encompasses a few different things. The most important are social media and your portfolio site. When I say social media I mean Twitter and LinkedIn.

Say what you want about them – and I definitely have my issues – but they are invaluable when trying to start and grow a career.

As with most things, the key to growing on these platforms is to be consistent. So this is a perfect fit for the Tiny Habits framework, too.

Engagement on these platforms is huge, especially at the beginning when your account is still small, so you really want to make sure you are showing up every day.

Start Networking

Finally we have networking. Although there is some networking included in our online presence component because of interacting with other people, the networking we want to focus on here is more direct.

When you are first starting out, it can be very helpful to start reaching out to companies you admire directly, telling them so, and introducing yourself.

This is a bit of a secret weapon because very few people do it, but it's very powerful.

Let's look at how we can create some Tiny Habits around these three main goals. Remember, the goal is to start embedding the habit in your brain. Then you can increase the amount of each of these things over time.

How to Develop Tiny Habits

You'll need to come up with the anchor actions on your own. Anchor actions are specific to each person, because they consist of things you already do as part of your routine.

So I'll give you recommended Tiny Habits, along with my anchors, but ultimately you'll need to come up with your own.

For skill development, I recommend something very simple:

After I take my first sip of coffee, I will write one line of code in my own project.

Remember, the anchor action should be specific to you. I already make coffee before I start working in the morning, so the first sip is my anchor.

Don't discount this because of the simplicity and ease of the task. That's the point. Make it ridiculously easy to start and the snowball will grow as you gradually increase the task.

Now, for online presence:

After I check my email, I will write one thoughtful reply on Twitter.

Again, I'm using what is an existing part of my routine and then anchoring my habit to that.

Finally, for networking:

After I check Twitter, I will write down one person I want to reach out to.

Same concept here.

These are just examples, and I recommend you start with just these three for a few days while you get used to how this works. Then you can gradually start to expand the habits and start to add more for the particular tasks you have.

Please don't overcomplicate this or try to add anything more. The goal is to make it so small and so easy that it feels stupid and pointless to not do it. These will begin to compound as you begin to build that habit and execute on it every day.

And don't forget the celebration! That part is crucial for forming the pathways in your brain that will make executing on these actions sustainable and fun.

Wrapping up

So much of why people struggle to make progress on their goals is because they go too big too fast or struggle with information overload.

This simple system solves both of those problems, but we naturally resist it because it seems too small to make a difference.

In reality, when we go overboard for a day or two, then burn out for a week or two, we are taking one step forward and two steps back. No matter how big the steps are, we aren't making progress.

But when we implement the Tiny Habits method, we might be taking miniature little baby steps, but we're taking them every day and always forward.

Finally, if you would like a step-by-step walkthrough on how to land that first web developer job, I have a free 10-day email course at LaunchYourDevCareer.com. It covers a lot of what we talked about here plus a lot more in order to give you a concrete path to that first job.

Have you ever sat down and taken an inventory of your habits? Habits are what make us who we are.

Good habits help you to become who you want to be. Bad habits will slowly turn you into someone you don't want to be.

After more than 12 years as a software developer, I've grown some habits that I'm proud of and some that I'd rather get rid of.

Most of the time, I wasn't aware of my habits, but looking back, it's pretty clear to me which habits were helping me grow and which were hindering me.

This drove me to take an inventory and write about good developer habits to maybe inspire you to do the same.

If you're starting as a developer, have a look at the habits outlined below and ask yourself if they would help you become who you want to be. Be conscious of your habits and actively nurture them to become a great software developer.

Volunteer for Things You Don't Know

At the start of your career, you don't know a lot. You come into that new project and feel like an impostor because they're paying you money even though you don't understand half of the acronyms, technologies, and frameworks they're throwing around in each meeting.

And you only faintly know the other half because you googled them.

Replace "At the start of your career" with "At the start of any new project", and you have a pretty good summary of a software development career.

Every new project, we start over. There are new people to meet, new requirements to understand, and new frameworks to learn. Every single time.

This is why it's important to learn new stuff. If you just keep doing the things you know, you'll never be confident about starting a new project. There will always be the fear of the unknown.

If you make it a habit to volunteer for tasks you don't know anything about, you will constantly learn new things.

If the build needs fixing and you've never worked with the build system, get on it! You'll learn about build management.

If there's a bug in the JavaScript frontend and you've only worked on the Java backend so far, fix it! You'll learn new Javascript idioms.

Doing stuff you're not confident about doing is a great way to grow. Be sure to manage other people's expectations towards you, though. Don't pretend you're an ace. Tell them you haven't done it before but you would like to learn.

Ask to Pair Up

If you're stuck and can't get started with a task because you're unfamiliar with the context, ask someone with experience in the topic to pair up with you.

A pairing session is a great way to kick off the work on a task. Discuss the requirements with your partner until you have an understanding of what is expected. Then, discuss the solution.

What's the context? Which codebase(s) do you have to touch? What are the explicit and implicit conventions in the codebase?

But you can take pairing even further. Instead of just pairing up to kick off a task, schedule more time with your partner. After kicking off the topic, start working on it together. You drive, your partner gives advice, then the other way around.

This way, you even get to learn how your partner thinks and solves problems. You can only profit from it! Even if it's just a new IDE shortcut you learned.

A note on working from home: due to working from home, I struggled with things that would not have been a problem before. I hesitated to ask teammates to pair up with me. What was a simple tap on a teammate's shoulder in the office became a high barrier when working remotely and communicating with video conferencing software.

If that is a problem in your team, talk about it with your teammates (in a retro, for example) and it will be much easier afterward. Turns out it's just a habit to re-learn.

Talk about What You're Doing (and What You're Not Doing)

I don't remember how often I have eagerly taken on a task, thinking I'd be done within a day, but I end up still working on it a week later.

It gets better with experience, but I still find myself making too optimistic estimations. There are just too many reasons to make an optimistic estimation:

• the pressure to deliver this new feature quickly because the deadline is looming,
• the pressure to look good among peers,
• things just not working as I expect them to (this is the one that's most commonly throwing me off, even with years of experience),
• and a lot more ...

Chances are that most of your estimations end up being too optimistic. What can you do about that?

You can manage expectations along the way.

Continuously talk about what you're doing and what is holding you up. With "continuously" I don't mean that you should provide a status update to the whole team every 15 minutes. But make sure the relevant people know where you stand at the start or the end of the day, at least.

So, if your manager / team / project manager / product manager / stakeholder expects results from you, give them a quick update every day: "This is what I've been doing. This is the next step. This is a problem I'm facing. These are the options."

This will let everyone know of your progress. No one will blame you if you're hitting a wall, as long as you kept them in the loop.

This will make discussions of the type "Why did that take so long?" a thing of the past. As an added benefit, the status update will trigger discussions that can help solve problems.

In the best case, this status update is ritualized in the team. It's commonly called "daily standup" where every team member quickly updates the rest of the team about their progress and problems.

But even if you have a daily ritual like that, take a couple of minutes to think if anyone should be updated that is not part of the daily ritual. Should they be included? Or should they be updated through some other mechanism?

Make it a habit to regularly update the people that have an interest in the results of your work.

Write a Blog

I'm probably not the first person you've heard saying this, but I'll say it nevertheless: write a blog!

It doesn't even have to be public. It can be a couple of pages in a company wiki or a collection of GitHub repositories with example code and a couple of lines of explanatory text.

Why?

Because writing with the intention to teach others (even if it's just future you) is a great way of learning and growing.

Write about how you solved a gnarly problem. Write about how to use that new and shiny framework you always wanted to try. Or write a journal of what you did each week (this will also help with the "talking about what you're doing" habit because you can look up what you've been doing).

I have started a blog a couple of times. It's hard to keep the motivation up in the beginning, because no one will read your blog posts. It feels strange to write into a void. So I stopped.

Then, I started my current blog 3 years ago, writing without an audience for half a year. I noticed only then that my robots.txt file didn't allow search engines to index my blog!

So I changed my robots.txt file and people actually started to read my stuff. Not many, but it gave me the motivation to continue. So, I pulled through, tuned my writing skills along the way, and grew my blog to > 200,000 page views a month.

All because I started writing about frameworks I wanted to learn and problems I had solved so that I could look my articles up again when I needed them. Not because I wanted to create a big audience.

Blogging is a chore at first but can grow to be very rewarding if you stick to it. If you do it with the intention of learning and teaching, you will not only learn a lot, but other people will notice your blog eventually and it will open a whole world of opportunities.

Have a Notebook and a System

I've only recently grown to be a big fan of notebooks. Not a computer notebook, but a real, paper notebook. I take it (and a pen!) wherever I go, so I can take notes about whatever strikes me as important at any time.

I take notes when I listen to a talk, or when I'm waiting for the bus, thinking about what I could make for dinner this week.

I also use the notebook to maintain lists: books I want to read, frameworks I want to try out, features I want to add to my side projects. Most importantly, I use it to take notes while reading books, because that conserves the learnings from the book.

I'm writing down everything that weighs on my mind. If I don't write it down, it will keep my mind busy, sometimes to the extent that I'm getting anxious and have trouble sleeping.

The reason I'm getting anxious without my notebook is that I don't trust my memory. If you have a great memory and can recall everything that you have thought about a week ago, you probably don't need a notebook. If your memory is as patchy as mine, though, it will make a world of a difference to your peace of mind.

To build trust in your notebook, you need a system. You need to convince your mind that whatever you put into the notebook will not be lost.

Create an index on the first couple of pages of the notebook to make the information retrievable. Then, make it a habit to review your notes regularly and process them.

To process the notes I'm taking while reading a book, for instance, I review the notes whenever I'm done with the book and write a book review on my blog. Almost no one reads these reviews, but the process of writing the review makes the things I learned stick so much better.

Keep Notes about Your Wins

Having a notebook can also help with the next habit: documenting your achievements.

As I said, my memory is patchy at the best of times. I can usually remember what I had for lunch yesterday, but if I'm deep in focus and spending brain power on some gnarly problem, the halftime of my memory goes down considerably.

That's why I like to document my achievements at the end of the day. It's usually not big achievements, but small wins - like having beaten a bug, or having finished one of the many steps towards adding a new feature to the software I'm working on. I also document personal wins like having stuck to my morning workout routine.

I just create a list of bullet points each evening in my notebook, but it'll also work with a digital medium like a spreadsheet or whatever you're most comfortable with - as long as you stick with it.

Over time, the achievements aggregate. You might want to mark the ones that are most important to you so you can easily find them later.

Then, on an occasion like a performance review, you go through that list, find the achievements that are relevant to that occasion, and list them out to prepare. Performance reviews always work out better when you're prepared.

Having a list of your achievements also helps in every-day situations to talk about what you've been doing (see habit "Talk about what you're doing").

Have a Time Slot for Important Tasks

At the end of the day, I often feel I haven't accomplished anything. While it helps to document your wins or even just the things you did, you still need to actually do those things.

It happens quickly that you go from meeting to meeting and suddenly the day is over. After a meeting, you want to continue the task you started before the meeting, but just when you've warmed up, the next meeting starts. And after that meeting, you have to start over, because you lost the context.

Context switching is killing productivity.

If there's one thing I learned to be productive, it's having a dedicated time slot for things you want to get done. If you don't have a pre-planned time slot for a task, chances are slim that you will get started on it. It will be eaten up by every-day work or other planned work.

There isn't a single way to implement a time management habit, and, to be honest, I'm hopping from one productivity method to the next every couple of months. But the core is always the same: block some time in your day for the things you want to get done most.

I block an hour in the morning, before work, to write articles for my blog (or for other blogs, like this one). Most days, I also block an hour in the evening, when the kids are in bed, to work on any side project I might have.

Currently, I have a Trello board with one column for every day of the week where I put the tasks I want to do in the morning and the evening. Once a week, I update that board with the things I want to do in the next week, so I don't have to waste my precious blocked time with thinking about what to do next.

I have a very similar Trello board for my software developer job. Every morning, I think of the things I want to do and put them into the column for the day.

I also block at least 2 hours of focus time in my calendar every day, so that my co-workers don't try to schedule any meetings at that time. That's when I get through my list of tasks.

It doesn't really matter how you manage your time, but it's important to do it and to make it a habit. Otherwise your days will be eaten up by things that are not important to you.

When Stuck, Take a Break

As software developers, we tend to get stuck a lot. And boy, does it piss me off when I'm stuck and don't see a way out.

It's such obvious advice to take a break when you're stuck, but it's so hard to do. "I'm so close to solving the problem, I can't take a break now!"

Also, taking a break now would mean I would have to warm up to the topic again later. Why should I deliberately switch contexts when context switching is the number one source of wasted time?

When you're stuck, you're not thinking straight. You're thinking about how stupid it is to be stuck with this problem, how easily your teammates would probably solve it, and why they always get the easy tasks. But you're not thinking about how to solve the problem.

Take a break and work on something else for a time. Or even better, try again the next day. Getting some distance to the problem will allow you to see solutions you were blind to before.

If you haven't tried this before, you won't believe how often a problem is "just solved" the next morning. Mostly because you see a path to a solution that you haven't seen before.

Now, it's easy to say to take a break, but how do you identify that you're currently in "stuck mode" and then persuade yourself to quit working on the problem for a time?

I'm honestly not very good at this myself, because I usually WANT THIS DUMB TASK OUT OF THE WAY so I can show that I've achieved something!

But what I found that helps me is to divide my day into 30-minute slices and have a quick recap after each of those slices. This technique is called the Pomodoro technique based on those tomato-shaped kitchen timers.

After each pomodoro unit, I'm asking myself if I'm still working in a "solution mode", or if I'm stuck and should work on something else for a while.

A nice benefit of the pomodoro technique is that you can use the end of a unit as a trigger for other habits.

I use it as a trigger to stand up from my chair to stretch my muscles and drink some water, for example. This is sometimes called "habit stacking", because you're stacking one habit on top of another, and it's very effective.

If you want to read more on habits, I can warmly recommend the book "Atomic Habits" by James Clear.

Don't Chase Silver Bullets

I wrote a book on a specific architectural style and I regularly get emails saying "I love that architecture style and I want to apply it to all of my projects! How can I do that?".

Can you guess my answer to that question?

There is no single architectural style that applies to all problems out there.

You build a plain CRUD API when it's a small project. You build a more sophisticated Hexagonal Architecture if you have a complex domain model. And you apply any of a hundred different styles when you're building microservices in a specific context.

Similarly, there is no single framework you should use for every single project. And there is no single best programming language or coding style.

Don't fall for silver bullets. They don't exist.

Having an opinion is good if it's backed with good arguments. "This is the best architecture style" or "I've always done it like this" are not good arguments and people will see through them.

Just imagine you have a developer on your team that has an opinion on everything and always wants to do things their way, "because it's the best way". You would get tired of that very quickly. Don't be that person.

Build Those Habits!

Wow, this article got longer than I expected. I hope it provided some inspiration on what to think about when growing your software developer career. I certainly haven't mastered all of those habits, but I'm trying to get a bit better every day.

Pick the habit that resonates most with you and try to consciously apply it in your everyday work.

Let me know on Twitter how it works out! I'd be thrilled to get your feedback.

We are a few months into a global pandemic which has forced many of us to adjust almost every aspect of our lives.

Our daily routines have been turned upside-down and many of us continue to spend more time at home.

This increased time at home offers an opportunity for growth and learning. When the pandemic began, I started to review how I was spending my extra time at home. I tracked this data, established a learning routine, and finally visualized the results.

This article is an overview of how I used the Pomodoro technique to track my learning. In it, we'll break down how to quantify your learning progress, and visualize the results.

Learning how to learn

“Learning is creating a pattern in your brain. The more you practice, the stronger and the more available it will be for you in the future.” — Barbara Oakley

Our brains process information in several ways as we learn new subjects. There are two primary ways that we think: focused mode and diffused mode.

When we first begin to learn something new, we have to focus and concentrate. Diffused mode, on the other hand, allows us to make imaginative connections between ideas. This includes time when we are relaxed and our thoughts travel broadly.

The Pomodoro Technique is a tool that helps us enter focused mode.

There are two primary ways that we think: via the focused mode and the diffused mode. When we first begin to learn something new we have to focus and concentrate.

What is the Pomodoro Technique?

The Pomodoro technique helps us do focused work by:

1. Shutting off all distractions and finding a quiet place to do work.
2. Setting a timer for 25 minutes. I have downloaded an app called "Be Focused Pro" which allows me to track this data.
3. Focus on the task, or the learning activity.
4. Take a break and repeat the process after the 25 minutes are up.

I learned to establish a learning routine with the Pomodoro technique. 25 minutes is tangible and short enough to focus on a desired learning activity.

Learning is an investment, and its value compounds over time. 25 minutes a day may seem short, but multiply that over a week, a month, a year and you will see results.

Be Focused Pro App. Start a Pomodoro. It has settings that allow you to export to csv.

Your Learning Goal

Think about what you'd like to learn – what is that topic or language that you're curious about?

After you've established your subject, think about the new skills that you need to acquire. It's important to break down the topic into pieces to achieve your learning goals.

Bringing in the Pomodoro technique

The Pomodoro technique helps you take a step-by-step approach towards new skill acquisition. And here's how.

Think about your learning goal and break it apart into smaller chunks. This exercise will help you space out your learning over several days, weeks, or months. Remember that we all learn at different speeds.

You build a solid foundation as you begin to put in time to learn and practice your new skills. This exercise is also helpful to develop milestones that you can quantify. The Pomodoro Technique helps you quantify that progress and analyze learning patterns.

Think about your learning goal and break it apart into smaller chunks.

Tools to Track Data

Several apps exist that help you use the Pomodoro Technque. As I mentioned, I have downloaded the "Be Focused Pro" app. The greatest benefits are that you can enter a name for your task, create tags and notes, and add a "due date."

This data helps you understand the amount of time spent completing a project or goal. You can download a csv of your data, which includes a time stamp, the name of the activity, the duration of your pomodoro task, and metadata.

There is a new row of data created every time that you complete a Pomodoro. The app has analytics such as the amount of Pomodoro's completed in a day, a week, or a custom date field.

The ability to download a csv is a great feature because you can transform your own data. This allows you to create a data set that best suits your purposes. You can understand your learning patterns, track progress, and visualize the various components.

After you have completed a few Pomodoro's you can export the data as a csv. This file will serve as the foundation and includes:

• Start Date: timestamp of when you started
• Duration: amount of time for the Pomodoro, the default is 25 minutes
• Assigned Task: the name of the activity
• Task State: indicates whether the activity is completed or if it is ongoing

The data export from the app Be Focused Pro.

Introspection

Before you begin to clean up and transform this data, take a step back and ask yourself a few questions.

• What am I most interested in understanding about this data?
• Do I want to understand how long it takes me to complete a learning goal?
• Am I interested in the length of time required to complete the various phases of my goals?
• Am I more interested in seeing the progress of my various goals?
• Do I want to build something that serves more as motivation? Should I focus on what I've accomplished and the goals I am working towards?
• What time frame do I want to focus on and how much granularity do I need? Minutes, months, or days?
• Do I want to look at the time of day that I do the most Pomodoro activities? Will this knowledge help me organize my schedule so that I can focus during my productive hours?

Before you begin to clean up and transform this data, take a step back and ask questions.

The answer to your questions will guide the data transformation and clean-up. These questions help identify gaps in your current data structure. I wanted to explore the following:

• How has the pandemic impacted my learning?
• What day(s) or hour(s) am I most productive in?
• What general activities consume most of my learning time?
• How can I track progress for my various courses on Pluralsight, Data Camp, and other learning platforms?

Data Transformation

Data Cleanup

After completing the exercise I spent time cleaning the data in the csv. I focused on the time stamp and created new columns of data, which included:

• Month
• Day
• Year
• Minutes

Date Cleanup

New Data Created

I created new columns of data that served as categories for my learning activities. I wanted to collect information such as the "Type" to separate the various "Assigned Tasks."

I also created a "Learning Platform" column to distinguish the course websites. I wanted granularity with these courses. The creation of the "Learning Skill" column specified the skill(s). "Course Title" referred to the name of the course, or the title of a project.

The new categories included:

• Type
• Learning Platform
• Learning Skill
• Course Title

New columns created included: type, assigned task, learning platform, learning skill, and course title

Data for Waffle Chart Visualization

The final data piece is optional and I used it to create my desired visual component within Tableau.

The Tableau community shares tips and tools, and I downloaded the waffle chart spreadsheet from Andy Kriebel's website. I did add a column to Andy's sheet so that my data set would translate appropriately.

The "minutes" columns helps visualize the progress percentage. This final piece is a spreadsheet that has several data fields including:

• Row
• Column
• Progress
• Minutes

"Waffle Chart" spreadsheet that creates the visualization in Tableau

Data Import

You are ready to import the data once the various pieces are transformed. I created two Google spreadsheets so that I could continue adding data over time and easily refresh on Tableau.

The google spreadsheets include:

• 2020 Pomodoro: data from the initial csv as well as the columns created:

2020 Pomodoro - Google Spreadsheet

• 2020 Focused Mode Waffle Chart: data specific for the creation of a waffle chart in Tableau:

2020 Focused Mode Waffle Chart - Google Spreadsheet

Visualization

Take a step back and revisit your questions from the introspection exercise. The answer to your questions help the data transformation and clean-up.

These questions will also help guide your data exploration. The main themes of my questions included:

1. How had my learning changed over time?
2. At what time am I most productive and learning?
3. What is the progress of my courses and projects?

As I began exploring data visualizations, I focused on these three themes:

• Patterns Across Months

Visualization breaking down the pattern across months

• Patterns Across Days/Hours

• Learning Progress

Play around with several chart and graph types until you find the form that best suits your purpose. The final step is to bring all the pieces together into one cohesive structure.

I finished by creating a dashboard in Tableau. First I took a broad look at the Pomodoro Activity Types. Next, I viewed how it has changed over time and examined these patterns across days/hours.

The bottom portion focuses on progress. I wanted an easy way to scroll through the status of the various courses/projects I am working on. You can explore the dashboard on Tableau Public here.

Just get it done

25 minutes a day of learning leads to positive change and growth over time. The effectiveness of the Pomodoro method compounds and helps build knowledge, experience, and new skills.

Each time that you focus and do a Pomodoro activity you are learning and can begin to build powerful habits.

Next monitor your growth and learn about the patterns, so that you become a better learner. What will you focus on and where will the learning lead you? What will you learn? What will you build?

Finally, share your work, along with any lessons learned.

"Make it a habit. Figure out when and where you're most comfortable doing deliberate practice. One you've made your selection, do deliberate practice then and there every day. Why? Because routines are a godsend when it comes to doing something hard. A mountain of research studies show that when you have a habit of practicing at the same time and in the same place every day, you hardly have to think abut getting started. You just do." - Angela Duckworth

If you're interested in getting started, these resources can help you:

• Ingrid's 2020 Pomodoro Google Sheet: this is a skeleton of the spreadsheet I used for this project.
• Be Focused Pro App: this is a link to the app I use on a daily basis. The instructions covered in this article are applicable to this particular app. There are many more apps out there as well.
• Learning To Learn by Barabra Oakley, Alistair McConville, and Terrence Sejnowski is a great book that teaches you the science behind learning. The Coursera course "Learning How to Learn" is available for free.

A few days ago, I started to read The Power Of Habit by Charles Duhigg. This book made me think a lot about why some people struggle with programming daily. I think it's because of the habit process. Most people don't know how habits work and need concrete examples.

In this article, I'm going to explain what a habit is and give you some advice to help you create a daily programming habit.

What is a habit?

Before starting, it's essential to define what a habit is and how you form one.

If we check the definition of the word "habit" on Google, we find this:

"Habits are routines of behavior that are repeated regularly and tend to occur subconsciously" ― Wikipedia

"a behavior pattern acquired by frequent repetition or physiologic exposure that shows itself in regularity or increased facility of performance" ― Meriam-Webster Dictionary

"a recurrent, often unconscious pattern of behavior that is acquired through frequent repetition" ― The Free Dictionary

"something that you do often or regularly, often without thinking about it" ― MacMillan Dictionary

As you can see, a habit is an automatic process in your life. Take brushing your teeth, for example.

It's interesting to define the components of a habit to understand how it works.

Each habit includes three components: a cue, a routine, and a reward.

The Habit Loop

What is the cue?

The cue is an event in your life that triggers a habit. Every time you do something automatically, it was started by a cue.

Most of the time, a cue is defined by time, an emotional state, a location, or an action.

For example, if I'm working and suddenly smell coffee from my colleague's direction, my habit "Taking a coffee break" is triggered.

What is the routine?

The routine is what you are doing while the habit process is running. You can define whatever you want it to be in this part. As I said previously, it can be, "I'm going to take a coffee break."

What is the reward?

The reward is the final element of the process. In other words, what this routine has done for you. For the coffee break example, the reward is "Thanks to the caffeine, I feel less tired, and I am more dynamic."

The more positive and pleasant the reward is for yourself, the more your brain will save the habit.

"This process within our brains is a three-step loop. First, there is a cue, a trigger that tells your brain to go into automatic mode and which habit to use. Then there is the routine, which can be physical or mental or emotional. Finally, there is a reward, which helps your brain figure out if this particular loop is worth remembering for the future. Over time, this loop—cue, routine, reward; cue, routine, reward—becomes more and more automatic. The cue and reward become intertwined until a powerful sense of anticipation and craving emerges. Eventually, whether in a chilly MIT laboratory or your driveway, a habit is born." ― Charles Duhigg, The Power of Habit: Why We Do What We Do in Life and Business

A little exercise

Here's something you can do: take one of your daily habits and try to define the cue, the routine, and the reward. Once you do, you're ready to read the next part on how to create your daily programming habit.

How to make programming a daily habit

All you have to do to make programming a daily activity is to create a routine.

You are free to define what you want for each part of this exercise, but I will give you a few tips to help you.

For the cue, you can try to define something based on time:

• Every morning right after I wake up
• When I come back from my job
• During my lunch break
• [Insert a time-based cue]

Routine will be our most straightforward element to define. You can just say, "I want to code for 30 minutes," "I'm going to learn [Insert a skill] for 30 minutes," or many more.

Finally, one of the most critical parts will be the reward. As I recommended in the first part of my first productivity article, you need to establish goals for yourself. It's going to help you define a reward. Every time you practice your habit, you are closer to your goal.

Try to determine a long term goal, and inside of that, a lot of small goals.

For example, you can say:

• I'm getting closer to my goals for the week.
• I'm getting a little closer to my final goal.
• If I code right after waking up, I'll make myself breakfast as a reward.
• [Insert a reward]

A challenge that can help you

One of the best ways to get into a habit is to follow a 100DaysOfX challenge. This challenge is designed to help you create a pattern and commit to it every day by sharing what you did on Twitter, Instagram, or your blog.

The reason I'm telling you about this challenge is that it became famous on Twitter with the 100DaysOfCode.

I strongly recommend that you read the rules on the site and get started. You'll see, at first, it may seem big and impossible, but you'll find it fun to do.

Besides, you will most certainly get support on Twitter, which will motivate you.

"Are you passionate about self-improvement? Eager to change your habits, have tried to do so many times, but had difficulties changing them? Life always seems to get in the way, there is not enough support, and you feel like you're alone in it? Find yourself thinking, "What's the use of all this self-improvement if I always seem to go back to where I started from?" ― 100DaysOfX

If I recommend this challenge to you, it's because I'm doing it. I'm thrilled with the results, and I'm only starting.

For my part, I'm doing the 100DaysOfReading challenge. I always wanted to start reading but I never took the time to do it. Thanks to this challenge, I'm on day 17, and already finished one and a half books.

My habit loop:

• Every day before lunch or before sleeping (the cue).
• I read 20 pages or more (the routine).
• I am approaching my long-term goal of reading daily. I am close to my short-term goal of finishing the book. It makes me happy because I have always wanted to read daily (the reward).
• I publish a quote from the book I'm reading with some explanations and motivational text on my Twitter (the commitment).

Here are some tips that can help you to create your programming habit.

Plan your tasks

To work every day and achieve my monthly goals, I plan all my tasks the evening before. I put on paper what I want to make, and every time I do it, I'll scratch it off my list. I recommend that you do this with your daily programming habit because it's going to motivate you and satisfy you a lot when you finish all your goals.

If you need more structure in your work, define what you are going to do, how, when, and why.

For example, I'm going to create a landing page for my website (what I'm going to do). I will use Vue.JS to build it (how). I will do it between 8am and 10am (when). It's going to help me better understand Vue.JS and help me to start getting my visitor's email addresses.

Code your dream project

What could be better than coding daily while working on the project of your dreams? If you need motivation, it's an excellent way to program every day. Don't be afraid to take the initiative. Doing it a little bit every day will motivate you even more and give you results in a short time.

Find the field you want to work in

The world of programming is vast – web, software, AI, embedded, and much more.

One of the significant difficulties is to define what you want to do as a programmer.

It's not easy for everyone, but choosing a topic and sticking to it can be a good motivation factor to practice daily.

For example, if you choose web programming, just focus on that. Even though it's still a big topic, you removed software, AI, embedded, and everything else. That's a good start.

To go further, you can choose between the front-end and back-end.

I'm telling you all this because often, when you start, you get demotivated fast because there are too many things, and you can't focus on a specific theme.

A good environment

Something that can motivate you in your daily programming habit is a pleasant working environment. I do not recommend working in your bed. You're going get tired easily.

Try to work at a desk or a table and do whatever you need to feel comfortable in that space. It will make you want to work more efficiently.

Further reading

If you are interested to know more about the habit process, I invite you to read The Power of Habit by Charles Duhigg. This book helped me a lot while writing this article, and a lot of the examples I gave you were inspired by it.

I've also heard about Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones by James Clear. This book offers a framework to improve your daily habits. The author tries to provide practical guidance on how to make changes.

Conclusion

Do you plan to make programming a daily habit? Are you going to commit to 100DaysOfCode?

Feel free to share this article if you liked it.

If you want more content like this, you can follow me on Twitter, where I tweet about web development, self-improvement, and my journey as a full stack developer!

Systems that interact with the public, like companies, educational institutions, and public services, are most susceptible. While delivery methods for ransomware vary from the physical realm to communication via social sites and email, all methods only require one person to make one mistake in order for ransomware to proliferate.

Ransomware, as you may have heard, is a malicious program that encrypts your files, rendering them unreadable and useless to you. It can include instructions for paying a ransom, usually by sending cryptocurrency, in order to obtain the decryption key.

Successful ransomware attacks typically exploit vital, time-sensitive systems. Victims like public services and medical facilities are more likely to have poor or zero recovery processes, leaving governments or insurance providers to reward attackers with ransom payments.

Individuals, especially less-than-tech-savvy ones, are no less at risk. Ransomware can occlude personal documents and family photos that may only exist on one machine.

Thankfully, a fairly low-tech solution exists for rendering ransomware inept: back up your data!

You could achieve this with a straightforward system like plugging in an external hard drive and dragging files over once a day, but this method has a few hurdles. Manually transferring files may be slow or incomplete, and besides, you’ll first have to remember to do it.

Instead, use cron

In my constant pursuit of automating all the things, there’s one tool I often return to for its simplicity and reliability: cron. Cron does one thing, and does it well: it runs commands on a schedule.

I first used it a few months shy of three years ago (Have I really been blogging that long?!) to create custom desktop notifications on Linux. Using the crontab configuration file, which you can edit by running crontab -e, you can specify a schedule for running any commands you like. Here’s what the scheduling syntax looks like, from the Wikipedia cron page:

# ┌───────────── minute (0 - 59)
# │ ┌───────────── hour (0 - 23)
# │ │ ┌───────────── day of the month (1 - 31)
# │ │ │ ┌───────────── month (1 - 12)
# │ │ │ │ ┌───────────── day of the week (0 - 6) 
# │ │ │ │ │
# │ │ │ │ │
# │ │ │ │ │
# * * * * * command to execute

For example, a cron job that runs every day at 00:00 would look like:

0 0 * * *

To run a job every twelve hours, the syntax is:

0 */12 * * *

This great tool can help you wrap your head around the cron scheduling syntax.

What’s a scheduler have to do with backing up? By itself, not much. The simple beauty of cron is that it runs commands - any shell commands, and any scripts that you’d normally run on the command line. As you may have gleaned from my other posts, I’m of the strong opinion that you can do just about anything on the command line, including backing up your files. Options for storage in this area are plentiful, from near-to-free local and cloud options, as well as paid managed services too numerous to list. For CLI tooling, we have utilitarian classics like rsync, and CLI tools for specific cloud providers like AWS.

Backing up with rsync

The rsync utility is a classic choice, and can back up your files to an external hard drive or remote server while making intelligent determinations about which files to update. It uses file size and modification times to recognize file changes, and then only transfers changed files, saving time and bandwidth.

The rsync syntax can be a little nuanced; for example, a trailing forward slash will copy just the contents of the directory, instead of the directory itself. I found examples to be helpful in understanding the usage and syntax.

Here’s one for backing up a local directory to a local destination, such as an external hard drive:

rsync -a /home/user/directory /media/user/destination

The first argument is the source, and the second is the destination. Reversing these in the above example would copy files from the mounted drive to the local home directory.

The a flag for archive mode is one of rsync’s superpowers. Equivalent to flags -rlptgoD, it:

• Syncs files recursively through directories (r);
• Preserves symlinks (l), permissions (p), modification times (t), groups (g), and owner (o); and
• Copies device and special files (D).

Here’s another example, this time for backing up the contents of a local directory to a directory on a remote server using SSH:

rsync -avze ssh /home/user/directory/ user@remote.host.net:home/user/directory

The v flag turns on verbose output, which is helpful if you like realtime feedback on which files are being transferred. During large transfers, however, it can tend to slow things down. The z flag can help with that, as it indicates that files should be compressed during transfer.

The e flag, followed by ssh, tells rsync to use SSH according to the destination instructions provided in the final argument.

Backing up with AWS CLI

Amazon Web Services offers a command line interface tool for doing just about everything with your AWS set up, including a straightforward s3 sync command for recursively copying new and updated files to your S3 storage buckets. As a storage method for back up data, S3 is a stable and inexpensive choice.

The syntax for interacting with directories is fairly straightforward, and you can directly indicate your S3 bucket as an S3Uri argument in the form of s3://mybucket/mykey. To back up a local directory to your S3 bucket, the command is:

aws s3 sync /home/user/directory s3://mybucket

Similar to rsync, reversing the source and destination would download files from the S3 bucket.

The sync command is intuitive by default. It will guess the mime type of uploaded files, as well as include files discovered by following symlinks. A variety of options exist to control these and other defaults, even including flags to specify the server-side encryption to be used.

Setting up your cronjob back up

You can edit your machine’s cron file by running:

crontab -e

Intuitive as it may be, it’s worth mentioning that your back up commands will only run when your computer is turned on and the cron daemon is running. With this in mind, choose a schedule for your cronjob that aligns with times when your machine is powered on, and maybe not overloaded with other work.

To back up to an S3 bucket every day at 8AM, for example, you’d put a line in your crontab that looks like:

0 8 * * * aws s3 sync /home/user/directory s3://mybucket

If you’re curious whether your cron job is currently running, find the PID of cron with:

pstree -ap | grep cron

Then run pstree -ap <PID>.

This rabbit hole goes deeper; a quick search can reveal different ways of organizing and scheduling cronjobs, or help you find different utilities to run cronjobs when your computer is asleep. To protect against the possibility of ransomware-affected files being transferred to your back up, incrementally separated archives are a good idea. In essence, however, this basic set up is all you really need to create a reliable, automatic back up system.

Don’t feed the trolls

Humans are fallible; that’s why cyberattacks work. The success of a ransomware attack depends on the victim having no choice but to pay up in order to return to business as usual.

A highly accessible recent back up undermines attackers who depend on us being unprepared. By blowing away a system and restoring from yesterday’s back up, we may lose a day of progress; ransomers, however, gain nothing at all.

For further resources on ransomware defense for users and organizations, check out CISA’s advice on ransomware.

The good habits

Let's start with the positive shall we? These are the best habits that often impress me when working with Junior Developers (and all developers for that matter).

Commit/Push code often

Chances are you'll have come across terms like "Git", and "GitHub", "source control" whilst on your coding journey. If you haven't:

1) Where have you been?!?

2) You can learn about it here: https://www.freecodecamp.org/news/how-you-can-learn-git-and-github-while-youre-learning-to-code-7a592ea287ba/

Source control is a marvellous thing. It's a backup of your code, allows you to track changes, and let's you quickly roll back when you have that "oh s*! everything is broken!" moment whilst coding.

Not to mention it makes life much, much easier when working as part of a team. I can't imagine working on code collaboratively without it - sharing code over email and slack?! Quivers.

A good habit to have is to commit code often, even for your own side projects as practice. Personally I like to "check in" my code when I have a completed a small part of my project. For example, if I were creating a TODO list app, I would commit and push my code when I have added the 'new todo button', or when I've completed the 'checkbox functionality'.

There are no hard and fast rules as to when to check in code. Other good times to commit code are:

• If you are about to finish up for the day (see a very important rule below)
• Before you do a major refactor or code change
• If there is a fire in the building (Just kidding, safety first)

There is only 1 important rule to follow when committing code.

The code must build successfully and the tests must pass

Does that count as 2 rules? Anyways, this is important. Something that is guaranteed to bring any development team to a halt is broken code. So before you commit your code, make sure the code builds and the tests pass!

Lastly, make sure to use good commit messages. "Fixed bug" isn't as clear as "Fixed issue with 'save todo' button not calling onClick function correctly". This will not only be helpful for yourself but your teammates as well.

Use clear naming for variables, functions, and files

Ah naming. The one thing in web development that we all thought was easy, is sneakily difficult at times. Naming is important though, as it makes our code easier to read and understand.

When choosing a name for your variables, functions and files, try to make it as descriptive as possible. Why?

• It makes it easy to quickly skim over code. If you see a method called getUsers() Without having to look at that method, you can be pretty sure that it's going to return a list of users.
• Helps enforce separation of concerns. Oooh a fancy new term! Don't worry, this just means keeping related things together. For example in a Node.js app, if you have a /users endpoint and a /products endpoint, you might keep the users logic in the same file ( usersService.js for example ) and keep the products logic in another file. Wouldn't this make it easier to find things?

Here's a simple function which is badly named (as are the parameter names) can you guess what it does?

const function1 = (x, y) => {
    return x + y
}

This function could either add 2 numbers or concatenate 2 strings, but it's original intent is not clear. Let's say its intention was to add numbers, but another unsuspecting developer comes along and uses it to concatenate 2 strings. It might be ok for now, but later if we refactor this function to validate the numbers, then the code calling this function to concatenate strings will break. Oh no!

Here's the function with better naming:

const addNumbers = (num1, num2) => {
    return num1 + num2
}

Now it's a bit clearer on what the function does, and what the parameters are.

Practice debugging

Would you believe that web developer's spend just as much time (if not more) fixing bugs? Yes, there will be bugs. And the best way to identify and fix a bug is to debug the code. Debugging is the process of "stepping" through your code, line by line, until you discover something you didn't expect.

Luckily for us web developers, many IDE's come with built in debuggers that makes this really easy (here's a VS Code guide to setting up debugging for different languages. For other IDE's you can check out Google https://code.visualstudio.com/docs/editor/debugging)

So how do you effectively debug your code? Here's a few pointers:

• Replicate the issue - replicate the bug a few times so you understand exactly what it is that causes the bug
• Think - before you dive into the code and start aimlessly scavenging around, stop and think. Why would this be happening? What area's of the code are related to this?
• Investigate the code - once you've had an idea of what areas of the code this is likely to affect, start digging in. After reading over the code, you might spot the issue. Hurray! If not, time to get out debugger out.
• Debug - Fire up the debugger, and go through the code line-by-line. Keep an eye on variable values (and how they change) and which functions get called (and which don't). Are the correct branches in an if statement being called? Are events being triggered correctly? Are calculations being performed correctly?

Plan before coding

You have just awoken from a good nights sleep. You're eating breakfast and all of a sudden an awesome new side project idea comes to you. What a fantastic idea it is! A revelation!

You burst out of your chair towards your laptop, cornflakes flying everywhere, and start frantically coding. (Or is this just me? OK moving swiftly along...)

While it is often tempting to jump straight into your IDE and start coding, a bit of planning can go a long way.

• Reduces the amount of "wasted" code
• Reduces code changes
• Gives you solid goals to work towards
• It's an impressive skill for junior developers to have - it shows your critical thinking!

I won't go into too much detail here, as I've written a more comprehensive article on this topic here: How Developers Think: A Walkthrough of the Planning and Design Behind a Simple Web App

Here's a quick summary from the above article for now:

• "What does it do?" - write out the features you want your app to have
• "What does it look like?" - make a quick sketch or wireframe with what your app should look like
• "How do I position and style the elements?" - once you have your wireframes, start thinking about how you will position everything on the page
• "How does it behave?" - next, start thinking about how your app behaves. Thinking about the features, and what happens when the user clicks and action
• "What will my code look like?" - with your behaviours and features in mind, start planning your code. What components will you need? will you need event handlers? state objects?
• "What do I need to test? And what can go wrong?" - think about the tests, edge cases and the parts of your code that could go wrong

The not so good habits

Now let's look at some of not so good habits that are easy to pick up. If you do some of these now, don't panic. We all do at some point! With some practice you can overcome them - and I'll give you some pointers on how to do this.

Blindly copying and pasting code

Put your hand up if you've ever encountered an issue or got stuck while coding? _**raises hand.**_ Obviously, we hit problems all the time whilst coding. It's part of the game and it's our job to figure out how to overcome these problems.

Most of the time we resort to using Google, StackOverflow, or similar in search of answers to our problems. Now, there is nothing wrong with this approach - arguably, it should be encouraged as it's one the best/quickest way for a developer to solve a problem themselves.

The problem is, when we copy/paste code blindly without understanding it.

But if it works, what's the problem?!

A valid point. Here's the reasons why this can cause issues:

• What happens when the code has to be changed? It'll be difficult to change code we don't understand
• If we don't understand the code, how can we be sure it truly solves the problem?
• Can we be sure it doesn't affect other parts of the codebase in a negative way?

So, how can we avoid this?

• Reading - read through it line by line, and take the time to understand the code
• Type - type it out instead of copying and pasting. This will force you can read/analyse each line as you type

There is nothing wrong with copying and pasting, as long as we understand exactly what the code does. If a senior developer is code reviewing our work, and we can't explain what is happening because the code was copy/pasted, that won't look too good.

Not writing tests

This is arguably the worst habit that can be picked up when learning to code. A lot of tutorials walk us through the "happy path" of creating an app, which makes it easy to neglect the test writing. Why are test's so important?

• Test's prove your code works. Nobody can argue about functionality working if the test passes!
• Makes it easy to check that new features haven't broken anything. While coding, run your tests regularly. A few tests broken? You know early in the development process where stuff went wrong. As opposed to, finding out tomorrow when you come across it by accident
• A seat belt for refactoring. Write your code. Write your tests. Refactor your code. Run the tests. Tests pass? Everything still works, happy days! Now try changing your code without having a suite of tests to run. How can you prove everything works as it should?

So make sure to test your code. You don't have to test things like small side projects all the time, but it's good to practice now an again. When you get a job, you'll be aiming to have test coverage for most of your functionality and features. Practice those tests!

There are many great tutorials on how to test your code, depending on your current projects and tech stack, try Googling "testing with {insert language}" or "How to test {insert language} apps". Heres a good overview of testing JavaScript.

Leaving out documentation

Documentation. The boring "red tape" that comes with all projects. As someone once said:

All developers hate writing it, but all developers want it

Which is true. Have you ever returned to an old side project and forgotten what it did? How much harder would it be if you were trying to use a third party library and there was no documentation to explain how it worked? This becomes especially more apparent when working in a large product company. What if another team needs to integrate with your code, but is unsure of the API?

It's important stuff, so here's some tips to practice:

• README's - GitHub lets you add a readme to your project. This is the perfect place to store documentation for the project, as it's easy to find
• Include what the app does and how to run it - This gives the read a good place to start
• Explain other "important things" - such as complicated logic, third party libraries and API's, or configuration settings

Thanks for reading! Want more articles like this?

Hopefully this has given you an insight into one creating good coding habits. If you'd like to be updated when I release more articles like this, feel free to join the mailing list over at chrisblakely.dev! Or reach me over at Twitter if you fancy a chat :)

This is a story of how I struggled to learn when I came back to school to study again for my master's (check my blog about master's) after 5-years of working in corporate. Through others, I learned a lot and improved my day-to-day life. It was a great transformation.

Struggle # 1 - Studying

I understand the concept, but it's not sticking in my head.

I listened to lectures, videos, and textbooks. What did I get? Nothing and sometimes boring.

I had to think of something to retrain my brain.

Tip 1: Writing / Typing increase knowledge retention by 50%.
I used to do this a lot during high school and college. I think most people know about this. But it is still a good reminder.

Tip 2: Blog about it. This would improve your communication skills in conveying your ideas.

You might say: But wait, I'm not a writer and my grammar is bad. =(
I am not good at writing either. I remember my high school and college days, I would have someone proofread my papers and my paper would be drenched in red ink. Ouch!

You might say: Someone already blogged about insert topic.
I always believe each person's perspective is different. Also, this blogging is really for yourself. Don't mind them.

You might say: I'm shy.
Well. Another piece of advice is just to place it in draft purgatory. I have like 72 drafts consisting of ideas or notes.

You might ask: What do I blog?
I found an interesting blogger before who blogs about complex technical stuff and a very simple blog post about MacBook's HDMI port. The HDMI port blog post? It was only an image and a few sentences.

It could be:

• text with pictures and an experience. Example here.
• text with memes and your journey. Example here.
• guides or instructions. Example here.
• power point style. Example here.
• purely visual. Example here.

It doesn't have to be perfect and you'll improve in no time.

You might ask: What's your secret?
Be curious. Aside from that, I have tons of stories and I just keep blogging. I didn't use my weakness in grammar/writing as an excuse to not try blogging. I use Grammarly to fix my sentences.

You might ask: Where to blog?
Right now an easy blog site where you can write stuff down and have a clear blog post like this is in Medium, a blogging site. I used to blog there until they graciously accepted me here, freeCodeCamp News, as an author here.

Tip 3: Learn something. Teach it right away.

You might say: I'm no expert.
Thing is. You learned something and that makes you more than a beginner. You can say... You're now an experienced beginner.

How can an experienced beginner help?
Easy. Help other beginners.

It can be through:

• Explaining high-level concepts.
• Pointing them in the right direction on what resources to check out.

Tip 4: Read... Zzz.
I'm a guy who does not like to read so much. I just remembered reading Harry Potter or Penguin Classics.

Now listen closely, this would rewire your brain to read again.
First, a scenario. You are given a book and It's a thousand pages thick.

Your goal: read the entire book.
In your mind: What now? A thousand pages?!
What you will happen: you will try to read as much as you can then you get sick of reading it.

Enter rewiring your brain.

Change your goal: read a chapter a day.
You might say: It's too long and I might not be consistent with reading a chapter.

Change your goal: read a paragraph a day.
You might say: There might be a chance that there are too many sentences. I don't think I can stay consistent.

Change your goal: read a sentence a day.
You might say: Uh. Sure? That's all? I can do that.
Haha, you fell into my trap. This is a Jedi Mind Trick. Your brain would be tricked into reading the next sentence.

Lesson: Keep your goals as small as possible. This preserves your energy to study and decrease the likelihood of mental stress.

Tip 5: Speak up! Do presentations.

If you got guts, create small talks for your friends and classmates.

Here's a video of my presentation in a conference:

I had tons of opportunities to practice presenting with different tech terms at the technology club at my school, City University of Seattle.

Tip 6: Reading while on commute.
You might say: I get motion sickness.
Two options:

Option 1 - Jedi Mind Trick. Read for 5 minutes. Then slowly increase the read time as you get comfortable.

Option 2 - Bring other materials. Study base on energy levels.
Status - Energetic: Read a physical book or ebook. Use a laptop/tablet.
Status - Somewhat tired from screen display: Watch an educational video .
Status - Very tired from screen display: Read a physical book.
Status - Dead eyes: Listen to a podcast.
Status - No energy: Sleep.

Tip 7: Go to local meetups.
Learn the next exciting thing and get to the change to network with like-minded people.

Bonus: You might get a mentor along the way.
Mentors have helped me big time in giving me a path to follow.
Mentors do come in all shapes and sizes. They could be with you for a short-term or long-term, and physically or virtually.

Tip 7: Join or create a study group.
You are hitting two birds in one stone. You socialize and learn at the same time.

Struggle # 2 - Too Much Distraction.

I'm so guilty of social media. I keep scrolling and scrolling. News Feed. Memes. Videos.

One time, I was with my local study group. I told my friend that I struggle with social media addiction. I got the greatest advice ever.

Tip # 1 Clean your social media to defeat your endless scrolling.

Who to lose:

• Unfriend everyone who you don't know.
• Schoolmate? Batchmate? If you just like their posts and don't interact such as commenting, unfollow them. You'll just envy their beach photos.
• Nonsense post? Unfollow.
• Too much negativity? Unfollow.
• Too much drama? Unfollow.
• Pages with no value-added content. Unfollow.

Who to keep:

• Current classmates
• Mentors
• Close friends
• Family and relatives

Who to add/follow:

• Inspirational people
• Educational and informative bloggers
• Pages that promote awareness
• Pages that give tips and tricks related to your field.

What do you gain:

• More time. Right now, I wake up, check my social media and I would have less than 10 notifications.
• More quality. I tend to have more energy to interact with them now.

Tip # 2 Let's bring in some fun.
For my downtime, I watch films related to technology. Also, I still use my social media for fun such as NBA, Legend of Zelda or other video games.

Next, I started to follow a lot of funny pages that are related to my field, technology. I have tons of these in my Instagram feeds. lol.

This way I'm having fun and learning at the same time.

How?

If I didn't understand the meme/joke, It means I lack the knowledge and would happily google for it to understand.

I current possess 90+ tech memes in my local machine. Whoops!

https://github.com/clarkngo

Conclusion

Try to integrate small tidbits of learning in your day-to-day life.

Jedi Mind Trick your brain.

And... This feels like a good stopping point. Feel free to reach out to me to ask more of my study hacks. =)

Reach out here:

Twitter

LinkedIn

Till next time!

Quick intro to #100DaysOfCode

It’s a challenge and a community that has grown around it over the last couple of years. Thousands of people have taken the challenge and improved their coding skills.

The problem it solves is: when people start learning to code, it’s very difficult to commit to a consistent course of action and code every day. Often the efforts, despite their best intentions, are sporadic. It’s very dangerous in the beginning of their learning journey, because if they take a long break they might quit and never come back to learning.

#100DaysOfCode is a challenge that anyone can commit to.
There are 2 main rules:

1. Code a minimum of an hour every day for the next 100 days
2. Tweet your progress every day with the #100DaysOfCode hashtag and the day number

The rules are not as strict as they may seem. You can adjust the time, or skip some days if needed. The main goal is not to ‘survive at all costs’ but to teach your own brain to be consistent, and to develop a ‘coding habit’.

Another great rule to adopt is:
Encourage at least 2 other people in the challenge (“hundreders”) by commenting on or liking their work and updates on Twitter.

This is one of the ways you can increase the value you are getting from the whole experience: on top of improving your coding skills, you are also making new friends and establishing yourself as a node (pun intended) in the tech industry network.

Sounds good? Let’s commit to the #100DaysOfCode together!

?CLICK HERE

to join us for #100DAYSOFCODE
Starting January 3rd, 2019!?

New Year Resolutions Caveat

Make sure you don’t commit to more than 1 major (and 1 minor) New Year Resolution. If you spread yourself too thin, you will — as many others do — find yourself back at the starting point around Mid-January or February.

Instead, do the opposite of what your brain might be telling you. Push down the excitement of changing everything about your life in an instant. Decide on one thing you will do, and cultivate and foster the excitement for it. Plan out in details what you will learn, when you will study, and so on. All of that helps you stick to the habit.

I think learning to code is one of the best skills one might decide to develop. It brings with it the freedom, the finances, the enjoyment of work and so much more. So, my biased advice is: make one resolution and let that be learning to code or improving your existing coding skills.

Read on to learn more about habits and get some #100DaysOfCode community updates!

Not Just For Beginners

The challenge is definitely not only for people starting to learn to code. It benefits people no matter what their skill level is. If you are just starting out, don’t feel that you need to ‘only work on projects’ — you can use any resources you want to learn.

If you are not new to coding, you can use the challenge to:

• Learn a new framework
• Learn a new programming language
• Get a lot of practice in a specific area or problem type you decide on
• Contribute to Open Source
• Get better at refactoring code

Remember that the #100DaysOfCode challenge is designed to be taken multiple times. Each time you plan, do it, then analyze the results. These are called rounds. Each round you will get better at planning and execution, which will lead to more results in the same period of time.

Be Kind To Yourself

To be more specific: feel free to bend the challenge rules to meet your needs.

This is the point I wanted to address the most. I often see people restarting the challenge because they’ve missed a day, or people who say they can’t do the challenge because they don’t have a whole hour to spare every day, and so on.

I want you to be kind to yourself, to understand the ultimate goal of the challenge — to develop a coding habit. Everything else is secondary. Life will get in your way. Things will happen, late nights out, laptop breakdowns, and more. Don’t be deterred by that.

I suggest that if you find that you’re asking yourself “Should I restart the challenge or continue?” and you are more than one week ‘in’, the answer should almost always be: continue.

If someone tells you that you’re doing it wrong or not really doing the challenge, just ignore them. It’s the same people who like to judge others like: “Oh, they are not a real developer because the do or don’t do X”.

Make A Plan, But Don’t Overthink

Before starting the challenge, write a quick plan. Write down what you want to learn (such as JavaScript, React, Python or CSS) and 3–4 resources you will use as you go along. The goal is to never have a day when you have to wonder: “What should I work on today?” because that is a slippery slope to breaking a newly formed coding habit.

Reach out to the #100DaysOfCode Community

If you feel stuck or struggling with something as you go through or plan your challenge, don’t hesitate to reach out to the community with your questions and thoughts — tweet using the #100DaysOfCode hashtag.

We currently have more than 4000 people in our Slack. Click on this link for the Slack Invite!

Remember that the more social connections you have in this journey of learning to program, the smoother that journey will be and, also, you will get there faster!

Learn more about the challenge on the official website: www.100DaysOfCode.com.

Identity-Based Habits

This is probably the most powerful concept I’ve learned this year. It comes from James Clear’s book: “Atomic Habits”.

The idea is that we often fail to acquire a certain habit because we don’t think of ourselves as a person who would do that. For example, you want to start exercising, but you don’t consider yourself “a fit person”. All the effort you put into forcing yourself to exercise gets nowhere, because eventually you get tired and “bounce back” to your regular lifestyle.

The key is to start thinking of yourself as a different, new kind of person you want to be, and then your efforts will just keep backing up your new belief.

Let’s say you think you are “not a technical person” and you decide to learn to code. If you keep that belief, whenever doubts will come to your head, you will think: “yes of course I struggle with learning to program, it’s because I am not a technical person”.

However if, when you start the #100DaysOfCode challenge, you were to change that one belief — just decide that from now on, you are a technical person, a hacker, a computer genius in the making. Then, when you code for an hour every day, you will be proving to yourself that you indeed were correct in the new belief you’d chosen for yourself.

Don’t rush to make a decision on whether you are ‘not meant to be a coder’. An example that will give some perspective on this: you wouldn’t expect that if you picked up a violin today for the first time, you would be a great player next week. Same with learning foreign languages. Yet, I see people judging themselves as ‘not fit’ for coding after they try it out for a week.

Nothing great happens overnight. It will be more like a sliding wave of daily effort, which you get at riding better slowly but surely. It’s unstoppable.

If you want to learn more about habit formation: this year I’ve given a talk at a free remote conference ByteConf React, where I’ve tried to crystallize everything I’ve learned so far about habits and self-improvement strategies and techniques. It’s available on YouTube ?

Let’s commit to #100DaysOfCode together!

?CLICK HERE to join us for #100DAYSOFCODE starting January 3rd, 2019!?

Thank you so much for reading this article! A lot more to come in the New Year! If you are interested in learning to code, habit formation, self-improvement (and a bit of nerdy sci-fi and space stuff), sign up for my newsletter:? https://www.dotheoppo.site ? …subscription form is below the projects :)

If you have questions, concerns or you are afraid the ‘coding is not for you’, DM me on Twitter and I will do my best to help!

Life moves pretty fast. If you don’t stop and look around once in a while, you could miss it. — Ferris Bueller

My time at freeCodeCamp was a fun and exciting one. When I first began with freeCodeCamp, I’d often come across this message, which also sounded like a preamble —

Let’s pick up a new skill and get a new job, all in a few months.

You will see a lot of articles like “Hey all, I was a school teacher before, and now I’m earning $100k as a engineer for x startup”. If you’re starting out in web development and you surround yourself with other people who want to achieve things — they will, you know, achieve. And so will you!

There’s a bit of expectation vs. reality here. If you are the kind of person that can memorize a ton of information relating to your chosen field, then you’re onto a winner. As for myself, it’s about repetition and repetition, until it becomes a habit. And there’s a lot to be said about habits.

Forming habits takes time though. On December 30, 2016, I decided to take part in the #100DaysOfCode challenge. I couldn’t give you an idea of how I felt then, but reviewing the log entries I seemed pretty confused and a little frustrated with it all.

At the end of it, it’s definitely been an enriching and life changing experience for me. Along the way I have met some truly awesome and inspiring people, happy to help with any issues or problems you may have. The support I found not just in the #100DaysOfCode community but the web dev community as a whole is truly amazing.

I’m going to go over some steps I have taken to help me with learning to code (again) and cracking #100DaysOfCode.

Having Patience

Being patient is essential — instant gratification doesn’t work all the time. This will soon come to light if you start to compare yourself to how other people (your cohorts) are progressing. You may start to wonder why you’re not progressing as fast as other people appear to be. This might probably add to any anxiety you may have, whether you can do something or not. Do not concern yourself with this and instead use that energy to focus on what you need to do, and code.

Different people progress at different rates and learn in different ways

As for myself, I have found that I’m a visual learner. I’ve known this for a long time actually, where to be able to ‘join up’ concepts and paradigms that I need to see in action. This is why I will always gush about courses by Kent C. Dodds or Wes Bos, as they are great at explaining complex subjects, among many others. Their content on egghead.io and wesbos.com are awesome at explaining concepts simply and visually.

Your mileage may vary though. So find out what works for you, and stick with it!

I have discovered recently that splitting my time between projects wasn’t really helping me. So I decided to work on one particular project each time I sat down to code. The first time I did this, I was struggling for hours with little to nothing show for it. It felt futile and I was getting anxious about not moving on. It was at this point when I would usually switch context and work on something else. I found though that pushing that little bit more was all I needed.

This was such a psychological win for me, and gave me the confidence to do more. It has paid dividends, as I now have 6+ demos of projects I have made on my portfolio.

Avoiding Distractions

I get distracted by things like Slack, email and Twitter. These apps should not be opened, as it will eat up your time. You have a set amount of time to get something done. This will come to light when you have finished reading your Twitter updates and Slack messages, only to realize you have fifteen minutes left to complete the task you set out to do.

I noticed this soon into starting #100DaysOfCode. What I did was turn off all my phone notifications. If you need to check something then check it. But don’t let your phone dictate where your attention needs to be directed.

I turned off all browser notifications for Slack and Gmail. My phone is left in another room on “Do Not Disturb” while I work. While in Do Not Disturb mode my phone will not make a noise, unless someone on my stared contacts list calls me. I pick up the phone in the afternoon to check for missed calls, listen to voice mails and return any calls if needed.

Making time

Saying that you don’t have the time to do 1–2 hours of coding a day isn’t going to help. Yes it’s tough, but it’s not about having the time. It’s about making the time to do it.

If it’s important to you, you will make time for it.

You’re the only one that can make these things happen. Often I get asked “So what do you like to do”? I struggle to answer this, as all I have been doing for the last 18 months is learning to code!

Creating Balance

It’s the key to everything. I am not perfect here — this journey has taken its toll on my health. Towards the end of 2016 I was 95 kg, and today as on February 26th I’m 115 kg.

This weight gain is a mixture of illness at the start of 2017 and bad diet choices thereafter. In the past I consciously opted for ‘healthy’ foods, spending that little extra time deciding what to eat.

While being ill at the start of 2017, I developed a bit of an addiction to cereals (granola) ?. It was quick to prepare and easy to eat, and I got a quick boost from it.

Quick and easy soon became the norm after that. I have identified this now and am making an effort to reduce this, while also making time for my development.

You need to have a balanced diet too! ?

_my hack-diet weight stats for the last 15 months: [https://www.fourmilab.ch](https://www.fourmilab.ch" rel="noopener" target="blank" title=")

Using Tools

I use some tools to help me ‘get on’ with what I’ve set out to do.

A while back I started using Todoist. This is great for when you’re scrolling through your Twitter feed and find a link to a really neat looking tutorial or post you want to read, but don’t want to go down the rabbit hole of working out where to document it. I usually add such links to Todoist and come back to it when I get the capacity to work on it.

WakaTime is a great tool for quantifying your coding — pretty handy when doing #100DaysOfCode.

stats yo!

RescueTime is handy for helping you identify your productivity black holes and give you a nice breakdown of where your time is spent on your computer and mobile.

Using Life hacks…

They’re called hacks, so everyone can think they’re used for “cheating the system”. In reality they’re some helpful rules to aid you if you need to find some extra time.

Get up early. I’ve taken to getting up an hour earlier than I used to, to squeeze an hour and a half out of the morning. I have an MI band that I have set to vibrate to wake me at that time, so I do not disturb my wife.

Go to bed early. Sleep is important kids — anyone that says otherwise obviously doesn’t get enough sleep.

…and some Good luck ?

When I finished my last (VBA) contract in October, I used that time to fully immerse myself in web development.

At the time (which was good timing actually) I started a build to learn project with two other remote developers — one in Egypt, and one in Serbia. We were all participating in the Chingu Voyage, and this has been a real eye opener for me. It has given me the confidence to get all my portfolio projects ready for potential employers to view.

While taking part in the project, I got to treat it as a full time job — which my WakaTime stats will attest. This was one of the triggers for me that I should start applying for jobs as a junior dev.

Thanks for reading

If there is anything I have missed, or if you have a better way to do something then please let me know.

Find me on Twitter or Ask Me Anything on GitHub.

This was originally posted on my blog.

You can read other articles like this on my blog.

At the end of last year, I wrote about my experience coding and making daily commits to GitHub for 30 consecutive days. I also pledged to keep the streak going for as long as I could. I am happy to report that I made it through 90 straight days! It was an incredible experience, and I learned a ton.

The following is an overview of the projects I completed and some lessons I learned along the way. I hope it motivates some of you to make your own daily commitment to code.

Completed freeCodeCamp’s Front-End Certification

I had worked on the more basic freeCodeCamp material ages ago. I still had to complete eight intermediate and advanced front-end projects and a series of small coding challenges before I could claim my certification.

The projects covered a wide variety of topics and proved quite challenging at times. I used an API to display the local weather, and for another I built a working clone of the children’s game Simon. The combination of good resources and the patience of some more experienced friends helped me finish them to earn my certification.

These projects taught me how to organize and write clean code. I honed my JavaScript skills and learned how the language differs from other more classically object-oriented languages such as Ruby and Python.

A few weeks after I earned my certification, I went back and refactored some of the initial projects. I applied the DRY principle and included some functional programming concepts I had subsequently learned. It was great fun trying to eliminate all of the for loops in my code.

Wrote a widely-shared (for me, anyway) article about learning JavaScript

After finishing my first blog, which freeCodeCamp was kind enough to publish on its Medium page, I had the itch to write something else.

Because it can be so hard to figure out which learning resources are actually worthwhile, I decided to put together a study plan for beginners looking to learn JavaScript based on what I had found useful. The article was again published by freeCodeCamp and currently has over 15 thousand views and 700 recommends.

Not exactly ‘viral,’ sure, but for someone who had never done any public writing as recently as six months ago, it was exhilarating to see my article resonate with a bunch of people.

Learned React

In addition to completing the freeCodeCamp Front-End Certification, I also began learning React. Thanks to a few great tutorials (shout out to the excellent Wes Bos course, React for Beginners), I was able to finish a few React projects. These included a live-searchable recipe repository. I also became comfortable using the create-react-app CLI tool to scaffold React applications.

Broke my streak on Day 91

With progress so great, why did I stop? The path I paved for myself had slowed down. I felt intimidated by some of the upcoming projects on freeCodeCamp, so I shifted my efforts to learning D3.js, a data-visualization library. At the time, it proved to be a bit too impenetrable for me despite multiple attempts to grasp it.

Also, I didn’t have a compelling personal project to work on, and needed a break from the grind of working full-time and coding at night for multiple hours.

The most important thing I learned about keeping a streak like this going is to always know what to work on tomorrow. When you sit down at your computer, you should already have a clear idea of what you’re going to do. If you make that decision ahead of time, it removes a barrier to getting started.

Take a moment before you decide to stop coding for the day and make sure you have something concrete to do tomorrow. I stuck to this plan for the vast majority of my streak and it was a major factor in my success. It was only when I stopped planning ahead that I eventually missed a day.

A completely worthwhile experience

At the beginning of my not-quite #100DaysOfCode, I had some familiarity with the Ruby on Rails ecosystem and HTML/CSS with only a few hours of JavaScript under my belt.

Three months later, I gained a good, foundational knowledge of JavaScript, learned React, got a bunch of cool projects in my GitHub portfolio, and had two articles published on freeCodeCamp’s Medium page. I am a far better developer today than I was when I started this daily coding experiment a few months ago.

Next steps

Having taken a pretty substantial break, I want to continue working on React projects, dip my toes into some backend JavaScript, and learn more about algorithms and data structures. I also hope to keep writing.

If you enjoyed this article and want to continue the discussion, come find me on Twitter.