For the past 2 months I have been trying to reach a mythical state in our product backlog. It is called "the clean slate". Now this might mean different things to different people, but to me it is clearing out the old jobs and tasks so that I can start the new year with nothing hanging on from the past year.
I know that this is something that I am not likely to achieve. Nor even get close to. A development department in an organisation is always going to have things to do. If you don't, then it is likely that the organisation your working for isn't looking at going forward, but just consolidating its position.
So, what am I to do? The only thing I can think of is to go back to that old saying. "Just Keep Swimming". I am still going to aim to complete the backlog list before the end of the year, and so (I hope) reach that clean slate on our development backlog. But if I don't get it done, I will not beat my self up (too much). I will just keep at it.
Sunday, November 29, 2009
Thursday, November 26, 2009
Coding Rules
There are many rules when it comes to coding. Some can only be bent (they get broken and bugs magically appear); the rest can be broken. The question is which rules are ones you can break, and which can you bend? Here are some of my thoughts....
Firstly, try to make your code readable. It might take a bit of getting used to, but try to write code in functions where each function is 10-15 lines long. There might be a trail to follow to debug the code, but it is better than trying to untangle a mess of one big function that does everything. It can, when you think about it, also lead to more reusable code.
Know what the function of the code is to be before you start. This is one that can be broken. Whilst we as coders can't know the in's and out's of everything, we do understand functionallity. So, before you start, understand the inputs to what your writing, how it should be processed, and the outputs. Then take a step back and think about that you need to do. When I do that, it helps me to focus more on what I need to do, and usually means that I only have to do it once. A trap is to get an outline and start coding without thinking about what you need the code to do.
Finally, be teachable. In any code that I write, I try to always be of the mind that there is a better way to do it. It dosent mean that I am always rewriting my code and so get nothing done, but it means that when someone has an idea as to a different way of doing something, I do my best to look at what they are saying objectivily. Sometimes I am the one who is right, sometimes not. Many a time fellow coders, and even on the odd occaision non-coders, have suggested changes to my code that would make the code faster, easier to understand or just neater.
Anyways, these are just a few of my thoughts on the rules of coding. If you have any others let me know, this isn't ment to be a definative list, just some of my thoughts on coding rules.
Firstly, try to make your code readable. It might take a bit of getting used to, but try to write code in functions where each function is 10-15 lines long. There might be a trail to follow to debug the code, but it is better than trying to untangle a mess of one big function that does everything. It can, when you think about it, also lead to more reusable code.
Know what the function of the code is to be before you start. This is one that can be broken. Whilst we as coders can't know the in's and out's of everything, we do understand functionallity. So, before you start, understand the inputs to what your writing, how it should be processed, and the outputs. Then take a step back and think about that you need to do. When I do that, it helps me to focus more on what I need to do, and usually means that I only have to do it once. A trap is to get an outline and start coding without thinking about what you need the code to do.
Finally, be teachable. In any code that I write, I try to always be of the mind that there is a better way to do it. It dosent mean that I am always rewriting my code and so get nothing done, but it means that when someone has an idea as to a different way of doing something, I do my best to look at what they are saying objectivily. Sometimes I am the one who is right, sometimes not. Many a time fellow coders, and even on the odd occaision non-coders, have suggested changes to my code that would make the code faster, easier to understand or just neater.
Anyways, these are just a few of my thoughts on the rules of coding. If you have any others let me know, this isn't ment to be a definative list, just some of my thoughts on coding rules.
Subscribe to:
Posts (Atom)