The Magpie


Note: I split this post into two to make it more digestible. For background and context, see my post Shiny things.

TL; DR;


Back in 2008 Jeff Atwood wrote a popular blog post speaking about the fast pace of change in technologies, and a specific class of developers that are particularly attracted to new technologies, sometimes to their detriment. If you have not read it yet do so now. There are some gems in there.

If you read the comments on that post it seems like some people took away the idea that sticking with what is familiar is the right thing to do. The Magpie developer got a bad rap and the analogy is incomplete. It ignores the benefits this pattern has for learning if used responsibly. In this post we will take a deeper look at that definition. I will attempt to describe my (personal) mental model of approaching continuous learning. We all have models on how the world (and our brains) work. Knowing that all models are wrong but some are useful I will proceed with caution on this topic. This is but one of my mental models but might be useful in shaping your thinking.

What is a Magpie?

Someone who hangs at the train station or bus stop or anywhere public all day long, usually asking for a cigarette, spare change or pocket lint. Usually unemployed and unemployable, using nothing but slang, and usually impossible to get rid of, until threatened with violence.

Called magpies because if they have gotten it once, they'll expect it again, and again, regardless of who it is.

Oh wait. Not that kind of Magpie.

Let us have a look at Jeff's definition:

I've often thought that software developers were akin to Magpies, birds notorious for stealing shiny items to decorate their complex nests. Like Magpies, software developers are unusually smart and curious creatures, almost by definition. But we are too easily distracted by shiny new toys and playthings.

...

I became a programmer because I love computers, and to love computers, you must love change. And I do. But I think the magpie developer sometimes loves change to the detriment of his own craft.

Jeff closes off with the following advice:

That's the beauty of new things: there's always a new one coming along. Don't let the pursuit of new, shiny things accidentally become your goal. Avoid becoming a magpie developer. Be selective in your pursuit of the shiny and new, and you may find yourself a better developer for it.

I cannot agree more with the conclusion. Never let the pursuit of shiny things become a goal in itself to your detriment.

An old wives' tale

Magpies scrambling to collect shiny objects is a myth.

Researchers placed mounds of edible nuts just 30cm away from each of the collected objects. In 64 tests during feeding, magpies picked up a shiny object only twice - and discarded it immediately.

The birds essentially ignored or avoided both shiny and blue objects, and often fed less when they were present.

Lead author Dr Toni Shephard said: "We did not find evidence of an unconditional attraction to shiny objects in magpies. Instead, all objects prompted responses indicating neophobia – fear of new things."

While it's interesting in itself that debunking this myth warranted a research topic, the conclusion appeals to me. Magpies seem to have an innate fear of new things and treat them with suspicion.

Many people see the world in black and white, in polar opposites, in extremes. I have learned over time that nothing is black and white. Whenever you find an opinion on the extreme end of a spectrum of options the truth is probably somewhere in the middle.

Let us reign back these absolute statements:

With a more plausible statement:

That is the advice I give my children - don't be scared, just be careful. Then make sure they know the safety rules to avoid death. Fear has lost its usefulness in modern society where we are not hunted down by lions in every day life.

My philosophy is that worrying means you suffer twice.

Newt Scamander (J.K. Rowling, Fantastic Beasts and Where to Find Them)

The V model of learning

Agile proponents talk about "T-shaped" people. The general idea is that effective people have broad (but shallow) knowledge in many topics, but deep knowledge in specific ones. It espouses the idea that a person should be able to work in different disciplines and that is indicative of a persons adaptability in a work environment.

While this model is simple to understand it fails to model the interconnectedness of concepts, that concepts build on each other. It represents a persons skillset as poorly as the skills matrix that recruiters keep asking me for and I refuse to provide.

Knowledge models are better expressed through graphs than trees. Although this T-shaped person can do A and B reasonably well it's safe to assume that they will perform poorly in other tasks without a significant time investment in learning. What it means to perform a job "reasonably well" is a subjective and religious topic and inconsequential to this discussion.

What we need are V-shaped people.

Let's assume a person knows technology A and now needs to learn technology B:

The deeper you go down, the more knowledge you have of how things work under the covers. You understand the underlying concepts and are able to transfer those learnings to other technologies or disciplines. The point of competence is the theoretical point that you need to reach to be able to produce work with reasonable competence using technology B. The point of commonality is where the knowledge base for these two branches intersect and where you can reason about them on the same level.

If your understanding is where I've plotted it in technology A, you have two options on how to proceed with learning B. You could jump the cliff between A and B with the potential risk of falling to your death:

Not only is it difficult, but the end result is that there are still large gaps in your knowledge as you have not reached the point of commonality - you have no point of reference. It will be difficult to achieve full competence in any of these technologies since the underlying concepts are still not clear and no skill transfer between A and B has taken place. Don't get me wrong - there is a time to skim a subject and get the job done - but if you are looking at longevity and productivity in a skill then this approach is sub-optimal. Even worse, the chance of failure to make the leap increases because the fundamentals are missing.

Compare a different approach - starting from the point of commonality and working your way up.

Note that I'm not suggesting a specific learning direction - only that having a point of commonality available accelerates the learning process. Whether you start with the details and work your way up to higher level abstractions or the other way around is a matter of personal preference.

In reality there are multiple V's and many intersection points:

The more intersection points there are the easier the learning process becomes. You can increase the intersection points available to you by increasing the number of V's or deepening the learning of existing ones.

The Magpie tries to maximize the potential number of intersection points they have at their disposal through continuous learning. It's an investment that pays off over the long term.


Build a solid core

Back in 2006 I knew my stuff or at least thought I did. .NET 2.0 was the flavour of the day and I made it my personal mission to learn every nook and cranny of the BCL off by heart.

Then, .NET 3.0 got released. With it came Windows Presentation Foundation (WPF), Windows Workflow Foundation (WWF), and Windows Communication Foundation (WCF). These were huge frameworks and it dawned on me that my current approach to learning was not sustainable nor sufficient. That was a hard blow for someone who hoards knowledge and whose basic fear in life is being incompetent.

In response, I pivoted. I learned principles and techniques rather than focusing on the implementation details. I started building a solid core.

I learned how to achieve quality through testing and how to architect applications to accommodate change and scale. I learned how to communicate my intent better by changing the way I write code. I learned how to work and communicate in teams which led me to the principles of agile methods and the psychology behind it.

I became proficient at learning and unlearning.

I became fascinated by people and how they see the world. I built up my leadership skills to lead and manage not only from a technical perspective but with a human centric approach. I delved into the principals of Lean manufacturing and opened up my eyes to the economics and methods of software development, product and business development.

I became a more well-rounded technologist which allowed me to perform well in management and strategic positions and still keep in touch with my technical side. And I'm still learning.

The trick behind learning and unlearning is to have a solid core in place. Your solid core represents the skills that are transferable across technologies and paradigms. As a developer you need to carry a toolbox with a decent collection of tools so that you can use the appropriate one when the situation presents itself.

Even if you don't get to use a technology on a day to day basis, learning it might still be of benefit as you can apply what you've learned elsewhere. Having a solid core deepens your V's and increases the amount of intersection points you have available. Building on practices like TDD allows you to do this safely.

Programmers who program "in" a language limit their thoughts to constructs that the language directly supports. If the language tools are primitive, the programmer’s thoughts will also be primitive.

Programmers who program "into" a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language.

My favourite quote from Steve McConnell’s Code Complete book

Intentional learning

The responsible Magpie does not latch on to every shiny object. Life is too short to acquire unused knowledge. Instead, the responsible Magpie follows a structured process.

The core evaluation criteria is usefulness (now or in the future) and the effort to learn versus the potential returns.

Haphazard learning isn't very useful. Identify a goal and a plan to achieve that goal. Learning has to be intentional and deliberate. I would recommend keeping a prioritised backlog.

Once the goal is in place set aside some time for learning. Using your personal time for this can be difficult especially if you have children. But even a 2 hour slot once a week will yield good results.

Set aside time for learning at work. Not making the time at work or your employer denying you that time will only be detrimental to both of you.


Make peace with the fact that you can't remember everything. I'm at a point where it feels like as soon as I learn something new something gets discarded. My memory is full and I can only hope it operates in a LRU fashion. Things get shipped off to long term storage only if they are frequently used - which, in a way, is a good thing as unused knowledge is pretty worthless.

My brain seems to respond pretty well to saving pointers instead of the actual information. I can't remember the full content of that article I read but I can sure conjure up the search terms to Google it again.

Do what works best for you.


In conclusion

Practice learning, unlearning, and connecting ideas. It's the most important skill you will ever acquire. Plan ahead on what to learn and look for intersection points as a guide. Try to know what you don't know. It will be worth your while in the long run.

I'm a Magpie, but a responsible one. And that's ok.


Photo by Marina Salles on Unsplash