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.

Another fear I'm seeing on the team is a fear of changing existing code.  The fear may stem from several sources: the code implements complex behavior that is undocumented; the code is inherited from a resident expert who is retasked or otherwise unavailable; the code hasn't been maintained properly and reads like a plate of spaghetti.  Whatever the source, a team member's response to the fear follows the pattern:

When team members are afraid, they will act in either their own interest of self-preservation, or in the interest of team survival.

When confronted with such code, a team member can choose one of two paths: they will choose to do as little with the code as possible, leave it alone as much as they can and still satisfy everyone's expectations; or they own up to the situation and remove the source of the fear, making the code easier for anyone to cope with and understand.

Those who pursue self-preservation take the former track.  They exert a lot of effort to develop an understanding of the code, but don't do anything to persist or share that knowledge.  Chances are they are trying to act in the team's interest by developing specialized knowledge of the code, but in the long-term they benefit only themselves.  The code remains an untenable briar patch for the next poor sod who receives it.

Those who pursue the best interests of the team take the latter approach.  They write unit tests around the existing code; they refactor the code and leverage the common design patterns to make the code comprehensible; they seek clarification from the business heads and write documentation targeted to other developers.  Their actions are targeted, whether implicitly or explicitly, at communicating with the other members of their team.

I've recently taken on the role of Scrum Master at the office, something I agreed to do in order to try out some new tools and techniques such as user stories and planning poker.  Making the switch from engineering software to engineering team results has been enlightening.  Keeping the pigs productive and the chickens out of the sausage factory has been exhausting.  This is due in no small part to sudden layoffs and subsequent attrition that directly impacted the teams. 

Four weeks as Scrum Master in this environment has reactivated my dormant psychology degrees.  Anyone exposed to psychology knows that fear is the fuel for a lot of animal behavior (e.g., two of the the four basic "F's": fighting, fleeing, feeding, and reproduction).  Some animals act independently to ensure their own safety; others act selflessly to ensure group survival.  Team members fall in line accordingly:

When team members are afraid, they will act in either their own interest of self-preservation, or in the interest of team survival.

I'm making no value judgments here - I would never fault anyone for doing what they feel is necessary to protect themselves and their family.  This is merely observation. 

Let us consider the fear shared across the team: losing their job.  Some act to ensure their own survival: they leave the team for a more stable environment; they hoard tasks to protect their value to the company by having a lot to do; etc.  Others act to the benefit of the group: they seek out improvements to the team processes to help compensate for loss of resources, they maintain their value to the company by moving into vacant but necessary roles; etc.

The longer I'm in the Scrum Master role, I can see the axiom apply to more and more individual behaviors.  Fears will vary, responses too; but the pattern tends to hold true.

Next time: Coping with the Fear of Changing Code