I never loved the phrase “junior developer.” Junior evokes memories of little league baseball, a suboptimal grade level and perhaps even the esteemed Weenie Hut Jr’s (for the Gen Z crowd). It takes hard work to understand enough code to convince a company that you can make that API come to life when push comes to shove. Juniors are valuable! They’re brimming with career ambitions, they have something to prove, and they bring a fresh set of eyes to languishing legacy code.

When I first started working as a developer, I quickly realized that learning Spring Boot and data structures would take a back seat to a more important topic. I felt like I was dropped in a pit of quicksand and didn’t know how to navigate through my increasingly growing list of technical assignments. Though companies can be garage-sized startups or enterprise empires, the paralyzing feeling of not knowing how to solve a problem is one size fits all.

I remember my first code assignment given to me by a senior developer was to find a SQL statement that was populating data in part of a program. Quicksand is deceptively plain! I opened the codebase and saw a beehive of modules, property files I didn’t understand, and file formats I hadn’t even seen before. I struggled hard my first weeks and learned to accept uncertainty. After a year of working, I figured out a strategy that made me feel confident about completing my work on time.

1. Follow the sage advice of Tay Money and ensure you understand the assignment. Within Agile development, you’ll have to review the upcoming tasks or “stories” that will be worked on, and you’ll be assigned stories to work on alone or with others. Ask for details if you don’t know what the story is asking you to do! You’re probably not the only one who’s confused. Sometimes even senior developers must clarify what problem a story is trying to solve. Luckily, there are a variety of people in an Agile team who can clarify the story for you: the product owner, a QA engineer, a fellow developer, etc.

2. Take time to figure out the true difficulty of a story. You may have no idea how to approach solving the problem. At least you understand what needs to be done now! Depending on the Agile team, you may be advised to create a “spike” to dedicate time to determining the difficulty of a story. The team doesn’t want you to wander off into the desert for 40 years. Instead, you can set aside dedicated time to complete a spike, and by the end you’ll feel confident that the story can be completed without a Biblical journey.

3. Agile teams have different strategies for assigning difficulty levels to stories. I’m used to a points system in which a story or spike’s difficulty ranges from 1-3 points. Generally, there will be a limit on the total number of points that an Agile team will take on in each sprint (I should mention that a sprint is a fixed period to complete stories that involves certain ceremonies). When pointing stories, be merciful with yourself and don’t point everything one point. Ambition is great until you realize you could only finish ¼ of the stories you were assigned for a sprint. I try to create a mental to do list of the tasks I can complete each day as part of a story, and I ask myself if these tasks realistically fit within the difficulty level I assigned.

4. Have a plan for how to approach solving a story before starting. If you don’t know how to even approach solving the problem, you’ll waste hours clicking around a repository in a state of despair. I used to click around different classes that seemed relevant to a story, hoping that I would serendipitously find myself with The Place that would be key to a solution. Alas, stories don’t resolve themselves as conveniently as romantic comedies (500 Days of Summer is my movie recommendation for today, by the way). Some ways to develop an approach to solving a story include asking another developer for advice, checking documentation, or taking advantage of debugging tools and client/server-side logging.

5. Being a hero isn’t about struggling alone for hours (or even days) with a problem. If you’re making constant progress on a story then that’s another matter, but there’s no reason to spend hours just trying to take the first step. Over time I learned to see myself as part of the team rather than an individual contributor. Would you want your teammate to silently struggle with a problem that you already know the answer to? This is especially important in a remote environment because nobody is there to notice you struggling. So, mention the code demons you’ve been fighting.

TLDR: understand, assess, assign difficulty, figure out how, and don’t be a tragic hero

I hope my mental checklist provides some ideas for your own problem-solving strategy. This post was something like a letter to my past self. When I first started working as a developer, I thought that writing code would be the big challenge to overcome. Instead, I spend most of my time understanding and debugging code. Without any problem-solving strategies I felt like Sisyphus trying to push my stories to production. Now, the struggle that remains is the challenge of constant learning.

Say hello and follow me on Twitter for more obscure pop culture references! @jahabeebs

I never loved the phrase “junior developer.” Junior evokes memories of little league baseball, a suboptimal grade level and perhaps even the esteemed Weenie Hut Jr’s (for the Gen Z crowd). It takes hard work to understand enough code to convince a company that you can make that API come to life when push comes to shove. Juniors are valuable! They’re brimming with career ambitions, they have something to prove, and they bring a fresh set of eyes to languishing legacy code.

When I first started working as a developer, I quickly realized that learning Spring Boot and data structures would take a back seat to a more important topic. I felt like I was dropped in a pit of quicksand and didn’t know how to navigate through my increasingly growing list of technical assignments. Though companies can be garage-sized startups or enterprise empires, the paralyzing feeling of not knowing how to solve a problem is one size fits all.

I remember my first code assignment given to me by a senior developer was to find a SQL statement that was populating data in part of a program. Quicksand is deceptively plain! I opened the codebase and saw a beehive of modules, property files I didn’t understand, and file formats I hadn’t even seen before. I struggled hard my first weeks and learned to accept uncertainty. After a year of working, I figured out a strategy that made me feel confident about completing my work on time.

1. Follow the sage advice of Tay Money and ensure you understand the assignment. Within Agile development, you’ll have to review the upcoming tasks or “stories” that will be worked on, and you’ll be assigned stories to work on alone or with others. Ask for details if you don’t know what the story is asking you to do! You’re probably not the only one who’s confused. Sometimes even senior developers must clarify what problem a story is trying to solve. Luckily, there are a variety of people in an Agile team who can clarify the story for you: the product owner, a QA engineer, a fellow developer, etc.

2. Take time to figure out the true difficulty of a story. You may have no idea how to approach solving the problem. At least you understand what needs to be done now! Depending on the Agile team, you may be advised to create a “spike” to dedicate time to determining the difficulty of a story. The team doesn’t want you to wander off into the desert for 40 years. Instead, you can set aside dedicated time to complete a spike, and by the end you’ll feel confident that the story can be completed without a Biblical journey.

3. Agile teams have different strategies for assigning difficulty levels to stories. I’m used to a points system in which a story or spike’s difficulty ranges from 1-3 points. Generally, there will be a limit on the total number of points that an Agile team will take on in each sprint (I should mention that a sprint is a fixed period to complete stories that involves certain ceremonies). When pointing stories, be merciful with yourself and don’t point everything one point. Ambition is great until you realize you could only finish ¼ of the stories you were assigned for a sprint. I try to create a mental to do list of the tasks I can complete each day as part of a story, and I ask myself if these tasks realistically fit within the difficulty level I assigned.

4. Have a plan for how to approach solving a story before starting. If you don’t know how to even approach solving the problem, you’ll waste hours clicking around a repository in a state of despair. I used to click around different classes that seemed relevant to a story, hoping that I would serendipitously find myself with The Place that would be key to a solution. Alas, stories don’t resolve themselves as conveniently as romantic comedies (500 Days of Summer is my movie recommendation for today, by the way). Some ways to develop an approach to solving a story include asking another developer for advice, checking documentation, or taking advantage of debugging tools and client/server-side logging.

5. Being a hero isn’t about struggling alone for hours (or even days) with a problem. If you’re making constant progress on a story then that’s another matter, but there’s no reason to spend hours just trying to take the first step. Over time I learned to see myself as part of the team rather than an individual contributor. Would you want your teammate to silently struggle with a problem that you already know the answer to? This is especially important in a remote environment because nobody is there to notice you struggling. So, mention the code demons you’ve been fighting.

TLDR: understand, assess, assign difficulty, figure out how, and don’t be a tragic hero

I hope my mental checklist provides some ideas for your own problem-solving strategy. This post was something like a letter to my past self. When I first started working as a developer, I thought that writing code would be the big challenge to overcome. Instead, I spend most of my time understanding and debugging code. Without any problem-solving strategies I felt like Sisyphus trying to push my stories to production. Now, the struggle that remains is the challenge of constant learning.

Say hello and follow me on Twitter for more obscure pop culture references! @jahabeebs