On Reddit, in the /r/learnprogramming forum, there was a post that I wanted to highlight. The original poster is still in his junior phase and is experiencing the pain of the learning curve. He got stuck, and stayed stuck for three weeks. His anxiety in the post is about how he is failing and what is going to happen to him when his boss finds out. He is stressed about having taken on something too hard and not finishing it. I think he is looking at it wrong.
Let's take a look at why that is.
Project Management for Content Writers
Vewrite, project management tailored for writing teams, is launching soon. Make sure to sign up for the waitlist so that you can be notified when the product launches.
Check it outThere is a great channel on YouTube called Healthy Software Developer, and he recently posted a relevant video about whether having a DIY mentality can limit a developer’s growth. It partially covers the topic above and I recommend that you take a few minutes to watch it if you feel like your path to being a better dev is blocked.
His core message is parallel to one that I’ve thought about a lot recently: how we teach kids to be is how they are as adults. I have three young kids (5, 9, and 11) and I spend an inordinate amount of time trying to guide them towards being the people that I know they can be. For the most part it isn’t about specifically pushing them to be engineers, scientists, or doctors.
To my mind, my job as a parent is about teaching them to be thoughtful, organized, present, and, of course, how to ask for help.
With a focus on individualism, we lose something that is critically important when we do not understand that we can not exist as atomic entities. We are all part of something bigger and our best selves pass through those that support us. It took me a really long time to internalize that because I really wanted to stand on my own and shine. It never occurred to me that I would shine brighter if other people helped me to do so.
Every blocker is a learning opportunity
I think that every developer that is passionate about their job because, at its core, development is about puzzles.
Recently, I described development to my wife by saying, “imagine you get to create really hard puzzles, and then spend time solving them.” That’s what programming is, and for some people it is like a drug. It’s self-perpetuating and can be intoxicating. These puzzles become something that we own, and it can be hard to let others play with them, too. It can be hard to let them go.
Every time that you get stuck, what you are really experiencing is a learning curve. It’s a bump in the road and with enough perseverance, you can overcome it. For those that learn this, there is some measure of solace in the knowledge that if they just keep going, eventually there will be a break in the code clouds and they will be enlightened. For me, this is how I learn. I’m stubborn and I keep going until I get it. Sometimes it takes a long time, but that’s OK by me.
But, and this is important, I’d probably be a better developer today if I spent more time earlier in my career asking for help. I often think about the absolutely excellent developers that I’ve had the pleasure of working with, and I regret not bringing more problems to them for us to solve together. The truth is that a lot of the value there wouldn’t have just been that specific problem that I was trying to tackle. It would have been in getting a better view into how those seasoned professionals handled those types of problems, how they would have broken things down, and how they would have built solutions.
Those times where I spent a week being blocked could have been life-changing learning opportunities from smart, successful people deep in their careers.
What a waste.
When to ask for help
Sometimes you create puzzles that don’t fit your constraints. Time and resources often limit what is solvable. More often than not a component of this is knowledge and experience. When you take something on, you don’t really know what the solution is going to be exactly. You poke and prod it, find its edges, and fill in the gaps until you have some clear picture of what kind of puzzle you’re looking at. The less experience you have in a specific domain, the longer this process is going to take.
That’s just the nature of learning as you go, and that’s mostly what development is.
In a private context, as with most of the development that I do, that’s OK. Things take as long as they take, and the point is to accrue knowledge and develop ideas into products that others can use.
In a professional context, this can be problematic. As we’ve talked about before, there is balance that must be struck within a company that allows developers some freedom to be creative, while also ensuring that management has visibility so that they can make informed decisions about their business.
This means that you have to set limits on how long you spend trying to succeed on your own before reaching out to your teammates to ask for assistance. This is one of the basic principles of Agile development: blockers should be exposed early so that the team can tackle them together. In fact, it’s one of the few things that I think that Agile development gets really right. In a company we act as a pool of knowledge about a business and a code-base. If the answer doesn’t exist in your head, it is likely to exist in someone else’s. Take advantage of that and you will be a better developer.
The individualist developer will often spend too long being stuck and this will negatively impact both the software product he is working on, and the business that pays his salary.
The right time to ask for help is earlier, rather than later. Use your judgment. When in doubt, ask for help.
Your ego will limit you if you let it
Throughout our lives we are taught that individual success is a measured quantity that defines who we are. In school you are measured not by your class' success, but by your individual success. You are graded on whether you learned what you were supposed to.
We teach kids that who they are is tied to whether or not they can succeed as individuals. The problem is that this is not a good reflection of how the world actually works. I am nobody without my wife's support. I am nobody without my friends. I am nobody without the knowledge of the group that I work within.
Successful software is not about you and the puzzles you can solve.
Asking for help is a core skill. It can help ensure that the product you are building sees the light of day, and more importantly, it can ensure that you continue to progress as a developer.