About learning to estimate, I recommend the following book:
These are three top things for me:
1. The Boy Scout Rule - Robert C. Martin (Uncle Bob)"You don’t have to make every module perfect before you check it in. You simply have to make it a little bit better than when you checked it out."
To be honest this is not something I have followed throughout my career, and although I certainly try improve code where I can, I never did it per check-in. I do however feel that it is an awesome principle and should be something that is actually part of a code review process. It is all to easy to just say:
"It was like that already"
"that nasty code was there for years, I am not going to touch it."
"It never had any tests"
I work in a corporate environment were applications often last for 4-10 years. If part of the process is always to just make something a little better, everything from deleting unused code to writing a single extra unit test, year after year... it will end up with saving a lot of people a lot of time and money.
This seems obvious, but not always we make it better when checking in. It takes a lot of diligence to do that - and agreement in a team environment on what better actually means.
4. Continuous Learning - Clint ShankThis is a very important topic, we are in a industry that is constantly growing, changing, shifting and as a programmer you need to be learning and improving yourself wherever you can. It's very easy to get into a comfort zone and just rest on your laurels, I did that for a couple years, and I do regret it now.
Things I am trying to do to keep up and would recommend:
- Get a Kindle... then buy & read books.
- Use Google Reader add the popular blogs and website RSS feeds for your specific field as well as a couple outside your field that interest you.
- Start a blog, by putting my code and thoughts out there, I put in more effort knowing that it's going to visible than if I just wrote the code/article for myself. I also force myself to do 1 - 2 posts a week, ensuring that I must always find new content to learn about.
- Join an open source community, we generally don't get to do enough "technical" development in our corporate environments.
5. Record your rationale - Timothy HighThis is something that I feel is often neglected. Quite recently a project that I had been involved in for a long time hit the spotlight for all the wrong reasons: customer, user and management dissatisfaction. The first thing to be questioned was not the analysis, requirements, testing, management or expectations, but rather the architecture. Documentation discussing all the decisions, options looked at and reason for options taken would have been valuable. When things go fine, no one will even know about the document, but when things turn bad as they sometimes do having justification and documentation for all the major decisions will be a lifesaver.
That happened a lot in my experience. People will disagree, or some people will not have been involved in some discussions, and then you need to be able to articulate why some decisions were made. Most of the times new arguments and ideas were considered, but without recording your rationale, you may not be able to discuss them, especially in public forums like large meetings. I'd say that one should write the rationale and make sure it's in your head when the subject comes up - and obviously this assumes that you communicate effectively.