Am I a Software Craftsman or a Software Engineer?

Dave Farley posted a new video this week discussing the differences between software craftsmanship and software engineering:

Software Craftsmanship vs Software Engineering
https://www.youtube.com/watch?v=12tDtvC55QM

This is a topic I have often thought about. Until I read Dave’s recently published book Modern Software Engineering, 2022, I would never had considered myself (or anyone else for that matter) a software engineer. But his ideas have got me rethinking that position.

A bit of history

Early in my career I read a book by Steve McConnell called “After the Gold Rush”, 1999. It is now out of print and has been replaced by a new edition called “Professional Software Development”, 2003. In both editions, McConnell advocates for the improvement of how software is produced and for the profession of software engineering.

The biggest takeaway for me was the idea that an ‘engineer’ is something more than what I was doing. Especially compared to other engineering disciplines which often require a license to be a professional engineer. You would have to pass tests, show experience is various aspects of the field and be judged worthy by a board/committee.

So I was of the mind that referring to anyone as “software engineer” was wrong. No one could be considered a software engineer because no one was licensed as such.

And that is not to say that software engineering isn’t an engineering discipline. It is a discipline you can study and use the guiding patterns, practices and principles every day. But that doesn’t make you a “software engineer”.

So here I was, early in my career with this mindset. Anyone calling themselves a software engineer was either fooling themselves or grossly unaware of what it really meant. Ah, the arrogance of youth.

It wasn’t long after that I discovered the idea of software craftsmanship. A book by Pete McBeen called “Software Craftsmanship: The New Imperative”, 2001 provided an alternative to engineering ideas. Craftsmanship, based on the time-honored traditions of other crafts was seemingly a worthy way of defining the current state of our profession. It made a lot of sense to me and still does.

Fast-forward to 2022 and the idea of a software engineer is once again bouncing around in my head. But I have a few years of experience to draw from to rethink my position.

Am I a Software Engineer?

I think of myself as a professional software developer. I strive to use software engineering principles to guide my work. But I don’t refer to myself as an engineer.

Dave Farley’s Modern Software Application starts with a reasonable position of what software engineering is:

Software engineering is the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems in software.

The adoption of an engineering approach to software development is important for two main reasons. First, software development is always an exercise in discovery and learning, and second, if our aim is to be “efficient” and “economic,” then our ability to learn must be sustainable.

This means that we must manage the complexity of the systems that we create in ways that maintain our ability to learn new things and adapt to them.

So, we must become experts at learning and experts at managing complexity.

Expert at learning and managing complexity. What if that is the definition of a software engineer?

I think of myself as a very good learner. I obtained a master degree in university in a discipline other than my chosen profession. My degree in statistics isn’t something I use a lot these days. But the process of obtaining that degree made me a better learner. It taught me how to conduct research, to design experiments and to be objective in reviewing the results. Does that make me an expert? Hardly. But it is a skill that I use a lot every day.

What about managing complexity? Again, I think I do an above-average job at that. Farley prescribes some general practices for helping to manage complexity on software applications. Software that is well designed and easy to maintain is:

  • Modular
  • Cohesive
  • Good Separation of Concerns
  • Uses Abstraction/Information Hiding
  • Loosely Coupled

It is hard to disagree with these ideas.

These are the skills I have learned and strive to improve upon every day. When I think about the code that I am writing, these ideas are always in my thoughts and are what I strive to achieve.

But am I an expert at managing complexity? Not even close. So if a software engineer is an expert at learning and managing complexity, I fall short.

Where Do I Go From Here?

So I ask myself is being a software engineer something that I am striving for? I suppose. Otherwise I wouldn’t be thinking about this topic much :-).

What course should I take to go from where I am now to where I want to be?

Great question.

Not sure I know how to begin. But it will be a great adventure…