3 Things You Can Do to Improve as a Developer
cross posted to dev.to
We Solved It! But What did We Solve?
As developers, we are faced with complex problems daily. The good news is that we're problem solvers by nature. But what problem are we solving?
A solution to the wrong problem, however clever it may be, isn't solving the right problem.
It is our job as technologists to make sure we truly understand the problem so we can offer the appropriate help.
Not only is this a critical success factor for developers, but it is also a crucial part of being effective in Developer Relations.
So how do we identify and solve the problem? Here are three things you can do to target and answer the right problems.
Ask Questions
You have opinions. Sure, you know what you know. Your experience got you where you are, and that is incredibly valuable. Be proud!
Now, when someone asks you a question about technology, how do you answer? Does your opinion immediately come out? Are you sure you know what they are asking you? Is the question really what the person wants to know? Do you know why the person is asking this particular question?
OMG! That's a lot to think about! (yes, it is)
Imagine the following scenario playing out.
Them: What JavaScript framework should I use?
How would you answer? We could say React, Vue or Angular - but would we be helping that person? Maybe. Why are they asking this question? Let's imagine this is how the conversation goes if you ask "why."
You: Why do you ask that?
Them: After using gobbledeegook.js (yes, I made that up) before, my team members are torn on which newer framework one for our new project.
You: Why are you considering switching?
Them: We know gobbledeegook.js well, but we hear the others are all better.
You: How do you classify better? What's wrong with what you are using now?
Them: Our current solution doesn't solve our problem. We need that.
You: What is that problem and why is it essential to your project?
Them: Because our current app is slow loading, and we want it to be under 2 seconds to load.
You: Why is it taking so long today?
OK, this is a bit of a fabricated story, but you get the idea. The original question was the result of a set of experiences that the person asking has acquired over time. In other words, they have a context that you do not have!
An excellent resource for this exercise is learning more about The 5 Whys
The good news is that you can gain that context by asking "why." Once you learn that context, you are much closer to being able to help the person asking the question truly. And sometimes, they even solve the problem while talking it out to you.
Ultimately, asking "why" leads you in a different direction that the original question might have led you.
If you are working in Developer Relations, this type of deep insight can be invaluable in providing product feedback and helping the customer.
Listen and Observe
While listening sounds quite simple, in practice it can be difficult. OK, don't make that scrunched up face at me. Imagine you are helping someone write code. You're looking at their laptop as they type and you see them doing it a different way than you would. They didn't define that function before using it. Now they move on to another set of code that gathers user input. Why aren't they fixing that function? Now they are writing a Dockerfile and hard coding environment variables. This is bugging you. Do you stop them and jump in? What do you do?
Carefully observing how someone works and solves problems can be one of the most illuminating ways to learn. There are reasons why we all approach things the way we do. If our goal is to help people solve problems, we must first understand how they are thinking. Consider what is going through their minds.
We can watch, listen, and ask open questions such as
- Where do you want your docker container to run?
- How will you test your function?
- How will the user know what to do when this event occurs in your app?
Notice these questions don't precipitate a yes or no answer. Instead, they are intended to provoke the other person to share their thoughts on why and how they are thinking. Armed with this knowledge, we can then learn common patterns in how they work and solve problems.
Maybe, just maybe, we can turn this learning into feedback for our software and make it easier for them to come to a solution.
If someone bangs their head against the wall, it's not the wall's fault. We don't move the wall. Instead, we solve the problem that caused them to bang their heads.
The best way to learn why and how people solve problems is to really listen.
Seek to Help Actively
We are in a fantastic career field. Technologists struggle and solve problems every day, and we share these struggles and solutions with our colleagues. That's a community. A helpful community.
You may have heard something similar to this next statement before, so forgive me.
Don't provide a solution to a problem they don't have, find the problem they do have and craft a solution for that.
Once we understand and connect with people, this becomes much easier to do. And this has a great side effect of making all of us feel good inside.
What Next?
When you solve a problem, share it. Figure out what your preferred way to communicate is and own it. You may prefer writing, recording a video, creating tooling such as VS Code extension, creating OSS, or talking about it on a podcast. The way you share it is up to you.
All of this applies whether you are on a team in developing software, developer relations, or solving any technical problems.
When we ask questions, we listen, and we observe - then we can take that feedback and genuinely start to offer helpful solutions.
- How are you asking questions?
- How are you listening and observing?
- How are you seeking to help others?
Please share your thoughts.