Be a Better Developer: 3 – Being a Researcher
This blog post is part of a larger series named “Be a Better Developer”. You can check out the intro, “Stop Being a Code Monkey” to get started from the beginning. Each post will have a link to the previous ones and a final summary post will contain links to all entries in the series.
Does this sound familiar? It’s 4:00 PM on a workday and your team lead comes by and says, “We’ve been thinking about how we are going to deal with feature XYZ. Bob says we should look at the 123 Framework, but John doesn’t like that idea. We need to know which one to choose. We meet tomorrow morning to make a final decision. Can you look into that for me?” Yeah, the only thing missing is the coffee cup and the patented Lumbergh, “ummm-yeah”.
I think most developers will notice that they spend a good amount of time researching things. Whether it’s reviewing products, comparing frameworks and components, or simply searching for some obscure syntax, we spend a lot of time looking into things. Researching IS a skill, and one that developers need to cultivate. We are often asked to do this research in limited time, so you’ll need to learn to prioritize and pick out what differences you need to research that will really let you make a good decision on if it’s a good fit.
Research also goes beyond finding information to use to make decisions for future work, it is also used to discover real answers to existing problems. Being a good researcher will also help you when you’re debugging or having a problem getting something to work. How many times have you been working on something and you know the solution is just one line of code away? There is some nuance to the API you’re missing, or some bit somewhere that needs to be flipped? You use your researching skills and scour the internet, you bang your head against the desk, you search through the help and the answer seems to be just on the other side of your grasp. You suddenly start to look like this guy:
How long did you let that go on? How long did your manager let it go on (or did they even know?).
This is called Thrashing. I’ve seen really good coders get stuck in this and I’m not immune either. We think that we almost have it, and will spend hours, or worse, days trying to get something to work. Sometimes how long we spend on an issue gets away from us and we don’t realize that we are slowly killing our timeline. After scope creep, thrashing is the number one killer of projects (oh, and 82% of statistics are made up on the spot).
To be a good developer you have to be a researcher.
Researching skills are essential to a good developer. You need to be able to find answers to all sorts of questions quickly and know where to look when you don’t know. To me, it’s not a matter of if you know everything, but that you know how to find out. In my next post in this series I’ll cover a few tips on how to get to the bottom what you’re looking into.
Previous Posts in this series: