Yet Another Eliot Blog

Updates from May, 2009 Toggle Comment Threads | Keyboard Shortcuts

• ty 2:55 pm on May 22, 2009 Permalink | Reply  

  Should You Really Be Optimizing Right Now? 

  C# is the language that is keeping the lights on right now. I had a conversation with a fellow programmer about refactoring and optimizing code. C# is compiled by a very refined compiler. I am hugely generalizing the process here, but the compiler can determine your intent and provide output based on that. This means you could write a method ten different ways and still produce the same output from the compiler. What does this mean? Let’s say I originally wrote a method and was happy, then I learn about generics. I rewrite the method to use generics. Rinse and repeat and eight times later, the compiler still produces the same output. Maybe my code is more readable after the ten refactors, or maybe not.

  I wanted to illustrate the unnecessary effort we sometimes fall victim to. A more wholestic approach would be this. Compose a solution to a problem, run your solution under some sort of load test, and analyze the results. Your analysis should show the inefficiencies. Then you target those areas for improvement.
   

  Reply Cancel reply

  Required fields are marked *

  

  Name *

  Email *

  Website

  

  

• ty 2:22 pm on May 22, 2009 Permalink | Reply  

  A Tester is an Ally and not an Enemy 

  Testers make your job easier so don’t give them a hard time. You would think most developers realize this, but most don’t. I have seen countless times where developers believe a tester is out to get them.

  

  I know some are thinking how does a tester help me. I write code and a tester will try to break that code. Let me let you in on something, you want a tester to find your bugs before it goes into production. Dealing with production bugs are stressful. Personally I like when something is found in a test cycle. That is one less issue to pop up when I am focused on some other project. Trust me, this will happen.

   

• ty 2:08 pm on May 22, 2009 Permalink | Reply  

  Read The Comments 

  There comes a time in a developer’s life where we have seen bad code. This happens relatively fast in your development. You pick up a new language, write some code, and comeback to it in a few months. You will be horrified at what you produced. Next time don’t beat yourself up about it. You are a better developer for recognizing your previous lack of skill. Because of this, you have improved.

  Next you have a situation where a developer can become jagged when it comes to documentation. You pickup a nightmare… tons of code and horrible documentation. You read the comments and look at the code and think, “This doesn’t do that!” Even though it seems like a waste of time to read it, you are learning valuable lessons.

  1. Don’t be this guy. Working with this guy is horrible. It’s even worse working after this guy. You and your coworkers come up with new words for the amount of pain this guy created. You want to be famous not infamous as a programmer.
  2. After reading you know some of the deficiencies of the system. You gain valuable insights of some of the potential problems you will encounter. If you find that a developers’ comments are vague or inaccurate, you may want to check that area first when encountering problems.

  I have a story to share. I was sitting in a code review recently. Someone asked me a question about a line of code, and I logically analyzed it right then and there. After I confirmed my code was correct, I gave a 30 sec blurb on why it was correct… and then I read the comment right above the line of code. I could have saved myself a minute by reading the comment first. I really blame the other person for not reading the comment first. Just kidding, but seriously if he read the comment it would have saved us both time.