Of all the changes I’ve made for self-employment, building up a system for getting and staying organized has had the most impact.  I’m a student of psychology, and I’m well aware of my mental limits for holding information.  I’m also a natural scatterbrain so … oh look a bird...  Anyway, the quicker I can get something out of my head and into a safe place, the more likely it is to get done.  So I’ve globbed several systems into my get-things-done process.

If you’re not familiar with the concept of a tickler file I suggest you watch this short video.  The system is genius, and rather than go into the details I’ll just say that this has saved my hide more times than I care to admit.

Another huge part of my get-things-done routine has been to use a personal wiki as a way to empty my brain and keep track of what I do during the day.  My wiki of choice is tiddlywiki because it requires no server and is highly customizable, and I use Dropbox as a way to share/backup the wiki as I roam the universe.  The pomodoro time management technique keeps me on task during the day, and I’ve integrated a pomodoro timer and task tracker into my wiki’s journal feature:

Finally, I tend to carry a hipster PDA on a lanyard around my neck when I’m away from the keyboard.  Anything that I need to remember, that I think is interesting, or that I’m afraid I may forget gets jotted down on a card.  When I’m back at my desk I process the cards.  If the card indicates something date sensitive, I just drop it into the appropriate of the 43 folders; if the card is a project idea, it goes into the wiki.

Not terribly technical or fancy, but it works like a champ and, most importantly, it’s easy to do and doesn’t get in my way.

I just got back from hearing Andy Hunt discuss his new book, Pragmatic Thinking and Learning.  I hadn't heard him speak before, and I have to admit I was not sure what to expect.

On the one hand, I hold many of this books in very high regard.  In particular, the following books were career-altering reads for me:

• Practices of an Agile Developer: Working in the Real World (Pragmatic Programmers);
• Pragmatic Unit Testing in C# with NUnit, 2nd Edition; and of course...
• The Pragmatic Programmer: From Journeyman to Master

And his keystone role in the Agile movement has earned my utmost respect.  However, when I saw the title of this latest book I was a bit worried.  I have a master's degree in cognitive psychology, and I know a lot about learning, memory, and perception.  Most learning books outside of the field are crap, so honestly my first instinct was that this was going to be a cash-grab treatise of self-help porch psychology fuzzy-feel-goods for software developers.

After listening to Andy's presentation, I am happy to say my instincts were way off the mark.

First of all, the book (and Andy's presentation) remains true to the pragmatic banner.  His recommendations are both practical and effective.  For example, a recurring theme during this talk was to write things down.  Carry around a small notebook and jot down every idea that pops into your head.  Maintain a personal wiki.  Mindmap as you read or think.  Solidify your thoughts into something concrete.  The point is not to be able to refer back to them later, but instead to force your brain to keep working, keep producing, keep processing.  To summarize one of his points, that's the first step to an accomplishment.

Second, a lot of what he was saying is supported by academic research.  Granted, Andy takes some license with his metaphors but his points hold water.   E.g., what Andy refers to as the "memory bus" being shared between "dual cores" of the brain is probably more of an attention effect; however, the behavioral effect cannot be denied - the serial and holistic parts of your mind compete when trying to solve a problem.

Based on the presentation tonight, I wouldn't recommend the book to my former psychology colleges - it's too macro to be useful to them.  However, for my fellow geeks, this is actually a useful introduction to becoming a more effective learner.

It was a great talk, a fun evening, and I plan to pick up the book next time I'm at the bookstore.  Oh, and I had a short chat with Andy just before the talk, and I have to say how awesome it is to meet someone you hold as a guru and detect no ego.  Awesome.

I want to refactor some code to a strategy pattern to isolate some complex authentication procedures, rather than have hard-coded behavior that prevents unit, load, and performance testing.  I just had a very frustrating discussion about it ...  

Developers talk about their code as if it were people all the time.  I do it, you do too.  Most of the time it's harmless, as in this little quip I said this morning:

"So when the service wants to authenticate the client, it will ask whatever authentication strategy is available."

Everyone in the conversation obviously knows that the application isn't capable of wanting or asking, and that these are metaphors to hand-wave over the technicalities of calling on an object.  No harm done; but consider the reply:

"But how would the service know that the client was really authenticated unless it does the work itself?"

Both examples show a kind of anthropomorphism ( like when your car won't start because it's upset with you for not changing its oil, or that your laptop doesn't like the couch because it won't connect to your wireless network there ).  Wants and asks describes dependencies and actions of the software - in short, the software's behavior.  Know attributes a conscious state to the software - that it somehow can understand the difference between doing some work and calling someone else to do the same work, which is nothing short of a direct demotion of a functional requirement ( the service MUST authenticate all clients ) into a software implementation ( this class MUST contain all authentication code ).

There is no homunculus in the software.  There is no little dude sitting in a virtual Cartesian Theater watching the bits fly by and getting upset when things don't happen the way he thinks they should.

Software doesn't know anything.  Software does whatever it is told to do.  If the service contains the authentication code, or if it delegates to a strategy that performs the same action, the behavior is the same.  Given that, if the former is prohibitive to testing, I say do the latter and test my heart out!!

I stumbled on an interesting service called Typealyzer that attempts to fit a person into one of the Myers-Briggs profiles based on the writing in their blog.  Based on my blog, it reports me as INTJ - Scientist, or:

• Introverted (vs extroverted)
• iNtuitive (vs sensing)
  
• Thinking (vs feeling)
• Judging (vs perceiving)

From my Typealyzer result:

This seems accurate with how I would assess myself; I found more detail on being INTJ here, along with details on the other 15 profiles. 

I thought it would be interesting to see what types of writing I'm drawn to.  So on a larf I ran through a short list of my favorite blogs and found the service to hit the mark rather well: not as many INTJs as I would have thought, a few ENTJs and even one ESTP, but not a single F in the bunch.  Not sure what THAT says about me ....

So, what profile are you?