"Software Tools You Should Be Using and Blogs You Should Be Reading"

I've read so many Dugg and Kicked articles about "Top 10 Tools" or "Top 10 Blogs", etc. that you should be using and probably aren't.  Every time I read one I think, what makes that person the authority on this topic and what research did they do to determine that yes, in fact these are the top 10 tools or blogs?  But ultimately it's just a title that is meant to draw your attention to tell you what tools that person or team is using or blogs they read.  And who knows, you may even find a tool or blog that you've never heard of but is just the one you've been looking for.

However, there's a problem with these articles.  There's a huge portion ("huge" added for dramatic effect, I have no research showing exactly how much) of the target audience that isn't even reading that article.  There are developers out there, probably working for a small company on a team of 5 or less that simply will never end up reading that article or hearing about those tools.  They may even be ignorant to the fact that such things exist.  These people are the ones who need to be reading these articles the most.  They are the ones positioned to gain the most benefit from it.

I'm not saying that anyone that works for a small company on a team of 5 or less fits in that category.  I work for just such a company yet I do not fit in that category.  In fact, I and a colleague brought a toolset to the company I currently work for and the other developers didn't realize that there were such tools out there or maybe just never bothered to really try to find them.  We've recently brought a new developer onboard and even in his experience working for several companies, including software development contracting companies, had never seen a toolset as large as the one we had constructed at this company.  We're talking the basics: source control, build processes, development aids such as Notepad++ and RegexBuddy.

So what makes us different from the developers that don't have an extensive toolset?  Much of the suggestions I'm about to make extend beyond the tools you use and into the improvement within your field in general.

Read the best blogs and technology sites

This one has been preached several times over.  I'm guilty not doing this one well though.  I read a couple, but I don't read the best ones and I tend to gloss over too many articles without actually paying attention to them.

This also requires changing your habits from time to time.  Blogs and technology sites go stale or become polluted with bad information.  Sometimes you have to give up on a site and move on to the next one.  Don't be afraid to abandon one of your favorite sites after it has gone bad or lost the lead.  Don't let their falling behind let you fall behind.

Strive for improvement

It's not just a matter of reading news on technology sites or reading popular blogs to try to stay on top of your field.  You have to be constantly on the lookout for better ways to do what you're doing.  You're not going to be spoon-fed every new tool, better process, better techniques or new technology.  Sometimes you have to go hunt for a better way by yourself.

Don't be satisfied with Notepad to record your notes or edit your text files.  There's Notepad++ and it's free!  Better yet, there's Microsoft OneNote for keeping track of your notes.  Don't want to pay for OneNote?  How about Zoho Notebook or Google Notebook?  Software constantly breaking because you and another developer deploy from your local working copy and end up ultimately overwriting each other's changes?  Set up a build server and build process.  It's what all the big boys do and maybe it's time you do too even if you're working for a Mom and Pop shop.  As long as it can improve your process, why not consider it?  NAnt does wonders for creating a build process and CruiseControl.NET is great for setting up the build server.  Both are free and XML based so they're fairly easy to work with.  Don't like those?  Search for more.  Search for better.

Also, when reading technology articles about the 'Top 10 Blabity Blah', don't be satisfied with what the author is telling you.  Look for better.  You may stumble upon a whole new slew of tools and blogs and ways of doing things that you've never heard of.

The same can be said for developing and testing software.  Don't be satisfied writing code the same way you used to.  Learn about design patterns, development methodologies, software testing techniques.

You have to be constantly hungry for knowledge.

Be curious

Don't shy away from the unknown.  Take a look at the ads on your favorite blogs or the technology site that you just discovered searching for a solution to your problem.  Hear something you've never heard of?  Google it.  Learn more about it.  It may not be as complicated as you think or it could help you in ways you've never dreamed.

A colleague once asked me if I had ever heard of 'Inversion of Control' (IoC).  I hadn't.  I read about it on Wikipedia and kind of got it.  But I was curious so I kept digging.  I found out about 'Dependency Injection' (DI) and 'Aspect Oriented Programming' (AOP).  All of which I was never taught about in college.  Never anything even remotely similar to these.  This also led me to the Spring.NET framework.  I started playing around with Spring.NET and within a month had employed IoC/DI and AOP and it greatly reduced the complexity of my code, decreased the development time and increased the unit testability and the system testability of the application.

On another day, I had been searching for the solution to a problem and saw an ad for XHTMLiT.  This company claimed to take any design file (of the popular file types such as PSD, PNG and AI) and generate valid XHTML and CCS.  They also said all the right things such as 'table-less' design (if you want), hand-coded and more.  All this in 8 business hours and for an extremely low price!  I was curious and decided on an upcoming web site revamp to try them out.  The price fit well within the budget and if they could get it taken care of in 8 hours, then they'd save me a bunch of time.  Sure enough, they delivered and got it done in far less time than it would have taken me.  If I hadn't taken the time to click that ad, I would have added probably a week or more to the schedule for that project.

Listen to others and more than that, talk to others

Don't wait for your friends or colleagues to tell you what they are doing or what they are using.  Ask them.  A vast portion of my knowledge and tools I use have been conveyed to me from one of my colleagues.  He does a lot of the footwork for gathering the information and I basically leech off of his knowledge.  Ok, I don't leech.  I do reciprocate.  I educated him on Spring.NET, AOP, IoC and DI.  So when I say 'talk' to others, I also mean that you should volunteer your knowledge.  They may be one of the people waiting to be spoon-fed.  So spoon-feed them once in a while and then educate them on how you learn about everything.

Don't be afraid to experiment

You have to experiment and play with new tools, technology and techniques before you can become familiar with them.  It's a rare breed that can simply read about something and put it into play the next day.  The first couple tries at using something may not be pretty.  But you learn more from your mistakes than you do from your successes.  Edison himself learned 2000 ways not to make a light bulb.

The toughest part about this one is that you either have to experiment on your company's time or your time.  The choice is yours, but either way, you have to do it.  Sometimes just monkeying with something helps you figure it out easier than reading about it or being taught about it and you can learn things about it that may not have been obvious or documented or taught.

Don't accept the world the way it is

Just because a set of processes, tools, etc. are already in place does not mean that they are the best.  Be the butterfly flapping its wings off the coast of India that causes a tornado in Kansas.  Speak up.  Suggest the new stuff.  Even if they don't change to what you suggest, it may be the catalyst for other change.  And sometimes you have to be more forceful.  Sometimes you have to implement a new tool without anyone knowing just so you can prove to them that it works.  Be smart when choosing to do this, but don't be afraid to do it if you think it will work.

Don't be afraid to throw the old stuff out

Things change all the time.  Tools, processes, methodologies, none of these live in a bubble.  They are subject to the same rules as everything else and thus they change as well.  When a tool just doesn't cut it anymore, get rid of it.  You may love it, have a long history with it and are an expert with it, but if it doesn't get the job done, then what good is it?  Throw it away and get a new one.

You must unlearn that which you have learned.

When you have a hammer, everything looks like a nail.  When you have a better hammer, everything still looks like a nail, but the nails are easier to pound.

I've got a million of these... Ok, I don't.

Keep your eyes open

One of things I have seen done as part of Lean is to observe your day-to-day tasks.  Even go as far as video tape your day.  Then analyze it.  Really scrutinize it for waste.  If you find waste, try to figure out if there's a tool that would be helpful in reducing or eliminating that waste.  Be mindful of what you are doing.  Things that are repetitive that we've done day in and day out are often glossed over and not seen as waste because we do them all the time and don't think twice of why we do it the way we do.  Find these tasks and ask why you do them that way and if there's a better way to do it or if there is something that will help you do it better or faster.

Not everything I suggested here is always feasible within a company because you are dealing with their money and time.  I can't go learn a new tool if my company doesn't allow me or I don't have the time.  Just be smart and you can sometimes find ways.  Explain to your manager how it could benefit the company and in the long run save them money.  But just because it may be difficult to follow these suggestions does not mean that they are any less valid of points.

Got any other suggestions?  Leave a comment.

Technorati Tags: Development Tools