Work-in-progress - move along, nothing to see here
Hello, my name is Tim Hastings, and I would like to offer advice to any software developers who want to become better. Whilst I am no authority, I would like to share the experience I have. Please feel welcome to share your experiences, either personally, by contacting me, or publicly using the comments below.
Whether your motivation is self-improvement, promotion, money, ego, or all of the above, the aspiration to become better is an honourable one. I salute you.
You may feel that the next section sounds a bit sanctimonious. If you already know it, then just skip ahead.
Accept Responsibility
Here is a harsh truth: it is your responsibility to plan your career.
Some people are fortunate enough to do a nine-to-five job where career progression is a given. They just need to show up. Unfortunately, I feel that software development is not one of these jobs. With its fast pace of change, our industry will not let you coast, you will soon be left behind. In fact, with the advance of platforms (think OSX, Vista and IE7) you have to tread water just to stay still.
My point here is that if you want to become a better developer then you need to take action, you need to make it happen. Sure, your boss and the company want you to be the best God damn developer in town, but it is not their highest priority. If you want to improve, then accept that you need to invest some of your own time and money. The good news is: you get to choose where to take your career!
Thinking about improvement... Do you have five year's of experience? Or one year's experience five times?
Adapt and Survive - Learning New Skills
If you subscribe to Darwin's theories about Natural Selection it is fun to apply his theory to a department of software developers. Just as birds with larger beaks may survive a shortage of insects; each new skill you acquire enables you to adapt to changes in your environment and evolve. As you gain experience with different technologies and techniques it may be possible to apply them to your latest project. You can shape your environment.
If a population of developers only learn the things that they must know to do their job then their exposure to different technologies and skills is limited. If you imagine a busy stressed out department of people who are too busy working on projects to spend time learning about
Understand The Difference Between Software Developer and Programmer
A great analogy is the different between a brick-layer and a property developer. If you want to be a great programmer and cut code all day, this is absolutely fine, but understand that this is a very narrowly-focused job. If you want to be a great software developer, you need to see the bigger picture, an understanding of all the other bagged that comes with developing software. But not just software related issues such as testing, tech support, build, installation and documentation; what about the business you are in? Who are your users? Why do they use your software? What market do you serve? How does your business make its money? Who are your competitors?
Business savvy developers are a rare bread. Communicate. There are lots of good books on business.
Eric Sink wrote a very good article on this subject, see the links section below.
WritingBetter Maintainable Code
It is difficult to define what makes one piece of code good and another bad. But you know yourself whether you consider a piece of code is nice and friendly, or horrible and mysterious. If you are trying to understand, test, or modify someone else's code, you soon know if it's good or bad. My view is 'better' just means 'maintainable'. For me, the maintainability of code defines whether it is good and bad. I knew a developer who prided himself on his credit card number validation algorithm written in a single line of infix c. It was very clever, but black magic to everyone else.
Writing maintainable code is a subject in itself. But I offer the following tips as a quick check-list:
Attention to Detail
Practice
Read, Read, Read
If your company allows you to expense book purchases - this an enormous advantage. This means that the company is helping people who want to improve. I think that smart people recognise the value of books. For the cost of a one-week course, you can fill a book shelf with knowledge that can be shared by a department. This is a great investment.
Ask Yourself...
Recommended Links
© Copyright 2006 Tim Hastings (all rights reserved)
Hello, my name is Tim Hastings, and I would like to offer advice to any software developers who want to become better. Whilst I am no authority, I would like to share the experience I have. Please feel welcome to share your experiences, either personally, by contacting me, or publicly using the comments below.
Whether your motivation is self-improvement, promotion, money, ego, or all of the above, the aspiration to become better is an honourable one. I salute you.
You may feel that the next section sounds a bit sanctimonious. If you already know it, then just skip ahead.
Accept Responsibility
Here is a harsh truth: it is your responsibility to plan your career.
Some people are fortunate enough to do a nine-to-five job where career progression is a given. They just need to show up. Unfortunately, I feel that software development is not one of these jobs. With its fast pace of change, our industry will not let you coast, you will soon be left behind. In fact, with the advance of platforms (think OSX, Vista and IE7) you have to tread water just to stay still.
My point here is that if you want to become a better developer then you need to take action, you need to make it happen. Sure, your boss and the company want you to be the best God damn developer in town, but it is not their highest priority. If you want to improve, then accept that you need to invest some of your own time and money. The good news is: you get to choose where to take your career!
Thinking about improvement... Do you have five year's of experience? Or one year's experience five times?
Adapt and Survive - Learning New Skills
If you subscribe to Darwin's theories about Natural Selection it is fun to apply his theory to a department of software developers. Just as birds with larger beaks may survive a shortage of insects; each new skill you acquire enables you to adapt to changes in your environment and evolve. As you gain experience with different technologies and techniques it may be possible to apply them to your latest project. You can shape your environment.
If a population of developers only learn the things that they must know to do their job then their exposure to different technologies and skills is limited. If you imagine a busy stressed out department of people who are too busy working on projects to spend time learning about
Understand The Difference Between Software Developer and Programmer
A great analogy is the different between a brick-layer and a property developer. If you want to be a great programmer and cut code all day, this is absolutely fine, but understand that this is a very narrowly-focused job. If you want to be a great software developer, you need to see the bigger picture, an understanding of all the other bagged that comes with developing software. But not just software related issues such as testing, tech support, build, installation and documentation; what about the business you are in? Who are your users? Why do they use your software? What market do you serve? How does your business make its money? Who are your competitors?
Business savvy developers are a rare bread. Communicate. There are lots of good books on business.
Eric Sink wrote a very good article on this subject, see the links section below.
Writing
It is difficult to define what makes one piece of code good and another bad. But you know yourself whether you consider a piece of code is nice and friendly, or horrible and mysterious. If you are trying to understand, test, or modify someone else's code, you soon know if it's good or bad. My view is 'better' just means 'maintainable'. For me, the maintainability of code defines whether it is good and bad. I knew a developer who prided himself on his credit card number validation algorithm written in a single line of infix c. It was very clever, but black magic to everyone else.
Writing maintainable code is a subject in itself. But I offer the following tips as a quick check-list:
- comment your code - this is obvious
- use sensible names for variables and functions
- defensively validate your input and if you're not happy, throw errors
- make sure you always throw helpful errors that pinpoint the cause of the problem
- eliminate duplicated code with shared functionality
- breakdown tasks into smaller subtasks and implement these as separate functions
- each function should do an identifiable job, not several jobs
- reduce the size of functions by creating common helper functions
- simplify your code - the body of a loop can always be implemented as a separate function
- should your switch/select statement have an else clause?
- separate data, business logic and the presentation
Attention to Detail
Practice
Read, Read, Read
If your company allows you to expense book purchases - this an enormous advantage. This means that the company is helping people who want to improve. I think that smart people recognise the value of books. For the cost of a one-week course, you can fill a book shelf with knowledge that can be shared by a department. This is a great investment.
Ask Yourself...
- What did you last learn that improved the way you work, forever?
- Is the code you write maintainable?
- What was the last book you read?
- How are you better than a year ago?
Recommended Links
- Small ISVs: You need Developers, not Programmers by Eric Sink.
- Rob Walling has a series about becoming a better developer, here is part one
© Copyright 2006 Tim Hastings (all rights reserved)
0 comments,
Professional, Friday, February 23, 2007 05:32