Cross post from IRefactor  –

Here is a scoop; The good software engineer is lazy!
You don’t believe me? Then ask yourself this: If a good software engineer was not lazy why would he:

  • Automate processes?
  • Reuse a function instead of duplicating its code?
  • Explicitly name a function for its behavior instead of naming a function F1 and providing a non descriptive (and possibly long) documentation?

Yet, here is another scoop; The bad software engineer is lazy too!
While this statement clearly isn’t a shock to you, it immediately pop-ups the question:

What is the difference?

The difference is that a good software engineer is lazy in a constructive way (which allows to build reusable software and automated processes) while a bad software engineer is lazy in a destructive way (which destroys any chance for a reusable software and dooms you for long hours of struggling to understand and fix the bad code).

And here is a short example:
The var keyword allows implicitly typed variable declaration.
To tell the truth, it doesn’t allow to be a bad lazy software engineer! 
Why bad? Take a look at the code below:

var database = DatabaseFactory.CreateDatabase();
What is the meaning (meaning = type) of the database object in this context? Do I really need to guess that? Does somebody expect me to go to its definition to find out?

foreach(var observingStore in wareHouse.Stores)
What is the meaning of the observingStore object in this context? Was it named observingStore due to its implementation of the Observer pattern (which implements IObserver), or is it just an object name of a Store, ObserverStore or even ArgicultureStore class type?

Remember, you want to be lazy in a constructive way; You want to read those lines of code without wondering. You want to immediately grasp the meaning (types) of the objects you are dealing with, without switching the context and jumping to a different location just to refresh your memory.

The var keyword was introduced for one and one purpose only; To allow usage of anonymous types. Therefore, this is the only place you should use it! Unless you are a bad lazy software engineer (which clearly is not the case 🙂 ) you will follow the rule!

7 Things Your Boss Doesn’t Understand About Software Development

original article here

  1. Technical debt slows down a project more than anything else
  2. Estimates are mostly bullshit
  3. It can be done right or fast
  4. Some developers can actually produce less than 0 code
  5. Better equipment is one of the cheapest productivity investments you can make
  6. New technologies are usually not as risky as you think
  7. Business analysts and project managers don’t do shit

Leave a comment to let me know what you think programmers?

Happy coding