Your daily thoughts, practices, and how you internalize what happens around you will determine your success.

When you run into something confusing or frustrating, re-position your mind: this obstacle is a learning opportunity.

Purpose

To collate and organize actionable info related to software engineering life and habits, specifically as a junior dev (and also take a load off my poor bookmark manager 🙃 ) Let's start with one responsible for the entire blog in the first place...

Write a Blog 📝

What

• Document learnings: new problems, frameworks, tips 🧐 (bite-sized articles)
• Document achievements: big or small, personal or work 🥳 (Grid Diary)
• Document activity: daily & weekly log, monthly & yearly retro 👔 (Grid Diary)

Why

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

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.

How

If you're reading this, I am probably writing blogs using Hashnode.

• Keep articles easy to find: using tags, images, code, bookmarks. Don't worry too much about SEO, visibility, etc.
• Keep knowledge linked: add links to reference projects, articles & other reference material.
• Don't worry about backlog: start documenting stuff encountered from now on.
• THIS IS GOING TO TAKE TIME. KEEP AT IT! 😎

  Blogging is a chore at first but can grow to be very rewarding if you stick to it.

When Stuck, Take a Break 😫

What

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!"

Why

Getting some distance to the problem will allow you to see solutions you were blind to before.

You won't believe how often a problem is "just solved" the next morning. 😒

How

Work for 45mins slices. At the end of each:

• Ask me if I'm still working in a "solution mode", or if I'm stuck.
• Use the end of a unit as a trigger for other habits: stretch, eat, journal, etc.

Volunteer for Things You Don't Know 🙋‍♀️

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

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.

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.

How to Ask For Help 🥺

What

There's no context. There's no information for them to go on. In fact, they have to ask for more information from you. This is incredibly inefficient and very frustrating for the person that is trying to help you.

Why

They will greatly appreciate that you gave them that information so clearly—and that you've already tried to fix it yourself.

This shows them that you respect their time, and you're not just looking for an easy handout.

They can understand what you're working on, what the problem is, what you've tried already and where the problem is.

How

• Wait for 30-40 mins on the problem before asking for help.
• Try rubber duck debugging.

  You're forced to explain the entire context in a logical way in order for the other person to understand what's going on. Just the act of trying to prepare this context can cause you to think about the problem in a different light.

• Then, use this template:

I am working on _____,
but when I try _____,
_____ happens instead.

I've tried _____, _____, and _____.
and I've looked at _____ and _____.

Other Bite-sized Advice

• Pair up: profit from how partner thinks and solves problems
• Update people regularly that have an interest/expect results
• Maintain a notebook for random on-the-go stuff but only if it can be processed each week.

  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.

Some Zen, Calming Advice

The company that hired you knows the limitations of your current knowledge and skills. They understand they'll need to invest significant time into your growth to teach and train you. Remember, this company wants you to succeed! They're on your side. They're not going to hang you out to dry—that would be a poor way to treat their investment in you.

Reading other people's code is a skill you have to develop, and it's one you'll use your entire career.

It's likely your boss will meet with you and create a 30/60/90 day plan. If they don't do this—ask! Any supervisor will appreciate you owning your job and job expectations.

Staying on top of your mind and not allowing the feeling of defeat to creep in will not only help you perform better in the situation, but it also increases the knowledge and skill you leave the situation with. Take a deep breath, take a break, ask for help—but keep pushing through.

Remember, this isn't unique to you—every new developer has faced this. Keep your mind in check and you'll push through.

It's not just practice, but how you practice that matters.

It's not like there's ten problems you have to work through and you're done for the rest of your life—you'll face problems every single day as a developer.

The best thing you've learned is how to teach yourself. Take this practiced skill you have and show up with it every single day.

And then at the end of the day: shrug it all off. Drop it on the ground when you leave the office or close your computer for the day. Start the next day fresh and ready for its own adventures.

References

• How to Become an Outstanding Junior Developer
• 9 Habits I Wish I Had as a Junior Developer
• How to Use Deliberate Practice to Learn Programming More Efficiently
• What I Learned from Reading "The Pragmatic Programmer"
• How to Set Your Future Self Up for Success with Good Coding Habits
• How to Make Your Code Reviewer Fall in Love with You

TODO

[] Spin off another article about calming down when things aren't going right (advice, when and how to ask for help etc)
[] Spin off another article on debugging
[] Spin off another article about git (hygiene, standards, PR, gotchas etc)
[] Add links (spin-off articles, action items)