One Key to Growth: Seeking Out Discomfort
July 21, 2024
There are many newsletters, tips, and tools for growing as a software engineer these days. And I think that is great! In many ways, I wish I had found or had access to some of these amazing newsletters or creators when I first started my career.
But no matter what tips or tools or templates you have at your disposable, one tried and true idea remains:
Growth will always require getting uncomfortable.
One of the best illustrations for this idea is from a now famous idea from Rabbi Abraham Twerski:
The stimulus for the lobster to grow is that it feels uncomfortable
This idea applies to our careers. When we experience moments of discomfort (e.g., a stressful project, difficult coworkers, complex use cases), we can often use these as catalysts for growth that we might never have experienced otherwise.
In my experience, we can take this a bit further. We don’t have to wait for outside stress or a conflict with a coworker to grow. We can seek out, appropriately, areas of discomfort that can help us grow in our careers.
Flow State
If you haven’t heard of Flow state, it’s a remarkable phenomenon. The idea is that there is a certain mental state we can fall into in which we produce more in a few hours than we could have produced in a regular full day’s work. Imagine writing a whole application in a morning that would have normally taken a week. It’s pretty incredible.
Thankfully, getting into Flow has a bit of science to it. Part of that science concerns how challenging the work you are doing is.
The science of Flow says that you need work that is right at the edge of your ability for Flow to occur. From my experience, this is often work that is a bit uncomfortable and a bit of a stretch for my technical chops.
Okay—why do I bring up the Flow state? I bring it up because of what I often experience after a session of Flow. I often realize how much I’ve improved my skills on whatever I was working on. It wasn’t that I was merely doing the same things just faster or with more ease; I was improving.
When taken with the lobster metaphor from earlier, what this means is that we can seek out an appropriate amount of discomfort in areas we want to grow in and start to experience that growth sooner. Moreover it shows that the experience of improving might actually be more enjoyable (a benefit for Flow) than we might have thought.
Of course, the next question is, what are some appropriate levels of discomfort to seek out? Here are some places I’ve turned to recently (even in the past week!) to gather feedback.
Ask for Direct Feedback
We all know feedback is critical to our growth. Not only can feedback be hard to listen to, but it can also be hard to get apart from your manager. Waiting for a quarterly performance check-in or yearly review is not a fast enough loop to make the changes you need if you want to grow your career.
There are two core key categories to focus on
1. Technical
Whether it’s code, a design, or a technical document, ask for direct and specific feedback on your work around a particular topic you want to grow in. A great way to do this is to find an engineer who you 1) trust and 2) is at least one level already of you in the skill you are wanting to improve.
It’s important to be specific “Can you give feedback on how I’m designing this API to be resource-oriented” or “Can you help me see figure out how to word-smith this paragraph to be more clear?” is important. Asking for general feedback is great too, but if you want to grow in a specific area, you need feedback on that area directly.
In my own career, I remember a time when I asked a manager to give me much more thorough and pointed feedback on some of my technical documents several years ago. His feedback was instrumental in helping me learn to write clearer and amazingly shorter documents.
2. Interpersonal
This one is a bit tricky, but it’s important to remember that the best ideas or technical skills don’t mean much if you can’t communicate - and you’ll make it harder on yourself to communicate ideas to others if others don’t want to work with you. You need to find out if you are rubbing someone the wrong way and what you can do about it.
As I mentioned, this one is tricky, and everyone has different advice on how to go about it. I know many engineers advocate setting up 1:1s with other engineers (not managers) to maintain strong working relationships across their team and department. I know others who advocate for going through their manager for insight whenever conflict or tension arises. I’ve used both of these strategies too.
One tactic I’ve used that has worked well is to identify teammates that I trust and respect and ask them, “Would you be willing to give me feedback on how I could have improved this situation?” It’s a bit bold, and you will likely get more feedback than you bargained for, but I’ve always had a takeaway when I ask this question.
A good place to start, which I’ve also done, is to tell your manager, “I really want to grow in how I communicate and treat others in my day-to-day work. Would you be willing to help me pay close attention to my communication and give me pointers on communicating well?” I’m sure your manager will be ready and happy to do so.
Work on Complex Projects
A great way to find a place of discomfort that also has impact to your organization is volunteering to work on complex projects just outside of your current skill level.
Most organizations and teams have a hub where you can see upcoming planned work. Look through the list and identify some projects that sound interesting to you and that you are confident you’ll have to learn new skills to complete. Talk to your manager about what it might look like to get on one of those projects.
Another approach might be to see if you can join any working groups within your organization. Working groups are often a great way to meet other engineers across the organization while learning about a new category of technology or problem you might not have known about.
I know this sounds intimidating, and that’s okay! It is intimidating! It can be easy to think, “I don’t know how to contribute, so it seems silly to offer my help.” I’ve found, however, that any engineer who is eager to learn and help is often met by engineers who are eager to teach and grateful for the help.
If it still seems a bit too much for you (which is okay - remember we are targeting “appropriate discomfort”), a good first step is to talk to your manager or your team’s tech lead and say, “I’m trying to grow in my technical skills. Is there any work you think would be a good fit for me but still stretch my skills?” I’m sure they can help you find something.
Seek Out Cross-Team Work
Another great way to get feedback is not so much focused on specific skills or areas of growth as on different perspectives. A great way to do this is to work on cross-team efforts or initiatives.
Working on projects that span different teams (or even departments) can expose you to different types of leadership, different ways of working, and generally different focuses within the company. As you do, you’ll meet and build relationships that have a different vantage point on you and your work. Creating and maintaining these relationships can be a great place to get feedback on how you can improve (not to mention they will provide you with different perspectives on company changes or politics).
A great way to get feedback in this context is at the end of a project, asking one of the people you build some rapport with to give you any feedback about how you contributed to the project. As in the other scenarios, asking for specific areas can be helpful, but being a bit broader in this context can help since the whole point is a cross-team project will likely reveal new weaknesses (and strengths!) that you didn’t realize.
It’s also important to note that this is where some feedback can be the most “out of tune,” so be prepared to get surprising answers or even answers you might not agree with. Don’t invalidate their feedback or write it off; it’s still valuable feedback! Just know they haven’t worked with you as much as your immediate team, and the likelihood of intentions getting off or something being mischaracterized is higher.
Before wrapping up, it’s important to remember that our current level of work will radically influence where and how we look for areas of discomfort. We don’t grow linearly, and as we grow, we often find there are more areas to grow in than fewer, while also recognizing improvement looks much more like refining and honing rather than gaining new skills.
Many of the suggestions I’ve laid out here are ones that helped me grow from a mid-level engineer to a senior engineer. I believe they are applicable to other levels (junior to mid, senior to Staff, etc.), given proper thought and strategy on how to apply them. A simple one might be that “complex” at a junior level might mean something different than complex to a Staff (as it should!).
The core of this all is to say: don’t shy away from discomfort. Be thoughtful about where you want to grow, identify ways to get the feedback you need to spur that growth, and then don’t wait around - go get it!
Happy coding!
If you enjoyed this article, you should join my newsletter! Every other Tuesday, I send you tools, resources, and a new article to help you build great teams that build great software.
Dan Goslen is a software engineer, climber, and coffee drinker. He has spent 10 years writing software systems that range from monoliths to micro-services and everywhere in between. He's passionate about building great software teams that build great software. He currently works as a software engineer in Raleigh, NC where he lives with his wife and son.