I’ve heard the term “pain” thrown around the developer community quite a bit. This “pain” comes from the vast amount of learning every developer needs to do to evolve in an ever-changing technological landscape.
There are always new languages and patterns to learn and countless legacy systems which need to be integrated. Stretching one’s knowledge on all things related to software development can be mentally strenuous.
It’s hard for me to quantify what this “pain” is. Personally, I’d define it as the level of discomfort I feel while writing software. Over the past few weeks, I focused on what kind of events cause pain points during development. I organized each event into a few categories and noted what I would typically do to relieve each of these pain points.
Pain from Unknown Technology
Some pain can come from not knowing a technology. For example, I recently joined a project that was using quite a few Amazon Web Services. I had no prior experience with AWS, and I had a rough few weeks trying to connect these services together.
Using new technologies can feel like wandering into a dark room and bumping into obstacles as you learn the layout. My adventurous side wants to continue to explore and learn as I go. My rational side tells me that maybe I should study the layout of the room before darting into the unknown.
Using an unknown technology is a common pain point in my software development career, and it’s easy to spot. Typically, relieving this pain point is easy as well. I just need to research the new technology and start building a framework in my head for understanding it.
Even better than diving into research myself, I can ask someone about the unknown first. This always helps shape the direction of my research. While it’s tempting for me to go forward into the unknown alone, I’ve always had better success with another developer guiding me to the right places to research the topic.
Pain from Misused Technology
For me, it’s quite easy to admit that I won’t know something if it’s completely new. However, I found that it is easy to “think” I know something and move forward with improper knowledge of the technology. Not knowing how to use a piece of tech properly can cause pain. Typically, I’ll power through and not stop to think that just maybe there’s something I don’t know.
I like to compare this to my toddler. He’s two years old, so in his mind, he knows it all. When eating lunch, he knows that he can use a fork to pick up food and eat it. But sometimes, he’ll try to use the wrong end. It kind of works, but the blunt edge makes it difficult to stab chicken, and he can get frustrated.
I hate to admit it, but sometimes I’m no better than this when trying to use a library on my project. For example, when I was using C3 to build some fancy charts, I felt like I couldn’t get elements to line up as I expected. Some slightly more complex behaviors in the chart stretched my knowledge, and I definitely felt pain due to my inadequate understanding.
The worst part about this pain is that I didn’t know there was a way to alleviate it. If only I had asked someone about the problems I was trying to solve! For me (and I’m guessing I’m not the only one), it is tough to know what you don’t know. Even though I might feel some pain when I misuse a library, I have a tendency to keep my head down and power through.
Again, relieving this pain is as simple as asking for help from another developer. It’s just much more difficult to detect that you need to do so.
Pain from Edges of the Architecture
I often feel pain when I try to apply a particular piece of technology that is not supported yet. Libraries and other pieces of software I might write are built to solve a particular problem. But as I hit the edge cases of a problem space, using the library in its current state is a source of pain.
To continue the pattern of non-software analogies of these pain points, I recently bought a single-stage snowblower. Turns out it’s good at blowing snow, but not a wintery mix of snow and rain. It threw the slush a few inches. The machine just wasn’t built to deal with the heavy slush.
Resolving this sort of pain requires either investing more time in a particular piece of tech or adjusting the strategy of the solution (i.e., choosing a new library). When I ask and confirm the pain points I’m experiencing with another developer, I find myself making better decisions about whether to invest more time building out a tool to fit the edge case, or to defer to another tool.
Relieving the Pain
All of these sources of pain can usually be resolved in the same way: asking someone a question. Whenever I feel some discomfort when writing software, I try to talk through the pain I’m feeling with someone else. They’ll either have an answer for me or point me in the right direction to research a bit more.
Pain is a good data point for deciding when to ask someone else about the problem you are trying to solve. I try not to let pain discourage me when writing software. Instead, I remind myself that this is an opportunity to stretch my knowledge and utilize my teammates to learn a bit more about a technology.