In a trial run for Heart of Clojure I gave my talk Functioning Among Humans yesterday at RUG::B. It covers topics very close to my heart and is a talk I wanted to give forever. It’s sort of a “best of” soft/social/people skills that I learned going back all the way to high school and that are useful to me in every day life.
If you happened to have seen the talk, please feel free to reach out to me with feedback as I still want to improve upon it for future versions.
In the development world most people are striving for technical excellence: better code, faster run times, more convenient interfaces, better databases… But is that really what helps us create better software?
In the end software development is done by groups of people creating products together. To do that communication and collaboration are essential. You can be the best programmer ever, but if you can’t efficiently work with others what good does it do you?
This talk will introduce you to relevant, easy to grasp concepts of collaboration and communication as well as give you food for thought.
As such it is about how the view the general public seems to have about programmers/software developers is actually pretty wrong as we actually communicate and collaborate a lot.
Enjoy – and thanks everyone again for the great event this Saturday! And of course to everyone laughing and smiling, that makes presenting so much more fun 😀
I often have the feeling that programming and software development is largely misunderstood. Many people seem to still have ancient believes about how software development works. Believes potentially scaring them away from pursuing a career in software development. Let’s fix this.
In this blog post I’ll show why the mental image of one person sitting in a cellar all by him-/herself is as wrong as it can be. I’ll explain why I believe that the most important ability of a software developer is his/her ability to communicate. And I’ll highlight why I enjoy software development so much. (hint: there are also slides about this)
The typical misunderstanding
Let me take you through a somewhat normal conversation for me with strangers at a party:
A rather typical conversation at a party. (Note for clarity: the depicted conversation wasn’t about this and those people are actually dear friends of mine, not strangers)
Bingo! You’ve just won yourself a speech of how that is basically the opposite of what I do. My work is filled with lots and lots of communication. Let me walk you through some of the most important and most frequent communication activities in Software Development.
Communication within the team
Team Spirit, December 2006 (Photo credit: JF Schmitz)
Most software isn’t built by a single developer. It’s developed by a team or even multiple teams. I mean does anyone really believe that a single nerd in a cellar builds Facebook and another one builds Windows?
This software is built by large collaborative teams. In a team you have to work together to achieve something.The parts developed by members of the team have to interact and play nice with each other. To Facilitate this the authors have to communicate. As software often solves complex problems, these systems also have to be carefully designed. This is best done in a group of people in front of a whiteboard – not in front of a monitor.
Modern software development actually focuses a lot on the team developing software and how they work together. Let’s take a look at the Manifesto for Agile Software Development, the foundation of most modern software development processes. It values:
Individuals and interactions over processes and tools
This is the very first point made highlighting that good software development is about people and how they work together. It’s not only communicating about the project, solving difficult problems together – of course the normal small talk and “grab a drink together after work” is included as well 😉 Motivation is very important.
It doesn’t stop here though. Often software projects are big enough that multiple teams have to collaborate to realize them. There is a lot of communication going on there as well. But there are still other people developers should communicate with like the system administrators and the customers. Wait, what – the customers?
Communication with the customers
Yep the customer. The ones ultimately using the applications. Or the client wanting the application.
Unfortunately that thought might seem alienating at first, but think about it. Those are the people who ultimately know what the application should do. They are the ones that will be using it, it should fit their purposes. The only way to know if the application reaches its highest goal, satisfying the customer, is through frequent communication and thereby feedback. That starts with asking them what the application should do and how it will be used. It doesn’t stop there though, it is enhanced through demos of a prototype of the application to verify understanding.
Some people take this even one step further. In one of the all time classic books about programming, The Pragmatic Programmer, it is recommended that you spend as much as one week working with the your users before writing an application. This way you should get to know what their work is like.
All of this generates invaluable insights and builds trust.
Look, there are two of them in front of just one monitor!
A friend and me doing some Pair Programming
Yep that’s two developers in front of just one monitor. Actually it’s me and a good friend of mine. So what do we do? Well naturally we are working. We are doing Pair Programming. That is one of us is actually writing the code while the other one observers. We both design the code and talk about it. We work together.
Some people think that this is a waste of time. Hell those are 2 programmers, give them 2 PCs so they can write twice as much code!
It’s not as simple as that. In software development we constantly solve problems. Solving them together leads to a solution sooner, higher quality code and more knowledge spread across the team. The benefits of Pair Programming are worthy of a whole blog post of their own.
Despite the benefits Pair Programming is still a pretty debated topic. Some people despise it. Some people only apply it to difficult problems. Some people say that all production code must be written in Pair Programming.
For me I love Pair Programming: It makes programming a lot more enjoyable, at least to me. When you try to solve a complex problem sometimes you hit the wall. You just don’t know how to solve this problem. You’ve run out of options. It can be really frustrating. That never happens to me when I’m Pair Programming. We, as a team, never seem to run out of ideas on how to solve a given problem until we find one that works. On top of that I can communicate and collaborate with someone all the time. How much more awesome can it get?
And what’s my point with this? During a good normal work day, I actually communicate and collaborate with at least one person almost all the time. Sweet.
Communicating through code
Now I really gotta be kidding right? What does code have to do with communication?
“(…) when you program, you have to think about how someone will read your code, not just how a computer will interpret it.”
Kent Beck
And that someone refers to the people in your team as well as yourself. As a team you work together meaning that you have to be able to understand and extend the work of your colleagues. And of course you must be able to understand what you wrote some months ago or even just some weeks ago. You might be surprised how difficult this can get with poorly written code.
Good code must communicate well. The best code, in my eyes, is the code that is the easiest to understand. Code that pretty much speaks to its readers. Writing such code can be very challenging. You can find me discussing with my Pair Programming partner about naming questions for like 2 minutes – it is important.
Not every company empowers their teams. Not everyone loves pair programming. Not every company cherishes communication. Not every company works Agile. There are people out there still following the Waterfall process, which has been a misunderstanding from the beginning, where at first rigorous documents are made and then the programmers are locked away to “just code it”. Why do people keep doing this? I have no idea. I just know that there are enough tech companies looking for developers out there so you don’t have to end up at an old-school command & control enterprise.
So with all this talk about communication one might ask: “What about the introverts? What about people who don’t like to talk as much?”
Well I’ve worked with some people who might qualify as introverts. Let me tell you this: I’d love to work with each and every one of them again.
See communication is not a one-way street. It’s not just about talking, it’s at least as much about listening. People who just talk but don’t listen are bad communicators. Maybe more introverted people don’t talk as much. However with the ones I know I found that if they say something it is of immense value. And they are very good listeners as well. Plus they enjoyed Pair Programming as much as I did. I would say they are good communicators and collaborators. To me bad communicators and collaborators are those that don’t work together with the team and spend most of their time simply criticizing others.
Wrapping up
Look we got post-its too! (Thanks for the photo to Andreas!)
So what’s the lesson here? Well today’s Software Development is a lot different from what many people think it is. You work together as a team. You talk. You draw on white boards. You have those funny little post-its to coordinate work. Some people work together all day long. You have fun. You actually communicate with he people using your product.
As I hinted at first all this makes me believe that the ability of developer to communicate is more important than his/her technical ability. Developers are part of a team. If they excel technically but don’t know how to share their expertise with the team then they’re not helping much. Even worse, people who spend meetings just criticizing ideas can easily kill the motivation of a team and slow them down significantly. Luckily I haven’t met many of them.
Good communicators and collaborators on the other hand do everything for the team. They help and motivate each other. They happily share their knowledge and are always ready to learn new things.
So my point is this: Do you like solving problems? Do you like to work in a team? Would you like to work in a continuously evolving field with lots of new technologies and opportunities? Do you like to build something awesome helping many people?
Congratulations, software development might be just the thing for you!
Journeys of a not so young anymore Software Engineer 