I feel like I’m cheating myself and my customer (read employer), so I’m going to do something about it.  I’ve never read much of Covey, but @shanselman mentioned Covey’s quadrants (see a mind-map version below) in this video I watched the other day.  For me, living only in quadrants 1 & 2 (the top two) is all good, but there are times when I basically want to just ‘check out’ and be a bum (Office Space style).  My goal is to be intentional and choose when I’m doing that, rather than just letting it happen.

Baby Steps

The pomodoro technique is a great start to help manage and become aware, but I need some help.  Here’s what I set up for myself at this point:

• Pomodo7o with Growl Plugin
• Growl using the Visor notification (I don’t like toast, so this is great for me)
• VirtuaWin (for Windows, this is built into most other OS’s, e.g. Spaces on OSX)
• Throw ALL distracting things to a second VirtuaWin workspace.
  • Gmail
  • GReader
  • Twitter (turn off twitter notifications)
  • Outlook (turn off new mail toast and new mail tray indicator)
  • Evernote (turn off any messages)
  • Windows Live Writer
  • Time tracking applications
  • Anything else that dings/hoots/toasts or otherwise distracts you
• Only check email (Gmail and Outlook) during pomodoro breaks or other scheduled times
• Only check twitter during pomodoro breaks or other scheduled times (I’ve started only checking twitter before I start work, and right before I head home).
• Hook Outlook into Growl so I don’t miss meetings
• Keep a text file or post-it note ready to capture interruptions.  Most interruptions can be logged, and then dealt with in a subsequent pomodoro.

I only allow myself to go over to my other desktop during a pomodoro break.  This makes it really easy to know when I’m going off task.  It also makes it REALLY hard to find something wasteful to do.  There isn’t anything in my “workspace” that is wasteful anymore, so if I do ANYTHING in there, it’ll probably be productive.

Feeling Too Disconnected?

I’ve got the shakes!  Doing this thing cold turkey is hella hard.  So here’s a patch to wean you off.

Download Trowl and hook up @’s and DM’s (and select other folks you might need to hear from throughout the day).  Now those tweets will be Growled at you.  I don’t get @’ed or DM’ed too often, so it’s not terribly distracting, but has high reward in helping to reduce the withdrawal symptoms.

I’m just starting, so this is my first attempt really.  How do you manage?

Basically, I wanted a gentle introduction to the Pomodoro Technique, so I thought, what better way to introduce myself to it, than to build a pomodoro app while pomodoro’ing (new word, probably).

So I whipped up an app that uses some of the fancy taskbar features of Windows 7.  If you don’t have Windows 7, this thing is going to be pretty useless to you.

Intoducing… Pomodo7o:

• Simple
• Provides minimal distraction (to keep flow)
• 25/5 Pomodoros
• Pause/Reset [I know, I know, but sometimes you just gotta]
• Awesome
• Taskbar Progress Indicator
• Taskbar Thumbnail Controls

You may not know what the heck I’m talking about on the last two bullets and they probably sound like some bullet point on a marketing brochure created by the marketing drones at Microsoft (wait… that is where those names came from).  They’re both Windows 7 features which I think are pretty cool.

Here’s a couple screenshots for ya… the first one shows the progress indicator.  The progress is how far you are into your pomodoro.  The second one shows the thumbnail controls when you hover over the tomato icon.  You can pause or reset your current pomodoro using those buttons.

Take it or leave it… either way, it’ll be a fun toy to play with.

Feedback/Requests: http://pomodo7o.uservoice.com
Source: http://github.com/jonfuller/pomodo7o
Download: http://github.com/jonfuller/pomodo7o/downloads
Bug Reports: http://github.com/jonfuller/pomodo7o/issues

Out!

<sigh_of_defeat>Shoot, we didn’t get him.</sigh_of_defeat>

As if we failed miserably.

For me, the apprenticeship/intern process has the following 4 goals (in order of importance, most to least).

• Teach and develop the apprentice as much as they can possibly absorb.  This includes technical skills, sof-tech skills (like how to learn, what it means to be an engineer, passion, etc.), and soft skills (e.g. how to deal with your lead/PM/that annoying guy next door, etc.).
• Learn from the apprentice as much as I possibly can.  These guys are at school at an amazing time with amazing things happening.  Leech this new knowledge… it’s relatively free. (I’m unapologetically selfish in this regard… I love to learn
• Develop an environment where the apprentice feels comfortable with his mentor, and can start to learn and teach with his mentor back and forth… a true partnership.
• Oh yeah, the last/least benefit… recruiting.  (Sorry Raman)

If at the end of this he happens to also be productive, great, win-win… but that isn’t the point (again, that’s my opinion).

After that list, does this look like defeat?  Not to me.  This looks like a dead-on success.  We NAILED it.  Let’s celebrate!  Congrats Man.  Next time we meet, I’m sure I’ll have something to learn.

[I’m at least going to pretend I played some small part in this outcome.  Whether I really did or not, is debatable.]

If you don’t want to follow the link…

Just double click that guy, or drag it downward, and you’ve split your file into two buffers.  Awesomeness.

Singletons are teh suck.  Don’t use them.  EVAR.

to

Singleton’s saved my life and marriage!

In fact, I might’ve been the person that said both of these… gasp!

I never like to speak in absolutes, so I’ll say it this way (see what I did there?)… if you’re striving to implement a singleton, you’re probably wrong.  For all you guys that are right, I guess you’re right, and you can leave now, I guess.  This might help you out.

I was reading a blog from Mr. Dependency where he was talking about statics and basically what amounts to global state, and how that binds you into globally available, global data, which usually (always?) turns into anarchy.

How do we always get ourselves into this mess if we know it’s bad in the first place?  Well, some of us (those who are now zombocomming, from above) don’t know it’s bad in the first place, and the rest of us probably do it because it’s easy to implement, and we understand it.  Long story short, we can do the singleton implementation in our sleep, so we pull out the singleton hammer, and smack the nail.  It always goes in a little sideways, but at least it goes in.

Maybe we should be using a different hammer?

What I’d like to do now, is propose to split singleton in two.  I think there are two distinct responsibilities that the current thought of ‘singleton’ introduces. It:

• Manages Session Scoping/Lifecycle/Lifestyle (albeit, poorly, only one strategy is available)
• Disables the ability to create more

When I talk about this out loud, I call the two approaches the singleton implementation pattern, and singleton lifecycle.

What I am a fan of, is the singleton lifecycle.  You create one of those objects, and use it throughout the application.  You don’t get messy and allow global access to it all over the place (which necessarily happens when you have global state).  You intentionally inject it to collaborators, and  intentionally don’t inject it to non-collaborators (don’t just hand this guy out willy-nilly, he’s important).

So naturally, the naysayers ask/demand:

How do you manage that there is a public constructor on this class!?  Dev’s are going to be new’ing this thing up all over the place!

I say:

False.  Use a DI tool and let it manage it for you.  Or establish a convention with your team, and enforce it through social contracts.

Both of these approaches allow your scope lifecycle turn into whatever you want at any time, in case you decide global isn’t what you really want.  It can be application session scoped, or some other scope, test scoped, or whatever you want… incredibly flexible.

If you go with the DI tool approach, instead of tying yourself to a particular scope, you can now have any scope you want, by changing a configuration parameter.  Delaying decisions until the latest responsible moment… seems like I’ve heard that one before.

Every software project is different, and there are subtleties associated with each one.  Every project  requires unique and specific tools, and we need someone to build them, or each member of the team needs the freedom and responsibility to do it him/herself.

I have very little (zero?) tolerance for waste when it comes to automatable processes that aren’t automated because “we don’t have time”, or “we’ll discuss it later” and then it gets dropped, or any other reason that is less than justified.

Zero Friction Development is what I’m going for here. (here is an article that I found interesting around this topic… it’s not really our fault, it’s built into our nature)

What kinds of things am I talking about?  Anything that slows down my development that can be automated away to make me a happier developer.  Whoa, wait, happy? Is that a requirement I have of my workplace?  Absolutely.  I can put up with periods of un-happiness, but long-term unhappiness is not acceptable (for me).  Oops, sorry, almost derailed there for a minute.

Specific frictions I’ve addressed or have seen addressed…  just so you can get an idea about the things that I’ve seen done, that might trigger an idea for you:

• Code-diff generation – On a previous project, all the code for our product was stored in the database itself (Intersystems’ Cache), so we didn’t have a real decent way to generate diff-sets for code review.  So we wrote a tool to do it.  A previously laborious task (at least 30 minutes for a simple changeset), with much room for human error, turned into a 30-second, enter in a task number and press ‘Go’ joy.
• Code Generation – On a previous project the best way to get where we needed was simply to inspect the structure of a piece of data, and then generate code to deal with it.  You’ve probably done this one before… many times.
• Source Control Integration – Again with the Cache project, we needed a way to version our code using standard tools.  We wrote a tool to bridge between the file system (for TortoiseCVS, or any other VCS) and the database storage.
• Client requires code-diff uploaded to their CMS for each completed task – Seems like a bogus business process, but it needs done.  It’s painful because their CMS is slow and clunky.  So I wrote a ruby script, paired with selenium, to automatically create a diff of my code and upload it to their CMS with some browser automation.
• Data generation – Ever need test datasets?  Yeah, me too.  Whip out some ruby and get it done.
• Tool integration – ever have two systems that need to be kept in sync?  Yeah, it’s a pain, especially when neither have an API.  What they both usually have though is either a command line interface or a web interface.  Both of those are easy enough to script with, given some ruby magic and some browser automation.
• Time tracking – There have got to be 8 billion time tracking tools out there… if one doesn’t match your style, bust out a quick one that matches the way you work.  Need it to integrate, there’s probably either a web interface, command line, or API, go for it… it’ll make you happier (hmm… there that is again!).

What other things have you automated?  What are your thoughts on the toolsmith?  There is a whole book about doing this type of stuff with Ruby.  I’ve never read it, but I’ve heard it’s pretty good: Every Day Scripting with Ruby.  Another excellent book by the guys at the prag bookshelf is Pragmatic Project Automation.  It deals a lot with things we already do (build automation), but takes it further as well.  Here is an intro: Pragmatic Project Automation Intro.

For sake of full disclosure, this is not a new idea, and I’m not claiming to have come up with it.  It’s been tossed around for years, just wanted to bring it up again.

I hadn’t ever really thought [at least not too much] about how to solve this problem until I heard Matt verbalize it like this a couple months ago:

I first try to gauge where the person is, and try to respond at a similar level.  I also adjust the response as I get visual feedback from the person as they are listening to my response.

Whoa.

I have been acutely aware of a person’s inability to do this every time I ask a question ever since I heard Matt say this (Shoot!  Now I’m ruined!).

So here is how I try to debug your question (and you) so I don’t irk you off when you come to me with a question:

• Think about the problem first.
• Understand the problem/Be empathetic.
• Assess where you are in the solution space of the problem, so I can give an answer in a neighborhood relevant to you.
• Start trying to help solve the problem.
• Be clear and specific.
• Change my response based on any feedback I'm receiving from you (verbal or otherwise).
• Respond with help that leads you into the pit of success.

I’ve come up [involuntarily… sorry, just something I do] with a list of don’ts when I ask you a question as well:

• Don’t blow me away with your superior knowledge/expertise/arrogance/cockiness/awesomeness.  I already know you’re awesome… that’s why I asked you!
• Don’t drown me with inane details.
• Don’t be condescending.
• Don’t be vague.
• Don’t pretend to know if you don’t.  (Hint: I can tell when you don’t!)
• Don’t yell at me, or yell about someone/something else, or go off the hook for some other reason. Not cool.

Reflecting over those two lists, looks like the moral of the story: Be a good listener, be resepectful, don't be an a-hole. Sounds about right

Do you run into this (or think about it)? How do you try to solve it (from both sides of the question)?

Why do we feel like our company ought to buy our tools for us?

This is an interesting concept to me, because, as of late, I’ve been considering pimping my work area to be mine… just as any other craftsman might.

My dad is a skilled tradesman.  He’s a Mould Maker in a glass shop.  He’s been doing this for over 30 years… and he is what I’d call a master craftsman.  I asked about the idea of owning your own tools last weekend.  He nearly interrupted my question by saying:

Yeah, I’ve got about $6000 of my own tools.

I stood floored.  I had no idea.

Previously, I considered the idea to include things like my IDE (Visual Studio, since it is somewhat expensive), ReSharper, Profilers, Editors, Static Analysis Tools, and more.  I also feel like this applies to books (you do read [tech] books… right?).  Someone asked me the other day:

so how do you get SEP to just buy all of your books?

… uhhh, I don’t.  I use my own money.

I can only assume that all machinists have their own copy of the machinist handbook as well.

I actually do have my own copy of all the tools I [willingly] use every day.

Do you?

P.S.  I’ll leave you with one more thought.  I challenge you to add one more piece of equipment to your tool chest (or to at least think about it)…your dev machine.  Should your company provide you with a dev machine?  Why not?  Why so?  I had never considered this until I read this article talking about Hashrocket.  They all use their own machines!

Update:
I think my lack of skill in writing prose has caused some confusion or misunderstanding [Thanks for the feedback!  For Reals.]  This was really meant to be more about responsibility and craftsmanship than about money (or anything else).  The main thought I wanted to invoke was who's responsibility is it to buy/make your tools?

I also did not try to infer that SEP doesn't buy me all the things I need (I'm sure they would, in fact... I just wonder who's responsibility it really is).

Sorry for any confusion.

I live in a .NET world most of the time, and I know of no similar solution for .NET.  It’s been awhile since that first time, and I’ve tinkered here and there trying to get something comparable, but usually come up short.  That is until I found watchr.

Watchr gave me the file change detection capabilities I needed, and the extensibility to do whatever I want when a file has been detected as changed.  This made it incredibly easy to hook up some autotest goodness in my .NET world.

You'll have to have ruby installed, and gems.  Then, the very first thing you'll have to do is

gem install watchr --source=http://gemcutter.org

Here is my watchr script:

require 'autotest.rb'

watch( '^.*UnitTest.*.cs$' ) do |match|
  run_test(match.to_s)
end

This is basically just a regex that says to watch any *.cs files that also contain the string “UnitTest”, and when it finds a change in a file matching that description, call run_test with the matched file name.

So all the magic is in autotest.rb… lets check it out:

require 'rexml/document'

def build(test_project)
  `msbuild /nologo #{test_project}`
end

def mstest(test_container, test_results_file, tests_to_run)
  tests_to_run = ([""] << tests_to_run).flatten

  File.delete(test_results_file) if File.exists?(test_results_file)
  `mstest /nologo /resultsfile:#{test_results_file} /testcontainer:#{test_container} #{tests_to_run.join(" /test:")}`
  test_results = process_mstest_results(test_results_file)
  File.delete(test_results_file) if File.exists?(test_results_file)

  return test_results
end

def process_mstest_results(results_file)
  results = {}
  File.open(results_file) do |file|
    xml = REXML::Document.new(file)

    results[:num_tests] = xml.get_elements("//UnitTestResult").length
    failures = []
    xml.elements.each("//UnitTestResult[@outcome='Failed']") do |e|
      failure = {}
      failure[:message] = e.elements["Output/ErrorInfo/Message"].get_text

      stack = e.elements["Output/ErrorInfo/StackTrace"].get_text.value
      stack_match = /^.*at (.*) in(.*):line (\d+)$/.match(stack)

      failure[:stack] = stack_match[1] if stack_match
      failure[:location] = stack_match[2] if stack_match
      failure[:line] = stack_match[3] if stack_match

      failure[:stack] = stack if !stack_match

      failures << failure
    end
    results[:failures] = failures
  end

  return results
end

def show_results(results)
  puts "#{results[:num_tests]} tests run (#{results[:failures].length} failures)"
  results[:failures].each do |failure|
      puts "---------------------------------------"
      puts "Message: #{failure[:message]}"
      puts "Location: #{failure[:location]}"
      puts "Line: #{failure[:line]}"
      puts "Stack Trace: #{failure[:stack]}"
  end
end

def run_test(file_name)
  test_container = ""
  test_results_file = "result.trx"
  test_project = ""

  system("cls")
  system("echo Detected change in:")
  system("echo   #{file_name}")
  system("echo Building and Testing")

  test_namespace = ''
  test_class = ''
  test_names = []

  File.open(file_name, "r") do |f|
    f.each do |line|
      ns_match = /^namespace (.*)$/.match(line)
      test_namespace = ns_match[1] if ns_match

      class_match = /^\s*public class (.\w*).*$/.match(line)
      test_class = class_match[1] if class_match

      test_name_match = /^\s*public void (\w*).*$/.match(line)
      test_names << test_name_match[1] if test_name_match
    end
  end

  test_names = test_names.map { |n| "#{test_namespace}.#{test_class}.#{n}" }

  build(test_project)
  results = mstest(test_container, test_results_file, test_names)
  show_results(results)
end

The key parts (I think) are the fact that I’m using MSTest to run my tests (this can easily be modified to run your framework of choice… note MSTest is not my choice ).  The result parsing is also specific to the MSTest output format, but should be simple enough for any framework that can output XML. Also, I'm making some assumptions based on my project... we've got one unit test project, so I know I can run tests in a single DLL, and rebuilding only that project, I don't have to worry about choosing the correct project and output dll to build and run tests in.

To get the thing up and running, just run

watchr <path to watchr script>

Please, use/adapt/give feedback/whatever at will.

Go forth and autotest, .NET comrades!

Which camp do you live in?

I’d say I [mostly] live in the viewing things as stagnant camp (it’s nice and cozy in my camp, won’t you come join me?).  I’m not trying to say there is anything wrong about believing and adhering to things that we know already work (stable), but what I am trying to say is that we can use stable as a platform to continually achieve better.

If you live over in stable-ville, you’re probably asking questions like:

• Why change it if it already works?
• We’ve done this before, let’s just do it that way, it’s safer (why would we possibly introduce risk!?).
• We made money doing this the last time, if we do it the same way, we’ll make money doing it again.

I admit, you ask great questions.  It’s hard to win an argument against [apparent] concrete profitability.

Here are my sentiments, however, in response to those questions.

First you must assume that things can always get and be better.  I’m not asking to make huge sweeping changes and walk away.  Rather, embrace the stable approach, incrementally make changes, measure, rinse and repeat.

Of course, if things seem to be broken, or you seem to have hit some ceiling (most likely artificial), you may need to take a step back, and take a completely alternative approach.

The key to making change to any subject for the sake of improvement is measuring.  Know what it is you’re trying to optimize, measure it, make the change, and measure it again.  That is the only way to know if you actually got better, worse, or had no impact at all.  (In a slightly related note, Steve McConnell, in Code Complete 2 drove this into my skull at least 50 times during his performance tuning chapters, and I agree whole-heartedly).

Oh, and on that profitability question?  You better always be changing (don’t forget to measure!) otherwise you’re gonna get leapfrogged into oblivion and your competitor that you didn’t even know existed is going to be raking in all your cash.  Likewise with risk.  If you’re not taking risks and just sitting in your comfort zone, you’re probably not growing as an organization or as an individual.

For me, it’s all about continuous improvement.  Don't let stable be the enemy of change, strive for improvement.

If you’re not getting better, you’re getting worse… right?