If you’re a junior, mid-level, or self-taught developer who keeps getting rejected and you don’t fully understand why, I hope this helps.

Here’s what I’ll cover:

1. My 18-Month Job Search Struggle

2. The Interview Problem I Didn’t Expect

3. Discovering Active Recall and Flashcards

4. My Interview Preparation System

5. The Results

6. Changing How I Looked for Jobs

7. Turning My System Into a Small Tool

8. Lessons I learned

9. Final Thoughts

My 18-Month Job Search Struggle

For 18 months, I was trying to land a remote or relocation web developer job.

During that time:

• I applied to more than 1,000 positions

• I went through around 20–30 interviews

• I failed most of them

It was exhausting. I felt like I was putting in a lot of effort but getting almost no results. Over time, I started doubting my skills and wondering whether I would ever find a job I’d actually be satisfied with.

What made this even more confusing was that a few years earlier, in 2021, I had found a remote job at a US company in just three weeks – with almost no experience

Something clearly wasn’t working anymore.

The Interview Problem I Didn’t Expect

After dozens of interviews, I noticed a pattern: I wasn’t failing because I couldn’t solve complex algorithm problems or build features under pressure. I was failing on basic technical questions.

Questions like:

• “What are portals in React?”

• “Can you explain how an HTTP GET request works?”

These were not hard questions. They were things I had learned before. But during interviews, under pressure, I just couldn’t recall. Or simply I skipped it during preparation because there were no systems in place.

That’s when I realized the real issue: I didn’t have a problem understanding concepts. I had a problem recalling them quickly.

My first instinct was to study more. More tutorials, more articles, more videos.

But passive learning didn’t fix the problem. I still froze during interviews. What I actually needed was a way to train my memory, not just consume information.

Discovering Active Recall and Flashcards

That’s when I came across flashcards and the concept of active recall.

Active recall means testing yourself repeatedly on what you’ve learned instead of just rereading material. You try to answer a question from memory first, then check the answer. This approach has been backed by research for more than a century.

I started practicing small, specific concepts this way, like:

• React fundamentals

• JavaScript basics

• HTTP methods

• Browser behavior

I repeated them until recalling the answer felt automatic.

This made a huge difference during interviews.

Flashcards help you cut through the noise and actually learn what matters. It's not just about memorizing facts – it's about really understanding, remembering fast, and building a solid base in every concept you study.

So to help you prepare for your interviews, I’ve taken years of experience and scientific learning methods and turned them into a tool and approach that gives you the right info at the right time.

My Interview Preparation System

Once I found the right learning method, I built a simple system around it.

Step 1: Ask What to Prepare For

Instead of guessing what to study, I started asking recruiters directly:

“What topics should I prepare for the technical interview?”

Surprisingly, many of them replied with a clear list, which helped me focus only on what actually mattered and avoid over-preparing random topics. In my experience, many HR reps are quite helpful to job applicants.

For example, when I applied for a position as a Frontend Web Developer in React, the HR specialist advised me to focus mainly on React and JavaScript. So I prepared for all the popular questions around hoisting (JS), the event loop (JS), how react works under the hood, what props are and how they work, and so on.

Overall, that interview went well – but when I got a question on React Portals, I couldn’t explain it properly. And so I didn’t get the position. But I don’t blame myself for this one, as that’s a very rare topic. 😊

I also applied for another Front End Developer role where the HR specialist advised me to prepare mainly for questions about GSAP, Framer Motion, and React/Next JS. This made sense, as the company mainly builds modern animated websites.

In my interview, the theory round went well, but I failed the take home assignment. I realized then that I didn’t have enough skills in these areas.

At another company, I asked HR about the cultural interview, which was the last round. The rep said: ”No worries, all the hard work is done from your side. Prep for just a human dialog.”

And for the last application I submitted (and after which I actually got the job offer), the HR specialist told me to strongly prepare for CSS – especially Flexbox and Grid. This made sense, as the position was for an HTML markup developer. And so I practiced all the ins and outs for these topics, even the more rare ones.

I use the same approach for each round of interviews.

Step 2: Use Flashcards (With AI Carefully)

I used ChatGPT to generate flashcards for each topic and reviewed them daily.

One important thing I learned: AI can be wrong sometimes. To reduce mistakes, I started adding links to official documentation in my prompts so the answers were grounded in reliable sources.

I kept sessions short and consistent. That consistency mattered more than long study sessions.

AI mistakes was the reason I created 99cards.dev

Here is the prompt I use in ChatGPT:

You are a web development expert with 20 years of experience. Your task is to help me to prepare for the interview.

Prepare 10 flashcards on CSS Flexbox topics. Format one question with four answers. One answer is correct.

You're going to serve all the questions one by one. After I answer, you give me feedback and then give me the next question.

Note that you should tweak your prompts for your needs, and based on what you need to review.

You can experiment with various factors, such as:

• Difficulty: beginner or advanced

• Specificity: from vague (for example: I want to practice with CSS) to highly specific (for example: I want to practice with the flex property in CSS Flexbox)

• Number of questions: sweet spot is between 10 and 20

• Add context: good practice is to add links to official docs, as it decreases the chances of AI hallucination

Here is a typical flashcard created by ChatGPT:

If you provide an answer, you’ll get feedback like this:

The Results

After a few weeks, interviews felt very different.

I was calmer. I answered basic questions without panicking. I could explain concepts clearly and confidently.

In my final interview process, I passed four rounds in a row and scored 95% on the technical test.

Soon after, I received an offer: $5,500 per month and a paid relocation package for my family and me.

For the first time in a long while, my effort finally matched the results.

Changing How I Looked for Jobs

About six weeks before getting the offer, I also changed where I searched for jobs.

Instead of relying only on large job platforms, I started using smaller communities like Telegram job groups.

This helped for two reasons:

1. Less competition: many smaller companies post roles there with fewer applicants

2. Direct communication: I could message recruiters before applying

Before submitting an application, I would ask:

“I saw this position. Here’s my CV and LinkedIn. Am I a good fit?”

If the answer was yes, I applied. If not, I moved on immediately.

This saved me a lot of time and energy.

Turning My System Into a Small Tool

While preparing for interviews, I created thousands of flashcards for myself. Managing them in notes became difficult, so I eventually turned them into a small tool called 99cards.dev.

It’s simply a collection of fact-checked web development flashcards grouped by topic, based on the same approach that helped me stop failing basic interview questions.

Here are some screenshots from the app:

Lessons I Learned

Here are a few takeaways from this experience:

• Failing interviews doesn’t always mean you lack skills

• Passive learning is not enough for interview prep

• Being able to recall basics quickly matters a lot

• Job searching is a skill, not just a numbers game

• Consistency beats cramming every time

Final Thoughts

If you’re struggling with interviews right now, especially as a junior, mid-level, or self-taught developer, don’t assume you’re bad at what you do.

In my case, the problem wasn’t effort or talent. It was preparation and approach.

I also created a free interview checklist based on my experience, covering HR, technical, behavioral, system design, live coding, take-home tasks, algorithms, and cultural fit.

I hope this story saves you some time and stress.

You’re often just one good interview away.
— Ilyas

The task was seemingly simple: build six squares with no color, make each square turn green when clicked. Then when the last square turned green, make them all go back to no color in the reverse order in which they were clicked.

I was excited to test out the skills of some junior developers I was working with who were just starting out in tech, so I shared the challenge with them. But the results were not what I expected.

Despite its apparent simplicity, the challenge brought out varying results. Some students successfully created a functional solution, while others struggled with the required programming concepts.

That's when I realized that this could be a great opportunity for a lot of people. So if you're a junior developer finding it challenging to create your own portfolio/demo projects, fear not! This article will guide you through the process of successfully building a project with a straightforward approach.

Who is This Article For?

This article is specifically tailored for junior developers who might be struggling to create their own personal side projects.

If you often find yourself relying on tutorials or feel like you lack the creativity to create projects independently, then this article is for you.

Getting Started

Let's take a look at the challenge I sent the students:

Build six squares with no color 
Every time you click one, it turns green 
When the last square turns green, they all go back to no color in backwards sequence to which it was clicked (not all at once)

If you were one of the students presented with this challenge, what would you do first? While it may be tempting to dive right into coding, it's important to recognize that writing code is actually the last step of building a project.

So, what's the first step? The first step is to think. Yeah I mean to literally stop and think about the problem you're trying to solve.

How to Think About the Problem

When approaching a project, it's important to think of it as a problem that needs a solution. Take your time to carefully consider the problem, and then break it down into smaller parts.

To do this, you may find it helpful to step away from your computer and grab a pencil and piece of paper.

For example, when faced with any kind of challenge, you can start by breaking the project down into more manageable parts. This might include:

1. Creating the six squares

2. Determining a way to change their color when clicked

3. Create a mechanism to track which squares have been clicked

4. Devise a method for the squares to return to their original state in the reverse order they were clicked

No matter how big a project may seem, it's always important to break it down into smaller parts. This makes it easier to tackle each individual piece one at a time while staying organized and focused.

So, when faced with a large project, don't be intimidated. Instead, take the time to break it down into smaller pieces and focus on tackling each piece individually. By doing so, you'll be able to stay organized, stay focused, and ultimately be more successful in your project.

After taking some time to carefully consider the challenge, I was able to come up with a potential solution. Here's what I came up with:

// step 1: creating the six squares

- CREATE six individual buttons in HTML 
- GIVE each button a class name of square
- GIVE them unique IDs

// step 2: Determining a way to change their color when clicked

- ADD a CLICK Event Listener to each button
- CALL a function called UpdateSquares() that changes the color of a clicked button

// step 3: Create a mechanism to track which squares have been clicked

- CREATE an array called `array_sqr` that stores the unique ID of a clicked button
- When a button has been clicked, add the ID to the array

// step 4: devise a method for the squares to return to their original state in the reverse order they were clicked

- When `array_sqr.length == 6` call a function called ReverseSquares()
- In the ReverseSquares() function, loop through `array_sqr`
- Inside the loop, SELECT each button with the unique IDs in `array_sqr`
- REMOVE the color green from the selected button

After you have carefully thought about your project, you can now move on to the next step, which is actually building your project.

How to Solve the Problem and Build the Solution

After careful consideration of the challenge, it's time to move on to building the project. Let's go through the steps:

Step 1: Create the Six Squares

In this step, we have three things to do: create six individual buttons in HTML, give each button the class name of a square, and give them unique IDs.

You can do that in HTML like this:

<body>
    <div class="wrapper">
        <button class="square" id="1">
            Button 1
        </button>
        <button class="square" id="2">
            Button 2
        </button>
        <button class="square" id="3">
            Button 3
        </button>
        <button class="square" id="4">
            Button 4
        </button>
        <button class="square" id="5">
            Button 5
        </button>
        <button class="square" id="6">
            Button 6
        </button>
    </div>
</body>
<script src="script.js"></script>

Above, we just created the buttons with unique IDs just like we wrote down.

Step 2: Determine a way to change their color when clicked.

In this step, we just have two tasks: ADD a CLICK Event Listener to each button, and then call a function called UpdateSquares() that changes the color of a clicked button.

We will do this in JavaScript, so we'll create a new file called script.js with the following code:

const buttons = document.querySelectorAll(".square");

for (const button of buttons) {
    button.addEventListener("click", UpdateSquares);
}

function UpdateSquares(event) {
    const btn = event.target;
    btn.style.backgroundColor = 'green';
    array_sqr.push(btn.id);
}

Step 3: Create a mechanism to track which squares have been clicked.

In the next step we need to create an empty array called array_sqr that stores the unique ID of a clicked button. Then, when a button has been clicked, we need to add the ID to the array. Modifying our code to achieve the above, we have this:

…
let array_sqr = []; // create the empty array

function UpdateSquares(event) {
    const btn = event.target;
    btn.style.backgroundColor = 'green';
    array_sqr.push(btn.id); // push the ID to the array
}

In the above code, all we have done is keep track of the way the buttons are clicked by storing them in an array.

Step 4: Devise a method for the squares to return to their original state in the reverse order they were clicked.

In this last step, we have to call a function ReverseSquares() when array_sqr.length == 6.

In the ReverseSquares() function, loop through array_sqr. Inside the loop, select each button with the unique IDs in array_sqr and remove the color green from the selected button.

Below is the code to do this:

const buttons = document.querySelectorAll(".square");

for (const button of buttons) {
    button.addEventListener("click", UpdateSquares);
}

let array_sqr = [];

function UpdateSquares(event) {
    const btn = event.target;
    btn.style.backgroundColor = 'green';
    array_sqr.push(btn.id);

    if (array_sqr.length == 6) {
        ReverseSquares();
    }
}

function ReverseSquares() {
    array_sqr.reverse();

    for (const id of array_sqr) {
        const reverse_btn = document.getElementById(id);

        // Remove the color 
        reverse_btn.style.backgroundColor = 'white';

        /* Also clear the array */
        array_sqr = [];
    }
}

With the code above, we are practically done with the project, and it works as expected-ish. Take a look at the demo below:

The only thing left to figure out is that at the moment, all the colors are removed at the same time. So we need to solve this, which will lead us to the final aspect of building our project.

How to Improve the Solution

Our project currently has a problem where the color is removed from all the squares at the same time. So we need to fix that.

Every project has to undergo this crucial step of making updates and fixes. It's very hard to build a perfect project on your first try. I didn't even build the demo in this tutorial on my first try.

Improving your project can sometimes be even tougher than building the project itself. Fun fact: it took me more time to get the colors to change at different intervals than actually writing the code for the demo I used in this tutorial.

This steps generally involves a lot of Googling and sometimes even asking others for help. It’s perfectly okay to do that – it doesn't make you a bad developer.

Now that we have got that out of the way, let's improve our project. All we have to do is modify the ReverseSquares() function like so:

function ReverseSquares() {
    array_sqr.reverse();
    // Use for..of loop to apply different timeouts for each button
    for (const [index, id] of array_sqr.entries()) {
        const reverse_btn = document.getElementById(id);

        // Remove the color after a delay, with increasing delay for each button
        setTimeout(() => {
            reverse_btn.style.backgroundColor = 'white';
        }, index * 1000);

        /* Also clear the array */
        array_sqr = [];
    }
}

When everything is put together, you have a solution that works. It might not be perfect, but it works – and that's a win.

Summary

Creating side projects as a junior developer might seem challenging. But by following a systematic approach of thinking things through, planning out your code, actually coding, and then improving on your solution, you can successfully build projects that showcase your skills and creativity.

Don't be afraid to break down larger projects into smaller, more manageable parts. And remember that improvement is an integral part of the development process.

If you have any questions, feel free to message on Twitter at @sprucekhalifa, and don't forget to follow me for more insights and updates. Happy coding!

Photo by Scott Graham on Unsplash

There are many reasons to join the tech industry such as competitive salaries, promising career paths, and work-life flexibility. In my opinion, one of the biggest reasons to work in tech is that some tech companies even hire without a formal 4-year degree.

In this blog, I will share some entry-level tech jobs and their potential career paths. I will also share some tips that will give you an extra edge and help you stand out in your job applications.

If you have decided to embark on your tech journey but are unsure about where to start, this blog post is for you.

How to prepare for entry-level tech jobs

For an entry-level job, you should be comfortable working on a computer and be familiar with commonly used operating systems like Windows or Mac.

If you plan to work remotely, you should have a working machine and stable internet. Most companies provide the necessary equipment, but if you plan to work as a freelancer, then it is always better to invest in a good machine.

Entry Level Tech Jobs

I have prepared a list of entry-level jobs that can help you get started with tech.

Help desk analyst

A help desk analyst usually works on tier 1, which means you would be in direct coordination with customers and users.

In this role, you are responsible for answering calls and offering support according to the company's processes.

For example, a user is using Outlook and their emails are not refreshing. You can help that user fix their Outlook issue by sharing some troubleshooting steps. If the issue is complex, you can engage tier 2 support and delegate the issue.

Requirements

While prior technical knowledge can be a plus, there are some soft skills that are especially required such as communication and problem-solving skills.

As most of the time you'll be dealing with customers and users over calls or emails, it is important that you are able to convey your message properly while understanding their problem.

Regarding the technical aspects of the job, most companies provide on-the-job training to help you grow your skills.

Potential career path

When you gain ample experience as a tier-1 analyst, you can progress to the tier-2 support where you would be able to handle even more complex issues.

Pros and cons of begin a help desk analyst

Pros:

• The learning curve can be steep, but you'll get on-the-job training.
• There are a lot of networking opportunities as you will be coordinating with numerous clients daily.
• Troubleshooting steps are applicable and helpful for your personal day to day issues as well.

Cons:

• The job can get hectic in case of an unforeseen issues.
• As this is a support role, there is a possibility of working on a shift basis including weekends.

Computer technician

Computer technicians repair computers and fix any other equipment issues. They usually work for companies or businesses as per contract.

A typical day as a computer technician could involve fixing printers, repairing laptop batteries, replacing faulty cables, and so on.

Requirements

As a computer technician, you will need to be aware of how a computer is built and how other peripheral devices are interconnected in order to troubleshoot and fix any hardware issues.

Once you start working in the field, you can select a niche and excel in that area.

Potential career path

Once you are comfortable in your current role, you can work as a consultant for companies that require hardware support.

You can also provide support as a freelancer and work on your own terms.

Pros and cons of being a computer technician

Pros:

• You'll learn a lot and you'll get to explore multiple domains. For example, if you are working in the network domain you can ramp up your skills by passing networking certifications.
• In-depth knowledge of hardware helps in almost every tech field. For example, managing server hardware is similar to managing regular hardware.

Cons:

• Being a support role, you can expect to work in a shift basis including weekends.
• The job could be physically exhausting if it involves lifting heavy equipment.
• There is a possibility that the job could involve traveling

Technical writer

Technical writers are responsible for creating documentation for a product or a company's processes, or services.

Documentation is really important in IT as it provides guidance for software development as well as helps in troubleshooting later. Clear and concise documentation reduces the chance of errors and helps users understand issues in the end product. So, there is always a need for technical writers.

If you are interested in writing and want to get your foot in the door, technical writing might be a good fit for you.

Requirements

To get a job as a technical writer, you'll need a strong writing portfolio to showcase your writing skills.

Your writing should be able to clearly explain the subject to your audience. You should be able to break down complex matters into understandable smaller blocks as technical topics can get really complicated sometimes.

Potential career path

You can write paid technical articles for various companies as a freelancer. Some companies pay a good price per article for certain topics.

Usually, there are editorial teams that work with you and share their constructive feedback before accepting your article. **

Pros and cons of being a technical writer

Pros:

• You can get good side projects that you can work on at your own pace.
• You can publish E-books and manuals and monetize them.
• You can create your own blog and a strong personal brand.

Cons:

• Some topics are difficult to research, especially newer topics in tech.
• Writing is a creative process, and you might not be able to write when you are tired.

Data entry officer

Data entry professionals are responsible for manually entering data into the computer. They use data processing programs to enter information into either a database or in spreadsheets or word documents.

Transcribing data also falls in the domain of data entry. Transcription includes transcribing data from audio recordings, videos, or phone conversations.

Requirements

Usually, you'll need a good understanding of data processing programs like MS Office and Excel. Good typing speed is a plus that you can improved on as you progress into the role of a data entry officer.

Potential career path

If you have decided to stick with this career, there are some strategies to power up your skills and move up the career ladder.

If you are studying, continue your education while focusing on subjects like data science and data engineering. Try to learn programming languages that focus on training the data like Python and R. It is also good to learn complex data processing and reporting tools like PowerBI.

Once your experience is coupled with good technical skills and preferably a degree, you can advance to supervisory positions or other positions like a data analyst.

Pros and cons of being a data entry professional

Pros:

• As a beginner, you can start with very few technical skills.
• There is a possibility of remote work.

Cons:

• The job can get a bit monotonous.
• As many companies offer remote data entry jobs, there is a high chance of getting scammed.

Software developer

And once you've learned some coding, you can apply for software developer jobs.

Software developers build applications and websites using languages and frameworks like C#, Java, and C++. They also fix bugs in production systems or during quality assurance testing.

Software developers work as part of a team, where requirements come from business teams and are evaluated by project planning teams. As this process involves managers as well, you can highlight your hard work to them.

Requirements

Some companies require an IT-related degree, but others accept applications without a formal degree.

In order to stand out when you don't have a tech-related degree, you'll need to work hard to showcase your skills by engaging with the development community through open source contributions, hackathons, and presenting a strong portfolio.

Potential career path

Once you have spent a while developing software you can transition into a senior role as a Software architect.

Software architects are responsible for designing efficient systems based on the requirements of the business.

Apart from working full time, you can also work on your own SAAS and monetize it to get an additional income stream.

Pros and cons of being a software developer

Pros:

• Software developers are offered good salary packages including attractive perks.
• You can work at your own pace as some companies offer flexible hours.
• As tools and technologies are always evolving, there is a lot of room to learn.

Cons:

• Depending on project deadlines, the job can be a stressful.
• Troubleshooting can be difficult sometimes specially in the case of unforeseen issues.
• You have to constantly keep up with the pace of continuously changing technology.

Tips for landing entry-level IT jobs

If you are looking to land a job in tech, the following tips can help you on the job hunt:

Work on your online presence

Recruiters regularly search online for potential candidates. It's useful to have accounts on LinkedIn, Twitter, and specially GitHub where you can showcase your skills and qualifications.

Another tip is to have a domain registered with your name where you can showcase your portfolio and also provide links to your social media.

In this way, it'll be really easy for recruiters to find you. Just be sure that your name and profile picture is consistent across platforms because you don't want to make it hard for recruiters to find you.

Accelerate your networking skills

Through networking, you can meet people with similar interests across the tech industry.

Networking enables you to highlight yourself within the community. IT professionals have some great options like hackathons, GitHub, discord chat servers, and other open-source communities where you can expand your network.

Use your personal connections

Getting a recommendation from a real person adds to the credibility of your job application. This is always better than applying to a company as a complete stranger.

Reach out to your family members or friends in the field who may be able to help you get an interview for an entry-level IT job.

Get suggestions from a recruiter

Professional recruiters have access to a vast network of opportunities. They could be really helpful in connecting you with the right hiring managers and land your dream job.

Consider volunteering

Volunteering experience such as contributing to open-source, mentoring, and writing helpful articles makes you more prominent in the tech industry.

It also adds some soft skills to your profile such as being self motivated, organised, and possessing a good work ethic.

The next steps

Once you have decided on a path for yourself, start working on the necessary skills. Create a compelling résumé and don't forget to include the details of your portfolio.

Search for jobs on sites like Indeed.com, Glassdoor, Crossover and Monster. Be sure to tailor your résumé to each job application.

In case you land an interview, thoroughly research the company and salary ranges. Be confident in your ideas and skills and don't sell yourself short. Good luck! :)

Wrapping up

I hope you found this tutorial informative.

What’s your favorite thing you learned from this tutorial? Let me know on Twitter!

You can also read my other posts here.

Banner image credits: Freepik.com

In this article, I will talk about the typical day of a junior developer and what to expect on the job.

The Onboarding Process

When you get started with a new company, you will go through what is considered the onboarding process. This is a term that refers to the process of getting introduced to the company.

You will first go through a period of filling out important paperwork for the company. This will include stuff like payroll information needed for the HR department.

You will also start to gain access to some of the company's project codebase, staff calendar, meetings, and staff chat room.

Before you get started with your first day, you will probably be receiving tons of emails. It is really important that you get your company email setup and check it periodically throughout the day to setup everything you need to.

In the first few days on the job, you will have a few meetings to get you introduced to your manager, your team, as well as an overview of the company and its expectations.

It is completely normal to be overwhelmed with the sheer volume of new information. Try to take notes during the meetings and ask questions.

Tips for Getting Set Up with the Project

You might be overwhelmed when you try to setup the codebase for the first time or you might not understand all of the code in it. It is important to remember that your company is not expecting to learn everything about the codebase during your first week.

They understand that it will take some time before you get used to where everything is and how things works. Take your time studying the codebase and ask questions about things you don't understand.

Also, if you have trouble getting set up with the project, make sure to reach out to a team member. If the setup process is not documented that well, this could be a good opportunity for you to update the documentation so future developers will have a smoother onboarding process.

What are Tickets and Project Boards?

Project boards are used so teams know the current status of a project and understand what work still needs to be completed. These boards will have what are called tickets which represent tasks in various stages of completion for the project.

This is an example of what a project board might look like. Here is an example from one of my personal projects.

Developers will assign themselves to a ticket listed on the board and read through the requirements.

Some of these tickets might be small bug fixes for an existing project. Or you might be asked to build out a new page or component for the site.

When you are finished working on the ticket, you will submit a PR (pull request) and ask for a code review. Once your code has been reviewed and approved, then it will be pushed into production.

If you have any clarifying questions about the ticket's requirements, just reach out to your project manager.

What are Code Reviews?

The code review process involves another developer looking over your code and submitting their comments for improvement. These code reviews will help catch small bugs, code inconsistencies, and improve code quality.

It is important not to take code reviews personally. Remember that your team is there to help you and offer constructive criticism.

As a junior developer on your first job, you might not be used to having other people looking at your code. You also might not be aware of the current best practices in building large scale production level apps.

Code reviews can be a great learning opportunity for you and help you become a more mature developer.

What is the Role of a Manager?

Engineering managers hold several responsibilities, including being involved with the planning, and coordination of projects as well as supervising engineering teams.

These are individuals that have years of software experience and have to balance project management with people management.

Here are are some core day to day activities for engineering managers:

• Being involved with daily standup meetings
• Meetings with other managers, clients, and stakeholders
• One-on-one meetings with engineers
• Might participate in some code reviews or coding

I believe that a good manager is someone who can effectively communicate with the team and is a good problem solver when issues arise. They are also responsible for providing feedback to their engineers on what they are doing well and areas of improvement.

What are Standup Meetings?

Standup meetings are when the entire team meets up and each member shares the work they did, the work that still needs to be done, and anything that is blocking them from moving forward.

It is really important that if you are stuck with something or blocked that you bring it up with the team. As a new member of the team, especially as a junior, make sure to ask for help if you can't proceed with the project.

Remember that your team is there to help you and you shouldn't feel ashamed to ask for help.

What to Expect from the Company's Group Chat

A lot of companies will have a designated chat server or group where teammates can connect with each other throughout the day. My company uses Slack and has a variety of channels for specific projects, software topics, and miscellaneous non-tech conversations.

I believe a healthy company culture will not expect you to be available for every single second on the group chat. It is ok if someone messages you and you don't respond back right away because you were busy with something else.

But it's typically not alright to go completely silent throughout the whole day where no one can get a hold of you. If you are working virtually as a junior developer, communication is really important.

It is up to you on how involved you want to be in the company chat. But I would suggest checking in once in a while throughout the day just so you remain up to date on what is going on with your team and the project.

Conclusion

Your first few weeks working as a junior can be overwhelming. It is important to remember that your company understands that you are still new to the industry and have a lot to learn.

Just try to take it one day at a time and learn as much as you can. Ask questions on what you don't understand and ask for help if you are stuck on an issue.

Make sure to try solving the issue on your own first by reading documentation and other articles before reaching out for help. Also do the best you can communicating exactly what the issue is with a lot of detail so others can best help you.

Try to learn from your co-workers because they have different levels of expertise and experience.

And most importantly, be easy on yourself. It will take awhile before you will get comfortable with the codebase and the workflow requirements.

I hope this article helped you understand what to expect working as a junior developer! Best of luck on your developer journey.

It's not a big secret that building a developer portfolio can greatly increase your chances of getting hired.

Everyone tells you that. But, they don't always tell you what makes a good one.

You see, many portfolios are generic and rather uninspiring. If your portfolio looks just like everyone else's, then how can you expect it to stand out?

Well, it won't stand out.

But don't worry – I've been there. My first portfolio was bland, uninspiring, and had many of the not-to-do's I talk about in this post.

However, I'm an ex-marketer, turned developer, I know how to make something stand out. I've made ad campaigns that have skyrocketed sales and had people talking. I realized I needed to think like a marketer to make my portfolio stand out.

The good news is that the same principles can be applied to your portfolio to level it up. If you read this guide and implement the tips, you'll raise your portfolio above the sea of other junior developers trying to stand out.

Before we launch into the five tips to level up your portfolio, let's just make sure we are on the same page.

What is a portfolio?

A portfolio is a way for you to showcase who you are, what skills you have, and most importantly the work you've done.

As a developer, your portfolio is going to be in the form of a website. The main goal of this website is to showcase yourself and your work in the best way possible.

It needs to make you stand out and it needs to make employers think "Whoa! I'd like to work with this person". Ultimately it will need to show them that you could be awesome to work with so they are compelled find out more about you.

A portfolio should therefore include some standard elements. Below are the bare minimum elements your portfolio must include.

The bare minimum of a portfolio

These are the non-negotiables of any developer portfolio:

1. Responsive design (learn about how to do that here)
2. Projects showcasing your work
3. An "about me" section or somewhere people reading your site can learn about you
4. Your portfolio needs to be accessible
5. Your portfolio should have a custom domain. Buy a domain name – you can get them for less than $10. Don't send people to 39238834.netfily.com
6. A way for people to contact you, preferably your email

If you have these six non-negotiables on your portfolio, you are off to a good start.

Now let's look at five ways you can level up your portfolio, starting with a non-obvious one.

Five things you can do to level up your developer portfolio

1. Know your target audience

One area that can help level up your portfolio is knowing exactly what the purpose of your portfolio is. That is, who is this portfolio for?

If I asked you what the purpose of your portfolio was, does the output match that? Let's say, for example, the purpose of your portfolio is to land your first junior developer role. Then your portfolio is going to look very different from someone who is looking to be a freelance web developer.

Therefore the first thing you need to do is ask what is the purpose of your portfolio. Start broad and then try to refine it. Keeping with the junior developer role example, you could refine it down to a junior frontend developer specializing in React.

If you are a junior frontend developer, then your portfolio won't need things like the generic skill cards below.

These cards are better suited for someone who is looking for freelance work.

When you know the purpose of your portfolio, you can better tailor the information to communicate why someone should help you achieve your purpose.

2. Level up your project details

This is the most important section of your portfolio, and it is the one section I often see that is not well-executed.

If you browse something like r/webdev and search "portfolio" let me tell you what you're going to see if you click 90% of those portfolios and look at projects. You're going to see a calculator app, a weather app, tic tac toe, a movie finder app, "insert big website" clone, and so on.

Now, don't get me wrong – these are useful projects for learning the skills they require. And people have spent time making them. The problem is that everyone builds the same stuff. You can often just follow along with a tutorial and create them without much thought.

There are two problems here.

The first is that you are not differentiating yourself. If I'm HR or the hiring manager why should I pick your calculator app over the other 30 in the inbox? Also, how can I trust that you built this thing yourself and that you didn't just copy/paste code from a tutorial?

The second is that most people just put the project in, link to the GitHub repo, and maybe a live demo. This doesn't tell the person who is potentially going to hire you a lot, and it doesn't give them much reason to employ you over everyone else who has done the same.

So then, how do you make your projects section stand out? Let's look at a few ways you could level up the projects section of your portfolio.

Add original projects

You don't have to reinvent the wheel or make the next great social media application. But it would be great if you tried to use a different API instead of the standard weather API.

You could for instance create a surf report app that is the same as a weather app but instead you are calling different endpoints. This shows me that you know how to call an API outside of a tutorial.

If you're not sure how to make your own original project then check out this guide on how to plan and build a programming project for beginners.

Give some details about the project

The first problem is that many projects are unoriginal. The second is that most people don't give more than the basic details about the project.

What will make you stand out is giving some details about your project. When I say details, what I mean is give me a story about the project. The best portfolios I see tell me about the project don't just show it to me.

Try answering some of these questions.

• Why did you choose to build this project?
• What challenged you when making this project?
• What did you learn from making this project?
• What learnings have you taken with you into other projects?
• What would you do differently next time?
• Did you get stuck at any point? How did you get unstuck?
• What was your process for completing this project? Did you do wireframes, make a Trello board, or did you just get stuck into it?

If you answer these questions and craft them into a few succinct paragraphs, I will now know a lot more about your abilities as a developer. I can see what interests you, how you overcome challenges, how you learn from those challenges, and what skill level you are.

You're already well on your way to standing out if you follow this tip.

3. Remove Unnecessary Fluff from Your Portfolio

Sometimes the best thing you can do to improve your portfolio is to remove things.

You should remove things that add no value to your target audience and things that reduce your credibility.

Here is a list of things you to remove and why.

1. Step-by-step tutorial projects. These projects hurt your credibility. They are unoriginal, they don't show me what you can do. Rather, they show me that you can copy what someone else does.
2. Projects not related to development or the job you are trying to land. These just aren't relevant to your target audience.
3. If one of your Projects is the portfolio itself. Why get rid of this? The reason is that they are on your portfolio now. They are interacting with the project. So save space for another project.
4. Skill progress bars. While they look cool, they are bad. If you're a junior you probably know 10% JavaScript, would you want to represent that? What the heck does 80% CSS mean? If you remove one thing, please make it these.
5. If your portfolio is a carbon copy of someone else's portfolio – start over. It's not cool for starters. Plus, I want to see what you're capable of doing, not what you're capable of copying. It can come back to hurt you in the long run.

4. Give your about me some personality

There is this song by Paul Kelly called "Every F$*#%) City" and the general idea of the song is that every city is the same. Well, I've seen a lot of portfolio's and a lot of them look the same.

The section that often comes off as the same is the about me section. Let's look at an example below.

"Hi, my name's Jonny Lucky, a Full-Stack Web Developer from Example Town. I love building websites that solve life's unique problems.

I work primarily with MongoDB, Express, React, Node, and GraphQL and have set up countless WordPress and Shopify websites. My previous career was as an IT Consultant, E-commerce Business Owner, and Digital Marketer. I also really enjoy tinkering with CSS.

In my spare time, I play video games and also work out."

Hello Jonny Lucky, or was it Lucy Lovely? I forgot because I'm the HR person and I've read 50 of these portfolios and they are all very similar.

If I were to change your name, town, and tech stack, many of these candidates would just become one.

To be fair, there are some personal touches like the that they "play video games and also workout". But, guess what? A lot of other applicants also enjoy these things.

Can you see the problem, if you have an about me section like the above? You won't stand out and you'll come across as a little stiff.

Your about me needs to be a little bit spicy, it needs to show your personality and experience. Because your personality is different from other people, so your about me section should be too.

Let's have a look at mine to give you an idea of what you should be shooting for. I've gotten a few compliments on it.

"I'm an ex-marketer who loves building things with code.

I first became enthralled with programming in 2015. I was in San Francisco with my brother in law and he was telling me about this thing called Python and how it could automate things. As a person who looks for efficiencies, I was hooked.

I jumped right into Python on my flight back to Australia. Soon, I was automating my own things. I made a bot to book classes at the gym, one to send weekly reports to my boss and I even made one to like my girlfriend's content on Instagram. Unfortunately, that is as far as it went. Shortly after, I got promoted. So, I had less time to learn and I let programming fall by the wayside.

But, then Covid hit and suddenly I had more time without my commute. So, I started learning again. Specifically, I learned web development, as I had things I wanted to build for myself.

After a few months of self-teaching, I knew this was what I wanted to do for my career. So, I signed up for the coder academy Bootcamp and put my heart and soul into it. I was coding every day, late into the night, and on weekends. Until I was ready to be unleashed on production code.

Since the boot camp, I have grown as a developer, working alongside senior developers who have helped me raise my standards for what's expected of any web application.

I'm now seeking a full-time role where I can contribute my skills both in coding and business to help a company achieve their goals."

As you can see my about me section is unique to me. I'd say there isn't another soul on the planet who could write the same about me section without telling some lies.

Now, your about me section doesn't have to be zany, it can be professional. But, and this is a key point...

You need to make it interesting so the person reading it wants to continue reading it.

To make your about me section interesting, you can try things like stories and anecdotes. Try and weave them in with the key points you want to get across.

Another way to think of it is, if you are invited in for an interview would your about me be interesting enough that the person interviewing you would say "hey, I loved that story about X on your portfolio"? If it can do that you're winning because you've opened up more dialogue.

In the end, you're trying to spark interest in the person looking at your portfolio.

Think about it like this. If HR has 50 applications to get through, they are only going to interview 5 of those people.

If your about me section is a bland generic version like the first one, they are likely to just skim through it and onto your next section. If nothing else on your portfolio stands out, then they'll move on to the next application until something does jump out at them. You want to grab their attention and make them shift you to the interview pile.

Since most portfolios are generic, it doesn't take much to stand out. If you have less experience than someone else but their portfolio is generic and yours isn't, I'd argue you are more likely to get picked for an interview.

Why? Because we like to work with people we like, and if you show that you're an interesting unique person, I'd probably like to at least find out more about you.

5. Throw some Sprinkles on it

One of the most important lessons I was taught early on in my coding Bootcamp was that you need the doughnut before the sprinkles.

Looking at this analogy in regards to your portfolio, the doughnut is all the other things I have listed above. You need the baseline requirements of a portfolio like solid projects, an interesting about me section, and responsive design.

The sprinkles should come after you have all the basics. So, if you followed the tips above you have the doughnut. Now, you can start to make your portfolio shine.

Add things that make a prospective employer go wow! You can add amazing animations like Christopher Cherupil, cool transition effects like Philippe Neveu, or dark mode like Jhey Tompkins.

I added a Zelda-themed modal to make sure a prospective employer grabbed my résumé before they left my old portfolio site. I just made sure I had the basics first.

You can also go wild with your ideas, just make sure you execute them. You don't want unpolished sprinkles that could take away from your doughnut's main elements.

Summary

If you read this post and thought, oh man my portfolio is quite generic – don't fret. You now have 5 things you can do to level up your portfolio so that it moves from the "forgotten" pile to the "give this person an interview" pile.

I can frequently be found in portfolio advice threads on Reddit and Twitter trying to offer advice to people trying to break into the industry.

When you're done leveling up your portfolio, and you're looking for some feedback on it, make sure to Tweet it to me with a link to your site.

If you have a portfolio you're proud of or you're looking for feedback on it, follow me on twitter and tweet the link to me so I can look over it and give you some feedback.

If you have an awesome one I might even add it to my portfolios that pop list.

In this article, I'm going to share with you what I've learned so far at my first programming job as a junior full-stack developer.

Ever since my developer career began in July, 2021 I've been learning constantly. And I'm gonna share some tips from my experiences so that you can learn as well.

At my company, I work on tasks end-to-end from the front-end to the back-end on a service that has a lot of users

Alright, here are the skills and tips I've taken away so far from this experience.

Technical Skills

I've learned a lot of technical skills (what some might call "hard skills") in my first few months on the job. Here are the highlights:

Architecture and Design Patterns

The first thing that opened my eyes was the architecture I get to work with at my job. When we are working on small projects we rarely think about the architecture – and that's okay, because we are at the beginning.

But there's a lot to learn about the most commonly used architectural patterns (like microservices, the MVC pattern, serverless architecture...the list goes on).

A really cool pattern that I've learned about recently is the repository pattern. This pattern will help to separate your application from your data.

So why is this helpful? Because it lets you easily change your database technology. Look at the example below to see how it works:

import {takeLatest, put, call, select} from 'redux-saga/effects';

import {authError, signIn, signOut, signUpSuccess} from '../actions';

import {
  signInWithEmailPasswordFirebase,
  signOutFirebase,
  signUpWithEmailPasswordFirebase,
} from '../repository';

import {
  AuthAction,
  AuthSignInInput,
  AuthSignUpInput,
  AuthTypes,
} from '../types';

import * as authSelectors from '../selectors/index';

export function* requestSignInEmailPasswordSaga(
  props: AuthAction<AuthSignInInput>,
): any {
  const email = props.payload.email;
  const password = props.payload.password;

  try {
    if (email && password) {
      const userCredentials = yield call(
        signInWithEmailPasswordFirebase,
        email,
        password,
      );

      yield put(signIn(userCredentials._user));
    }
  } catch (err: any) {
    yield put(authError('cannot sign In'));
  }
}

export function* requestSignOutSaga(): any {
  try {
    const isLogged = yield select(authSelectors.isLogged);

    if (isLogged) {
      yield call(signOutFirebase);
    }
    yield put(signOut());
  } catch {
    yield put(signOut());
  }
}

export function* requestSignUpEmailPasswordSaga(
  props: AuthAction<AuthSignUpInput>,
): any {
  const email = props.payload.email;
  const password = props.payload.password;

  try {
    if (email && password) {
      yield call(signUpWithEmailPasswordFirebase, email, password);
    }

    yield put(signUpSuccess());
  } catch (err) {
    yield put(authError('cannot sign Up'));
  }
}

export default [
  takeLatest(
    AuthTypes.REQUEST_SIGNIN_EMAIL_PASSWORD,
    requestSignInEmailPasswordSaga,
  ),
  takeLatest(AuthTypes.REQUEST_SIGNOUT, requestSignOutSaga),
  takeLatest(
    AuthTypes.REQUEST_SIGNUP_EMAIL_PASSWORD,
    requestSignUpEmailPasswordSaga,
  ),
];

In my sagas, I'm calling some services but I'm not doing this directly inside. I'm calling from the repository as you can see:

import {firebase} from '@react-native-firebase/auth';

export const signUpWithEmailPasswordFirebase = async (
  email: string,
  password: string,
) => {
  return firebase
    .auth()
    .createUserWithEmailAndPassword(email, password)
    .then(user => console.log(user + 'signed Up'))
    .catch(err => {
      throw new Error(err);
    });
};

export const signOutFirebase = () => {
  firebase.auth().signOut();
};

export const signInWithEmailPasswordFirebase = async (
  email: string,
  password: string,
) => {
  return firebase
    .auth()
    .signInWithEmailAndPassword(email, password)
    .then(user => user.user)
    .catch(err => {
      throw new Error(err);
    });
};

My repository is handling all contact with the Firebase service that pulls my users. If I decided that I wanted to change Firebase for any reason, I would only have to change this file and my sagas would be safe and sound.

If, on the other hand, I decided to use any Firebase service on another part of my code, I could just call the service from the repository without passing through other places. This separation of concerns is super helpful in the long run.

Here is the link to the whole project if you want to explore more:

And this article can help you to learn more about this pattern:

Global State Management

When I was working on my React projects, I didn't know about global state management and Flux architecture. But I've learned that it can be an important thing to know. You can read more about it in this introduction to Flux architecture.

Redux will help you implement this architecture, but many other libraries can help you deal with Flux architecture – like Mobx, for example. If you want to understand the general idea about Redux, read here! You can try to learn one of these libs and build a project on top of it.

An example would be the problem that Facebook had some years ago. This problem is better explained in the article below:

Clean Code

It's really important to deliver clean and readable code. So if you can do that then you're ahead.

There are a lot of repositories that show best practices for each language, so you can search yours and try to write your code like that.

Here's a simple but important example. Don't use this:

const a = "Leonardo"

What is a? The name of the author? The name of someone who lives in Brazil? you don't know because nobody besides the person that has created this variable will know what the context of this variable is. And after some time even the person who wrote it won't know either.

So do something like this instead:

const freeCodeCampColaborator = "Leonardo"

Now you know the context even if I don't write any comments. And it's far easier to search for something like this when you're in a big monorepo with over 1000 files, for instance.

You can see more examples of good practices and clean code in JavaScript in the following repo:

and check here for TypeScript:

How do you learn all these skills?

I learned these skills by building projects and asking for feedback from my co-workers. But I would suggest that, even if you don't have any co-workers, you should read some good tutorials and then try to build the projects in them.

Make sure to use the technologies that you're trying to learn. If you just read, and don't build, you won't grasp them fully.

I have a project with this approach if you need a more general idea of how to do it:

Non-Technical Skills

Be proactive

If you're working remotely, it's often hard to show that you're being proactive and productive. If you're working in your first developer job, like I am, asking for stuff to do might sound scary – but is very rewarding when you're able to pull it off.

Even if you can't get it done or don't understand the task, then ask for help. That's normal and super useful as well.

Here's a good example: let's say you have just finished a task and now you have to wait for a code review or something. In the meantime you can offer your help to others, talk to people other than developers to learn more about the business side, and document some environmental difficulties that you had on your first task so that others can learn by that as well.

Learn how to ask for help

One of the skills you'll learn as a developer is how to ask better questions. Before I was a programmer I studied mathematics, and doing my bachelor's thesis I learned how to ask good questions to my advisor.

Here's one of my main tips: try to narrow your question down.

If you go with a question like: "I don't know React Native, can you help me?" What can you expect as an answer? If you don't know anything start by googling it and finding some resources on the topic.

Then you can ask your colleagues who know the tech, "Hey, I'm trying to learn React Native and found these materials – do you have any suggestions? Are they good?"

As another example, let's say that you were given a task to center a div. After some time you weren't able to do it and you want to ask someone to help you. Don't ask like this:

"Hey I was trying to center this div and I wasn't able to do it – how does it work?"

Instead, ask like this:

"Hey to center this div I've tried this method and it didn't work because of this, and then I've tried this .... and so on, so... do you have a better approach?"

On the path to asking a good question, sometimes you will find your answer. Generic and abstract questions are not so good because they make you look like you're giving up and asking for help before even trying. If you tried and still don't know the answer, then go for it – ask for help. As you gain more experience, you'll get better at asking questions.

Stay organized

If you are not the Notion type, just take notes about what you do during your day. Create a system to remember meetings or silly things that you will probably forget if you leave them only to your memory.

If someone asks you to do something simple, like change a description of a task from this to this and you forget because you trusted this to your already busy mind, it won't look good for you.

So it's not only important to have an organized note system but to stick with it. This will show your team and your boss that you can get stuff done without someone watching you 24/7.

Thomas Frank's YouTube channel has lots of helpful tips for staying organized and getting things done.

Conclusion

When you're at your first developer job, you will learn a lot of stuff that is not only code-related – so be open to it. Learn to Google and ask for help!

That's it! I hope my experience helps you and happy coding :)

If you want to contact me, you can find me on LinkedIn.

LinkedIn is sort of a love-it-or-hate-it kind of platform.

Some people love it for the opportunities it provides and the ease with which it facilitates professional connections.

Other people hate it because it often seems like it has a veneer of genuine connection while the substance is mostly self-serving networking.

In reality, both of these extremes have a degree of truth to them.

LinkedIn is not a magical solution where you can create an account and instantly be discovered by hundreds of companies eager to throw money at you.

But it is also not the cesspool of recruiters and fake networkers sending out spammy connection requests all day.

Despite what you might think about the platform, the reality is that, when used correctly, LinkedIn provides an excellent opportunity for you to stand out, get noticed, and get hired, even if you don't have professional experience.

The key lies in the when used correctly part of that sentence.

So today we're going to go through some strategies that you can can use to leverage LinkedIn to get you that crucial first job.

We'll cover both profile setup and connection/networking strategies. These will help you increase your visibility to recruiters and employers searching for developers, and start to form relationships with people in the industry who can bring you valuable opportunities.

I love examples, so I'm going to walk you through this using an example as if I was a new React developer trying to get my first job.

You can follow along using your specific situation and goals.

How to Set Up your LinkedIn Profile

The main goal with setting up your profile in LinkedIn is to make it easier for the right people to find you, mainly recruiters and employers.

Recruiters are not the only people scouring LinkedIn for good candidates. Small agencies and other small companies that may not have the resources for a recruiter also use LinkedIn in order to find good talent.

We want to be visible to both groups of people here, so when they are searching for someone matching your skillset they find you.

Let's go through each component of a strong LinkedIn profile.

Use the Right Keywords

It all starts with the keywords. Your keywords are how you are going to structure the content of your profile. We'll include these keywords in relevant parts of your profile where it makes sense. But we'll make sure to maintain readability so you don't sound like a robot and still appeal to the humans actually looking at your profile.

Some keywords I might want to include might be React, GraphQL, and Node if I'm going for a full-stack JS developer position.

I like to go more specific and put the specific technologies I am learning and want to work with, rather than going too broad, like JavaScript.

At the same time, there's a balance here. You can also go too narrow and put things that not a lot of people are going to be searching for.

An example of something too narrow might be Next, Firebase, and Tailwind. Those are very specific technologies and the likelihood of someone searching specifically for those is less than React.

But, somebody who knows React and can demonstrate some basic proficiency in a few different stacks based in React will be appealing to someone even if the specific stack they are using differs from your specific stack.

The main thing we want to communicate here is that you have knowledge using certain technologies you want to work in while communicating the fact that you are capable of learning others.

For this example I'm going to go with React, GraphQL, and Node as my keywords.

Compose Your Intro

The intro portion of your profile is comprised of your photo, headline, banner image, name, location, and your URL.

It forms the first impression people will get of you and your profile, so it's important to get it right. Let's go through each component of the intro section one at a time.

First, the big three.

These first three components are what will show up anytime you interact with anyone on LinkedIn or show up in someone's feed.

They are the only parts that people will see even if they don't click through to your profile, so make them count.

Your Name

Pretty self-explanatory. Use your real first and last name. Nicknames are fine, as long as that is what you would go by if you were to get hired somewhere.

Keep it consistent across all your profiles and your website if possible, as this strengthens the branding aspect of your online presence.

Example: My name is Kenneth Rogers but my LinkedIn says Ken Rogers because that is usually what I go by, and that's what I go by on all my social media profiles.

Profile Photo

Your profile photo is an important part of your profile.

There's some disagreement about whether or not you should have a photo of yourself in your social media profiles.

Some people think it can cause unnecessary unconscious bias in people who look at your profile.

While this may be true, let's look at the alternative.

Whether we like it or not, having an empty spot where you profile photo gives the look of incompleteness.

So the unconscious bias is unavoidable. It's part of the process, whether we like it or not.

I think having a high-quality photo is a much better decision that leaving it empty or using something that is not actually you.

For the photo, the basics apply.

Clear, high-quality headshot, preferably smiling, with a neutral background that is not distracting.

If you are able to do so, hire a professional, but I realize not everyone can do that.

Luckily smartphones have amazing capabilities these days. By asking a friend who knows what they are doing or by learning a bit about phone photography yourself, you can take a great picture that gives a good first impression.

Make it so that if someone met you in person after looking at your profile, they would easily recognize you. No pets or family, just a clear headshot of you.

Headline

The headline is one of the most important pieces of your LinkedIn profile.

Even though it's short, it has a high impact on your search visibility and on whether or not somebody will click through to learn more about you.

So what makes a good headline? It needs to appeal to both human readers and the LinkedIn search engine at the same time.

That means it needs to be clear and concise in communicating exactly what it is you do (or want to do).

One thing I do not recommend doing is putting words like "Junior", "Aspiring", or "Student", in your profile.

If you currently create things using code, you are currently a developer, you just may not have an official job title.

Get rid of any language that says you are not currently a developer. It's not about lying, we're not going to fake any experience you don't actually have.

It's about having confidence in your abilities and yourself to call yourself what you are, a developer: someone who creates things with code.

Your headline should include your specialty (what you want to work in) and your unique value proposition (what you specifically bring to the table).

The first part is pretty self-explanatory, but how can you have a unique value proposition as a brand new developer?

This can be as simple as what you want your specialty to be or unique things you have accomplished with past projects.

Do you have an interest in accessibility and did you build a project that incorporates accessibility? That's a recipe for a compelling headline that helps you stand out.

Something like, "React developer building highly-accessible web applications."

We've got one of our keywords in there, potentially two if you identified accessibility as a keyword, and it clearly communicates the value you bring to the table for companies.

For my profile, I'll go with "Building excellent user experiences in React and GraphQL".

I want to be a React developer and I have a passion for crafting excellent user experiences.

For you, this might be clean code, well-tested code, and so on.

Choose something that you uniquely focus on that adds value to organizations.

This doesn't have to be technical, either. If you come from a background that utilized other soft skills that are relevant to development, integrate that in there.

Let's say you used to work in customer service, so communication is one of your strong skills.

You might make your headline "Building React applications that effectively solve client problems" because your communication skills allow you to ensure that you are clear on the client needs and the tools you build accomplish that task well.

Something to decide here is which part of your headline you want at the beginning. Only the first 65 to 80 characters will be shown in search results and content feeds depending on if you are on mobile or desktop.

So you need to decide which aspect of your work is more important and put that first.

Banner Image

Customizing your banner image is another one of those little details that communicates that you took the time to customize your profile and really care about how it looks.

There are two options for your banner image.

If you can find a stock photo or a photo you took that communicates something about you, you can use that.

For example, I live in Colorado and love the mountains, so I might choose a mountain photo.

It does not necessarily have to communicate something professional about you, but it shouldn't be generic.

For example, don't use a picture of a computer with code on it, since that doesn't do anything to differentiate you from other new developers.

The other option is to create your own banner image that communicates your career goals.

Lots of consultants do this, and I have something similar on mine.

You can do this using Canva or hire someone on Fiverr.

Some things you could put on the banner:

• Icons of the tech you work with
• Another picture of you with an overlay and some text describing what you can bring to the table

Here are a few examples of this:

Here Justin highlights his primary professional driver and lists his website.

This is a great example if you have a specific mission that drives you to code.

As you can see, the banner image doesn't have to be fancy or complicated, simpler is usually better.

Here's what mine looks like:

Personally, I would go with this second style of banner, where you have some text describing what you do, over the first. It gives more clarity on you as a person.

Although if you are having trouble coming up with something like this, a beautiful picture that still communicates something about you is better than the default.

URL

Customizing your URL is one of those little details that takes 10 seconds but adds that little bit of polish to your profile.

Change your URL to some form of your first and last name. You can also add in initials and other forms of your name if necessary.

For example, I usually go by Ken Rogers or Kenny Rogers, but those were both taken so my URL is https://linkedin.com/in/kennetharogers, which uses both my full first name and my middle initial.

Summary

Opinions vary on the best length for a summary, but I am personally inclined to recommend shorter summaries.

One thing I've noticed is that people feel like they need to include their entire life story in their summary or in places like their portfolio site about page.

Think about your online profiles like online writing.

In writing, the only goal of the headline or introduction is to get the reader to read the next line.

Your goal with your LinkedIn headline and summary is not to get hired, it's to get the person viewing your profile interested enough to just take the next step. That might be sending you a DM on LinkedIn, sending you an email, or visiting your portfolio site.

This job hunt process should be viewed in this step-by-step manner. It helps keep you focused on what each component is best used for and avoids overwhelming people with too much information too soon.

So how can we apply that to your summary?

You want to hook the reader in on the first two lines of the summary, since LinkedIn requires you to hit the "Show More" button in order to view beyond that.

To make this a bit easier to write, I like to use the following structure:

• Hook
• Mission
• Expertise
• Proof
• CTA

In the hook, you want to use something unique and interesting about you and open up a loop that can only be closed by reading further. This is how you'll get the reader to read your entire summary.

I like to integrate something from my background and why I got into coding here. You can also hint at something that happened to you during that process that gets explained later in the summary.

So if I was doing this for my example, I might write something like this:

"It was many late nights spent coding after driving a forklift all day before I built my first web app. But when I did, I learned something unexpected about myself."

This captures the reader's attention by showing that I am motivated to learn and dedicated to doing so, briefly mentions I've built something from start to finish, and hints that I learned something, which we'll continue explaining in the mission section.

"I learned why I truly love to code. That particular app was built to solve a small problem I had in my life, consistent journaling, and by completing it I realized the immense satisfaction I get from building something real, that makes someone's life easier, using nothing but code and my own effort."

Now we're starting to get into why I actually code. This is more important than people realize. Hiring, as much as some companies try to make it, is not an automated, robotic process.

It's people who will be looking at your profile, reaching out to you, and hiring you. You need to connect on a personal level in order to catch someone's attention.

Now let's dive into our expertise by moving into talking about how we actually accomplish the "what" and "why" listed above.

This is another spot you'll want to use those keywords you chose earlier. In this example, I chose React, GraphQL, and Node. With that in mind, here's how I might write this section of my summary.

"I'm obsessed with solving complex problems using React, GraphQL, and Node by building web applications with an emphasis and accessibility and usability."

Anyone can say these things, you also need to back it up with proof. That means you need to have a built a complete project or two using the exact tools and concepts you discuss in this section.

We'll go into that in just a second, first let's round out this section with a clear CTA so readers know what we are looking for.

"I'm currently looking to contribute my skills to a team where I can prove my skills while growing in my capabilities. If you are looking for a competent, highly-motivated developer, let's chat. You can reach me at email@example.com or by DMing me here on LinkedIn."

This gives people a clear action to take and shows them exactly what you are looking for.

Now, on to that proof we were talking about.

Rather than just listing it out here, I like to include links that link to a project or two, and maybe a piece of writing that showcases the attributes you've written about here.

You can utilize the "Featured" section for that.

Featured

The featured section is simple but very powerful.

What I recommend doing here is linking to a project or two that lines up with the skills and attributes you listed in your summary, and maybe a piece of writing or two that does the same.

For the projects, don't just link to a live version of the project or a GitHub page. You should have a dedicated page on your portfolio site that walks readers through how and why you built the project.

Building a portfolio site is outside the scope of this guide, but I highly recommend reading Josh Comeau's book on building great portfolio sites.

Experience

What can you put in the experience section when you don't have any experience?

There is almost always relevant experience that can be used even if your other jobs were in another field.

Learning how to communicate they ways in which your soft skills learned in other fields are relevant to web development is going to be critical here.

What I recommend doing is looking at this list of skills that virtually every employer values. Then see which of those you had to utilize in your previous jobs and how that translates to being a good developer.

Be sure to list any specific accomplishments and awards you received as well as concrete examples of demonstrating those skills.

For example, I used to be a server and drove a forklift before I became a developer.

A couple of skills from that list that I had to use quite often were communication and adaptability.

So let's see how I could integrate that into my experience.

I might write something like this in my server experience section:

"Simultaneously served multiple tables while ensuring their orders were correct and guests were satisfied. Adapted to changing demands by performing multiple duties such as hosting and bussing as restaurant traffic increased and decreased throughout multiple shifts."

This is a simple example, but it communicates that I am able to handle multiple responsibilities while maintaining good communication and customer service, and that I am adaptable and willing to help out the team even if it means doing a job that is not necessarily my primary function.

One mistake I see a lot of people make is just stating that they have certain skills instead of showing it with examples. This is one way to do that.

If you have done any freelance work, you can also put that here as relevant work experience if you did it under a company name, or even your own name.

Make sure to focus on results delivered to clients or employers. If you can, list specific things you accomplished and how that contributed value to the organization or person you worked for.

Education

If you have formal education or a bootcamp under your belt, you can put that here.

Besides that, put any course work you've completed here. Things like Udemy courses or freeCodeCamp curriculum certificates should be included here as well. Any structured training program or course you've taken should be included in the Education section.

Skills

For your skills, I recommend choosing the top three based on the keywords you've chosen. These top three are the most crucial and will be used to filter your profile.

As for the rest, my preferred rule of thumb is to include any skills you have used to build a complete project.

Don't list every piece of tech you've ever touched here, as that is a subtle hint to employers and recruiters that you are desperate to get whatever job you can. And it's virtually impossible for someone to be proficient in that many things.

Recommendations

If you can get them, recommendations are great. Try to get recommendations from people you have worked for in the past.

These aren't required as getting them depends on external factors, but get one or two if you are able to.

How to Amplify Your Reach on LinkedIn

You've got your profile nailed down, now it's time to get it in front of people.

The other half of LinkedIn is using it properly in order to meet the right kind of people and get on their radar as someone who will be a valuable addition to their organization.

You have the foundation in place in your properly created profile, now you need to get it in front of as many eyes as possible.

You've optimized your profile to take advantage of LinkedIn's search functionality, but you don't only want to be passive in this process.

You also want to be active in getting in front of the right eyes.

This isn't going to be some awkward process. We'll mostly just be connecting with people and posting content.

You won't have to send any DMs or try to sell yourself on LinkedIn.

This is a two-part process:

1. Connecting with people
2. Writing compelling content

How to Connect with People on LinkedIn

Let's talk about connecting with people first.

You want to be intentional about the people you are connecting with. The best way to do that is to connect vertically.

Most people focus a good chunk of their networking on horizontal connections. This means that they connect with people at the same level as they are.

There's nothing wrong with this, and I'm not saying you shouldn't do that. But your effort is better spent on people who are either in a position you want to be in, or are in a position that hires people like you.

So a good place to start is to start looking up companies you admire and would want to work for, and start connecting with employees at that company, people that currently do what you want to do, and people in charge of hiring at that company.

As you do this, LinkedIn will start to suggest relevant people to connect with, making this process a lot easier and faster.

I have conflicting feelings on connection request messages. On one hand, I understand the value of customized messages, but on the other, I actually tend to see better acceptance rates with the default message. So I don't write custom messages anymore.

This is something you'll want to experiment with for yourself.

Try both and see what works better for you. For your custom messages, keep it simple and say you are a new developer looking to connect with other people in the industry.

That's it. You don't need to send a personal DM or try to form a friendship with them now. You're just trying to grow your network and increase your visibility. The long-term connection is going to come in the form of creating valuable, interesting content.

How to Write Good Content and Share it on LinkedIn

So how do you write engaging content on LinkedIn that makes people want to learn more about you?

My favorite method is to be working on a project, and write about what I'm learning during your process But – and this is an important distinction – write about it from the perspective of a teacher/authority.

What I mean by this is that instead of writing "I learned this today" write "Here's how to do this."

And LinkedIn is better for high-level, conceptual types of content rather than overly technical types.

So write about the high-level lessons you are learning, rather than the technical things themselves.

So let's say I was working on a project using Gatsby and after a bit of struggle, I figured out how to turn it into a PWA without following a tutorial, just the docs.

I might write a post along these lines:

"Today I managed to accomplish turning my Gatsby site into a Progressive Web App without following a tutorial.

Tutorials and courses are great, but the real learning occurs when we struggle through implementing a solution on our own, dealing with the inevitable bugs and setbacks along the way.

Whenever you're slogging through a problem and struggling to come up with a solution, know that struggle is your brain adapting to a new situation and learning.

This is where real growth happens."

You want your content to communicate the fact that you are learning every time you build something, and that you are constantly on a journey of discovering the best ways to be a developer, and share those insights with others.

This gives people a great insight into how your mind works and what kind of a developer you will be.

By consistently creating content like this and getting it in front of the intentional connections you've been making, you can start to build a profile for yourself that will help you stand out among other new developers.

Slowly, you'll start to have people reaching out to you who are interested in hiring you. And then when you start to see job openings show up for these companies, you will already be on their radar as someone who is competent.

The key to coming up with great content is to learn to see inspiration everywhere. As you are browsing Twitter, working on projects, reading articles, listening to podcasts, and so on, start writing down content inspiration and ideas you have.

Then, set aside some time every week to write your content for the week and try to post a new piece of content every day.

Wrapping Up

By following these steps you will drastically increase your chances of being found on LinkedIn and building new relationships with people in the industry.

It's not a magic bullet, but it is one piece of a strong job-hunting strategy and an important piece of the puzzle when hunting for that first job, which can be very challenging.

For the rest of the roadmap, Lever.so can help. It's a step-by-step course and mentoring community designed to help new developers land their first jobs, regardless of experience or education.

To build mastery in software development, you should build projects.

Not one.

Not two.

Lots of projects!

But you have to start right. If you jump into any random project as a beginner or junior developer, you'll not only feel lost, you'll begin to doubt if programming is for you. So work smart.

Start small.

First, build your confidence from one tiny project. Then another tiny project. After multiple small projects, move on to something bigger, and go as big as your imagination allows.

Before you build any project, learn the basics

If you don't learn the basics, you'll build on a shaky foundation.

No matter the level of mastery you hope to get to in Python, you'll need these fundamentals in place before you jump into any project.

You need to know how to:

• declare variables
• collect user input
• store information
• repeat an action through loops
• write functions to repeat blocks of code

That's it.

Of course there's more to learn in Python, but these are standard things you need to know and they'll be good enough for you to jump into beginner projects.

There's that tempting feeling that you need to finish lots of Python tutorials before you work on any project.

Don't do it.

Many fall into the trap of learning back to back Python tutorials waiting to feel super ready. Instead, learn the basics first. Next, build some tiny projects. Then return to learning with more tutorials.

Trust me, you can finish 100 Python tutorials and still feel you're not ready to build any projects.

Studying alone is not enough.

You need to build.

How to use these projects

• First, read through the instructions and make sure you understand what you've read. Try to say what you read in your own words.
• Attempt to solve it on your own without going through the YouTube tutorial or example code on Github. You'll most likely struggle. That's fine. Push yourself. This is the idea of deliberate practice from Behavioral Psychology.
• If you haven't made any progress at all, watch the YouTube tutorial where available then look through the example code. You can also search online to see more example tutorials and Python code for the same problem.
• After going through, go back and try to write the code by yourself without looking at the tutorial. Again, push yourself. This is grit also from Behavioral Psychology. You need it.
• Whatever you do, do not blindly copy out the code in the tutorial, then pat yourself on the back. You may finish quickly but the reality is you haven't learned anything.
• If you feel you're completely stuck after lots of attempts, take a break. When you step away, we know from Neuroscience research that your subconscious will continue the learning. This is because your mind has shifted from focused mode to diffused mode.
• Whenever you solve something, celebrate it! You need the positive reinforcement to build internal references that you did it. In the future when your mind whispers “you can't do it” during a moment of doubt, you'll reply “that's not true, here's proof of what I did in the past so I can do this too”.
• Repeat, repeat, repeat.

You can also use this breakdown for any project beyond the ones listed below. Let's get to the Python projects.

Projects for junior Python developers

Here are some beginner-friendly projects for you to work on:

1. Odd or even
2. Mad Libs Game
3. Word Count
4. Biography info
5. What's my acronym?
6. Rock, Paper, Scissors
7. Guess the number
8. Is a palindrome
9. Calculate the tip
10. Email slicer
11. Lyrics generator

Odd or even

Welcome a user then ask them for a number between 1 and 1000.

When the user gives you the number, you check if it's odd or even and then you print a message letting them know.

Example:

• Prompt: What number are you thinking?
• Input: 25
• Output: That's an odd number! Have another?

Mad libs game

Ask the user for an input.

This could be anything such as a name, an adjective, a pronoun or even an action. Once you get the input, you can rearrange it to build up your own story.

• Here's a youtube tutorial on mad libs in Python.
• And example code on Github.

Word count

Ask the user what's on their mind. Then after the user responds, count the number of words in the sentence and print that as an output.

Example:

• Prompt: what's on your mind today?
• Input: well, it's just a day for me to be an expert in coding
• Output: oh nice, you just told me what's on your mind in 13 words!

To take this a step further, open a file that is handed to you, count the number of words in there, then print it out.

Here's some example code on Github.

Biography info

Ask a user for their personal information one question at a time. Then check that the information they entered is valid. Finally, print a summary of all the information they entered back to them.

Example: What is your name? If the user enters * you prompt them that the input is wrong, and ask them to enter a valid name.

At the end you print a summary that looks like this:

- Name: John Doe
- Date of birth: Jan 1, 1954
- Address: 24 fifth Ave, NY
- Personal goals: To be the best programmer there ever was.

What's my acronym?

Ask the user to enter the full meaning of an organization or concept and you'll provide the acronym to the user. For example:

• Input -> As Soon As Possible. Output -> ASAP.
• Input -> World Health Organization. Output -> WHO.
• Input -> Absent Without Leave. Output -> AWOL.

Rock, Paper, Scissors

This is a popular game played between two people. Each player gets to form one of three shapes using their hand:

• rock (a closed fist)
• paper (a flat hand)
• scissors (a fist with the index finger and middle finger extended, forming a V)

Here's a youtube tutorial on coding up rock-paper-scissors in Python.

Guess the number

You ask a user to guess a number between 1 and 50.

If they guess outside that range, you prompt with an error encouraging them to choose a number within the proper range.

Whenever they guess the wrong number you ask if they want to keep playing or if they'd like to quit.

Finally, when the user eventually guesses the right number you congratulate them and show the number of attempts they had.

Here's a youtube tutorial on coding up a number guessing game in Python.

Is a palindrome

Ask the user to give you five words. Then check if any of the five words is a palindrome.

A palindrome is a word that remains the same whether it's read forward or backward.

Example:

• madam is a palindrome.
• so is malayalam.
• But not geeks.

Here's some example code from Github.

Calculate the tip

Your goal is to find out exactly how much tip you should give after receiving a service. In this scenario, ask for the total bill. Then display the tip for 18%, 20% and 25%.

Example:

• Prompt: what's the total bill for today, please?
• Input: $55.87
• Output: 18% tip is $10.06, which brings your total to $65.93

Remember you want to be nice, so don't forget to round up. To push this more, ask for the number of people involved, then evenly split the tip and total cost among them.

To go even a step further, split unevenly (for example, one person pays 70% of the bill while the other pays 30%)

Email slicer

Collect an email address from the user and then find out if the user has a custom domain name or a popular domain name. For example:

• Input: mary.jane@gmail.com
• Output: Hey Mary, I see your email is registered with Google. That's cool!.
• Input: peter.pan@myfantasy.com
• Output: Hey Peter, looks like you've got your own custom setup at MyFantasy. Impressive!.

This is a convenient python project that has a lot of use in the future. The program helps get you the username and domain name from an email address.

If you want to push this further, you can customize the application and send a message to the host with this information.

Here's a Youtube tutorial and example code from Github.

Lyrics generator

Ask a user to choose from a list of 10 songs. When the user does, you print out the lyrics to the song they selected.

Example:

Welcome, please select a select a song from this top 10 songs:

1. Baby by Bieber
2. Hotline Bling by Drake
3. Flawless by Beyonce
4. Fall by Eminem...

You chose Flawless by Beyonce. Here you go:

------- Flawless by Beyonce ------------
I'm out that H, town coming coming down
I'm coming down, drippin' candy on the ground
H, Town, Town, I'm coming down, coming down
Drippin' candy on the ground...

Press * to choose again.

To push it further, have at least 3 songs by the same artist.

Next, ask the user to put the name of the artist so you can show them only options by that artist. Then the user can select a specific song from that list.

Closing out

Working on these projects, you might hit a road block and get completely discouraged. It's okay. You'll get through.

Remember, take a break then come back to it later. You can also read these stories of developers from all kinds of backgrounds who made it to motivate yourself to keep going.

Software development is a challenging field. But with lots of rewards.

If so many others have done, you too can do it.

Thanks for reading

If you enjoyed this, there's more.

• Join my email community: I share techniques for new coders and junior developers to grow faster and double their confidence. If you're interested, join the community.
• Follow me on Twitter: Want more rapid-fire tips? Or have a question? I'm most active on Twitter so feel free to reach out to me. My DM is open.

Heads Up - I love research so I tend to back my advice and approach with concepts from Behavioral Psychology and Neuroscience.

There is an endless stream of new challenges to tackle in technology.

The frameworks you know will change. The tools you feel so comfortable using will evolve. Technologies will go in and out of style. You might want to switch to a different area in tech when your interest wanes in another.

Working in engineering means you’re always learning something new to keep your skills fresh.

While Angular was popular five years ago and most frontend jobs wanted Angular skills, now the market has changed. React has overtaken all other frontend frameworks as the hot new technology.

While Rails was popular five years ago, now Node and Python are dominating job descriptions.

Keeping your skills fresh is one of the key parts to being a standout engineer and building a lasting career.

However, this might seem challenging when you start out in your career. I remember looking at everything I had to learn and feeling so frustrated when people would discuss some new technology that I didn’t know.

And as soon as I felt competent in one framework, another one would become popular. I felt like I would never catch up.

But this is also one of the best parts of being an engineer – you will never be bored. And this is a tool you can use to set yourself apart from the competition.

Learning how to learn like a developer is nothing like how you’ve learned in school. There will be some reading, and some courses. But the majority of time will be spent building.

How to Learn by Doing

When you were a child, you learned by doing.

You started speaking even if it wasn’t in full sentences. You started drawing by doing. You didn’t read about it as an infant. You weren’t reading the ‘Baby’s Guide to Fingerpainting 101.”

You started walking by practicing. And this helped you to grasp new concepts quickly. You were always doing.

Generally, in engineering, concepts will start to stick if you focus on building rather than memorization.

When I started out as an engineer, I would read books constantly and make flashcards. I can’t tell you how much time I spent making flashcards. I thought buying a new book or online course would teach me how to code and make me a superstar engineer. But that never happened.

Looking back now, I’m not sure what I thought those flashcards would do.

After months of trying to memorize syntax and definitions, I was right where I had started. It wasn’t until I started building that my skills started accelerating.

While I loved reading engineering books and still do, the majority of my time is spent skimming the book and then trying out a new concept right away.

This is a more painful way to learn. I won’t lie to you – it’s scary. But nothing helps build new programming skills quite like building something out yourself. The fastest way to learn to code will be by building.

But how can you do this?

Escape Tutorial Hell

When I was learning how to code, I spent months following tutorials. I would watch the tutorial and follow along step by step. Never attempting to do anything on my own.

If a tutorial got too difficult, I would switch to another one. I would spend hours every day watching tutorials.

I tried to use the learning skills I had from college and apply them to coding. And it didn’t work. Learning how to code is about active learning. Not passive.

But it was so easy following tutorials. I never felt stupid or felt any imposter syndrome. I would feel like I had accomplished something at the end of the day.

Meanwhile, I was absentmindedly following along with the video and not learning a single thing. I wasn’t pushing myself. If you want to learn new skills fast, you have to push yourself.

After around six months of sticking around in tutorial hell enjoying the warm weather, I realized I had learned next to nothing. I had no skills. I had prioritized flashcards and passively watching tutorials over actually building anything.

Meanwhile, friends that had started working on projects right away were whizzing right by me at a pace I thought was incredible.

I felt so frustrated. I couldn’t even create a basic application. If it wasn’t in a tutorial with step by step guides, I couldn’t do it. It wasn’t until I started focusing on building something small on my own that coding finally clicked for me.

Step away from the tutorials as soon as you feel comfortable. Tutorials are great when you’re starting out. But at a certain point, they only slow down your learning if you rely on them too much.

This applies in every step of your career. If you’re a junior engineer, pick a small project. Don’t use a tutorial. Try to figure out how to build it on your own. Don’t feel bad if you can’t build an entire application yet - that’s fine! Start with small projects and build up.

And if you’re an engineer and have a few years of experience and want to switch to machine learning from backend engineering, for instance, pick a small project and start coding.

Always Be Learning

Another skill a standout developer must have is to become an endless learner.

When you first start learning how to code, the amount of material you learn every day seems astronomical. You’re picking up new concepts constantly. It seems like there’s an endless stream of information to learn.

Ideally, you’ll always be learning something new no matter how long you’ve been an engineer. But this can sometimes level off.

You begin to feel comfortable in a job and the nagging feeling that your skills have started to stagnate starts to set in. Boredom quickly follows.

Keeping your skills sharp will keep your employment status stable even in tough economic times.

Here are a few ways you can always be learning.

• Write code. A lot of it.
• Find developers who are better than you and work with them.
• Ask to switch teams at your job if you feel you’ve stagnated.
• Contribute to open source projects.
• Attend meetups and conferences.
• Subscribe to newsletters.
• Start connecting with developers on Twitter.
• Read constantly.
• Build side projects.
• Pursue new certifications.
• Take online courses.
• Take some time off. You can’t take your PTO to the grave.
• Read blog posts.
• Find a mentor.
• Share your knowledge.
• Write blog posts.

Some of these things you can’t do in your spare time. And that’s OK. We all have personal lives. Focus on finding ways you can be learning during your work hours like switching teams, finding a mentor or becoming a mentor, and so on.

Being a standout engineer doesn’t mean you need to spend all your spare time coding. Coding is still a job. It is your 9-5. But you can choose to be a builder at your job.

When you’re working on a new skill, step away from the book and course. Try to pick up tasks at work that use the new skills you want to acquire right away. This will enable you to build skills quickly and efficiently at work.

Get Comfortable Being Uncomfortable

While learning new skills, you also need to push yourself. You need to get comfortable being uncomfortable.

Before I became an engineer, going through tutorials felt easy and welcoming. I rarely felt overwhelmed. I would use Codecademy and other similar platforms and think I was making progress. But I wasn’t.

After over 6 months of tutorials, I wasn’t much further along in my coding journey than when I had started. I was still a beginner.

When I started working as a junior software engineer, I was in a constant state of fear. I felt like I could never get enough work done. It was a terrifying feeling. Yet I suddenly learned faster than I ever had in my life. My brain felt like a sponge.

Find opportunities for growth. If you continue to do the same thing and feel comfortable, you’ll never find the opportunities for growth. If you take on the same tasks at work and continuously work on the same things, you won’t be pushing yourself and growing.

Always be biting off more than you can chew. If you spend all your time taking tutorials, it will begin to feel routine and it won’t be a challenge anymore. And you won’t be learning.

However if you choose to push yourself, you’ll learn faster. You’ll be uncomfortable which means you’ll be growing.

Much as if you were practicing piano, if you kept practicing the same piece over and over again because you were confident with it, you wouldn’t be improving your skills by learning more challenging pieces.

The same principle applies to most things in life.

When I was trying to get my first dev job, I had to decide between a position at Apple and an apprenticeship at a small startup.

The role at Apple was going to pay more and I knew other people who worked there so I would have built-in friends and a support system. However, it was half QA and half engineering, with the opportunity to move to full time engineering if things went well.

The startup job was unstable at best. Nothing was guaranteed. They didn’t have another engineer who identified as a woman at the company. I would be the only woman in the entire engineering team.

Not to mention – this wasn’t a job offer! It was an offer for a three month apprenticeship with no guarantee that I would have a job after. I would have to move to the city, sign a lease, and hope that I could somehow afford the rent if I failed the apprenticeship.

And this was back when coding bootcamps were at the largest point of the bubble. Students were graduating in San Francisco and the market was more saturated than ever before. Job postings frequently included “No bootcamp grads” which was highly discouraging.

I knew if I started at Apple, it would be good for my resume. I’d be making more money as well. But I couldn’t stop thinking about growth and mentorship opportunities that the startup offered me.

Sadly, I had no idea what to do. I had been sold the idea of a high paying dev job during my coding bootcamp. Not a low paying apprenticeship that might not even lead to a job.

I ended up accepting the three month apprenticeship. Most of my friends thought I had lost it. My own family thought I had lost it.

I suddenly had three months to prove myself at the apprenticeship. I quickly lost count of how many weekends and late nights I worked. I was terrified.

The pace was fast and I was blown away by how little I knew. I felt so nervous some days that I wanted to call in sick. I would fantasize about my train getting delayed underground so I would be forced to miss work. Every standup felt like torture because I felt I wasn’t doing enough.

Meanwhile, friends that attended the same bootcamp as I had were discussing their cushy entry level jobs at Apple and how they got to leave at a reasonable hour every day. Not to mention, they were paid so much more!

After the first two months my manager asked to have a meeting about the apprenticeship. I was convinced they were going to fire me.

Instead they told me that they were ending the apprenticeship program a month early and they were going to offer me a full-time software engineering position at the company. I can’t describe how happy I was that day.

I continued throwing myself into my work. I would volunteer for tasks that I didn’t feel ready to complete. If I didn’t know how to do something, I would say I could do it anyway. A year and a half after that, I was a senior software engineer at the same startup.

Would it have been easier if I accepted the position at Apple? Absolutely. But the engineers I knew that accepted the Apple position never had a mentor like I did to push them and challenge them to improve their skills.

In the long term, they ended up spending more time recovering from the lost learning early on. Some are still stuck with the same entry level title years later.

Depending on your goals, that might be fine for you. And that’s okay. But I wanted to become a standout developer with an exceptional career. And I’m guessing if you’re reading this, so do you.

Was it risky to accept the startup job? Absolutely. Most people thought it wasn’t a good move. But I chose to be uncomfortable and it paid off. Did it feel comfortable? Absolutely not. I probably aged five years in that role.

Choose discomfort. The biggest most rewarding success in life happens after hard work. Put down the tutorial and pick up a task you don’t know how to solve.

Deep Work

Coding is a job that requires deep concentration. Switching context to check your phone or social media platforms will be detrimental to the amount of work you can get done in a given day.

Most people will work for a few minutes and then check their phone. If the average employee spends 8 hours working each day, and spends two hours or more being unproductive, you can quickly become known as an engineer who gets things done by simply spending your work hours actually working.

By building a habit of focus and deep work, you’ll become an engineer that stands out from the crowd. Creating this habit will also show that you have an impenetrable work ethic.

How long can you go without checking your phone or Facebook or Twitter? Five minutes? Ten? Fifteen?

If you haven’t read it, pick up a copy of Deep Work by Cal Newport. Start small. Try to focus on one task for 20-25 minutes without interruptions. Put your phone on airplane mode, close all unnecessary tabs and put a big sign on your door that says ‘DO NOT DISTURB.’

Start building this time up. Try to work up to a 45 minute uninterrupted session. In such a distracted world, the ability to do this is rare and the amount of work you’ll find you can suddenly get done in a short time will be shocking.

There are many apps that use the Pomodoro technique that can help you stay focused. Try to experiment with a few and see what works for you.

Wrapping Up

Building a standout career as a developer is all about becoming a life long learner. If you can use the strategies that I've shared above to grow your skills, you'll always be employed.

This blog post is an excerpt from my latest book, The Standout Career. It's available for pre-order now.

I initially wrote this article as a list of lessons for beginners and junior developers on Reddit. Then it blew up with over 50 awards. Lots of heart warming messages followed.

So I've decided to upgrade the post based on people's reactions.

Here are the things that I wish I knew at the beginning of my journey as a Software Developer. They would've helped me stress less, and hopefully they do the same for you.

Let's get to it.

All tutorials are not created equal

When you're first starting out, you're just trying different things. As you learn and experiment, pay attention to the kinds of tutorials that work for you.

Many will not work. And that’s fine.

In fact, that’s exactly how experiments work until you find a solution.

But the moment you strike gold, stick to it, consume that content voraciously, and then find similar tutorials so you can continue your rapid growth.

_Photo by [Unsplash](https://unsplash.com/@cgower?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Christopher Gower / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

When I started, I used to bang my head against Head First Java, the book. But after studying for many hours, I just wasn’t getting anywhere.

But everyone online said it was the best programming book ever. For me, though, TheNewBoston's YouTube tutorials did it for me even though people don't recommend him anymore.

I wish I could say this stopped after my first year.

Fast forward two years down the line.

I started learning algorithms, and ALL the blog tutorials I followed just didn’t make sense until I watched YouTube videos on Hungarian folk dance teaching algorithms.

And it just clicked.

Since then, my approach to learning has been to learn the same thing from multiple places until I find the instructor and style that works for me.

You’ll forget a lot of things

Deeply understanding this will change how you learn.

I can’t count the number of times I took Introduction to Python Programming on websites like Udacity, Coursera, and still forgot everything.

It’s so annoying.

But I’ve since learned that you’ll forget anything you learn in isolated exercises because they are stored in short term memory. Neuroscience research shows that this is just how the brain works.

If you don’t want to forget, test your knowledge using spaced repetitions. To do this, build projects.

I’ll give you a concrete example:

len(myList)

This will give you the length of a list in Python. You’ll learn this in Udacity’s Intro to Python course.

Come back a month later and you might not remember if it’s len, length( ) or myList.size( ).

But with spaced repetition through a project, the outcome is different.

For example, you work on a 2-month long Django app for new coders where you need to:

• Count the number of users multiple times.
• Store the number of exercises done.
• Find the number of chats in a day.

Imagine doing this throughout the span of the project – for two months. It’s hard to forget what len( ) does.

This is a trivial example, but hopefully you get the idea.

New learners can start with simple, isolated examples.

But if you’re not practicing within the scope of a project and using and reusing what you’ve learned, nothing is going into your long term memory. It’s all short-term.

And that means you’ll forget it.

Work within fear, not against it

I’ll admit that this one's easier said than done.

But you have to master this if you want to last.

There’s this temptation to fix your fear first before you continue to learn. Unfortunately, it doesn’t work like that.

In fact, you’ll spend a lot of time trying to make your fear disappear but instead it’ll only double your anxiety. You have to find a way – your way – to acknowledge that you’re afraid.

And frankly you'll continue to be afraid for a long time. So work within that realization.

No need to fight it.

Sometimes, this fear disappears as you become more proficient.

Other times, it vanishes for a while and comes back when you get into a new environment, work with smart software developers, or move to a completely new stack.

It’s okay.

_Photo by [Unsplash](https://unsplash.com/@open_photo_js?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Jasmin Sessler / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

If you want to progress as a software developer, you have to remember:

This IS the life.

It’s a sinusoidal wave – endlessly going up and down. Don’t take it too seriously or you’ll lose yourself.

Consistency > hard work

Consistency is king.

When you start learning, you lay down neural pathways that make it easier to retrieve information.

According to Neuroscience research, these pathways only get strong through frequency of use, not just intensity.

This means 30 minutes a day, for 5 days a week is way better than 2.5 hours one day, only once a week.

Same hours, different impact.

Don’t just work hard, apply wisdom here.

Talent = hidden practice

It’s easy to dismiss progress as talent.

My first programming class was in C++ and my classmates refused to believe I had never coded before because I was just-so-talented.

But what they also refused to accept was that right after class, I would spend five hours typing:

cout << “this is my first program”

Then I'd realize it didn’t run because I forgot a semicolon ;.

So I'd retype it and realize it didn’t print out my statement on a new line because I didn’t add endl.

This deliberate practice built perceived talent.

Talent is sexier than hustle so no one wants to hear that you worked hard and got here. Just tell me you were born this way – it’s more believable.

Talent vs. Hustle - The majority of us mostly hustle our way through it.

But becoming a proficient software developer is like playing an instrument.

Only a tiny few are born talented.

The majority can only get as good as the amount of practice we put in.

And you can immediately tell a student hasn’t been practicing the moment they sit at the keyboard.

You’ll meet jerks!

Every field has its dose of horrible people.

No doubt.

But I’m not sure what it is about software dev that attracts jerks in droves.

Maybe because coding gives you the feeling of having a super-power or a rare skill. If you’re a beginner programmer, you’ll meet those who’ve been coding for years and think no one else should come in.

A Windows developer only? You’ll meet Linux fanatics that think you’re mediocre.

If you’re a woman, you’ll immediately be dismissed because of your gender. I know this from personal stories from colleagues over the years.

If you’re a minority, you’ll meet people who think you should only fetch coffee, not code.

If you’re coming from another field (particularly not STEM), you’ll meet people who automatically make themselves gatekeepers of the programming community.

“We don’t want social scientists here – we’re purists!”

_Photo by [Unsplash](https://unsplash.com/@markusspiske?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Markus Spiske / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

They’re online.

And at work.

And sadly sometimes in your family.

It’s not if you’ll meet them, it’s when.

Learn to move on.

Things are getting better but there’s still a lot to do to educate people.

But don’t let this deter you. Build your resilience so you don’t quit after you meet these people.

And when you get to the top don't be a jerk!

Master one thing

New developers tend to jump around learning a lot of things.

Okay, it’s not just new devs – it’s also experienced folks.

You learned React for one week. Then JavaScript for two weeks. Laravel for three.

Stop.

You need to wake up and realize that you’re simply extending the time it’ll take you to truly learn anything.

“If one is a master of one thing and understands one thing well, one has at the same time, insight into and understanding of many things.” ~ Vincent Van Gogh

Pick one thing.

Stick with it for a few months – ideally 6 to 12 months before you move to something else.

This has two benefits:

1. You’ll go deep enough and hit critical mass that moves you towards mastery.
2. After you master one domain, you can transfer knowledge to another. Example: learn Flask and you can easily walk into Django. Learn React deeply, and you can quickly identify the pros and cons of Laravel within a few days.

This doesn't mean learn HTML alone for six months. Then only CSS for 1 year.

Rather, it means don't mix up learning:

• Django
• With Express
• Then React
• Some Gaming Development
• And iOS.

You might get a lot done in a short time. And maybe feel like a beginner programmer rapidly growing. But it's an illusion.

You've mastered nothing.

Software development is an ever evolving field

It’s exciting.
It’s frustrating.
It’s intimidating.

But if I had to, I’d do it all over again.

Thanks for reading!

Phew! Did a lot of reflection and lots of hours to put this together.

1. Follow me on Twitter: I'm most active on Twitter. If you enjoyed this, share and retweet this to help spread the word. Have questions? My DM is open.
2. Join the email community: I'm putting together resources to help new coders and junior developers boost their confidence. If interested, join this email list. And if you enjoyed this, check out more of my articles for beginners and junior developers.

Heads Up - I love research so I tend to back my advice and approach with concepts from Behavioral Psychology and Neuroscience.

I vividly remember my first 6 months trying to learn to program. I was following along with a tutorial of some sort, not understanding anything of what I was doing.

I was basically a copy cat.

The video in front of me would often go too fast for my typing. And too many times I had to stop the video, rewind and rewatch or pause at a specific location, just so I could copy the exact same code as the instructor.

And even then I often got it wrong.

I remember the frustration of trying to debug a specific tutorial for two straight days, just because the instructor had forgotten to show something he took for granted that I knew.

It wasn't their fault per se, but it sure was frustrating. It's easy to forget that attained knowledge for us is black magic to someone else.

I'm guilty of that too.

Many years have passed since those early days, and my journey of learning and hard work has paid off. But I still wonder, could I have learned more effectively?

How to learn effectively

In this article there are three points I'd like to address that I think slowed down my learning: lack of focus, the tutorial trap, and abstractions.

Lack of focus

My early days of programming were plagued by a severe lack of focus. I was like a lost lamb. Searching for knowledge, but not in the right places, and never enough. The lack of focus was not entirely my fault, but was a product of why I was learning.

I started learning how to program as the result of working in a startup where we needed a web developer. Our outsourcing strategy was failing, and we needed someone to learn in order to help bring the product to market.

I was going to help out our overseas developers, so I began learning the programming language they were writing our platform in: PHP.

As time went by we changed developers three times. And programming languages. This resulted learning a little PHP, a little Python and a little Ruby.

That was a mistake.

Learning a little of this and a little of that means you're not really giving yourself time to grasp the concepts fully. Programming is difficult, there's no getting around that. So we need to give ourselves time to fully grasp these concepts.

Only once I made a commitment to learning JavaScript fully did I start to see significant changes in my understanding over time.

Do not flap around. Master one programming language. Master it to the core. Master it fully.

This does not mean that you are marrying one language. You can branch out later. It means you are using one programming language as your vehicle for understanding programming.

The tutorial trap

Tutorials are great. Honestly, I've lost count of how many tutorials I've done. It's a great feeling to create something that works. Besides, watching videos of someone who knows what they are doing makes you feel like you know it too.

But it's all too easy to fall into the trap of only watching tutorials. Putting on a video is simple. Doing the hard work isn't. And doing the hard work is what is going to make you a developer.

The problem I often had with tutorials was that all of the thinking was already done in advance, by the instructor. And the instructor doing that work meant that I didn't have to.

That wasn't good, because it meant that I was fooling myself and thinking I was learning at the same time.

Double trouble.

I'm not saying you shouldn't do tutorials. Especially if you are self learning, sometimes you just have to get a grasp of what exactly you need to do to move forward. Or you need to try to pick up pieces here and there to fill in the big picture.

But every time you are done watching a tutorial, you must practice.

I know. It's hard. I'm being deliberately hard on you now. Even today I'm guilty of just putting on a video tutorial when my energy is spent. I keep thinking it's better than nothing. And sure, it is.

But if you don't practice, you are wasting valuable time and effort.

One of the best things that ever happened for my learning was the decision I made to do the freeCodeCamp projects. They are defined projects that don't hold your hand. I needed to figure out how to implement everything.

And guess what? Doing that is exactly the job of a developer. That's how we feel every single day. We are given a task that we often initially have no clue on how to solve, and then we apply a toolbox of learned skills to that problem.

Being a developer is not about having an answer to everything. It's s about finding the answer to everything.

And you don't get there by only watching tutorials.

Practice. Practice. Practice.

Don't rely on abstractions

Being a developer in 2020 is hard. Technology is moving rapidly, and advances are being made all the time. One of concepts that allows us to move quickly is abstractions.

Abstractions are a great thing. Someone has taken something hard, and made it easier by abstracting away the hard part.

You can think of it like a stove. You don't need to know how the stove works, you only need to know that when you press a button, the stove turns on and puts heat on the plate. That's all you need to make dinner.

In code, this is a great thing too. We don't need to write machine code, because it's abstracted away. We don't need to write HTTP servers, because they've been made and are available for us to use, and we can build new and amazing things on top of these.

Unfortunately, this is also a double edged sword.

While abstractions allow us to do amazing things, we also miss important things that allow us to grow as developers. Things that allow us to understand on a deeper level what is going on. Things that could be important for creating great solutions.

We miss these things because we don't have to learn them, even though when learning them, we often become better developers on the other side.

These things are often bothersome, difficult, and boring to learn. Which makes them easier to skip in our learning process.

But I'd like to challenge you to be curious.

Don't be satisfied just building with frameworks like React. Build a single page application in vanilla JavaScript.

Don't be satisfied just using Express. Try to build your own web server using Nodejs and TCP. Learn HTTP.

Learn the difficult, boring, and trite things that make you a better developer. Or at least try. In my opinion you'll be better off.

Conclusion

In this article we've explored three areas that I think slowed down my path to becoming a developer: lack of focus, the tutorial trap, and abstractions.

I've given some concrete advice based on my own experience on how you can avoid these mistakes and hopefully learn more effectively.

If you're interested in my content, you can find my youtube channel here, where I cover things like React, web fundamentals, chatbots and more to come.

You can also follow me on twitter @foseberg.

Thanks for reading this article, and please share it with anyone you think might find it useful. Good luck on your journey.

##

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.

When you think about skills, you're probably thinking about programming languages and frameworks. There are a lot of those, and they vary depending on which kind of developer you want to be. We can consider these hard skills.

But there are many so-called soft skills (I personally do not agree with the name, but we will go with it). The dictionary defines those as:

“Personal attributes that enable someone to interact effectively and harmoniously with other people.”

Those skills are more complex than your tech stack, because you can’t just prove them in a test, and most companies won’t ask you about them. But they are, in my opinion, vital to new developers.

I am Pachi, a self-taught developer and a Latinx immigrant. And without perseverance, I would have given up on a developer career a while ago.

What is perseverance, you might ask? The dictionary says:

“Persistence in doing something despite difficulty or delay in achieving success.”

And let me tell you, the delay will feel eternal and the difficulties will show up one after another.

I am telling you this from a place of experience. I have yet to get that first dev job we all see people talking about. All my work experience comes from accepting any and every opportunity that is offered to me (which I don’t recommend – it is exhausting and the burn out is certain).

So how do you keep going? Well, I'll tell you.

How to persevere in 3 steps

Know your "why"

I don’t care if your reason is to save the hungry, to be the next Bill Gates, to help your parents buy a new home, or even just to pay your monthly bills.

You have to have a reason that is strong enough to motivate you when things aren’t looking awesome.

My family is in Brazil, and dollars convert to a lot of money there. I really want to help my family to live a more comfortable life.

So I have a picture frame with them just sitting on my computer. They are my number one reason I'm working to become a developer.

So just find something that can keep you going: money, family, glory – or all of it!

Have a Plan

No, you don’t have to buy a pretty planner and fancy pens and stickers and write down short and long term life goals. Although you can do that if if that is your thing. It certainly isn’t mine. I am a minimalist. So let’s keep things short and effective.

Figure out what you want to learn, and why. And how. You can give yourself a time frame, but keep it loose so you don’t pressure yourself too much and end up feeling like a failure.

Your plans should look something like this:

“I want to learn React. Because I am a front-end developer, and React is a popular framework that I see a lot in job ads in my area.

I will start with the freeCodeCamp free React class. And it would be great if I could study 5 hours a week and get it done in 3 months.”

It has to make sense to you, seem doable, and not scare you too much (unless that is how you work).

I often see people saying they don’t set goals because they are afraid that they will fail and feel terrible about it. Your little plan here is just a plan. It helps if it makes you feel excited and hopeful but not overwhelmed.

Also, there is no shame in changing your plan as needed. I was freelancing for a company that used a framework I didn’t know (they didn't use ReactJs, the one I wanted to learn).

So I revised and adapted my plan. That also helped me work on being flexible, and that is definitely an important skill in our big tech world, where things change everyday.

Give yourself permission to chill

New coders are fearless and unstoppable. They are active on social media, they have 10 Udemy courses and have started only 3, they have way too many websites saved and tabs open, and people keep telling them more and more things to learn.

deep breath It is exhausting!

You want to succeed. I know, I see you! And there is SO much to learn. But you have to respect your mind and body.

It is okay to take a day off and binge watch some show, read a good (non-technical) book or just do nothing at all. It may be cold tea or a warm bath, maybe chocolate or going for a walk. But it helps to know that little things that can help you relax and get your mind where it needs to be to go back to work in a health way.

We all know that procrastination is our biggest enemy (I will just check my Twitter REAL quick before finishing this article). But sometimes it is easier to deal with things in the long run if we give in every now and then.

Conclusion

I am by no means what most people would consider a "successful" developer yet. I have a part-time job at a small company and I have big dreams and places to go. So I also will be revisiting this article again and again.

But here you have my "secrets"... The things that has been keeping me going. And I bet you already do some of these things as well, and you didn’t even know it!

I bet you are a Junior Dev full of perseverance, making your way in this dev world. And now, you do know these tricks and you can use them in your favor.

Every time that you are stuck, go back to your plan and check if you are on track with it. If everything is on track but you still feel "off", have a little talk with yourself about your WHYs and try to get pumped up about them again.

But don't forget, sometimes the answer is to just take some time off to relax for a bit.

If you're reading this, you probably just got your first tech job — so congratulations! Getting the first job is one of the hardest things you'll do in tech. There's so much work and effort already behind you.

Or maybe you don't have your first job yet, but you want to know what you should expect.

Either way, in this post I will address the common worries and questions about what to expect on the job, and how to succeed in a career as a developer.

Here's what we'll cover:

1. What to expect on the job (early days/weeks)
2. Your short to medium-term plan
3. The mindset for success
4. How to be an outstanding new developer

What to expect on the job

The day finally arrives. You walk into the office (or join the morning team standup remotely) for the first time as a new developer. Even if you're nervous, try to remember and take in your first day. It's an exciting time!

Your first day will likely be logistical things: setting up your computer, orientations or trainings, and HR logistics (banking information, insurance, and so on).

However, it is becoming a common practice to have new developers do a push to production on your first day. It's usually something very small—like adding your name and photo or fixing a typo on the company website. This tests that your computer setup is good to go, and it also gives you a very quick win and lets you join the rest of the team shipping software.

Your company wants you to succeed

As a new developer, 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. This company went through enormous effort to find, interview, and hire you. It's a costly process from both a time and money perspective for the company. They're not going to hang you out to dry—that would be a poor way to treat their investment in you.

There are some skills that you bring to the table at the start, but there are some skills that are difficult (though not impossible) to acquire outside of a professional work environment.

Since this is your first job, it's likely you've never collaborated with a large team using source control or maintained production applications—and that's ok! These skills are easier to pick up in a production environment.

Your first days/weeks

Once your computer is setup and you have access to all of the tools that you need, your first tasks will likely be small feature improvements or fixing small bugs—just things to get your wet feet across the various projects.

Outside of pure technical knowledge, in every company there is domain knowledge or "business logic" (what the company's products or services do and how they do it) that you'll need to pick up.

If the company has multiple products, they may give you small tasks in each codebase to begin exploring those products. It's also likely that they will assign another person on the team to pair up with you—or at least be available for questions you have throughout the early weeks.

In these early days and weeks you only have one goal: learn, learn, learn.

Learn about the technology you're using, learn about the company and how it works, and learn how to work with your teammates. Your work output is not important at this point—your rate of growth is.

Diving into a production codebase

As you begin working your way through the various codebases at your company, you'll likely feel a like a fish out of water. This is totally normal—it's much easier to write code than it is to read it.

A production codebase is very different from the tutorials you've been working through or the toy projects you've been learning with.

For one, this codebase has likely existed for many years, and been worked on by many different people—each with their own style and each of them making their own mistakes.

It's also likely there are many more software packages or plugins injected into this application than you have come across before. All of the convenient shortcuts or edge cases that were ignored in a tutorial (like error handling) have to be handled here—this is a real app.

This can be overwhelming at first, but reading other people's code is a skill you have to develop, and it's one you'll use your entire career (and at the end of this post I'll give you some tips to help with that).

In the end, don't be afraid to ask for help! Your teammates are there to support you, and at some point in the past they had to ask the same exact questions.

New developer expectations

First things first: this company is not expecting you to jump in and start knocking out features. They know you'll need time to develop skills you don't have yet, understand the codebases, and learn how to work with the team effectively.

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.

In the first 30 days, you'll likely just be doing small feature improvements and small bug fixes—just things to get to know the company's products and codebases. At 60 days, it's likely you'll be doing slightly larger features and bug fixes. By 90 days, the scope will have grown a little more, but they still won't expect you to own and drive large features forward yourself.

Ultimately, the company just wants you to continue to learn and absorb the information around you. You're not going to know everything going in, or after 90 days, and that's ok! Take it a day at a time.

The new developer mindset

Walking into a new company, there are many things you can't control, but there is one very important thing you can: your mindset. Your daily thoughts, practices, and how you internalize what happens around you will determine your success.

At times you'll be confused, at times you'll feel overwhelmed, and at times you'll even doubt if you can do this (I did). How you internalize these thoughts matters. Remember, this isn't unique to you—every new developer has faced this. Keep your mind in check and you'll push through.

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

It's an opportunity to understand something new and grow. It sucks, it feels bad, but soon after this you will be a better developer. And this will happen a lot—that's just the reality of being new to something.

Instead of internalizing:

"I got stuck 10 times today."

Try instead:

"I had 10 opportunities to learn today."

It's a powerful shift, and it will be obvious to your teammates and in your job performance.

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.

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.

Also, remember to celebrate the little wins along the way! Those small wins will stack up and become a large mountain of success over time.

Here's another important thing to remember: give yourself the freedom to make mistakes. You're going to break production, you're going to make some bad database updates (I definitely have)—it's recoverable, it's not the end of the world or your job, and any experienced developer has done it. It's just a part of the process.

Your greatest skill as a new developer

You may not realize it, but your greatest skill as a new developer is that you've learned how to learn.

You've learned how to take something hard, complex, obscure, and break it into pieces—work through it step by step.

More than learning JavaScript, React, Ruby, or anything else, 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.

Own your growth—no one else will.

This might be the most important statement for a developer at any stage of their career: your career is your own. You have to own it, and you have to own your growth.

Sometimes the your company, job position, or boss will help facilitate your growth, but in the end, it's up to you.

Most companies have some kind of scheduled review process—possibly quarterly or yearly. If they do, great, but if they don't, own your growth! Ask your supervisor regularly for feedback, and do what they say. If someone mentions something you've never heard of, ask them about it or go do your own research it!

"The Power of Tiny Gains"

https://jamesclear.com/marginal-gains

One of my favorite books, Atomic Habits by James Clear, has a great diagram titled "The Power of Tiny Gains." It's a simple diagram. It shows the difference between a 1% improvement and 1% decline every day.

If you get 1% better every day, after a year you'll be almost 38 times better than you were at the start of the year! That's the power of "tiny gains," and it's just as true for becoming a great software developer.

Every day you have an opportunity to learn something new—no matter how tiny it is. Maybe it's a new function on arrays you didn't know about, a different method for structuring CSS, a new text editor shortcut, or something new entirely like learning SQL and how data is stored at the database level.

Regardless, aim to be 1% better every day (most days you'll end up doing much more) and the growth from the first few years of your career will be astounding.

One page per day

I heard a story on a developer podcast once about the guy who maintains the pg gem for Ruby. This is the gem that is the interface between your Ruby code and the Postgresql database. It's some pretty serious stuff, and it's used by most Ruby developers every single day.

The story of how he became the maintainer of this gem was interesting. He said that when he was first getting started, he would open up the Postgresql documentation and read one page—just one page each and every day.

Over time, he grew an extensive knowledge of Postgresql and was able to start contributing to the pg gem. After a little while longer, he became the maintainer of that gem.

It's the perfect example of tiny gains stacking up—just one page per day. Any of us can do that, and I encourage you to take the same philosophy and apply it to whatever language or system you're working with!

"Practice make perfect"

You've probably heard this phase before: "practice makes perfect."

My piano teacher growing up used a different phrase: "perfect practice makes perfect."

I think he was right. I could practice the piano in the wrong way—with bad technique, sloppy, without a steady rhythm—and that's the result I would get: sloppy piano playing.

It's not just practice, but how you practice that matters. I could practice the first measure of a song over and over and get it down perfectly, but if I never pushed beyond the first measure I would never learn the song. I could play that first measure of the song at the level of a world-class pianist, but I wanted to play the piano, so I had to learn the whole song.

This is a perfect parallel for development. The way you "practice" development (your daily habits, methods and routines for development) determines the type of developer you will become.

In the beginning you'll make lots of mistakes (everyone does), but if you're conscious of your work, you'll notice areas you can improve. These are perfect practice moments: the opportunity to learn something new or do something in a better way.

When you look back on your career ten years from now, you will want to have had ten years of growth, practice, and learning—not one year of growth, practice, and learning ten times.

So ask those dumb questions. Ask the obvious questions. When someone mentions something you don't know anything about, boldly ask, "What's that?" My hope is that they respond in a kind and teaching manner, but regardless, be ready to learn.

It all comes back to owning your growth.

T-shaped people

A "T-shaped" person

In the beginning of your development career, there are so many topics that you can benefit from knowing, so you want to spread your effort and knowledge across a wide range of subjects.

If you're aiming at becoming a full-stack developer, that list might include things like HTML, CSS, JS, a backend language of your choice, SQL, Git, etc. There's so much easily attainable knowledge and benefit right on the surface of each of those topics that can be acquired by casting a wide net and taking it all in.

Over time, you'll find what type of development you enjoy most. Maybe it's frontend, backend, database work, ops, design—or some combination of those and more.

As your career progresses, you'll start to become a "T-shaped person." A T-shaped person is someone who, like the letter "T" is visualized, has a wide but shallow knowledge and experience about a lot of things, and a couple areas with a deep amount of knowledge and experience.

This deep knowledge takes a while to build up, and each step down is increasingly more effort than the previous—that's just the reality as you approach mastery of a subject. In the beginning, scoop up all of those easier beginner gains across a wide field of subjects.

Having this T-shape ability will help you become a better developer as a whole. Frontend developers who understand the database schema or backend developers who understand how those database tables are going to be used as models in the frontend will be more knowledgeable and better teammates than those who are siloed in their own area.

In the beginning this little foray into all of the aspects of development is also useful to find what you're drawn to, and to give you the bigger picture of all of the moving pieces in the software world.

Follow your interests and stay hungry to learn!

Tips for being a great new developer

Now that we've covered your expectations and how to think about them, here's some practical tips to make you a great new developer—one your teammates love to work with.

#1 Communicate really really really really really really well

You may not have incredible development knowledge and skill walking into your first day, but you can have incredible communication skills.

As a new developer, you're going to ask for help and guidance—a lot. And that's ok! Here's a tip for how to ask for help effectively.

Getting stuck is frustrating (it was for me). In these moments, it's easy to let that frustration overwhelm you and fire off questions to your teammate next to you (or maybe via email or a chat app).

Things like:

"im stuck"
"it errored"
"the page won't load"

Now take a step back and view this from the perspective of the person you're asking help from. A message like "the page won't load" doesn't help this person help you at all. 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.

A better way to ask for help is to think of it like a Mad Lib™ (if you remember those):

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

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

An example of this message might be something like this:

I am working on the user password reset bug,
but when I try to generate a password reset link,
the user's token is already empty.

I've looked at where the token is set, and I can see the token in the database,
but the token is missing on line X of File Y.

If you sent someone the message above, they can understand:

• What you're working on
• What the problem is
• What you've tried already
• Where the problem is

This is a wealth of information for the person you're asking help from. 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.

There's nothing wrong with getting help, but if someone just fixes the problem for you they've really robbed you of the opportunity to learn and grow yourself.

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. So the best outcome is if they give you enough help to get you unstuck but allow you to solve the problem yourself.

#2 Hone your Google Fu

Just like developing skill in the physical martial art of Kung Fu, over time as a developer you will develop skill in the art of Google Fu—that is the art of finding answers by Googling them. This is a real skill that every experienced developer has and it is developed over time.

Sometimes, you just need to google the exact problem you have (this works great with error messages):

Sometimes pasting the whole error message works

Sometimes googling the exact error message will produce the correct result, as it did above. You ran into a technical problem, and someone else ran into the exact same problem.

But sometimes, you need to edit the search query a little bit to remove project-specific info:

Too much project-specific info returns no results

In the image above, Google has never seen the function whos_that_pokemon_its_pikachu() in the file gotta_catchem_all.rb (except now it has since I searched it :)). Removing that project-specific info and adding generic info returns better results.

The underlying generic error

#3 Use a "try timer"

As a new developer you're going to get stuck a lot. There will be error messages you haven't seen before, and how you handle these situations will determine how quickly you grow as a developer.

Although these can be terribly frustrating moments, these are the moments where you will learn and you will grow. You don't learn by doing the same kind of work over and over again—it's by journeying through these bumps in the road that growth takes place.

When you run into one of these problems, take some time to try and figure it out yourself. Some companies will tell you this as a part of onboarding—something like "try for 30min before asking for help." In other companies it's not as clearly defined, but the message is still there: do your best and then if you're still stuck ask for help.

This not only allows you the opportunity to figure it out and learn for yourself, but it also respects the time of your teammates who are focused on their own work. Interrupting someone for something you could have quickly figured out yourself is a net loss for the team.

So give it a good try, and then of course ask for help!

Here's the secret to being a great new developer though: always reset the timer.

Let's say you get stuck, try for 30min, and then ask for help. The next time you get stuck try again for another 30min before asking for help.

This may seem obvious, but on those days where it feels like you hit nothing but problem after problem, you're going to get frustrated and you're going to want to start asking for help as soon as the next problem arrives—it's just natural.

Take a deep breath, go for a quick walk, and approach each problem with a fresh perspective.

(This is, of course, easier said than done!)

#4 Remember to relax and take breaks!

Remember to take breaks when things start to feel overwhelming.

Go for a walk. Go get a glass of water. Sleep on it if you can. Sometimes just getting up and moving for a minute can help you re-center yourself.

Remember that every developer was once in your place, and you will get through it.

Development will always be frustrating to some extent—you never stop making mistakes or running into problems. But over time you just get better at dealing with them, and your confidence to fix those problems increases so it bothers you less and less.

#5 Ask the duck

Have you ever written an email or a text message describing a problem you have to someone, and right before you hit send you realize the solution? In the software world there's a phrase for this—rubber duck debugging:

The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line-by-line, to the duck.

You see, by writing an email or talking to another person, you're forced to explain the entire context in a logical way in order for the other person to understand what's going on.

To explain the problem in this way, you yourself have to be able to think about and order it logically. Just the act of trying to prepare this context for someone else can cause you to think about the problem in a different light, and many times you'll find the solution yourself.

So relating back to using a try timer, before you ask for help, try explaining (or typing) up the summary of the problem in an email that you don't send. The chances are you'll gain new insight about the problem without having to interrupt another person, and worst case, you've got a great email or chat message to send them.

(I've seen many people put actual rubber ducks on their desk too!)

#6 Take notes

This tip may seem obvious...but take notes!

You will be introduced to many different things when you first join a company: codebases, products, people, business logic, and it will be impossible to remember it all. Write this stuff down.

When I started my first job, my boss told me he had no problem explaining anything to me, but he didn't want to have to do it twice. I understood then, but now eight years later I really understand—it's all about respecting your teammates and their time.

If he explains something to me and I forget it, we've wasted both of our time—and I'll have to ask him again. At his recommendation I even started putting physical sticky notes on my monitor of things I wanted to see often and remember. Things like:

• TRY FOR 30MIN
• CHECK THE BUILD PASSES BEFORE ASKING FOR PR REVIEW
• MAKE SURE YOU HAVE LATEST CODE

#7 Fight against imposter syndrome daily

If you don't know what imposter syndrome is, it sounds like this in your head:

I don't belong. I'm a fraud. Everyone else understands this but me.

This is a mindset you have to fight on a daily basis. There will be frustrating times as a developer, but you've faced frustration already and pushed through it. Every developer has felt this, and this too will pass.

In reality, imposter syndrome looks more like this:

Imposter syndrome

The one key difference between a "senior" and "junior" developer

Sure, a senior developer has more knowledge and experience than a new developer, but that isn't what sets them apart. A senior developer has a problem solving system.

When I first started in development I thought eventually I would stop making mistakes—that I would stop running into errors.

The opposite happened. I still make an incredible number of mistakes every day. Wrong syntax, wrong file, wrong function.

I didn't stop making mistakes—I just got incredibly fast at fixing them.

This is a skill that is developed over time, and it requires intentional problem solving.

Here's some tips on how to build this system.

5 Debugging tips

#1 Don't thrash your code!

One of the things I did as a new developer—and something I see many other new developers do when they run into a problem—is they start wildly changing things in their code. Instead of having a systematic evaluation process, they just make a ton of quick changes trying to see if that fixes the problem.

This is a very bad habit. You will only create more mistakes doing this. What you should do is:

#2 Read the error message!

This tip may seem obvious, but actually read the message. What is the error? What is the file where this error is occurring? What line is this error coming from? This is all vital information.

If you resist just changing your code rapidly, you can jump straight to the exact place the error is happening.

This is what the experienced developer does. Read the message—go straight to the problem.

Doing this will save you an incredible amount of wasted time and mental effort.

#3 Don't waste time on the impossible! (Or at least the improbable)

Don't waste time on the impossible!

This is something I see new developers do often. They face an error in their code, they find something that they think is the problem, and they can't believe how it's not true. As an example:

"I see the problem is on line 14, where it checks if the is_admin variable is true, and it's not true—but the user is an admin!!

They approach this problem thinking, "How can this be!!!" instead of, "How can this be?"

There are times when you will encounter a core language or framework bug, but 99.9% of the time, you did something wrong or the situation is not as it appears.

Instead of spending time marveling at the impossible unfolding before your eyes, question your assumptions about the situation. Something is not as it seems. Being aghast at the impossible is only a waste of time—start your problem-solving system.

#4 "When in doubt, print more out." - Some wise person

I don't know who originally said this, but it's one of the most effective debugging techniques out there. When you don't know what's happening, start printing the state of your program in places where you think the problem is happening.

What is in the user variable? What is the response from the HTTP request? Did we take the if or the else branch in this situation? Did we even call this function or are we even on this page?

I've seen countless developers trying to debug and fix an issue (and I've done it many times myself too) when they weren't even working in the right file! A quick print or console.log will show you that you are in fact looking at the actual code being run.

#5 Take it one step at a time.

A common mistake every new developer does: they do too much at once.

They want to write code for 30min, click run, and see it work. What they find is that they spent 30min writing bugs and errors, and it's now a nightmare to fix.

When I go to make a new page in an app, the first thing I do is put <p>hi</p> on the page. I want to make sure that all of my internal code is setup correctly and I see that hi on the page. I take it one. step. at. a. time.

Do one thing at a time. Get "hi" printing on the page. Next get the user input. Next validate the input. Next save the input. If you take small steps you know exactly where to fix the problem when it occurs.

Even eight years later into a development career I still take it step by step. I know I'm going to make a ton of mistakes, and I want to know immediately when and where that happens.

Conclusion

You've already come so far, but there's still a lot ahead of you.

There's much to learn, and many skills to develop, but there's also a lot of fun and rewarding work ahead as well!

Keep your head up, and remember to take breaks. Get 1% better every day, and in a year you'll be astonished at the results!

If you liked this post, I write similar things on my blog here.

Thanks for reading!

Getting that first developer job is the goal of many new programmers. But I've discovered that far fewer developers want to take the next steps in their careers.

I found myself in this position, so I formulated a plan to progress my career. Over five months I learned everything I needed to get three job offers that almost doubled my salary. It wasn’t easy, but it was definitely worth it.

Here’s how I did it, along with the steps you can take to do it too.

But first, since this is an in-depth article, here's a quick summary of my advice.

A Junior Developer Career Guide in 7 steps

1. Decide on your goal. What kind of job do you want and when do you want it? You can learn a lot in six months of part time studying if you work at it.
2. Find 10-20 current job descriptions for jobs you would ultimately want to get. Create a list of all the requirements and how many times each one came up.
3. Find the 3-5 main skills that are usually required by those jobs, that you don't currently have.
4. Use courses to boost how quickly you can learn a new skill. Courses can be a great idea as they save you time and effort.
5. Apply to jobs before you've learned everything. Interviewing well is a skill that you should practice too.
6. Build projects with what you've learned - that's the best way to make sure you solidify the skill.
7. Get the job that you've worked hard to get.

If you're looking to become a full-stack developer and want to know what you'll need to learn, I've got a free guide to the skills and tools you'll need.

The Goal

I was planning to travel around southeast Asia for 3–6 months, and I knew that I wanted to get a better job when I returned. My junior JavaScript job had shown me three things:

• I loved to code, not only as a hobby but as a job.
• I enjoyed back-end development work. It was more logic-based which I really liked.
• I didn’t like Angular that much.

With this knowledge, I set about creating a target for where I wanted to be by the time I finished traveling, and what I needed to learn to get to that point.

My target was to be a mid-level full stack developer.

The Recon

To become the mid level full stack developer I wanted to be, and to find out where I needed to improve, I looked for jobs that I would actually want to get in the end.

First, I saw what those jobs required in a candidate and what they said was desirable. I created a list of all the skills and then ordered them by how many times they came up in those job descriptions.

With this list I looked at the highest ranked skills that I didn't have yet. You don't need to be able to do everything on this list to get one of these jobs. On average a new hire only has 70-80% of the required skills listed on the role. Most of the time the things that are actual deal breakers are just a few key areas. We are aiming to get to that level and then any other skills are a bonus.

Through this research, I made a list of things that most of the jobs I was looking at required:

• Strong understanding of JavaScript
• At least one front-end framework (usually React or Angular)
• Ability to create a REST API
• Knowledge of one or more database

This process can really be used for anyone in any career. But it works really well with development, as there are usually a specific list of skills that a role "requires".

Formulating the Plan

With this information, I knew that I needed to up my game in a few key areas:

1. I needed to finish reading You Don’t Know JS. This book series helped me really understand the basics of JavaScript, so I reasoned that it would be great for learning the more advanced stuff.
2. I needed to become very good at one front end framework. I looked into Angular, Vue, and React and decided on React. I’d done a bit of React before and liked it, I wasn’t a fan of Angular, and Vue wasn’t requested in many job adverts.
3. Although I could just about create an express API from scratch, I wasn’t very confident and could only do the basics. I needed to up my game across the board with this, especially if I was wanting to have a job that prioritised back end work.
4. I could either stick with relational databases (postgreSQL) or learn a new DB. I decided that I would go for learning MongoDB as it was massively popular and added NoSQL databases to my CV.

I wasn’t sure how long I’d be traveling, so decided to plan my learning out like this:

1. Learn React (and Redux) while reading You Don’t Know JavaScript.
2. Get much better at API development and learn MongoDB.
3. Make something with the skills I’d learned.
4. Learn other things.

I did this for a very good reason. If I ended my travels after three months and had completed #1 but was still part way through #2, then I would still be able to apply for mid-level developer jobs — they’d just be limited to mainly front-end jobs.

If I did back-end learning first, after 3 months I still wouldn’t be very confident with any front end framework. That would probably be a sticking point for every mid level job. I could try to apply for a back-end only developer role, but they all seemed to want much more experience than I had.

Learn React and Redux, and read You Don’t Know JS

I’d done a little bit of React before, using Youtube videos and normal web tutorials, but this time I wanted to make sure that I was learning it properly. This led me to getting the React JS and Redux: Mastering Web App course from Udemy.

This course was brilliant, and the little bit of experience I had with React helped a lot, but I had no experience with Redux. By the end of this course, I felt like I could have built a pretty complex website and was confident with both the syntax and formats of React and the data control of Redux.

This course took me about 2 weeks to complete, but I was working on it for an hour or 2 once or twice a week. I was on holiday in Asia so this wasn’t my main priority.

As well as working on the course when I had my laptop, I read my way through the last few books in the You Don’t Know JS series. I stored the online Github version on my phone and read it while I was resting between climbs.

Having gotten some real world experience, I understood a lot more than the last time I tried to read these books. Things like Promises are really hard to understand if you’ve never used them.

Get much better at express and learn MongoDB

Now that I felt comfortable creating front ends, it was time to work on my back end skills.

Again I decided to do a Udemy course. I found that because they’re complete packages, things progress nicely and tend to cover the whole process. Of course you can learn all of the same stuff for free on Youtube or other online tutorials, but they never seem to cover a whole topic quite as well.

The next question was which course to do. There are free ones and paid ones, short ones and long ones.

I decided to invest in myself and buy a course ($10 is a tiny investment for such a great deal of information) and I managed to narrow it down to about 3 courses. They varied in length between 7 hours and 25.5 hours.

I was tempted by the 7 hour course — I could get it done in a week or two whilst still enjoying my holiday. The 25 hour course would obviously take much longer, but seemed to cover more topics. By this point in the trip, I’d decided that I was going to be traveling for as long as my bank balance allowed, so I went with the 25 hour course.

Node with React: Fullstack Web Development

I’ve actually done a full review of this course here, and it’s a great course.

Having done the React and Redux course before, the React stuff was being repeated. So you don’t waste time, you can just skip videos you already know or put the video on 2x speed and “skim watch” for a refresher or to check for any bits of useful advice.

The back-end stuff is where this course excels. It covers a huge range of topics including: oAuth, email handling, payments, API key handling, MongoDB, mongoose, and advanced deployment.

The reason that this course is so long is that it covers so many topics in such great detail. This is good and bad, but I ended up watching most of the videos at 1.5x speed and pausing when I needed to.

This course took longer than the first, but I managed to finish it in about 1.5 months.

One of the things that I struggled most with was the DevOps, how to deploy and host the app in a reliable way. If I was doing this now I would probably go with Serverless as it removes a lot of the barriers to back end development.

I started writing

At some point, while staying in China, I decided to write an article about how tough it is to do development in China. It got accepted into the freeCodeCamp publication, and now has 7.1K reads and 1300 claps. I was amazed that people read what I wrote and liked it.

I decided that I was going to try to write more articles about what I was doing and cool things I had found. This also ended up giving me a great talking point when it came to interviews.

I've continued to write and it has opened some amazing opportunities. I've been highlighted as a FreeCodeCamp Top Contributor, been offered freelance work, and even been given a book contract.

Writing a blog is also a great way to log your progress and allows you to see how you’ve improved.

Make something with the skills I’d learned

Now that I had all the tools I needed, I wanted to create something with them. I was three and a half months into my travels and expected that I would be able to travel for another 1-3 months.

This meant that I might need to start thinking about jobs soon if I wanted to start ASAP when I got back.

To apply for jobs, I needed to update my CV and portfolio. This gave me a great chance to use what I’d learned to build a new portfolio using Node and React.

This is exactly what I did, and below is the result. As I said before, I’m not a designer, but it works well. I even used a Wordpress API to host blog posts on the page.

I knew that the design was awful, so I posted it in a web design review subreddit. I got lots of good advice, most of which revolved around spending the next few months researching and learning the basics of web design. This wasn't quite what I was looking for but there were a few good pieces of advice.

One bit of advice I did take was to utilise design frameworks that existed. This resulted in a completely new website, using none of the skills I’d used before, but it does look less garish. If I was doing it again now, I'd probably try and follow something like Material UI.

Applying for Jobs

The next place I visited was a remote climbing area in Laos. By this point I knew that I had two weeks in Laos, then about four weeks in China again before heading home. Time to get applying for a job.

If you don't have a hard deadline like I did then I would try and set one. It really helps motivate you to finish your project or get on the job search (no one likes searching job boards).

If you don't want to set a deadline then set a point in your learning when you are going to start applying for jobs.

This should NOT be after you've learned everything! Learning to interview is also a skill and you should be getting experience with that as soon and as often as you can. Start applying to jobs that you are less keen on to practice the whole process.

Progress

Over the course of the next one and a half months I applied to well over 50 jobs, had email and LinkedIn conversations with about 25 people, and managed to secure five job interviews for the week after I got back.

Most of my interactions were by email, but if someone wanted to call directly then I tried my best to accommodate that (I was eight hours ahead).

I think that having an actual conversation is a great way to improve the relationship between you and the other person, increasing the chances that they’ll invite you to interview or recommend you for a job.

If you don’t feel comfortable having a call or Skype with people then you can stick to emails, but I think you’re missing out on improving your chances.

Build More Things

One of the interviews asked me to prototype what I would do for a company with an awful website and minimal customer service. This was cool as it pushed me into learning about prototyping.

I wrote a series of articles on how I prototyped and fleshed out the website. You can see the website here read my articles here.

It also gave me an opportunity to take what I'd learnt over the last 4 months, practice it, and build something that showcased what I could do.

The last thing I did on this project was to create a chat bot for returning orders. I had to learn about the workings of chat bots and it took me about a week to get a decent working version. This was a massive factor in me getting the job and it led to lots of other opportunities.

Learning one or two slightly alternative skills that you can showcase can work really well. Just make sure that's after you've got your core skills sorted.

Interviews

Now that I had these five interviews lined up, I had to convert them to job offers.

Preparation

I’ve written articles about preparing for a JavaScript interview and mastering the interview process. I made sure I ticked every box.

I knew all the points I was wanting to emphasise, how to answer the questions about my weaknesses, and what each company did.

The Interviews

I’ve always been quite good at interviews even though I’m naturally introverted. I’ve had to teach myself to act more extroverted and engage with the people interviewing me.

If you find yourself acting shy and reserved in interviews, I recommend practicing this as you would any other skill. Find a good resource (charisma on command is a great Youtube channel) and then repeat what you learn. Start with friends and family giving you fake interviews but then try and find people who you are less familiar with and might be more similar to the real developer.

I had tech tests at three quarters of the interviews (having done the other two online) and my preparation paid off. There were small slip ups, but I talked through my thinking and finished all of the tasks well.

You interview is also an opportunity to find out more about the company and what it might be like working there. A company might seem awesome on paper but doesn't live up to the hype, or could be the other way around. Choosing the right company is a big decision so make sure you ask for all the information you need.

The Offers and Negotiating

From my first three interviews, I had two offers. After the fourth interview I knew that they weren’t the company for me, so let them know I wouldn’t be considering an offer from them. If you are ever in a similar situation, try not to lead them on if you know you’re not going to accept an offer from them.

Now I had offers from two companies who were very keen to hire me. It was time to negotiate. I’ve never been great at negotiating or asking for more, but I read a few articles and went for it.

_You might think to yourself: “well, I don’t want to set high expectations, and the offer is already generous, so I ought to just take it.” No. Negotiate._

_Or maybe: “I don’t want to start off on the wrong foot and look greedy with my future employer.” No. Negotiate._

“But this company is small and — “
No. Shut up. Negotiate.

From Ten Rules of Negotiating a Job Offer. I recommend reading it if you’re applying for jobs.

I definitely didn’t do this perfectly (or even that well), but I did do a few things that strengthened my hand. I had two equal offers, but I had a preference for one company. I wrote myself a little script and (after some breathing exercises to calm myself) I called the director of my favoured company.

Hi Dave. I’m calling to give you an update on where I’m at. Thank you for giving me an offer, I’m glad you thought that I would be a a great fit in the company too.
I’ve had another really strong offer and I’ll be making my decision this weekend, letting you know by Monday at 12pm.
There is one thing that could really strengthen the offer. I’m going to be relocating to wherever I take a job, and some assistance with the relocation costs would be amazing.

It didn’t quite end up going exactly like that, but it helped a lot. I thanked them for the offer, told them a deadline for making the decision, and asked for an improvement in the offer without just asking for a higher wage.

Summary

I found out what I needed to get the jobs I wanted. I used this to create a plan and then used paid online courses to speed up the learning process.

I applied to loads of jobs and got five interviews. Having prepared for these interviews I ended up with 4 offers, and 2 that I wanted to decide between. I negotiated the offers from the two companies I liked the best and ended up with an awesome job at a great company.

If this article has inspired you to take the next step to become a full-stack developer then you'll need to know the skills that you need. Luckily, I've got a free guide to the skills and tools you'll need to become a full-stack developer.