I was updating the blog and getting a few advance posts in place for February 2009. Thanks Blogger.com for the neat features of scheduling blogs that you introduced last year. This saves me a lot of hassle in remembering to post pre-written content and also allows for me to have a blog day every now and then.
Anyhow, I was also reading a few "Top Ten" advice lists that were sent to me over the years by a trusted colleague called Jim. I always take the time to read these and he generally only sends over meaningful content and this time was no different.
This did get me thinking a little so I thought I'd write one and see if he agrees.
I have blogged in the past about what I believe makes a good developer.
Today, I'll issue my Top Ten tips for developers covering both work and life. In no particular order apart from number 10.
1. Always be on the look out for the next big thing (in IT) and see if you can get in early enough to actually ride the wave rather than be left behind frantically trying to swim there.
2. If you find something you like doing and the opportunity is there to continue doing it, then continue to do it! Don't be bullied into career progression if it is not for you. My old boss once said to me that there is a difference between earning and dying. Words of wisdom for everyone.
3. Always test your code no matter how trivial the change. You have no come back if you didn't test a change you have made, fullstop.
4. The ten minute tasks always seem to take a day, or two.
5. Never assume anything when it comes to user requirements or management reporting.
6. Never under estimate the desire of the testing team to see you fall on your developer sword.
7. Never code if you are drunk as you will need to recode the next day. Also never ever ever ever ever ever return to the office if you are inebriated. You will start to talk about 'Pink Screen' technology and how one day you will be everyones boss or worst case scenario, you will set off the fire alarm with a toaster and cause an evacuation of a 21 storey building. Again, certainly no come back here, you are on your own. Believe me, these are true stories......
8. Remember good quality applications and systems have corners. You simply can't cut them.
9. Remember it takes 20% of the time to build 80% of what the user sees and interacts with. The remaining 80% is making sure that they don't break anything.
10. Never compile a top ten list and not have a decent one for point number 10.
Thanks for reading.
Lee.
Well,
ReplyDeleteit's taken a while to respond to this, but respond I must.
Point 1.
Riding the wave can be dangerous – I know because the waves smashed my face at the weekend when I was surfing. But fun stuff aside, you need to catch the right wave. In the Microsoft world, one of the current hot topics is the Entity Framework and it’s close cousin Linq to SQL. To summarise the discussion, it looks like Linq to SQL is the wrong wave, even though it is a very good wave.
So choose a wave, choose it carefully and stay with for a few years. Synon was a good wave for more than a few years, but is Plex the next big wave? What is the next big wave for the AS400 world? Or are they more like ripples and the waves are happening on another beach?
Point 4.
You also need to throw into the mix the difference between elapsed time and effort time. The two are quite different. A 4 hours task (effort) spread over 4 days is a 4 day task (elapsed). You need to bear these in mind when you schedule your work otherwise, you’ll miss every deadline and be working to 11pm every night just to catch up.
Make the difference clear to your managers and your project managers. They understand this and occasionally recognise this.
The other thing to bear in mind is interrupts. These happen. It takes you 15 minutes to get back in the groove – 15 minutes of dead time. 8 interrupts a day – one per hour and 2 hours of your day is just recovery time. What a waste. Now here’s a challenge. Instead of saying I have an open door policy, try saying, I have an open door policy after 11am. Before that, I have to get through a certain amount of work for everyone’s benefit, please don’t disturb me during that period unless the building’s on fore or someone has burnt the toast.
Point 6.
As a developer it is your god given right to make testers redundant. You must strive to do this every single day. Naturally, as Lee points out, it is their job to make a fool of you. No-one is immune. Let the battle commence.
Point 8.
Another way of saying this. Just because you CAN do something, doesn’t mean you SHOULD do something. Software development sadly lacks a set of morals and ethics – but maybe at the higher levels it is getting there.
The most common mistake here, in my mind is updates to production code – the preceding model in 2E terms. You really, really need to make sure that the change to production is actually worth it. Double coding is always fraught with issues, so minimise this. Even if the customer is trying to bully you – ask the question, can you wait a few more weeks or months or has this issue really stopped you dead in your tracks. You need to test your code at least twice before going live with it –once in your dev environment and once in an independent one. This takes time. This is part of quality. Do not compromise.
Just because you CAN deliver after once optimistic test, doesn’t, mean you SHOULD deliver.
There are countless other examples in the software world and the real world. Try walking across a motorway!
Point 10.
You always need a decent point 10.
Always code as if the maintenance developer behind you is an axe wielding maniac. Some poor guy or gal will have to come and alter your code at some point in the future. Whether it be bug fixes or new enhancements. The code will be changed by someone. It is your duty to make it easy for someone else to maintain your code. This includes, but is not limited to following standards, or at least conventions, documenting your code in design specs, documenting your code at the code level – maybe even making it available to tools like Intelisense.
Got to go now.
Toodle Pip