Is it time you tried some new programming habits?
This is something my Taekwondo instructor is always going on about, we practice TKD twice a week so if we are attacked then we will just react out of habit. It's important you must practice hard so that when it comes to the crunch you hit full power outside when you are being attacked.
That isn't really that relevant to the point I was going to make but it's a slightly interesting story so I thought I would put it in. I
Ship It!: A Practical Guide to Successful Software Projects
It is a book about development and I am always quite interested in these books because it's like getting the advice from an experienced programmer about how you work. Not about coding but about the whole programming concept.
In the first chapter they are talking about Habits and people just get into the habit of doing things because that's the way they were shown or that's how people do it at a certain company. I am always keen to try and improve my development process and if someone with a lot of experience is going to give me some advice (via a book in this case) then I am going see what they have to say.
Talking of habits reminds me of when I first became a Java programmer I would often do things that I would know worked but without really knowing what they're doing. The more experienced programmer showed me how to solve my problem but didn't really tell me how it solved the problem or why.
It's always interesting when you work with new developers to see their work processes and code. Everyone is usually very different, everyone does bits of some methodologies whilst excluding other bits. The main person to benefit is you when working with different people because you can see how their way of doing things is different and then you can take bits and put them into your own style. One person I worked with was very into preparing things at the start with a requirements documents, UML diagrams and then after all that he would start coding. Initially I thought this looked like a lot of work but he did it and his code always worked very well, so I thought I would give it go. Now I do it all the time and find it very useful and I was even blogging about it the other day
Planning cuts time bug fixing
So back to my point. The chapter starts off by saying, try a bit of a new methodology, try it for a week and if you like it, try it for a month. It's true, if it turns out to inefficient then you can go back to your old style knowing that it's quite good and if the new method turns out to be beneficial, well you have benefited.
That isn't really that relevant to the point I was going to make but it's a slightly interesting story so I thought I would put it in. I
Ship It!: A Practical Guide to Successful Software Projects
It is a book about development and I am always quite interested in these books because it's like getting the advice from an experienced programmer about how you work. Not about coding but about the whole programming concept.
In the first chapter they are talking about Habits and people just get into the habit of doing things because that's the way they were shown or that's how people do it at a certain company. I am always keen to try and improve my development process and if someone with a lot of experience is going to give me some advice (via a book in this case) then I am going see what they have to say.
Talking of habits reminds me of when I first became a Java programmer I would often do things that I would know worked but without really knowing what they're doing. The more experienced programmer showed me how to solve my problem but didn't really tell me how it solved the problem or why.
It's always interesting when you work with new developers to see their work processes and code. Everyone is usually very different, everyone does bits of some methodologies whilst excluding other bits. The main person to benefit is you when working with different people because you can see how their way of doing things is different and then you can take bits and put them into your own style. One person I worked with was very into preparing things at the start with a requirements documents, UML diagrams and then after all that he would start coding. Initially I thought this looked like a lot of work but he did it and his code always worked very well, so I thought I would give it go. Now I do it all the time and find it very useful and I was even blogging about it the other day
Planning cuts time bug fixing
So back to my point. The chapter starts off by saying, try a bit of a new methodology, try it for a week and if you like it, try it for a month. It's true, if it turns out to inefficient then you can go back to your old style knowing that it's quite good and if the new method turns out to be beneficial, well you have benefited.
posted by The Hosk at
10:06 pm
0 Comments:
Post a Comment
<< Home