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.
... 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)