Every WEB developer should know...
K. Scott Allen (OdeToCode), Kevin Dente, Scott Koon (Lazycoder) and Jon Galloway record a weekly podcast where they discuss various development issues, technologies, etc.
In November 2008 they had a show about what web developers need to know:
Episode 27: What Every Web Developer Needs To Know
If you are a web developer I'd recommend you have a listen. And not just because of the title of the episode.
... they will benefit from a breadth of experiences
"The ideal engineer is a composite … he is not a scientist, he is not a mathematician, he is not a sociologist, or a writer; but he may use the knowledge and techniques of any or all of these disciplines in solving engineering problems."
—N. W. Dougherty
... being a developer is not the same as being a designer
Every developer should know that being a developer is not the same as being a designer.
Just because you can program the server side of a website doesn't mean that you are the best person to design the graphics, layout, colour scheme or logos.
Just because you are an expert at optimising data retrieval from relational databases doesn't mean that you should be designing the layout of the forms used to display that data.
Or, if you're a design whizz, it doesn't mean that you should be writing the code of an application that uses your designs.
Why is this important?
Be honest with yourself. Know your limits. Focus on what you are best at. Let the people who are best at different tasks work on those tasks.
What do you do once you know this?
Don't be afraid to defer a task to someone better skilled.
It'll allow you more time to focus on what you're best at.
Would you rather be the developer of some amazing software that someone else designed? Or the developer and designer of some software that is only OK?
Just because you can program the server side of a website doesn't mean that you are the best person to design the graphics, layout, colour scheme or logos.
Just because you are an expert at optimising data retrieval from relational databases doesn't mean that you should be designing the layout of the forms used to display that data.
Or, if you're a design whizz, it doesn't mean that you should be writing the code of an application that uses your designs.
Why is this important?
Be honest with yourself. Know your limits. Focus on what you are best at. Let the people who are best at different tasks work on those tasks.
I know I'm not a great designer. Just look at this site. (One day I'll get a designer to make it better.)
I'm not saying you can't be both, just that most people aren't. What do you do once you know this?
Don't be afraid to defer a task to someone better skilled.
It'll allow you more time to focus on what you're best at.
Would you rather be the developer of some amazing software that someone else designed? Or the developer and designer of some software that is only OK?
... that if debugging is the process of removing bugs... ;)
"If debugging is the process of removing bugs, then programming must be the process of putting them in."
- Edsger Dijkstra
... you can't fully estimate from just a description of what is wanted
"You cannot write a description of software you want and then have someone develop it on a fixed schedule for a fixed price."
- Robert Martin
... that complexity hides deficiencies
"There are two ways of constructing a software design. One way is to make it so
simple that there are obviously no deficiencies. And the other way is to make it
so complicated that there are no obvious deficiencies."
... that they must be involved in implementation
"The designer of a new kind of system must participate fully in the implementation."
"… the designer of a new system must not only be the implementor and the first large-scale user; the designer should also write the first user manual. … If I had not participated fully in all these activities, literally hundreds of improvements would never have been made, because I would never have thought of them or perceived why they were important."
... you won't get rid of all bugs, add all the features or write all the programs
Every developer should know that you won't get rid of all bugs, add all the features or write all the programs you might want to.
Why is this important?
You need to set limits and prioritise.
There isn't enough time to do everything. So you need to focus on what's important and do that!
There isnt' the time to fix every bug. So fix the ones that cause the biggest problems or affect the most people (or whatever criteria you use to prioritse bugs) first. By the time you've made those changes, circumstances may be different.
Make sure you're adding the feature which will bring the most benefit. Not just the one that is easiest to code, or most fun.
Make sure you're creating a new program that is of use, doesn't already exist and will actually benefit others.
What do you do once you know this?
Prioritise!
Make sure you're doing something that is worth doing.
Don't do one thing if there's another that is more important.
Understand the costs and benefits of fixing the bug, adding the feature or creating a new program, before you write the code.
Why is this important?
You need to set limits and prioritise.
There isn't enough time to do everything. So you need to focus on what's important and do that!
There isnt' the time to fix every bug. So fix the ones that cause the biggest problems or affect the most people (or whatever criteria you use to prioritse bugs) first. By the time you've made those changes, circumstances may be different.
Make sure you're adding the feature which will bring the most benefit. Not just the one that is easiest to code, or most fun.
Make sure you're creating a new program that is of use, doesn't already exist and will actually benefit others.
What do you do once you know this?
Prioritise!
Make sure you're doing something that is worth doing.
Don't do one thing if there's another that is more important.
Understand the costs and benefits of fixing the bug, adding the feature or creating a new program, before you write the code.
... that design and programming are human activities
"Design and programming are human activities; forget that and all is lost."
... to check that something exists, before trying to use it
Every developer should know to check that something exists before trying to use it.
Following on from the previous advice about not making assumptions about a file system. Be sure and extend your assumption checking beyond just the file system. Immediately that means files and their contents. But also think about: other programs; operating system components; peripheral devices; hardware components (ports, cards, etc.)
Why is this important?
Because at some point in the future, whatever your expecting to be there won't.
When that happens, one of the following is likely:
What do you do once you know this?
Make sure you check!
You'll save yourself some support and your users some inconvenience by dealing with problems before they can happen.
Following on from the previous advice about not making assumptions about a file system. Be sure and extend your assumption checking beyond just the file system. Immediately that means files and their contents. But also think about: other programs; operating system components; peripheral devices; hardware components (ports, cards, etc.)
Why is this important?
Because at some point in the future, whatever your expecting to be there won't.
When that happens, one of the following is likely:
- It will have no impact.
- Part of the program won't work.
- It will cause an error message to be displayed.
- The program will crash.
- The program will crash and will corrupt user data.
- An important customer will be disappointed in your software and in you/your company.
- You (or someone else in your company) will have to spend time with the user working out what went wrong and how to work around it.
- You (or someone else in your company) will have to spend time updating the program so that it can deal with the missing element, to prevent customers having the same problem again in the future.
What do you do once you know this?
Make sure you check!
You'll save yourself some support and your users some inconvenience by dealing with problems before they can happen.
... that different platforms have different requirements
Every developer should know that different platforms have different requirements.
It is important to understand the platform that you are developing for:
It is important to understand the platform that you are developing for:
- Developing for the desktop is different from developing for the web.
- Developing for a device with a large screen is different from developing for a device with a small screen.
- They are both different than a device with no screen.
- An interface that will be navigated with a mouse or keyboard is different from one which will be navigated with a peripheral device, or thumbs!
Remember, assumptions usually turn into bugs or the user not getting what the really need/want.
What do you do once you know this?
Make sure that you understand the platform you are developing for, particularly if it is new to you.
Don't assume that the way you've done things on other platforms is appropriate or even possible.
What do you think?
Is this something every developer should know? Have you say in the comments.
... not to make assumptions about a file system
Every developer should know not to make assumptions about a file system.
Don't assume that certain folders or drives will ever exist on the machine your software will be deployed on.
Also, don't assume you will have permission to access a location.
Why is this important?
If you assume a certain drive or folder will exist, or you have permission to access it but it doesn't or you don't. You software is likely to fail in unpredicted ways.
What do you do once you know this?
Test all assumptions. In code.
Want to install to the C drive? Test it exists first.
Want to write a file to a particular directory? Check it exists and you have permissions to write to it.
What do you think?
Is this something every developer should know? Have you say in the comments.
Don't assume that certain folders or drives will ever exist on the machine your software will be deployed on.
Also, don't assume you will have permission to access a location.
Why is this important?
If you assume a certain drive or folder will exist, or you have permission to access it but it doesn't or you don't. You software is likely to fail in unpredicted ways.
What do you do once you know this?
Test all assumptions. In code.
Want to install to the C drive? Test it exists first.
Want to write a file to a particular directory? Check it exists and you have permissions to write to it.
What do you think?
Is this something every developer should know? Have you say in the comments.
... not to save dates (and/or times) as strings based on formats which can change
Every developer should know not to save dates (and/or times) as strings based on formats which can change.
Such settings will, at some point, change or vary. And when they do: at best, a date may be displayed incorrectly or inconsistently; at worst, the program will crash as it is unable to correctly convert a date.
Why is this important?
Not doing this and trying to deal with varying formats can lead to:
When saving a date and/or time as a string you should use an ISO defined format.
By always using one of these format you will never have to deal with multiple format conversions within a system.
If dates (and or times) are saved as strings in other formats a separate piece of information must also be saved which explains the format. '01/02/2008' could be the first of February or the second of February. '02/03/02' could be an even larger number of possibilities.
Of course, you'd never consider using a two figure year value though. would you?
These formats also have a number of other benefits.
It might be tempting to think that, as computers process dates and times as numbers, this is how you should store them also, when saving to a file or database. The potential downside to this is that you really also need to store the date (and time) from which to start counting also. This means that two pieces of information should be stored. In practice, it is unlikely that anyone would store two pieces of information for each date being recorded by a system. If this was recorded it would likely be in a global setting, or, more likely, in the documentation somewhere. Either way these are likely to be places which are overlooked when they are most needed.
What do you do once you know this?
Don't do it!
Save dates and times using the numeric representations defined in ISO 8601:2004. Such as:
YYYY-MM-DD
YYYY-Www-D
hh:mm:ss
YYYY-MM-DDThh:mm:ss
In doing this you can have a simple set of utility functions to convert dates to strings and numerous future headaches are saved.
You can then just worry about formatting dates when they are displayed to the user. Which should be in the user defined format, of course.
What do you think?
Is this something every developer should know? Have you say in the comments.
Such settings will, at some point, change or vary. And when they do: at best, a date may be displayed incorrectly or inconsistently; at worst, the program will crash as it is unable to correctly convert a date.
Why is this important?
Not doing this and trying to deal with varying formats can lead to:
- regionalisation issues.
- compatibility issues.
- unnecessarily complicated programs.
When saving a date and/or time as a string you should use an ISO defined format.
By always using one of these format you will never have to deal with multiple format conversions within a system.
If dates (and or times) are saved as strings in other formats a separate piece of information must also be saved which explains the format. '01/02/2008' could be the first of February or the second of February. '02/03/02' could be an even larger number of possibilities.
Of course, you'd never consider using a two figure year value though. would you?
These formats also have a number of other benefits.
- They ensure readability and accuracy amongst all systems.
- They allow for easy sorting and comparison of dates.
- They are language independent.
- Most notations are short.
- They are of a consistent length.
It might be tempting to think that, as computers process dates and times as numbers, this is how you should store them also, when saving to a file or database. The potential downside to this is that you really also need to store the date (and time) from which to start counting also. This means that two pieces of information should be stored. In practice, it is unlikely that anyone would store two pieces of information for each date being recorded by a system. If this was recorded it would likely be in a global setting, or, more likely, in the documentation somewhere. Either way these are likely to be places which are overlooked when they are most needed.
What do you do once you know this?
Don't do it!
Save dates and times using the numeric representations defined in ISO 8601:2004. Such as:
YYYY-MM-DD
YYYY-Www-D
hh:mm:ss
YYYY-MM-DDThh:mm:ss
In doing this you can have a simple set of utility functions to convert dates to strings and numerous future headaches are saved.
You can then just worry about formatting dates when they are displayed to the user. Which should be in the user defined format, of course.
What do you think?
Is this something every developer should know? Have you say in the comments.
Subscribe to:
Posts (Atom)