Table of Contents
- What are common developer struggles?
- Advice From Experienced Devs
- More Helpful Strategies
- Harness Your Strengths And Weaknesses action plan
- Next Steps
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:
- Imposter Syndrome: causes you to doubt your abilities as a developer, and to worry that other people will come to think of you as a fraud.
- Perfectionism: is where you are so worried about writing faultless code, that you are not able to make progress on or even start your project.
- Lack of Motivation: is where you struggle to get yourself to work on something that you want to finish.
- Depression: can make you lose interest in programming, learning and life in general.
- Anxiety: can be a natural consequence of a constantly simulated mind, where you are always thinking about what can go wrong. This is compounded when you are building software that might have significant real-world consequences if problems are not caught in the development stage (which is normal and happens all the time).
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:
- Which pieces are available to you, and
- 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.
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:
- When you are working on a project, you make a lot of decisions that you won't remember later. Capturing why you chose to do something in a specific way will give a great insight into your thought processes.
- Much like capturing your workings out when solving math problems, a Live Developer Journal allows you to get more nuanced feedback on areas that would otherwise be lost in the process.
- When setting up a new project, you might find that you have to deviate from the documentation. Keeping a list of steps you had to take to set up your project, allows you to skip the headache of trying to untangle the documentation again next time. This saves you a great deal of time down the line.
- Any time you come across a problem and look for a solution on Stack Overflow or something, you can add it to a list of "Here's a problem I had" and "Here's how I solved it" with a link to the solution. The more experience you get, the more you will rely on this list of previously solved problems to fast-track your future builds.
- Your life developer journal is one heck of a resource for other people, and can end up being widely read by people who are looking to solve similar problems.
- A live developer journal allows you to explain how and why you built a project in a specific way, which is a huge advantage when it comes to interviews and pair programming sessions.
- A Live Developer Journal is a portfolio on steroids. You don't even need many completed projects, because there will be so much material that demonstrates your capabilities.
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.
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.
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:picture_as_pdf
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.