If you have an interest in learning how to develop on the Android, iPhone or Windows Mobile platforms then you may want to check out the CINNUG Mobile Firestarter event on April 24th.  To help show you the differences between the platforms we have the presenters all creating a simple tip calculator application from the ground up.  You’ll be able to see the tools and techniques used to create simple mobile applications on each platform.

You can find more information and a link to the registration over on the CINNUG special events page.

On Tuesday, March 9th, nPlus1 will be holding an ArcSummit in Indianapolis.  The focus topic for this summit will be the SOLID software design principles.  We only have a few slots left, so if you are interested, please get registered soon!  You can register at https://www.clicktoattend.com/invitation.aspx?code=145609.

Dan Rigsby and I will be presenting the content.  The afternoon will be spent with presentations on each of the 5 principles and then an open discussion at the end of the day.

This last week I spoke at the KY .NET Developers Association in Louisville, KY.  They meet at the Duthie Center for Engineering on the University of Louisville campus.  Before my talk the Chair of the J.B. Speed School of Engineering, Dr. Adel Elmaghraby, and Professor Rammohan Ragade gave me a tour of their new facilities.  The building is very nice, with lots of places for students to congregate.  What I found most impressive about the tour were the research projects that the students and faculty were involved with.  Check out some of the research projects they are working on.

They have a few people in their Multimedia Research lab working on technology using ground penetrating radar to detect landmines.  This is actively being used in Afghanistan by our military.  Also in this lab they were working on image recognition

In one of the labs they had “video wall” made up twenty plus monitors driven by nine computers working together to produce an image equivalent of 70+ megapixels.  Sadly, it wasn’t on while I was there. :)  They have other projects like data forensics they are working on with the FBI, projects that research the origin of a file in a peer to peer network, and analysis of network security and reliability.  In their graphics lab they were working on 3d graphics and had a set of clustered playstations! Some really cool stuff.

While pizza was being served before the talk I had a few minutes to chat with a student who, as a class project, is working on a team to build a black jack game that is played on a Microsoft Surface platform.  The game will use mobile devices to let a user have their “private” card view while the Surface displays the “public” cards on the table.  That’s a pretty neat project.

So, now I’m highly jealous of the things students are doing at the University of Louisville.  They seem to have a great program there for computer science that covers a lot of the foundations of computer science with a lot of opportunities to work on some fun and interesting projects.

I have to thank Jeremy Sublett, Chad Campbell and Brian Carter (the leaders of the group) for having me down.

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.

__________

 

So, have you decided if you should be a plumber or not?  Previously I said that I agree that “Don’t be a Plumber” is very sound advice, but I think there are times when you will just have to play that role as a developer. 

On what appears on the surface to be a complete counter view to Brian Prince’s “Don’t be a Plumber” advice, Leon Gersing posted his own thoughts about why don't be a Plumber is horrible advice (read the comments to his post… interesting stuff).  What I took from Leon’s post is:

• Don’t assume that it can’t be done better.
• If everyone is not a plumber, then there will be no innovations, no new frameworks.

In Leon’s post he uses Nate Kohari as an example of someone who wanted to create an alternative dependency injection framework and not just use an existing framework like Spring.NET (If you haven’t looked at what Nate created with Ninject, you should).  What I take away from Leon’s statement is that Nate saw a different way to tackle a problem and became a plumber, creating Ninject in the process.  This is an awesome thing because now we have more options when it comes to a dependency injection framework.  If there weren’t plumbers in the world, then we would all be writing a lot more code.  I completely agree with this viewpoint, but at the same time when you are working on projects for a business who specializes in Tax calculations, should you really be spending time generating your own dependency injection framework?  If you can’t find one that fits your needs, then perhaps, but make sure the choice to do so is in the best interest of the project.

So, I’ve concluded that while for the most part you should not be a plumber in the sense that you are writing a lot of plumbing code, but you may need to roll up your sleeves and get dirty from time to time if you don’t find something that fits your needs.

 

Finding the Right Pipes

In a comment to my previous post Maggie Longshore takes a different approach to the analogy.  She states:

“If you think of plumbers as the ones that choose the right pipes, design how to network them and seal them from leaks then we should be plumbers. Occasionally a plumber may need to fashion a custom pipe, but they try not to make it the norm.”

As I discussed in Being a Researcher, you’ll need to know how to select a good framework or component for your needs.  Given Maggie’s take on the analogy that means being able to select the right pipes.  Choosing the right one will mean less work on your end for the plumbing it is responsible for.  If the framework you choose doesn’t meet your needs then you may find yourself having to code around its short comings or doing a lot of extra work. 

About a year ago I was between client engagements so I took some time to compare Spring.NET and Unity as two inversion of control containers.  My goal was not discover which was “better”, but more to understand their differences.  I wasn’t working on a project so my investigation was more about how they worked, what their features were and how they compared to one another.  I created a series of unit tests that tested the features of each so that I could see how they accomplished similar tasks.  I have to be honest and say I didn’t get too far into this before I was back on another project, but the exercise gave me a better understanding of the two frameworks and their capabilities. 

My tip for choosing the “right pipe” is to check out several options and compare them from time to time.  Keep an eye on what frameworks and helpers are in the ecosystem.  If you haven’t already, check out various ORM frameworks, logging frameworks, dependency injection frameworks, etc.  You don’t have to spend days on this, just get the latest drop of them and put together a simple “hello world” application with them.  Most of these will have a small tutorial or sample you can try to get a feel for how they work.  Understanding their differences, but more importantly just what is available, will put you in a better position to know which framework will work best for you on a project, or if you’ll have to be a plumber yourself for a while.

 

Don’t be Afraid To Look Under the Hood

In one of the comments to Leon’s post, Ben Von Handorf makes the statement that junior developers rely so much on the framework that they don’t understand what’s going on under the hood to the point that they get lost when something breaks.  I’ve seen this too and I believe it is a symptom of taking the “Don’t be a Plumber” advice a little too far.  One of the reasons I advocate researching the various frameworks is so that you are familiar with how they work.  If something breaks or isn’t handled the way you expect you need to be capable of digging into the code of the framework to find out why.  Understanding how the framework is built and what it is built upon will help you troubleshoot issues or understand how best to use that framework. 

Here’s some homework for you: go grab the code for the most recent framework you used and walk through it.  See how it operates and understand how it works.  Can you think of a few ways to improve it?  If so, share those ideas with the creators of the framework, or if it is an open source project, submit your improvements as patches! 

 

Be Wary of the Not Invented Here Syndrome

On the complete opposite end of the spectrum from “Don’t be a Plumber” is the "Not Invented Here Syndrome”.  This productivity killing disease often manifests itself in the form of developers deciding that they must write everything themselves.  One of their favorite arguments is “If I code it I know how it works and it will be easier for me to maintain.”  Another is “it’s just not that hard to write X.  I can do that in a day and we’ll save money not buying a component.” 

Here’s a great example: let’s say there was a project that had a requirement for a printed page from the application.  This wasn’t really an in-depth report or anything like that, just a simple page of information printed.  Instead of using a reporting control or package, the developer decided to write his own.  How hard could it be?  He just needed to build up a string and then push it to the printer right?  On the face this is really simple, but once he got into having to write code that needed to center the text on the page, deal with margins, pad data or even left justify it became a lot more work.  What took him a few days to produce could have been done in a few hours with a reporting package.  He thought he was saving money by not getting a reporting package, but if you add up his hourly rate and how long he took on getting the code right I’ll bet he came out on the more expensive side.

 

Conclusion

To be a good developer you will need to be comfortable getting into some plumbing code when necessary, but for the most part you should be selecting tools to help you concentrate on the code that really matters for your solutions (what you are really trying to solve).  You should understand how plumbing works, but not necessarily be ripping out or installing new plumbing on every project.  Don't be a plumber, but know when you need to implement something better!

Next up in the series will be a role that I find very hard – Being a Salesperson.

Previous Posts in this series:

• 0 – Stop Being a Code Monkey (Intro)
• 1 – Being a Student
• 1.5 – Being a Student – Tips
• 2 – Being a Janitor
• 2.5 – Being a Janitor – Tips
• 3 – Being a Researcher
• 3.5 – Being a Researcher – Tips
• 4 – Being a Plumber

I'll be speaking tomorrow night at the KY .NET Developer's Association in Louisville.  The topic of the presentation will be my "Be a Better Developer" talk, which is the lecture version of my blog series of the same name.  If you are in the Louisville area and are interested, please stop by.  The meeting will at University of Louisville Campus, Duthie Center for Engineering, Room 121 starting at 5:30 PM.

 

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.

__________

 

“To be or not to be -- that is the question.” 
– William Shakespeare, Hamlet

 

“Don’t be a Plumber”: I’ve heard this many times from several people.  I believe it originated from Brian Prince as he left one stage of his career and moved on to a position at Microsoft as an Evangelist (listen to an MP3 of Brian discussing this in his Career series). 

To get started, I want to define “plumbing” as it pertains to our field.  Plumbing is that code that has to be there, but isn’t the purpose of the application.  A great example are data access layers.  Let’s say we are writing a Tax calculation component.  The purpose of the code is to crunch numbers and provide a result; however, we must include code to read data from lookup tables based on the user’s zip code for instance.  Clearly the data access is required, but it’s not what makes the application different than any other.  What is more important are the algorithms we choose for the calculations and how the user interacts with the application.  In this case I would call the data access code plumbing. 

In the tax calculator example above, we could write the data access code by hand (in .NET that would mean straight ADO.NET code), or we can choose to select an Object Relational Mapper (ORM) framework to get that data for us and relieve us from having to write all that plumbing code.  This is really the point that Brian is making in his statement, Don’t be a Plumber.  He is suggesting that if there are frameworks that meet your needs for your application infrastructure to do data access, logging, etc., then don’t spend your time writing that.  Instead, focus on the parts of the application that differentiate your application from the gazillion other tax calculators (or whatever your building). 

Besides not spending your efforts writing this redundant, and often boiler plate, infrastructure code by choosing a framework you will also benefit from innovations to the framework you choose.  Brian makes a good point that if you choose a framework with a vibrant ecosystem (either open source or 3rd party commercial) you will benefit from other people endeavoring to make that framework better.  For example, in the .NET world nHibernate is a very popular ORM.  There are new features and continuing development for nHibernate going on, which means other people are focused on making that tool a great ORM.  Let them do that, and you focus on making a great tax calculator.  I think Brian makes a great statement by saying, “Only write the code that only You can write”.

Don’t be a plumber is very sound advice.

So all that sounds good, right?  From those points it’s hard to see why anyone would want to be a plumber at all.  I mean, if not being a plumber means I can A) do less work and B) focus on making my tax calculator the best one out there then how in the world can following this advice be bad?  Well, notice how I slipped in the phrasing, “frameworks that meet your needs for your application…”.  Well, it turns out that little tidbit is very important.  It can be interpreted to mean that it does what you need it to, but it can also be interpreted to mean it does things how you need/want it to as well. 

So, from everything I typed so far it seems I’m saying that to be a good developer you should NOT be a Plumber.  That’s contradictory to the title of the post, “Being a Plumber”.  So should you be a plumber or not?  To be or not to be.  In my next post in this series I’ll provide a counter viewpoint (as well as point a few others who have done the same) and give you some tips on what to do if you have to roll up your sleeves and get out your plumbing tools.

 

Previous Posts in this series:

• 0 – Stop Being a Code Monkey (Intro)
• 1 – Being a Student
• 1.5 – Being a Student – Tips
• 2 – Being a Janitor
• 2.5 – Being a Janitor – Tips
• 3 – Being a Researcher
• 3.5 – Being a Researcher - Tips

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 ¹. 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:

• 0 – Stop Being a Code Monkey (Intro)
• 1 – Being a Student
• 1.5 – Being a Student – Tips
• 2 – Being a Janitor
• 2.5 – Being a Janitor – Tips
• 3 – Being a Researcher

 

¹ 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.

It’s not often that someone like Ballmer is out our way, but he’ll be in Nashville, TN on January 20th.  This is a free event and will be a “Lap Around PDC 2010”. 

Check out more information the CINNUG web site (registration links is provided there).

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:

• 0 – Stop Being a Code Monkey (Intro)
• 1 – Being a Student
• 1.5 – Being a Student – Tips
• 2 – Being a Janitor
• 2.5 – Being a Janitor - Tips

I noticed the following downloads on the MS Downloads RSS feed and thought they might come in handy one day.  If you do a lot of PowerShell you might want to get these help files to see if you can utilize some of their functionality.

 

PowerShell Help Files for:

• Office Web Apps
• Search Server 2010 Express
• SharePoint Foundation 2010
• Project Server 2010
• SharePoint Server 2010

 

I’m mainly posting them here so I can find them again later.