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?

Justin Etheredge recently posted Being Smart Does Not a Good Developer Make, in which he offers several important perspectives in his usual good-hearted way; the one that sparked my neurons was that drive and curiosity are more valuable than raw knowledge to becoming a "good developer."

I whole-heartedly share this perspective.  This is probably due to the fact that I've painted myself into a professional corner in many respects.  I have no formal education in my chosen profession of software engineering, which has historically put me at a disadvantage in job interviews, when I push to lead a project, and in a lot of interaction with my peers.  Nevertheless, I've been able to land the jobs, get the project leads when I want them, and feel confident - if reservedly so - talking with my fellow engineers without sounding like a total poser.

I attribute my success to three things:

1. I've been pretty lucky with my opportunities;
2. I'm insatiably curious about most things;
3. I have two degrees in psychology. 

Justin calls software engineering a meta-industry; likewise, psychology is probably the second-best example of a meta-science I can think of (with first place going to cryptography).  Digesting all that research on learning, perception, and memory has given me a significant leg-up when it comes to learning new things, understanding someone else's perspective, and communication.

I honestly believe that having and honing these skills is what keeps me employed as a software engineer.

If it was possible for me to add any value to Justin's post, it would be to not limit your exploration to your career.  Learning is an active, forceful process - go find something that interests you and relate it back to software design and engineering.  Psychology may not be your bag, but learning opportunities abound.  Here are two ideas I've taken from my own personal history:

Design and build a birdhouse (or, if you have some modest woodworking skills, a tree house or bookshelf).  If you really want a challenge, have someone else design it.  What sort of problems did you hit during design vs. construction?  How well did you estimate your materials?  What sort of mistakes ended up in the final product, and how would you avoid them next time?

Cook a menu by a fickle four-year-old.  This is a great exercise in communicating across domains of expertise: you could be a Master Chef, but you'll have no idea how to make Glittery Rainbow Unicorn Fishsticks or Chocolate Marshmallow Beans and Rice without some discussion.  Moreover, try explaining to them why their culinary delights don't taste as delightful as they expected.  Work with them to hone their ideas and produce something palatable.  Think about the communication problems you experienced and how you worked around them - they have a lot in common with communication problems you experience at work.