Sunday, November 30, 2014

Setting Ground Rules

Things i will be following for sure.

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

2. Beauty Is in Simplicity – Jørn Ølmheim
“The bottom line is that beautiful code is simple code.”

3. Step Back and Automate, Automate, Automate – Cay Horstmann
I believe in automating everything possible: builds, deploys, code analysis, unit testing, functional testing, integration testing. 

4. Continuous Learning – Clint Shank
This 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:
  1. Get a Kindle… then buy & read books.
  2. 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.
  3. 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.
  4. Join an open source community, we generally don’t get to do enough “technical” development in our corporate environments.
5. Check Your Code First Before Looking to Blame Others – Allan Kelly

6. Hard Work Does Not Pay Off – Olve Maudal
“truth is that by working less, you might achieve more”
“If you are trying to be focused and “productive” for more than 30 hours a week, you
are probably working too hard.”
7. Comment Only What the Code Cannot Say – Kevlin Henney
Need to put more and more comments. For me.

8. Know Your IDE – Heinz Kabutz

9. Learn to Estimate – Giovanni Asproni
I feel this is something that comes with experience, I pride myself on my estimates and over the years I have tried to nurture this “skill”. I have a couple points I would like to share on how I get better estimates:
  1. Be honest with yourself, make sure you know what you think you know, and openly admit what you don’t. This is the quickest way to end up in trouble.
  2. Keep track of what you do and how long it.

1. Understand The Business Domain – Mark Richards

2. Before anything, an architect is a developer – Mike Brown
“If you design it, you should be able to code it.”

3. Dealing with Developers

Balancing the control and freedom.

4. Performance
There are 2 topics about performance:
It’s never too early to think about performance – Rebecca Parsons
Application architecture determines application performance – Randy Stafford

5. Record your rationale – Timothy High
This 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.

6. Stand Up! – Udi Dahan
“The easiest way to more than double your effectiveness when communicating ideas is quite simply to stand up.”