I feel that software development, at least the customer-facing business application type of development that I do, is a craft. Although my current official job title is "Software Engineer", I feel less like an engineer and more like a craftsman.
There has already been much debate about this distinction, and I won't repeat it all here. But suffice it to say that the critical difference, to me, lies in how one should go about getting better at their particular flavor of software programming. I tend to agree with this assessment of the continuum of software programming as it relates to the concepts of "art", "craft", "engineering", and "science":
Programming is rarely a science, sometimes engineering, but usually a craft. No example of programming-as-science comes to mind, but there is certainly a lot of science going into programming (codify natural laws found by science, and you have a simulator). Programming is an engineering discipline when the goal is not to add new functionality, but to make existing functionality work to certain quantitative goals. A lot of OS design and database work, for instance, is engineering. Making new functionality is usually a craft, where the result isn't getting something to work at such-and-such a speed but getting something to work at all.If the types of programs you write tend to be farther to the engineering side of the spectrum, concentrating on speed, efficiency, scalability, interoperability and other quantitative goals, how do you improve your skills? Generally, you increase your algorithmic vocabulary by learning or inventing new algorithmic techniques, or you devise clever ways to harness existing methods in unique and powerful ways. This is mostly an academic exercise, and can be accomplished with traditional educational practices.
But what if your programs are more aligned with qualitative goals? What if the success of your software depends more on being understandable and easy to use than on being ultra-fast or efficient or (gasp) bug free? How do you get better at that? For most of the software that I write, the success of the software depends much more on the qualitative aspects than the quantitative (assuming the engineering quality is reasonable, of course). In my experience, improving one's ability to be successful with that kind of software has shown to be more about practice than about education. You improve the same way you would improve in any other craft.
I recently came across the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.
Are you doing all you can to further your career as a software developer? With today's rapidly changing and ever-expanding technologies, being successful requires more than technical expertise. To grow professionally, you also need soft skills and effective learning techniques. Honing those skills is what this book is all about. Authors Dave Hoover and Adewale Oshineye have cataloged dozens of behavior patterns to help you perfect essential aspects of your craft.The authors recognize that the most effective way of honing a craft is through the process of apprenticeship. In lieu of a traditional apprenticeship (does anybody know of one?), it is up to you to provide one for yourself. Steps for doing so are provided in the book.
The best part, though, is that you don't even have to buy the book to see what those steps are. The entire contents are freely available through the publisher's website at http://apprenticeship-patterns.labs.oreilly.com/.
There you will find advice on how to:
- Unleash Your Enthusiasm
- Confront Your Ignorance
- Retreat Into Competence
- Nurture Your Passion
- Find Mentors
- Be the Worst
- Share What You Learn
and many other patterns to follow on the road to mastery over your craft. Each pattern is presented with its relevant context, what problem the pattern solves, and specific actions you, the apprentice, can take. From the preface:
This book is written for the person who has had a taste of software development and aspires to become a great software developer. You may be a web developer or a medical device programmer, or you may be building trading applications for a financial institution. Or perhaps you have just graduated from high school or college knowing that software is your future.If that describes you, then you owe it to yourself to (at least) give the online version a look.
Although this book was written for newcomers, more experienced developers will benefit from its content as well. People with several years of experience may find themselves nodding their heads in recognition of dilemmas they’ve already faced, and may come away with new insights or at least a new vocabulary to describe the solutions they want to apply for themselves or suggest to their colleagues. Even people with a decade or more of experience—particularly those who may be struggling to navigate their careers—will find inspiration and perspective to counter the siren call of promotion to management.