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.
... self discipline and motivation
Every developer should know self discipline and motivation.
Why is this important?
There are many elements to software development. The chances are that you aren't going to enjoy all of them. Unfortunately though, there will be times when you have to do them. If you don't: certain bugs won't get fixed; features may not get added; customers may be lost; users will be frustrated; documentation won't get written; and your software won't be as good as it should be.
What do you do once you know this?
You find a way to to motivate and discipline yourself to do the things you'd rather not. There are lots of possibilities. What is important is that you find what works for you and don't give up until you do.
What do you think?
Is this something every developer should know? Have you say in the comments.
Why is this important?
There are many elements to software development. The chances are that you aren't going to enjoy all of them. Unfortunately though, there will be times when you have to do them. If you don't: certain bugs won't get fixed; features may not get added; customers may be lost; users will be frustrated; documentation won't get written; and your software won't be as good as it should be.
What do you do once you know this?
You find a way to to motivate and discipline yourself to do the things you'd rather not. There are lots of possibilities. What is important is that you find what works for you and don't give up until you do.
What do you think?
Is this something every developer should know? Have you say in the comments.
... not to use mapped drives
Every developer should know not to use mapped drives.
I'll start by admitting that this is something that really annoys me. I'll also admit that it may be appropriate to use mapped drives if, and only if, you are creating a mapped drive to connect to a directory that only you will ever need to connect to. An example being your personal area on a server.
If you're not sure what I mean by "mapped drives" or want to confirm that what I mean and what you understand are the same, take a look at these two Wikipedia articles:
Drive mapping
Drive letter assignment
I'd sum it up like this:
Rather than have to specify a long file path, such as:
\\aServer\folder\directory\another folder\another directory\my files\file.ext
It is possible to tell Windows that the letter X should be mapped to \\aServer\folder\directory\another folder\another directory. This means that it is now possible use the drive letter X, when specifying the path to the file (X:\my files\file.ext)
Now I've got the boring part you already know out of the way.
DON'T DO IT!
Why not?
Because using mapped drives causes problems down the line.
Need to set up another machine?
Lost your mapped drive settings?
Which drives do you need to map? and where?
Someone else wants to know where a file is? Telling them it's on Drive T doesn't help them unless they know where you have drive T mapped to. And why would you remember? You mapped the drive so you wouldn't have to.
Mapped drives provide no meaning.
//Server1/Departments/Support/Customers/Acc01234/history.crm - has meaning.
H:\history.crm - has little.
They are user specific.
Different users can map the same drive letter to different paths.
This can lead to all sorts of problems. Especially if there are files of the same name in the different mapped paths.
They add unnecessary and artificial constraints.
Using a mapped driver anywhere in the development or build process can cause problems.
Very rarely is the development of a piece of software done by a single person, on the same machine for the lifetime of that piece of software. If more than one person will be working on an application, ever. Requiring a mapped drive will just be one more thing to configure and this flies in the face of what every developer should aim for. Removing all unnecessary complications from the development process.
What do you do once you know this?
Ensure that the software you create software that can support file paths in either (any) format.
There should definitely be no excuse for ever creating software which can only connect to a file if using a mapped drive. You'd just be creating problems for other people.
What do you think?
Is this something every developer should know? Have you say in the comments.
I'll start by admitting that this is something that really annoys me. I'll also admit that it may be appropriate to use mapped drives if, and only if, you are creating a mapped drive to connect to a directory that only you will ever need to connect to. An example being your personal area on a server.
If you're not sure what I mean by "mapped drives" or want to confirm that what I mean and what you understand are the same, take a look at these two Wikipedia articles:
Drive mapping
Drive letter assignment
I'd sum it up like this:
Rather than have to specify a long file path, such as:
\\aServer\folder\directory\another folder\another directory\my files\file.ext
It is possible to tell Windows that the letter X should be mapped to \\aServer\folder\directory\another folder\another directory. This means that it is now possible use the drive letter X, when specifying the path to the file (X:\my files\file.ext)
Now I've got the boring part you already know out of the way.
DON'T DO IT!
Why not?
Because using mapped drives causes problems down the line.
Need to set up another machine?
Lost your mapped drive settings?
Which drives do you need to map? and where?
Someone else wants to know where a file is? Telling them it's on Drive T doesn't help them unless they know where you have drive T mapped to. And why would you remember? You mapped the drive so you wouldn't have to.
Mapped drives provide no meaning.
//Server1/Departments/Support/Customers/Acc01234/history.crm - has meaning.
H:\history.crm - has little.
They are user specific.
Different users can map the same drive letter to different paths.
This can lead to all sorts of problems. Especially if there are files of the same name in the different mapped paths.
They add unnecessary and artificial constraints.
Using a mapped driver anywhere in the development or build process can cause problems.
Very rarely is the development of a piece of software done by a single person, on the same machine for the lifetime of that piece of software. If more than one person will be working on an application, ever. Requiring a mapped drive will just be one more thing to configure and this flies in the face of what every developer should aim for. Removing all unnecessary complications from the development process.
What do you do once you know this?
Ensure that the software you create software that can support file paths in either (any) format.
There should definitely be no excuse for ever creating software which can only connect to a file if using a mapped drive. You'd just be creating problems for other people.
What do you think?
Is this something every developer should know? Have you say in the comments.
... how long the software being developed will need to be supported
Every developer should know how long the software being developed will need to be supported.
First off, lets get the exceptions out of the way. If the software being developed is a small, one off application, which serves a single purpose and will only be used by a single person, there is a chance that it may never need supporting. In such a case it will normally be sufficient to just keep a copy of the source code and
any specification documents.
So what do I mean by 'software needing to be supported'?
Simple. It's everything after the software is finished and delivered to the user.
This includes:
- Helping installing the software.
- Answering questions about the software.
- Fixing bugs.
- Adding new features.
Why is this important?
Because time taken in support is time that can't be spent on other software or a new version of the software.
If you aren't accounting for supporting previously created software when planning subsequent work or determining how much to charge for the software, problems are likely to follow.
It is also likely to matter to the person buying the software. They will have expectations about how long support will be available for. As part of managing the relationship with the customer and their expectations it is important to be clear about this. And this is sometihng that can only be done if it has been thought through.
What do you do once you know this?
Make sure that you plan for support and are always have sufficient resources and knowledge to do so.
What do you think?
Is this something every developer should know? Have you say in the comments.
First off, lets get the exceptions out of the way. If the software being developed is a small, one off application, which serves a single purpose and will only be used by a single person, there is a chance that it may never need supporting. In such a case it will normally be sufficient to just keep a copy of the source code and
any specification documents.
So what do I mean by 'software needing to be supported'?
Simple. It's everything after the software is finished and delivered to the user.
This includes:
- Helping installing the software.
- Answering questions about the software.
- Fixing bugs.
- Adding new features.
Why is this important?
Because time taken in support is time that can't be spent on other software or a new version of the software.
If you aren't accounting for supporting previously created software when planning subsequent work or determining how much to charge for the software, problems are likely to follow.
It is also likely to matter to the person buying the software. They will have expectations about how long support will be available for. As part of managing the relationship with the customer and their expectations it is important to be clear about this. And this is sometihng that can only be done if it has been thought through.
What do you do once you know this?
Make sure that you plan for support and are always have sufficient resources and knowledge to do so.
What do you think?
Is this something every developer should know? Have you say in the comments.
... how to touch type
Every developer should know how to touch type.
Touch typing is typing without looking at the keys.
It's much faster than typing and looking at the keys for two main reasons.
1. You will spot mistakes sooner as you immediately see them when they occur.
2. You don't lose time finding your place on the screen as you do when your focus is constantly changing back and for the between the screen and keyboard.
The good news is, you can probably already do it, you just need to trust yourself. If you currently use all of you fingers
This will take practice. Don't worry if you make lots of mistakes early on, you will get there in the end and it will be worth it. Your typing will be much much faster. Plus correcting your mistakes without looking at the keyboard provides an extra sense of achievement.
This is not about telling you that you should be specifically forcing yourself to learn to use specific fingers for specific keys, but about doing it without looking. If you don't use a specific system, you will soon learn which keys arm naturally easier for you to press with each finger.
Touch typing is about learning not to think about the unimportant and unnecessary, so you can focus on what is more important. Focus on what is on screen, not how to get it there.
There is an argument from developers that touch typing only helps when typing large amounts of text and not when typing structured code. This isn't true. While touch typing traditionally focuses on alphabetic characters and not the numerous operators, brackets and other characters that are needed when writing code it can make typing anything faster. If you can push the button without having to look at the keyboard each time, you can type faster, regardless of what you are typing.
There are also other ways of typing faster, or even faster, such as using a keyboard layout designed for this purpose, like the Dvorak keyboard layout. There are also other layouts which allow for faster typing.
If you're not confident to try this by yourself and want extra help there are a number of tools and training aids to help.
Search for what works best for you. Here are some of the more popular aids available from Amazon:
Aids for learning touch typing (Associate link)
What do you think?
Is this something every developer should know? Have you say in the comments.
Know a developer who should read this? Email them this article.
... about UI developer guidelines
Every developer should know about UI developer guidelines.
Developing software that is easy to use is not always a simple task. One way to help create software that is easier for users to learn and use, is to follow conventions in the use, style, layout and positioning of form components.
Here are some guides for a number of different environments and platforms:
Windows Vista User Experience Guidelines
Microsoft Inductive User Interface Guidelines
How to Create the Best User Experience for Your Application
Java Look and Feel Design Guidelines
Apple's User Experience Guide
GNOME Human Interface Guidelines
UI and User Experience Guidelines for Nokia mobile phones
Smartphone User Interface Guidelines
Sometimes there are benefits to creating something that looks different, but it is very easy to create something that looks ugly and is confusing for users.
Creating something that looks and behaves like applications that users have used before:
Developing software that is easy to use is not always a simple task. One way to help create software that is easier for users to learn and use, is to follow conventions in the use, style, layout and positioning of form components.
Here are some guides for a number of different environments and platforms:
Windows Vista User Experience Guidelines
Microsoft Inductive User Interface Guidelines
How to Create the Best User Experience for Your Application
Java Look and Feel Design Guidelines
Apple's User Experience Guide
GNOME Human Interface Guidelines
UI and User Experience Guidelines for Nokia mobile phones
Smartphone User Interface Guidelines
Sometimes there are benefits to creating something that looks different, but it is very easy to create something that looks ugly and is confusing for users.
Creating something that looks and behaves like applications that users have used before:
- Creates comfort and familiarity for the user.
- Means that things will work the way the user expects.
- Means that the application will be quicker and easier for the user to learn.
... about Unicode and character encodings
Every developer should know about Unicode and character encodings.
This is a complicated subject but it's a very important one. It's also a subject that I expect to return to several times.
“If you are a programmer working in 200[7] and you don’t know the basics of characters, character sets, encodings, and Unicode, and I catch you, I’m going to punish you by making you peel onions for six months in a submarine.” Joel Spolsky
Joel is famous for his site http://www.joelonsoftware.com/. If you haven't read it I recommend you do.
Of particular relevance today is the article:
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
If you haven't read this article before, read it now. If you have, read it again. A little refresher is rarely a bad thing.
But why do you need to know this?
Well, at some point you are going to have to know:
This is a complicated subject but it's a very important one. It's also a subject that I expect to return to several times.
“If you are a programmer working in 200[7] and you don’t know the basics of characters, character sets, encodings, and Unicode, and I catch you, I’m going to punish you by making you peel onions for six months in a submarine.” Joel Spolsky
Joel is famous for his site http://www.joelonsoftware.com/. If you haven't read it I recommend you do.
Of particular relevance today is the article:
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
If you haven't read this article before, read it now. If you have, read it again. A little refresher is rarely a bad thing.
But why do you need to know this?
Well, at some point you are going to have to know:
- Why some fonts show characters differently.
- Why characters with diacritics don't always display (correctly).
- How you display text from languages which uses alphabets other than the English one (A to Z, no diacritics).
- How you create characters with multiple diacritics.
- What UTF-8 & UTF-16 really mean.
- How you display text from languages which read from right to left.
- How you display text from the Chinese, Japanese and Korean languages.
- How you should display text that contains a words from varying languages.
This list could easily be a lot longer, and as you start to investigate the subject you'll soon see how.
The most important thing to take from this is that you will not be able to get through the rest of your career in software development assuming that the only letters you will ever need are A though Z. As the world gets smaller and international boundaries blur, especially on-line, there will be more and more need to know this.
This is a complex subject. Start learning about it now and you'll have a head start when have to implement related functionality.
... about this blog
Every developer should know about this blog.
But you (assuming you are a developer) probably want to know a bit about it as well. To that end, I've answered a few general questions below.
What is the purpose purpose of the blog?
To provide information to help developers improve and become better at what they do (create software). I hope everyone who is involved in software development wants to become better at what they do and I hope this blog can become a resource to help.
To be a really good developer there is loads you need to know but will probably never be taught. Often these are things that you might normally only learn with experience but might also be because few people teach them, because few people know them.
At the very least this blog might help you identify what you don't know. I'd like to hope it will inspire you to find out a bit more about those subjects also.
Why does it exist?
Because I couldn't find another resource for this type of information. Sure there are lots of sites that provide information in specific areas, but none that provide good general information on a regular basis.
Who is it for?
Anyone who is involved in software development. Whether you are a newbie or a seasoned expert, I hope you can learn something here.
I'd also love for you to contribute. If there is something the you think all other developers should know but frequently seem not to, please let me know. And if you can write a bit about it, even better.
What can you expect?
Once or twice a week, I'll post something that I, or someone who I respect, think that every developer should know.
The aim is to try and list information, or sources of information, that will be useful or relevant to any developer but sometimes things might be focused on a specific technology or language.
Who's writing it?
Me.
Hi, my name is Matt Lacey. I also have a personal blog which might tell you a bit more about me.
Do I think I know everything?
Definitely not!
Part of the aim of setting up this blog was also so that I could learn (directly from other people as well as by researching articles).
Got any more questions? Stick them in the comments. I'll do my best to answer them.
But you (assuming you are a developer) probably want to know a bit about it as well. To that end, I've answered a few general questions below.
What is the purpose purpose of the blog?
To provide information to help developers improve and become better at what they do (create software). I hope everyone who is involved in software development wants to become better at what they do and I hope this blog can become a resource to help.
To be a really good developer there is loads you need to know but will probably never be taught. Often these are things that you might normally only learn with experience but might also be because few people teach them, because few people know them.
At the very least this blog might help you identify what you don't know. I'd like to hope it will inspire you to find out a bit more about those subjects also.
Why does it exist?
Because I couldn't find another resource for this type of information. Sure there are lots of sites that provide information in specific areas, but none that provide good general information on a regular basis.
Who is it for?
Anyone who is involved in software development. Whether you are a newbie or a seasoned expert, I hope you can learn something here.
I'd also love for you to contribute. If there is something the you think all other developers should know but frequently seem not to, please let me know. And if you can write a bit about it, even better.
What can you expect?
Once or twice a week, I'll post something that I, or someone who I respect, think that every developer should know.
The aim is to try and list information, or sources of information, that will be useful or relevant to any developer but sometimes things might be focused on a specific technology or language.
Who's writing it?
Me.
Hi, my name is Matt Lacey. I also have a personal blog which might tell you a bit more about me.
Do I think I know everything?
Definitely not!
Part of the aim of setting up this blog was also so that I could learn (directly from other people as well as by researching articles).
Got any more questions? Stick them in the comments. I'll do my best to answer them.
Subscribe to:
Posts (Atom)