A learned journey
As a mercenary developer, I come across programmers from many different walks of life; of all skill levels and abilities with varying levels of enthusiasm. Whilst I'm certainly not perfect (and am always learning), I encounter some who are yet to grasp some of the more basic programming concepts. It's very easy to take a blinkered view of the technologies you're familiar with and to become complacent in your current role or too comfortable with your existing skills. On the other hand, some developers I encounter are far keener than I, and therefore usually far exceed my skill; two things which are directly related.
I speak from first hand experience when I say that by taking a step outside of your comfort zone and making even one or two small changes to your daily routine as a developer could seriously improve your general programming knowledge and overall productivity. Although not quite ad-verbatim, I think it was Scott Hanselmann who recently blogged that simply stating that you are a developer with 20 years experience means very little; having 20 years experience writing the same code over and over is very different to going a little bit out of your way to learn something new with every project (or even every day - there's really no excuse!); (20 years x 1 years experience) > (1 years experience x 20 years). The fact is that if you do not look at what you're writing and constantly want to improve it, or at least to investigate new technologies and employ new techniques and patterns to your existing knowledge, you're digging yourself a career-swallowing hole.
I often see code written by senior developers that doesn't even follow some of the more simple programming principles. I appreciate that code can get "in a state" over time (especially in environments that aren't tightly managed), but it's rare that I ever need to "hack" code to get it to work - hacks are usually a result of bad planning or just because a developer doesn't know a right way to do things. Of course, new technologies are sometimes lacking in various areas, but most are extensible, and with a little bit of work can be neatly expanded to include functionality you require, whilst avoiding those nasty code smells.
I can forgive junior developers not understanding some of the more advanced techniques, but when I see senior developers (especially contractors) who still blindly copy & paste code segments from the web, constantly use WYSIWYG editors or hack their way around a language without making use of it's features and tools, it baffles and infuriates me. All it takes is to spend as little as 20 minutes a day researching the right things to keep your skills fresh and brain active. You can even fit things in and around work, which is a healthier way to approach it than taking time out of your personal life, if you're as busy as I can sometimes get.
I appreciate this post won't be very popular with the search engines - no developer I know (whether they are good or bad) is going to search for "how do I stop being a complete ball-bag at programming", mainly due to the fact that the people this blog is aimed at are, whilst being intelligent, usually ignorant to the fact they can do things better... or they simply don't care how terrible their code is. This isn't just me having a winge; developing better code (and understanding it) is the first step to a more rewarding and interesting daily work life, whether you've been somewhere for 30 years, or you move around from client to client like me. It certainly helps me land work - a breadth of knowledge is generally much more important to my clients than specialising in one particular area, though of course there are arguments for both.
So, I shall attempt to compile a list of "Dos and Don'ts" for those programmers who wish to become wiser in the world of development. Some of the items below are platform / language agnostic, whereas others are .Net / C# specific. I am, after all, a .Net developer :) I'm more than open to additional suggestions; as previously mentioned, I'm far from perfect, and my quest for knowledge is never ending.
I speak from first hand experience when I say that by taking a step outside of your comfort zone and making even one or two small changes to your daily routine as a developer could seriously improve your general programming knowledge and overall productivity. Although not quite ad-verbatim, I think it was Scott Hanselmann who recently blogged that simply stating that you are a developer with 20 years experience means very little; having 20 years experience writing the same code over and over is very different to going a little bit out of your way to learn something new with every project (or even every day - there's really no excuse!); (20 years x 1 years experience) > (1 years experience x 20 years). The fact is that if you do not look at what you're writing and constantly want to improve it, or at least to investigate new technologies and employ new techniques and patterns to your existing knowledge, you're digging yourself a career-swallowing hole.
I often see code written by senior developers that doesn't even follow some of the more simple programming principles. I appreciate that code can get "in a state" over time (especially in environments that aren't tightly managed), but it's rare that I ever need to "hack" code to get it to work - hacks are usually a result of bad planning or just because a developer doesn't know a right way to do things. Of course, new technologies are sometimes lacking in various areas, but most are extensible, and with a little bit of work can be neatly expanded to include functionality you require, whilst avoiding those nasty code smells.
I can forgive junior developers not understanding some of the more advanced techniques, but when I see senior developers (especially contractors) who still blindly copy & paste code segments from the web, constantly use WYSIWYG editors or hack their way around a language without making use of it's features and tools, it baffles and infuriates me. All it takes is to spend as little as 20 minutes a day researching the right things to keep your skills fresh and brain active. You can even fit things in and around work, which is a healthier way to approach it than taking time out of your personal life, if you're as busy as I can sometimes get.
I appreciate this post won't be very popular with the search engines - no developer I know (whether they are good or bad) is going to search for "how do I stop being a complete ball-bag at programming", mainly due to the fact that the people this blog is aimed at are, whilst being intelligent, usually ignorant to the fact they can do things better... or they simply don't care how terrible their code is. This isn't just me having a winge; developing better code (and understanding it) is the first step to a more rewarding and interesting daily work life, whether you've been somewhere for 30 years, or you move around from client to client like me. It certainly helps me land work - a breadth of knowledge is generally much more important to my clients than specialising in one particular area, though of course there are arguments for both.
So, I shall attempt to compile a list of "Dos and Don'ts" for those programmers who wish to become wiser in the world of development. Some of the items below are platform / language agnostic, whereas others are .Net / C# specific. I am, after all, a .Net developer :) I'm more than open to additional suggestions; as previously mentioned, I'm far from perfect, and my quest for knowledge is never ending.
- Once and Only Once / Don't repeat yourself (DRY) - Two similar programming principals stating that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". Hard to follow in their purest form, but in an ideal world, you would never write the same line of code more than once, nor would you ever copy + paste code from another part of your application; if you need to output the same error message on multiple web pages, store it in a class or a configuration file. If you need to log different levels of error, write a number of objects to do the complicated work, and a helper method to call and manipulate the objects etc.
I often see code that repeats itself, even within the same method; create directory A, create directory B, create sub-directory B-A etc... applying this principal (or at least having it in mind) will greatly improve maintenance of your code, and make your code more predictable. - Use the correct type - Please, for the love of Zeus, don't just use "int" and "string" for everything, and avoid using base types like "object" unless absolutely necessary. E.g. use boolean types for boolean data; if you're storing a CHAR(1) in a database that only has two potential values ("Y" and "N" or "0" and "1", for example), store as a boolean. Not only do you save memory / disk space (in the above example, CHAR(1) stores 1 byte, whereas you can have up to 8 BIT columns in a single table occupying 1 byte), but the column is naturally constrained to two possible values, reducing the possibility of a data error.
- Code Formatting - Most IDEs will format for you these days, but there are still some that don't. Those that format should give you plenty of options on how to display your code, and a little bit of fiddling should do the trick. Well formatted code is easier to read and modify, for you and other developers that may need to access it.
- Subscribe to blogs - One of the most productive things I ever did was starting using RSS to subscribe to tech blogs. Subscribing to the right blogs (it took me a while to filter down to the ones that are useful to me) gives you instant access to the latest tech releases and insider info. I'm always adding and changing my blog subscriptions - but there are a few .Net guys I will mention by name, due to the fact they provide consistent quality in their updates. Scott Hanselman, Scott Guthrie and Phil Haack. I enjoy reading their blogs more than most, though I am subscribed to quite a number of other developers too.
- Expand (and understand) your toolset - I recently posted a Tools Roundup listing the apps and programs that I use on a daily basis. I have to admit, I don't know all of the tools I use inside-out, but I sure as hell know that what little I do know about them has improved my productivity unfathomably. I used to shun tools, until I grew out of it :)
- Read whitepapers - As with blog subscriptions, another thing that I've been doing for the past few years is actually reading through online articles, instead of skipping through to find code examples. None of us have the time for that though, do we? By reading the full article, you have a better chance of understanding a concept, and taking away from it much more than just what you're looking for. They help you make informed decisions and give you all kinds of facts that you didn't know or think about. Online whitepapers can be written by individual developers, or sponsored by corporations - both can be full of relevant information, but beware - they can also be full of rubbish, just like blogs (ahem).
- Embrace new technologies - It's hard to keep up, but it's definitely possible. I have a lot on my plate (see my "bio" section), but I still manage to fit in the odd example project now and then. At the time of writing, MVC4 is in Beta and not far off RC - I've already played around with the new MVC4 framework, but I've not spent too long on it. It doesn't hurt to download example projects or follow blog posts to at least see what a tech's new features are capable of.
- Inform Yourself of Popular Design Patterns - Pretty much every developer uses at least one design pattern, whether they know it or not. Different patterns can be used to make your development quicker and easier, as long as you know where to apply each one. I'm no expert by any means, but since I started reading about and understanding different design patterns, I've come a long way. Take a look at MVC, MVVM, nTier, Factory and singleton to get you started.