Blog Home  Home RSS 2.0 Atom 1.0 CDF  
The Efficient Coder - Tuesday, March 14, 2006
There has got to be a better way of communicating with our computers!
 
 Tuesday, March 14, 2006

Why the efficient coder?

Well - There are really a number of different motivations/categories to care about the idea of becoming an efficient coder see if you can pick where you're at...

1)  You think you have an extremely stable position where you just show, up cut a little bit of code, not really deliver anything and pick up your paycheck, if this is you this blog really isn't for you...

2)  You have deadlines that never get met, but these deadlines aren't really that important, if the deadlines aren't that important your job/department probably isn't that important and hense when the next round of lay-offs you might be a good candidate, if not you might by in category 1

3)  You care some what about delivering your software on time and your project is understaffed so you're working 50-60 hours per week (an incompetant project manager/boss goes along way to put you into to this category)

4)  You're a consultant and get paid by the hour...the more you can get done in one hour (and sell yourself) goes a long way to boost your hourly rate...would you rather work 40 hours at $100/hr or 80 hours at $50/hr?

Kevin

3/14/2006 9:44:42 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]    |  Trackback
 Thursday, January 19, 2006

One thing that I've seen a number of times in a number of different clients is the following:

  • A team decides on an approach
  • The team spends considerable effort building support mechanisms for this approach
  • The approach that was decided on turns out to be invalid
  • The has to scrap all the support mechanisms built for this approach costing the effort days/weeks or in some cases months of time

There are two ways to avoid or minimize this type of problem:

  1. Make absolutely sure that the approach you are taking does indeed solve all your problems and doesn't have any "deal-breakers" that would invalidate using the approach.
  2. If you can be absolutely sure of the approach, try to build your support mechanism such that they are as generic as possible so if your initial design approach is invalid you don't have to scarp all your work.

The may seems obvious, but this is one of the bigger product killers I've seen out there.

1/19/2006 9:30:00 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]    |  Trackback
 Saturday, January 14, 2006

The Chaos Filter allows for identifying and capturing metrics on day-to-day assignments for a large number of knowledge workers.  As processes are defined they are put into a "portal" that will be used as a dash-board to capture metrics as work is completed.  Targets are established for tasks down to a fine level of granularity, if those targets are not met, that is OK in that they will be adjusted however and reasons are captured as to why things take longer than they should.

Once it is established why things are taking longer than they should, the process/job aids can be modified so that the next time the process is executed actual time may be closer than expected.

This same model can also be applied to the sales process.  Reasons can be captured as to why sales are not be closed.  These reasons can then be addressed.

An interesting challenge here is how to allow for an environment where the knowledge workers can feel empowered to suggest changes to optimze the process as well as try new things and make mistakes in an effort to be more efficient.  The problem here is not where people try and not meet the targets for their processes/tasks but where people try to "game" the system and take advantage of a situation where processes are closely being tracked.

The key here is worker efficiency, not making people work harder.

1/14/2006 9:28:30 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   Software Metrics  |  Trackback
 Friday, January 13, 2006

COMPLE - ATTACH - SWITCH - REFRESH - ENTER

Once changes are made in my application, I speak these words into my microphone.  At that point I can keep my hands on the keyboard and not get distracted by finding the mouse and then making the required clicks. 

Touch Typing is pretty good for keeping your hands on the keyboard and the occasional trip up to the function keys, but keeping your mind on the actual code and not on seaching for the mouse/click points/function keys is key for quickly evolving code.

1/13/2006 9:27:01 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]    |  Trackback
 Wednesday, July 20, 2005

For more information, please visit www.dasblog.net from newtelligence.

7/20/2005 2:00:00 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   dasBlog  |  Trackback
Copyright © 2009 Kevin D. Wolf. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: