This is the script for the presentation I gave at Git Merge 2019 (Brussels, 01/02/2019). The slides are available at https://belenbarrospena.github.io/the_art_of_patience_gitmerge2019/
Hello everybody. Thank you very much for sticking around for this talk, which is called The Art of Patience, or Why bother teaching Git to a Designer. I am Belén, and I love it when they schedule my talks at this time, when everybody is nice and sleepy after their lunch. I will do my best to keep you awake, but I can’t promise anything.
I must warn you: this is a bit of a weird talk. This is a conference about Git. Git is a version control system mostly used for software development purposes. But I don’t develop software. I am not a software engineer. I am an interaction designer.
And to explain to you what an interaction designer is, I need to introduce you to someone. This venerable looking man was - sadly - Bill Mogridge. Bill Modridge was an industrial designer. He was one of the founders of a very famous design company called IDEO, and he is also credited, with another Bill (Bill Verplank) with coining the term “interaction design” back in the 1980s. And what the Bills meant by interaction design was quite simple: it was the application of principles and techniques of industrial design to software. When you design a physical product, the first thing you need to think about is who is going to use the product, where and what for. And the same applies to software.
In practice, this means that interaction designers look at software from the user’s perspective. We look at software from the outside in. Because as interaction designers, we are not responsible for building software that works: that is the responsibility of software engineers. But we are responsible for building software that makes sense to the people who use it.
You may have noticed that I didn’t say building software that is easy to use. I said building software that makes sense to the people who use it. Because, you see, some things can never be made simple. And Git is one of them.
This talk is the story of how an interaction designer managed to learn Git. The process and the approach I am going to describe happened to work for me, but that doesn’t mean is the only way to teach Git to designers, or that it will work for everybody. I’m afraid I don’t have a bag of magic tricks for you, not even a list of "best practices". This is just my personal experience: no more, and no less.
And let me be completely transparent about this: the purpose of this talk is to convince you to teach Git to the designers you work with. If I succeed, if I manage to convince you, you will all find yourselves in the situation of having to teach Git to a designer. So brace yourselves! Because it's not easy.
This story is broken down into 3 parts. First, I am going to tell you how I learnt Git. Second, I will tell you why all designers should learn Git. And third, I will utterly embarrass myself by confessing to you how long it took me to learn Git. Are you ready? Let's start with how.
My story begins when I first came across Git. It happened about 7 years ago when I joined something called the Yocto Project. The Yocto Project is a Linux Foundation initiative that provides a set of tools for creating and maintaining customised Linux distributions for embedded devices, with the most important of those tools being a build system. The first time I heard this, I don’t think I understood any of the words. Not a single one of them ... apart from the articles and prepositions. I didn’t know what Linux was, or a distribution, or an embedded device, or a build system. So imagine the scene. Middle manager in big multinational tech corporation approaches Linux engineer and says to him: hey, you, here is this designer. She knows nothing about what you do, but she is here to help you. Yeah, right. Sure she is!
That’s what I would have thought. Luckily for me, that Linux engineer didn’t think that at all. His name was Paul Eggleton, and he is a very particular man. Instead of thinking “yeah, right. Whatever.”, he thought the Yocto Project could do with all the help that came its way, even the help of a designer. And so he started teaching me about it as much I was able to take in.
Part of my job was designing a web-based, graphical user interface for the build system included in the Yocto Project tools. Something like GitHub and GitLab, but for a Linux build system rather than Git. After a few months of design work, we started building the web interface, and I needed to keep an eye in the progress.
Yocto is an open source project. Because it deals with Linux things, it has borrowed many processes and workflows from the Linux Kernel, between them Git for doing version control. Roughly, this is how things worked. The developers building the web application would commit code to their own work in progress branches that were based off the project master branch. When they deemed the work ready, they would submit their patches to a mailing list, the patches would be reviewed by the community and eventually would be merged into the master branch.
Before I learnt Git, if I wanted to keep an eye on the work in progress of the developers, or if I wanted to do a design review of any patches they sent to the mailing list, I had to ask a developer to run an instance of the web application for me from a branch containing the changes I wanted to review. That was a pain in the ass for me, mostly because I knew it was an even bigger pain in the ass for my developer colleagues. They were extremely busy, and yet every time I had to check something, which was quite often, they would need to stop what they were doing, and update the instance of the application they kept for me to incorporate whatever changes I wanted to look at. Sure it wasn’t that much work, but when you have to do it over an over again, and you don’t have time or hands to automate the workflow, it becomes a very annoying interruption. So one day the developers decided they'd had enough. But instead of shouting at me or telling me to stop annoying them, they decided to teach me how to do it myself.
And this is the first interesting takeaway from the way I learnt Git: teach on a need to know basis. Teach your designers just enough so that they can do whatever it is they need to do in order to do their jobs.
This is how Paul explained it.
You see, your designers don’t care about version control, they don’t care about Git. They just care about getting their jobs done. So don’t bother organising big Git workshops or teaching sessions: teach your designers what they need to know at any given time to do their jobs better and more independently.
This is what the developers told me at that point. There is this special place where we put all our work in progress. You need to make a local copy of that special place, and to make that local copy you need to type this in a terminal
git clone [SPECIAL_PLACE]
In that special place there are these things called branches. Well, the changes you need to look at will be in one of those branch thingies. We will tell you which one, and you need to select it from your local copy of the special place. To select it, you type this in your terminal
git checkout [BRANCH_THINGHY]
Then you run our web application this way.
That was it. What I was doing was cloning the work in progress repository and checking out the appropriate branch, of course. But they didn’t tell me any of that. They did not use those words. They did not explain to me what a repository was, they did not explain to me what a clone was, they did not even explained to me what a branch was. They just told me things in a way I could understand, and gave me the commands. Another interesting lesson comes from this: avoid the Git jargon. It is incomprehensible to non-Git human beings, and it is very off putting. It just scares the bejaysus out of people! So avoid it like a plague, and explain things in terms people can understand.
After cloning a repository and checking out a branch, I had to learn how to update a branch, because branches contained work in progress, and developers would constantly push changes to them, and I had to look at those changes as well. So they taught me to do git pull, although afterwards they changed their minds and told me to use git fetch instead, and to this day I still don't have a clue as to what the difference is between the two. And guess what? I don't care! So far I haven’t had the need to understand what's the difference between fetching and pulling. Remember: I use and learn Git on a need to know basis, not because I am interested in the intricacies of version control.
So when you are teaching Git to a designer, don’t bother too much with the concepts, particularly at the beginning. Your designer doesn’t really care about what a repository is, or what a branch is. Your designer doesn't care about the difference between pull and fetch. So don't bore them with detailed explanations of those things. What’s worse: Git concepts are completely alien to everybody except software developers, and they are incredibly hard to grasp in the abstract. So don’t waste your time trying to explain them: designers will understand them progressively as they learn to do things with Git. Rather than learning these concepts theoretically and all at the same time, they will learn them bit by bit and through practice. That’s a slower way to learn, but it’s also a much more resilient and long-lasting way to learn.
After that, I really wanted to help the developers by fixing little things in the web interface in the work in progress branches. To do that, I had to learn a whole bunch of new Git stuff. How to create a branch, how to commit my changes, how to write good commit messages. If you learn how to create branches, you also have to learn how to delete them of course. You need to learn how to edit a commit for those numerous occasions when you discover a typo in the commit message or you forgot about something. You need to learn how to push your changes to a remote repository so that your developer colleagues can fetch them.
That was a lot of stuff to learn. Every time I needed something new, Paul would sit down with me and walk me through it. But you see: Paul never did things for me. He did them with me. He would sit down next to me, and I would have to type the commands and do everything myself. And this is a very important lesson: if you are the one doing the things, your designers will never learn. Git is just too hard to be learnt by observation. To properly learn something as abstract as Git, you need to develop muscle memory, and typing the commands yourself is key for acquiring that muscle memory. So never do Git things for your designers: do Git things with your designers.
Now, if you take the time and effort to sit down and do things with your designers, instead of doing them for your designers, make sure those designers are taking notes about what it is that you are doing, particularly about the commands they need and the right command sequence. What you are aiming for here is sitting with your designers once, and only once, for every new Git command or task they need to learn. Designers must understand you are investing time and effort in teaching them; they need to put the best of themselves to make sure you only have to teach them something once. So every time you sit to teach a new thing to a designer, make sure they have a notebook at the ready. If they don’t, tell them to go get one. And encourage them to type those notes and keep a cheat sheet they can go back to. Here is a bit of the one I kept, which was called "useful things".
I learnt lots of other things after that. How to to initialise a local directory as a git repository, how to add and remove remotes, how to reset a branch (really useful), how to create and apply patches, how to use git send-email, how to rebase, and even how to fix conflicts while rebasing! But by then something had changed. I had become a much more independent Git learner. I had acquired a sufficient grasp of the fundamental Git concepts to go learn things by myself, looking at resources like Stack Overflow and git-scm.com
As your designers reach that point, you will have to spend less and less time with them teaching them things. When your designers reach that point, you can finally rest and relax. Congratulations: you have succeeded in teaching Git to a designer!
As I was telling you this story, you might have noticed that these developers taught me how to do everything from a terminal. They never introduced me to any of the very good graphical user interfaces that exist for Git, and there are many, many of them. I am not sure why they did this, but I am very, very grateful to them for going about it this way. I’d tried to use some of the graphical interfaces before I learnt Git, and I found them bewildering: I couldn’t understand anything. This is because there is no graphical user interface for Git that fully hides the system model, and therefore that Git laypeople can understand.
Let me explain what I mean. Usability people will tell you that our graphical user interfaces should not reflect the way the system works (the system model), but the way users think the system works, what’s called their mental model. Mental models are often incomplete or inaccurate, but they do work, in the sense that they allow us to do things without having to understand how absolutely everything works. So our graphical user interfaces should hide the system model, and mirror the users' mental model instead.
I think this idea of making graphical interfaces reflect the mental model, rather than the system model, probably works most of the time, specially for trivial things like washing machines or buying a movie ticket online. But when it comes to a tool like Git, I am not sure it works. This is because people who are not software developers do not have a mental model for Git. Why would they? They never use Git for anything! And software developers probably don’t have a mental model for Git either, because their profession requires them to learn the system model itself. So there is no mental model for Git that graphical user interfaces can use.
And so, every single graphical user interface for Git exposes the system model: they organise the content into repositories, and they talk about commits and branches and patches and clones and so on and so forth. So if your designer doesn’t know what these things are, the graphical user interface simply makes no sense whatsoever. But if you understand Git’s system model, you can use any of the graphical interfaces without any problems. So it pays off to teach your designers how to use Git itself, having to type the commands and stuff, because that will enable them to adopt and use any of the graphical interfaces if they so wish.
And that's way you should always teach your designer command-line Git, no matter how much they moan or complain about it.
And this brings us to the why should designers learn Git. I've added this section because ... well, because Paul told me to.
At this point I have some bad news. You see, before you can even start teaching Git to your designers, there is a chance that you might have to convince them first of why they should do so.
There is a certain breed of software designer who truly believes that things like learning Git are not part of their job. I think they are wrong. Designers of software don’t need to learn absolutely everything about Git, the same way they don’t need to learn how to write production quality code. But they absolutely must acquire a sufficient understanding about software, because software is their design material.
This is similar to how product designers must understand materials. When you design a physical product, there are lots of materials you could use for it: there are woods and metals and plastics and glass and fabrics and rubbers and ceramics and so on. If you are a product designer, you don’t need to know everything there is to know about those materials. You don’t need to be a material scientist. But you need to know enough about materials in order to make sound decisions about which ones to use in your products. If you are an interaction designer, or a graphic designer producing visual assets for software, software is your design material. Therefore, you need to know enough about software in order to make sound design decisions. I believe that understanding software sufficiently for design purposes requires understanding source control sufficiently as well, because source control is fundamental to the way software is made. So by teaching people Git, you are teaching them about the nature of software, and they are learning about software as design material.
The second reason why designers should learn Git is so that they can participate in the development process, and become your partners in building. Paul also spoke about this.
You see, I’ve come across this way of working whereby there is a wall. On one side of the wall sit the designers. On the other side of the wall you have the developers. As designers design things, they throw them over the wall to the developers, and then they forget all about them. The developers try to build the design as best they can, but they are not allowed or expected to reach out to the designers on the other side of the wall. Working this way is a sure recipe to make bad software.
And this wall takes many forms. I worked in a company where designers actually requested a physical wall between them and the developers in the office. Guess in which side of the wall I decided to sit, by the way. But this is somehow rare. Most walls between designers and developers are made not of bricks, but of attitudes. Some people think that just because you are doing some form of agile development this wall problem goes away. Not true.
Teaching Git to your designers is a great way of dismantling the wall, no matter what it's made of. Teaching Git doesn’t knock the wall: it’s more like digging a tunnel under the wall. It’s the sneaky, bottom up way of destroying the wall working culture, and the bottom up way is always the most resilient and long lasting one. This is because learning Git enables designers to directly participate in the development process, without intermediaries, and also because it allows them to better collaborate with you. So they stop being the people on the other side of the wall, and become your partners in building.
And they can not only participate: they can participate in their own terms. They can influence the software-making culture and processes, to ensure design makes the meaningful contribution to software it is supposed to make. [PAUL]
And this is how "influence" happened for me while I was working on the Yocto Project. Once I learnt Git, I realised that I could not only check work in progress branches: I could also check patches that had been already submitted to the mailing list, and were therefore on their way to be merged into the main tree. Those patches came from all over the world, from developers who didn't know me, and had never worked with me. They could potentially break the design, so it was important that I could intercept them before they did so.
Git allowed me to take those patches and check them out, making sure they were not doing nasty stuff to the interface. The same way that developers did code reviews via the mailing list, I could do design reviews, so that no patches went into the main tree that broke the design. And I documented and formalised that design review process, so that any other designers joining the project could - and hopefully would - work in the same way.
So learning Git allowed me to make design a first class citizen in the Yocto Project, incorporating the principles and ways of working that are part of my personal design practice. I could practice design in my own terms.
Finally, there is one more reason why I think designers should learn Git. And this one is very important to me. 5 years ago, the very, very few interaction designers involved in Free and Open Source Software got together at FOSDEM for the very first content track about design in FOSS. Out of that meeting Open Source Design was born, a group that advocates the importance of people-centred design approaches to the free and open source software community; but also the importance of free and open source software to the mainstream design community. We want more interaction designers to get involved in FOSS, but the challenges they face when trying to do so are quite phenomenal. Between them, the fact that they do not understand many of the tools that FOSS projects use, including Git. And that makes them feel excluded and defensive and somehow pissed off.
By teaching Git to a designer, you are making it much easier for her to get involved in free and open source software, something that I believe will benefit everybody.
I am coming to the end of my story, but there is a fundamental piece of information I have not told you yet. How long is it going to take? How long is it going to take you to teach Git to a designer? Well, I have no idea of course. I can only tell you how long it took me to learn enough to be comfortable with Git. It took, well, this is a bit embarrassing, I must confess. It took me … 2 years. 2 YEARS!!! But you know what? It was worth every minute of it.
So yes, it will take a long time, and yes, it will take a lot of effort, and yes, you will need to arm yourself with a lot of patience. But on the other side you will have a designer who is better equipped to do design work for the software you build; a designer who is capable to work with you in a collaborative way; a designer who can truly participate and influence the projects she works on; a designer who will be able to contribute to free and open source software; and most importantly, a designer that will be forever grateful to you for teaching her Git.
Thank you very much for listening.