The four golden rules to be a better software developer.
The research to become a better software developer is core to any good software developer. Being a better software developer reflects directly in the code you produce, the better software developer you are, the less bugs, easier to read and easier to maintain code you will produce.
What follow are the four rules I use on my day to day work to help me become a better software developer.
Rule number 1: My code is crap.
All code is crap, and that includes yours, (and mine, of course). No matter how brilliant a piece of code you think it is, there will be always better ways to implement it, and several programmers who will hate it.
Even if you are sure your code happens to be good, force yourself into “my code is crap” mode, and ask around about improvements, be open minded and you will see soon how you will find issues in your code that you never have thought about.
Rule number 2: Even if it’s crap, I care about my code.
It is not about creating the best code upfront, is about making it better every time you visit it. When you finish some functionality, you are not done, I haven’t met any programmer that produces acceptable code on their first attempt, you need to polish it. Refactoring is then one of the main activities you should be performing.
Rule number 3: My opinion about my own code is wrong.
We are so egocentric that we end up believing that what we have produced, no matter how bad it is, is the best solution as possible. Never trust your own opinion, show your code to as much developers as possible and listen to them.
Rule number 4: My manager doesn’t care about my code, and he pays me.
This rule regulates the other three, it is easy to forget that you actually get paid to get things done, your manager should also care about the code, but he is more focused in completing things on time with an acceptable quality, so be careful not to expend too much time just making sure your code is not that crap. The key is being able to balance getting things done and their quality.
Bonus: A few tips to help you with these rules.
Related posts:
![[Google]]( http://www.makinggoodsoftware.com/wp-content/plugins/easy-adsenser/google-light.gif)
[...] This post was mentioned on Twitter by RoadHouse and Ben Armstrong, Steve Levine. Steve Levine said: Four rules to be a better developer: http://bit.ly/16AH6v [...]
Tweets that mention The four golden rules to be a better software developer. | Making Good Software -- Topsy.com
10 Nov 09 at 7:53 am
Nice. My code isn’t always crap when I first write it, and in those cases I will hunch over it and mutter about “my precious.” But I can be sure that soon enough, I (or someone else) will need some functionality that I didn’t quite figure into the initial architecture, and the crapification will begin.
Cujo
10 Nov 09 at 8:23 am
You seem to have missed the point of your own title. Good title, meaningless content. How does knowing my code is crap improve it?
Jim Danby
10 Nov 09 at 8:51 am
[...] via The four golden rules to be a better software developer. | Making Good Software. [...]
On the 8 Spot » rePost::The four golden rules to be a better software developer. | Making Good Software
10 Nov 09 at 6:29 pm
Rule No 4 can be such a pain in the a** sometimes. It collides with rules 1, 2 and 3 many times. If only managers could understand how tricky it can be to get things write considering the time they require.
Time estimates always seem to go haywire especially when trying to solve something you did not expect would occur in the first place. How do you estimate that?
Kevin
26 Feb 10 at 8:43 pm