A Live Developer Journal

Advice For Struggling Devs

Table of Contents


Being a developer is incredible. We get to imagine and build things that delight, inspire and solve real-world problems on a huge scale. We are real-life superheros. Yes, that means you too, you magical person you.

As the cliché goes, with great power comes great responsibility, and with that responsibility comes the ever-present risk of burnout, depression, anxiety and more. All because we care so much that we are constantly driving ourselves to become better and better.

It's a catch 22, but we can't help others when we are paralyzed by imposter syndrome, burnout and depression. We have to put our oxygen mask on first, and then keep it on, every single day.

Throughout this article, you will learn about some of the most common struggles that developers face, and how to deal with them based on advice from experienced developers, plus a few tried and tested strategies that have proven effective.

At the end of this article, you will find a harness your strengths and weaknesses action plan that helps you leverage your strengths and systematically overcome your obstacles, so that you can rocket forward on your happy and healthy developer journey.

Skip to Action Plan

What Are Some Common Developer Struggles?

Every developer struggles from time to time, no matter how experienced we are. Often, we can be afraid to share our struggles, especially when we are used to thinking through and solving problems for a living. It can be hard to admit that we don't know how to get past our own blockers. This is totally normal, which is something I have learned from being open about my experiences with some of the following common struggles that developers face:

Advice From Experienced Devs

Try Combinations Of Pieces

Me: I don't know how to solve problems as elegantly as you can, it's hard to just keep shooting in the dark when I don't know if I'm heading in the right direction.

A: If you think about kids learning language, they’ll experiment with the building blocks and they’ll come up with amusing constructs that are understandable but not ideal. We gently correct them, even though we understand them, because those amusing constructs have rough edges that will make things harder in the real world.

When I’m observing you performing something that I am skilled in, there are things that I can see that you can’t. I might know that two pieces don’t fit together well because I’ve tried those pieces in the past, but I couldn’t tell you in advance not to use those two pieces because I didn’t know until you started putting them together that that was a pattern you were going to try.

I’ve tried many, many thousands of combinations of pieces, and when I say “those bits don’t fit well”, I don’t mean “those bits don’t fit at all”, because we can make things fit together by adding supporting monstrosities around them (like the high rise slums). What I’m trying to get at is “there’s a Japanese joinery solution for the thing that you’re trying to force together with glue, rope, and nails; and the joinery version will be easier to change later because it’s not all gummed up with glue, rope, and nails”

And while I’d love to give you a curriculum, a specific map for how to achieve everything you want to, I’m afraid that I literally have no idea how to do that. Every single person that I have coached or mentored over the years, I have done it by watching them try to put pieces together and telling them whether I think it will work or not.

Sometimes, someone might put together two pieces in a way I’ve never seen before, and I’ll say “I have no idea if those pieces will fit, let’s explore”.

But typically the learning process is "A, will these two pieces fit together?” “No, they don’t quite match”

“OK, what about these two?” “Those are better, but you probably want to try these two”

Until eventually, the other person is asking whether two pieces will fit and they’re usually getting “Yes” answers.

But there’s no test, no right answers, it’s randomly trying bits with each other until we learn which bits fit well together and which bits don’t.

You Get Better At Recognising Pieces And Shapes

Me: I can't even write simple programs.

What I’m observing with your frustrations is that when you say “I can’t even write simple programs”, it’s because you don’t know:

  1. Which pieces are available to you, and
  2. How the pieces fit together.

My advice to you is to look around and try to find as many pieces as you can… As you find more pieces, you’ll begin to understand what pieces look like and it’ll be easier to find new ones. Play with the pieces that you already have, and I’ll try and steer you away from combinations that will require you to use too much supporting infrastructure to hold them together.

Reading design patterns shows you, not only some examples of small pieces, but also some examples of small pieces assembled into larger shapes, and gives some reasons about why we might want those shapes.

As you get better at recognising pieces and shapes, you also get better at recognising glue, rope, and nails. So code that used to look ok to you, you begin to see that it’s actually not that great and is not well held together. So then, you can identify bad code, not because you know what the good code will look like, but because you can see that there’s too much glue involved.

I think that’s what Ward Cunningham was getting at when he talked about clean code and elegant code. Clean code is using the absolute minimum of glue… everything that’s there needs to be there. Elegant code is the Japanese joinery… there is no need for glue, it was designed to create this shape.

Perfection is achieved, not when there’s nothing left to add, but when there’s nothing left to take away. - Antoine de Saint-Exupery

Learn A Little, Do A Little

Me: I'm completely overwhelmed with programming right now. I'm really trying to learn Test-driven development, object-oriented programming and design patterns plus a bunch of other things, but am really struggling...[]

K: Sounds like you are taking a deeply thoughtful approach to learning programming. A mistake I frequently make (in programming and [hobby], for example) is thinking too much and doing too little. All that theory jumbles up my brain so I can't act without second guessing myself eight different ways.

What I have learned is that I can't learn it all. I can't even learn most of it right away. If I learn a little, do a little, learn a little, and do a little then I maximize my learning and reduce anxiety.

Regarding your pair seeing stuff you don't see: that's what's supposed to happen.

Nobody understands everything and yet they get stuff done. The same is true of you. Cut yourself some slack. And code.

Accept that your contribution will be small at first. I started out just pointing out to my first mentor where his parentheses didn't balance. I was already useful and I was around enough to start to see the bigger patterns at work.

Another technique is to take something you worked on together and try to reproduce a small version on your own. Whether you succeed or fail doesn't matter, but where you get stuck is valuable feedback about what to learn next.

Good luck.

More Helpful Strategies

Live Documenting Your Work

Live documenting your work is extremely helpful. I think that it's the single most important habit for any developer to adopt for many reasons:

screenshot of my live developer journal homepage.

Feedback Into Action Plans

Many of us are afraid of getting feedback for our work, in case it highlights silly mistakes or shows us to have less experience. These thoughts are often coupled with imposter syndrome and perfectionism. The uncomfortable truth is that by hiding our raw process, we drastically slow down our progress, and so we have to suffer with not feeling good enough for far longer than we would have if we'd just gotten feedback in the first place. Think about it this way, we can't invent the best solutions for problems that we have no experience in solving.

Andy Palmer hilariously (and insightfully) compared learning how to be an exceptional programmer to a vocation known as chicken sexing, where your job is to try and identify the sex of a chicken. Apparently, it's really difficult to do this, and the only way to learn how is to pair with an experienced chicken sexer. Every time you make a guess as to what the chicken's sex is, you are told whether you are right or wrong. Over time, you build up an intuitive sense for which sex a chicken is, but you can't explain how you know to someone else (tacit knowledge), so the training process repeats itself.

Easy Wins

When you first start building a project, begin by asking yourself what is the absolute bare minimum needed to launch a working model of your system? Once you have built the bare minimum working version of the project, you can keep up momentum by identifying the next most important baby step to move your project forward. To do this, it is useful to ask the question: What is the next most important thing my project needs to provide for the user, from their point of view?

Once you have achieved your baby step task, celebrate it. Every Single. Time. You can celebrate your baby steps by ticking off your baby step and also writing a congratulatory message for yourself next to it. This will feel strange at first because many of us are quick to beat ourselves up for making mistakes but rarely praise ourselves when we do something right.

Easter Egg

Add an Easter egg to your project. An easter egg is an undocumented feature in a piece of software that included as a joke, or just for fun. For example, when you are waiting for a video to load or buffer on youtube, the load bar turns into a game of snake when you hit one of the directional keys (left, right, up, down).

The reason for adding an Easter egg to your code is to inject a little fun into your project. It’s something that will encourage you to open your project and start writing on it. Once you have written a small fun something for it then you are likely to be inspired to start working on it now that it is open and now that you are in a good mood after having played around a little.

Harness Your Strengths And Weaknesses Action Plan

Below is a set of downloadable worksheets for harnessing both your strengths and your weaknesses. You can download it by clicking the button below:

Download Action Plan
worksheets for harnessing your strengths and weaknesses, download button above image.

Next Steps challenge time

Your challenge for this article is to write down one example of something that is holding you back. Then, come up with one baby step that you can take right now that will bring you closer to overcoming that obstacle.

If you completed the challenge, high five for taking action! Bonus points if you leave a comment with the obstacle and tiny step forward you came up with! It could inspire another developer to do the same.