software solutions / project leadership / agile coaching and training

The Human Side of Software Craftsmanship

Posted on January 29, 2013

The Manifesto for Software Craftsmanship states that they “are raising the bar of professional software development by practicing it and helping others learn the craft.” As a software developer, I take pride in my work and have high standards for myself, and I appreciate it when others do the same. But if those high standards turn into arrogance toward others, then maybe we’ve gone astray.

They told us back in grade school that you shouldn’t pull yourself up by putting others down, but even today that wisdom can be hard to remember. I admit that I’m guilty. If you work at a company that has any code that has been around for a few years, you’re going to find some horrible code, and it’s really easy to make fun of it. I still do it all the time, but I’m trying to stop.

Arrogance and software craftsmanship don’t mix. While the technical aspect of software development is extremely important, the human side of things is just as important. It doesn’t matter how good your code is if the software doesn’t meet the needs of the users. If you refer to people in the business as “stupid users”, how are you going to be able to understand what life is like in their shoes? If you know all of the SOLID principles but you have a bad attitude, your teammates would probably rather work with someone else.

People who don’t know what we do sometimes think of software developers as a bunch of people who sit in front of a computer all day and never interact with anyone. In my experience, that hardly ever happens, and in fact, we often get rid of cubicles in favor of more collaborative workspaces where we can communicate easier with other team members, and sometimes even have business users come sit near us so that we can have their constant feedback.

I remember a situation several months ago where I had to meet with some users to design some functionality. After the first few meetings, I had to present a potential design idea to them. Before I went into the meeting I had already thought of potential issues that the users might bring up and the rebuttals that I would give. The users expressed some concerns and I wasn’t winning them over.

I stopped after that meeting and took a step back. Maybe I was listening to the words coming out of their mouth but not actually hearing what it was that they were really saying. Maybe their concerns weren’t petty after all and they had good reason for bringing them up.

The next time we met, I tried to go in and just listen. I mean really listen, like let them talk without thinking about what I’m going to say next. I tried looking them in the eye and processing every word that they say, the feelings they were expressing, and the reasons why they believed that way. Then when they were done talking, then I would think about how I’m going to respond. And this time I finally saw what they were talking about. It really hit home when one of the users (who was excited about me finally getting it), said excitedly, “That’s what we’ve been saying for the last month!”

I’m glad that I finally got it right, but I’m disappointed that it took me so long to get there.

In my mind, in order to really consider yourself a craftsman (or craftswoman), we need to not only value technical expertise but skilled human interaction and communication skills, and that starts with having an empathetic attitude toward others instead of finding ways to put them down.

No Comments »

No comments yet.

Leave a comment





SERVICES
SOFTWARE SOLUTIONS
I have over 10 years of software development experience on several different platforms (mostly Ruby and .NET). I recognize that software is expensive, so I'm always trying to find ways to speed up the software development process, but at the same time remembering that high quality is essential to building software that stands the test of time.
PROJECT LEADERSHIP
I have experience leading and architecting large Agile software projects and coordinating all aspects of a project's lifecycle. Whether you're looking for technical expertise or someone to lead all aspects of an Agile project, I have proven experience from multiple projects in different environments that can help make your project a success.
AGILE COACHING
I believe that Agile processes and tools should be applied with common sense. I've spent the last 6 years working on Agile projects as a consultant in many different environments, both in leadership roles and as a practitioner doing the work. I can help you find out how Agile can work best in your organization, not just apply a prescriptive process.
TEST DRIVEN DEVELOPMENT TRAINING
TDD Boot Camp is a hands-on, three day, comprehensive training course that will teach you all of the skills, tools, frameworks that you will need to use test-driven development to develop real world .NET applications. If you're not looking for something that intensive, check out the the half-day version.
Have any questions? Contact me for more information.
PRESENTATIONS
The Business of You: 10 Steps For Running Your Career Like a Business
From CONDG 2012, Stir Trek 2014
From Stir Trek 2013, DogFoodCon 2013
From Stir Trek 2012, QA or the Highway 2014
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
(presented with Paul Bahler and Kevin Chivington from IGS Energy)
From CodeMash 2011
An idea of how to make JavaScript testable, presented at Stir Trek 2011. The world of JavaScript frameworks has changed greatly since then, but I still agree with the concepts.
A description of how test-driven development works along with some hands-on examples.
From CodeMash 2010
From CodeMash 2010