Ideas to be a better developer

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/ideas_to_be_a_better_developer.htm]

Here are some practical ideas to become a better developer. Of course people write entire books on this stuff, but here’s a brain-storming list (and that’s what blogs are for =)

1. Budget your job on an eight-hour day. Deliberately planning for a 12 hour day will just spin you into a downward spiral by burning you out, preventing you from learning new things, and constantly make you feel behind. Ideally try spending any overtime doing optional exciting learning or experiments that energize you (or improving code that already functionally works), not required features that just burn you out. If a feature does take longer, make sure management knows that, i.e.: “This is a 5 day feature, but I’ll work overtime to do it in 3 days.”

2. Get a blog aggregator, such as SharpReader or RssBandit: http://sourceforge.net/projects/rssbandit/. Then spend at least 10-20 minutes a day reading blogs.  This will give you a pulse on the community, alert you to new techniques, and introduce new creative solutions.

3. Keep a kudos list of positive things you’ve done. This helps build confidence (“I have done positive things”). This prepares you for a review. This is a service to management because it helps “jog their memory”, and management already has enough stuff to remember. If you can’t remember the good things you’ve done, why will anyone else?

4. Do incremental checkins, especially when working on a critical path. This results in much lower stress. Two small changes are easier to integrate than one big one. Check in what is needed to make sure you’re not blocking anyone, especially if you’re on the critical path. Ideally try to check in at least once every other day.

5. Think beyond your current feature. With each feature, try to make at least one reusable component/utility that improves the project as a whole. For example: reusable logic for the application’s framework, a global UI component, refactor an existing component to make it better, or make reusable validation/formatting logic. This will give you stepping-stones (and positive reputation) to do bigger experimental components.