Be a Better Developer: 3 – Being a Researcher - Tips

January 21, 2010 (Last Modified: January 21, 2010)

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.

In the last post of the series I covered some reasons why being a researcher is an important part of being a good developer. You have to be able to research new technologies or components to understand if they are a good fit for your solution. You also need to be able to dig into issues, bugs and “code improvement opportunities” to learn how to correct problems. Both of these require you to be a good researcher.

There is No Such Thing as a Stupid Question (Google-Fu)

Have you heard this statement before? I have; a lot. I’d like to amend it though by adding, “unless you haven’t at least run it through a search engine yet.” Constantly I find that people won’t even take the time to copy and paste an error message into a search engine before they post to a forum, send off an email or go bug another developer. Part of being more than a code monkey is doing a little thinking on your own. As a developer you need to hone your problem solving skills and become a better researcher. At least learn to ask the right questions. It’s one thing to go to another developer for help (which I encourage); it’s quite another to do so without even attempting to find the answer with a quick search.

Joe Stagner, self titled Misfit Geek from Microsoft, tells a story about getting just tons and tons of questions via email. Many of which he responds to by sending a screenshot of a search result with their question typed in, almost verbatim, and the answer being the first result. There is even a site called, “Let me Google that for you”, so that you can send a poignant response to people who do this to you.

A friend of mine uses the phrase “Google-Fu” (sorry, Bing-fu just doesn’t sound right). It’s the art of using search engines to find what you need. This includes learning how to force the engine to search for exact phrasing, constraining to a specific site or date range, etc. Most of the major engines have some advanced syntax you can learn and as a developer you really need to be familiar with the options.

Bing: Advanced Search Options

Google: Advanced Search Tips

There are even some sites already designed to help constrain your searching. For example, http://searchdotnet.com is a custom search site (using Google) that searches a specific set of well-respected sites in the .NET community. The site is managed by industry luminary Dan Appleman. I’m sure if you look around you’ll find similar sites for Java, PHP, and other technology stacks. If not, create your own. They’re free (Google Custom Search, Bing Custom Search).

Collect, Organize and Record

As you are researching you’ll hopefully come across mass amounts of data and information about whatever it is you are trying to investigate. You’ll need some way to gather this information into a format that makes sense to you. If you are collecting this information to determine which component to use in your upcoming project you may need to have some sort of comparison chart of the different options you explored. If you are doing investigations on a new technology you may want to have a record of useful resource sites that helped you get a good grasp of the capabilities and usage. Just finding all of the information is half the work, organizing it and analyzing it still has to be completed as well.

One of the comments on the last post asked what tools I used to collect my thoughts as I do research. I will delve more into tools later in the series, but to answer the question you can use just about anything and I highly suggest trying different tools until you find something that works (then try some more). I have been using Microsoft OneNote recently to capture snippets from the web, links and images. Just about anything. I use it much like I would a traditional notebook. I also use Mindjet MindManager to create mind maps for specific topics I want to brainstorm on. The mind map format allows me to quickly link thoughts and organize the information. Technically, both of these applications could serve the same purpose, but I’ve found that for straight notes and gathering actual data, OneNote is easier for me to work in. For gathering disparate thoughts, outlining a presentation or brainstorming, mind mapping works best for me. For example, when I originally put together the Be a Better Developer presentation I started with a mind map of what I wanted to cover, then as the outline and order flow started to gel, I moved to using OneNote to record the information, slides and facts I wanted to include (linking to the notes from the mind map).

The tools I’ve mentioned are just two among thousands. There is The Brain, EverNote, Free Mind and metric ton of others that may work for you better. Some are free, some are pay. In the end, the tool is just a means to collect and organize the data. The habit I’d like to see developer’s nurture is the actual research and analysis. Focus on the goal of produce good results from your research and find a tool that facilitates that goal while working well with your research style.

Combating Thrashing and Time Loss

In the last post I talked about one of the worst habits that developers can have: thrashing. Thrashing is where we just throw ourselves against some problem over and over, spending countless hours trying to find the solution on our own. In my opinion thrashing is a habit in that we keep doing it, even though each time after a thrashing event is over we realize how badly it affected us. We don’t look for it, we just fall into it. We get wrapped up in the problem, getting sucked in. Much like any bad habit thrashing takes something from us: Time.

So how do we overcome this habit? By using Time to our advantage. One of the best skills I’ve seen in good developers is the ability to time box. Time boxing reduces thrashing and helps keep priorities in focus. Justin Kohnen made a reference to this in his comment on my last post as advice he was given from Jim Holmes. If you come across a problem and can’t resolve it right away set a time limit that you’ll spend trying to figure it out on your own (apply thought and a healthy dose of Google-Fu to the problem). Create an alert on your computer that will sound when the time limit passes, or set your alarm on your watch/phone/robot. Don’t just mentally keep track, because that’s a symptom of thrashing that was already affecting you … getting wrapped up in the problem and losing track of time.

When the time passes and the alarm goes off resist the urge to keep trying something different. Stop what you are doing and get someone’s help. Go to your fellow developers, your dev lead or even Twitter if you have to. If you have to explain what you are doing and what you’ve tried then it forces you to walk through all the facts as you know them. Sometimes that’s all you need in order to trigger the answer. Also, when working on a problem, document in some manner each of the steps you’ve tried in order to solve the issue. That helps when you go talk to others about the problem. It doesn’t have to be a detailed step by step list, but at least enough so that you can talk through what you’ve tried and what you haven’t.

You can use time boxing in many different scenarios. I’ve used it to time box design discussions, requirements review, meetings agenda items, etc. At the end of the time limit you determine if you need more time on the subject (which may mean scheduling another meeting) or if you have beaten the topic to death. In the case where you need more time, then it’s acceptable to reset the time limit and keep going as long as the group concurs that it won’t be a waste of time.

Since we are talking about time boxing I’ll bring up the Pomodoro Technique. This is using time boxing to the extreme so that you don’t just use it for problems, but for all of your tasks to create a focused goal. I recommend looking into the Pomodoro technique to see if it can help you not only to keep from thrashing, but also to keep you on task and focused. I’ll talk about other organizational tips later in the series as well.

Dive Into Code, Head First if You Can.

“Reading others code is a good way to become a better developer. And it’s more fun when you read it aloud in the style of slam poetry.” – A tweet by Phil Haack.

While I can’t make a comment regarding the entertainment value reading code in slam poetry, I can definitely concur that reading code written by others will make you a better developer. It doesn’t matter how experienced you are as a coder, looking at other people’s code will help you in some manner. If you are a new developer the foray into a more experienced coder’s codebase may expose you to knew techniques and idioms. As an experienced coder looking through another code base can help you hone your own skills in finding code smells and seeing approaches that just don’t work (of course, even the most experienced coder can learn something new just like a new developer).

Scott Hanselman has a blog series called the Weekly Source Code. In that series he looks at open source and code freely found in the internet to see how other people code things. This can be a great learning tool. It may just expose you to a technique you were familiar with or introduce you to a technology stack you are are learning. It’s also a great way to pick up on coding styles you like and don’t like.

In addition to learning new patterns and approaches by looking through code that isn’t yours, you’ll also learn to get around in code easier. Most advanced IDEs have some mechanisms of navigating code and you should learn to them. For example, Visual Studio has commands to go to the definition of a variable/class, or return to the last changed line. Plug-ins such as Resharper and CodeRush can also help provide ways of navigating code easier (the marker feature in CodeRush is one of my favorite ways of getting around code and back to where I left off). Learn tricks like setting book marks, splitting the code screen so you can see two portions of the same file at once, etc. All this gives you the power to move through code better.

I believe the faster you can move around in code and the more code you are exposed to the better developer you’ll become. As you learn the new idioms and patterns you’ll use them in your own solutions (just make sure they are appropriate). As you see approaches that have failed in other solutions and understand why, you’ll be able to make better assessments and decisions in your own solutions. As you learn to move through code better you’ll find that your development time will become more productive. While this alone won’t make you a good developer, it will, in my opinion, make you a better, more informed developer.

Learn how to really dig into code. There are times that the frameworks we use simply don’t behave the way we expect, or when we are tracking down a bug you have to really work to find it. There’s no better documentation than the code, because it says exactly what the application is doing at all times. Learn to get really good with using the debugger and tools like ILDasm and .NET Reflector 1. The good developers I’ve met can whittle down the probable causes of issues and then delve deep into the code and come up with the reason for the errant behavior. Learning to dig through code will help you root out problems, as well as expose you to more code.

So where can you get code to look through? Thankfully, it’s all over the place. Check out Source Forge, Git Hub, Google Code and Codeplex for thousands of open source applications to look through (and while you’re at it, why not contribute to one?). If you have a developer in your company that you think is particularly good, go into the source control system and look at their code. See how they approach problems and then talk to them about it.

Conclusion

Being a researcher is not just about finding the data, it’s about learning from it and acting on it. You will find that learning good research techniques will make you a better developer, as well as becoming a wealth of knowledge for many things. If you can research a technology or problem and provide a thorough explanation and summary of the item in question you will have one more desired asset that sets you apart from the code monkeys.

Next up in the series, being a Plumber. Yeah, that one might draw some comments. :)

Previous Posts in this series:

1 Some people would say that if you have to resort to a debugger you’ve failed. I don’t agree with that. While I don’t use the debugger all that often when coding I have no problem resorting to it when necessary, especially if the code base isn’t mine and I’m just learning how the code works together.