Paper Critique: Towards a Theory of Software Development Expertise

Towards a Theory of Software Development Expertise Sebastian Baltes and Stephan Diehl.
Proceedings of the 26th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2018).

I remember when I was just starting out as a software developer. I had moments of complete certainty about my utter expertise in the profession. I also had moments of complete despair that I had any clue at all about what I was doing. Reading books like The Pragmatic Programmer helped me get a sense of what it meant to grow in expertise. This paper by Baltes and Diehl tackles this same question with a Grounded Theory approach.

Paper Critique: On the diffuseness and the impact on maintainability of code smells

Palomba, F., Bavota, G., Penta, M. et al. Empir Software Eng (2018) 23: 1188. https://doi.org/10.1007/s10664-017-9535-z

Suppose you are working on some chunk of code. You notice that the logic is a bit convoluted, some of the class fields are public, there seem to be more methods on the class than make sense for the concept, and the particular method you are looking at is absurdly long. You sit at your keyboard and the training about code smells in you says that you need to be a responsible software developer and address those smells. Then your other training about engineering being about tradeoffs kicks in and you wonder, which of these matter? What impact do they have?

What is the job to be done of your job?

A few days ago three of us were talking back from the Devonshire Square market after having enjoyed the warm, sunny weather by eating our food outside. The topic of conversation had wandered but had eventually rested on careers. Specifically, we had hit upon the topic of how to decide on what one’s next position might be. How can one decide between staying at an existing job or leaving to something else? If the decision is to leave, then how does the decision between different positions on offer get made?

The question seems to be easy to answer by just listing out specific aspects one could be looking for: look for a higher salary, look for better working conditions, look for a place that has less overtime, take the one where you’ll learn the most. This hasn’t answered the question at all! It has actually made the question even harder to answer by obscuring the issue with too many details and, at the same time, not providing any way of deciding which of these specific aspects the decider cares about.

To get to the real answer, you have to first ask yourself a very different question: what are you hiring this new (or your existing) job to do for you?

Are you looking to have it pay off your debts? Move you to another country? Teach you a new skill? Allow you to have time to fish?

If you look at the job as a product to be bought or a service to be hired, what are you hoping to get out of it?

Once the job to be done is clear, then the choice between the different aspects above will be, if not easy, at least guided toward a goal.

Reading Notes from “Johnny Bunko: the last career guide you’ll ever need”

There is no plan

The world is too unpredictable to be able to plan out in advance your career or your life. You can make choices for instrumental reasons: the choice is based on the perceived utility for something else down the road. The object of choice is seen as an instrument of a plan. You can make choices for fundamental reasons: the choice is based on the inherent value of the object of the choice. The object of choice is seen as good in and of itself (reminds me of the Meditations on the subject of stoicism that a friend has been talking about). Because things are so unpredictable, instrumental reasons often lead to the wrong choices for the plan anyway. Most successful people, most of the time use fundamental reasons.

My interpretation: using fundamental reasons actually keep your options open and keep you happy at the same time! Instrumental reasons shut down options and likely are not what you actually wanted to do thereby making you less happy.

Math for Programmers

Given that software development has so many ties into mathematics, I’m always surprised by how seldom it seems to show up in my day to day life. However, today was a little bit different.

Understanding Environment Caching in Puppet

Recently, puppet got a new way of defining environments. Along with the new environments, came a new way of handling the caching of the environments inside the puppet master. I found out that what puppet is now doing, and was doing in the past, wasn’t well understood by users and so this post is to get rid of some of the mystery.

I’m going to cover what an environment is internal to puppet, what the caching of an environment is, and what it isn’t, and what it used to be. In other post I’ll cover how to evaluate your situation and tune the environment cache and your workflow.

You’re done when

Every team that I’ve worked with has eventually come to ask the question: when is it done? And they don’t just mean “done”, they mean, when is it “done-done“? Every time, for whatever reason, this seemingly innocuous question becomes a sticking point of a lot of conversations. Sometimes everyone can agree on what it takes, but there ends up being concerns about the feasibility of the definition in practice. Other times there is some dissent about the points of done related to what is actually in the team’s control. All of these are perfectly valid concerns. Some of those concerns point to larger, organization problems that are being faced and some point to fear of tackling what at first looks like a daunting mountain of change to reach “done-done” of knowing when you are “done-done”.

You’re Wrong and Can Never Be Convinced Otherwise

Are you a rational, logical person? When you are given the data about a situation, do you change your mind? I would be willing to bet that you like to think about yourself in that light. I know that I do.

However, I know that I still hold beliefs in spite of some data. If you give me some data about a situation, I’m not very likely to believe it. I might accept it, I might even agree with it, but I won’t likely change my thought process that you, as the presenter of that data, think I should be changing. Why is that?

CITCON 2012 in Portland

CITCON is a conference that I’ve been attending since 2006 in London. I showed up because it was “near” where I was living in Germany and sounded like it might be interesting. Boy was it ever interesting! The only European one that I missed was because I had a final exam on the same day as the Brussels conference (damn you, formal methods!).

Well, now that I don’t live in Europe I probably won’t be making it to those CITCONs very much anymore, but there are still the North America ones. And what do you know? The next North America CITCON is right in my back yard here in Portland.

Leaving of London

Looking back on the last five years of my life spent living abroad it is easy for me to dwell on the things that didn’t work out well. That is just the way I seem to be. I’d like to try to spend a little time dwelling a bit on the things that really worked out well, though, because once I start listing them out it will become apparent to me just how many there are. And in the end the events that were good really outweigh the problems that came up.