{ "version": "https://jsonfeed.org/version/1.1", "title": "Glenn Vanderburg", "description": "Web home of Glenn Vanderburg.", "home_page_url": "http://vanderburg.org/", "feed_url": "http://vanderburg.org/feed.json", "authors": [{ "name": "Glenn Vanderburg", "url": "http://twitter.com/glv", "avatar": "http://vanderburg.org/images/glv.jpg" }], "expired": false, "_glv_feed_metadata": { "last_build_date": "2026-05-11T22:02:21-05:00", "generator": "Jekyll v3.10.0" }, "items": [ { "id": "http://vanderburg.org/blog/2019/02/06/reading-broadly.html", "title": "Reading Broadly: A List of Good Books", "summary": "A blog post by Glenn Vanderburg.", "content_text": "This morning I gave a keynote at the O’Reilly Software Architecture Conference called “Roaming Free: The Power of Reading Outside Your Field”. Several people asked me to post a list of links to the books I talked about, so here it is. Books Others Have Read The first part of the talk gives real examples of non-software books that have been the source of interesting ideas in our field. Here are those books: The Timeless Way of Building by Christopher Alexander A Pattern Language by Christopher Alexander The Design of Everyday Things by Donald Norman How Buildings Learn by Stewart Brand The Death and Life of Great American Cities by Jane Jacobs “The Revolutionary Bridges of Robert Maillart” by David Billington (Scientific American, July 2000) Engineers of Dreams by Henry Petroski To Engineer is Human by Henry Petroski What Engineers Know and How They Know It by Walter Vincenti Definition of the Engineering Method by Billy Vaughn Koen The Design of Design by Gordon Glegg (not the one by Fred Brooks, although that one’s great, too) Warfighting by the United States Marine Corps The Mangle of Practice by Andrew Pickering The Buzz About Bees by Jürgen Tautz Better by Atul Gawande Complications by Atul Gawande The Checklist Manifesto by Atul Gawande Books, Talks, and Essays I also mentioned three resources that are (at least partly) about software, but reflect insights gained from other fields: Programming with Hand Tools, a talk by Tim Ewald Pragmatic Thinking and Learning by Andy Hunt “Tacit Knowledge” by Brian Marick Suggestions for Your Own Reading I concluded with a challenge to the audience to each read two serious nonfiction books that aren’t about software this year … and to jumpstart that, I provided some suggestions. Here they are: Mountains Beyond Mountains by Tracy Kidder A Truck Full of Money by Tracy Kidder Cognition in the Wild by Edwin Hutchins Chaos: Making a New Science by James Gleick Genius: The Life and Science of Richard Feynman by James Gleick The Information: A History, A Theory, A Flood by James Gleick Time Travel: A History by James Gleick Emergence: The Connected Lives of Ants, Brains, Cities, and Software by Steven Johnson The Ghost Map by Steven Johnson Where Good Ideas Come From by Steven Johnson Farsighted by Steven Johnson The Coming Plague by Laurie Garrett Betrayal of Trust: The Collapse of Global Public Health by Laurie Garrett Draft No. 4 by John McPhee Irons in the Fire by John McPhee Uncommon Carriers by John McPhee", "content_html": "

This morning I gave a keynote at the O’Reilly Software Architecture\nConference called “Roaming Free: The Power of Reading Outside Your\nField”. Several people asked me to post a list of links to the books I talked\nabout, so here it is.

\n\n

Books Others Have Read

\n\n

The first part of the talk gives real examples of non-software books that have been the source of interesting ideas in our field. Here are those books:

\n\n\n\n

Books, Talks, and Essays

\n\n

I also mentioned three resources that are (at least partly) about software, but reflect insights gained from other fields:

\n\n\n\n

Suggestions for Your Own Reading

\n\n

I concluded with a challenge to the audience to each read two serious nonfiction books that aren’t about software this year … and to jumpstart that, I provided some suggestions. Here they are:

\n\n", "url": "http://vanderburg.org/blog/2019/02/06/reading-broadly.html", "tags": [ "books", "blog" ], "date_published": "2019-02-06T08:16:00-06:00", "date_modified": "2019-02-06T08:16:00-06:00", "authors": [{ "name": "Glenn Vanderburg", "url": "http://twitter.com/glv", "avatar": "http://vanderburg.org/images/glv.jpg" }] }, { "id": "http://vanderburg.org/blog/2018/01/10/real_software_engineering.html", "title": "“Real Software Engineering”", "summary": "A fresh look at software development as an engineering discipline.", "content_text": "Almost eight years ago, at a conference in San Mateo, I presented a new talk that I thought had some potential: “Real Software Engineering”. Since then, I’ve given updated versions of the talk 18 times. Each time I give it, I assume it will probably be the last; talks get stale after a while and the world moves on, and it’s best to retire old talks and develop new material. But people still keep asking me to give this talk, and nearly every time I do, a funny thing happens: someone in the audience finds me and tells me about some book, paper, or bit of engineering history that I didn’t know about — one that sheds new light on the subject of the talk, allowing me to deepen the talk just a little more. For example, the last time I gave “Real Software Engineering” as a keynote address, Michael Keeling (author of the wonderful Design It!) introduced me to the delightful works of Gordon Glegg, which touch on numerous aspects of the talk. Most recently, I spoke at the Melbourne offices of Zendesk as part of their really good Software Art Thou? lecture series that they host for the Melbourne development community. I’m excited about the result: they have a good audiovisual team and put in some serious post-production effort on the videos, and the result is by far the best video of “Real Software Engineering”. The talk itself is improved in numerous ways, and the video is really well done. (And sure enough, during post-talk discussions I got some valuable new pointers to relevant material.) If you’ve never seen this talk, or are interested in revisiting it, this is the one you should watch. If you show the talk to classes or meetups, please use this version. I’m grateful to Zendesk (and especially Jeffrey Theobald) for the opportunity to speak to so many great developers in Melbourne, and for the excellent video! Software Art Thou: Glenn Vanderburg — Real Software Engineering", "content_html": "

Almost eight years ago, at a conference in San Mateo, I presented a\nnew talk that I thought had some potential: “Real Software\nEngineering”.

\n\n

Since then, I’ve given updated versions of the talk 18 times. Each\ntime I give it, I assume it will probably be the last; talks get stale\nafter a while and the world moves on, and it’s best to retire old\ntalks and develop new material.

\n\n

But people still keep asking me to give this talk, and nearly every\ntime I do, a funny thing happens: someone in the audience finds me and\ntells me about some book, paper, or bit of engineering history that I\ndidn’t know about — one that sheds new light on the subject of the\ntalk, allowing me to deepen the talk just a little more. For example,\nthe last time I gave “Real Software Engineering” as a keynote address,\nMichael Keeling (author of the wonderful Design It!)\nintroduced me to the delightful works of Gordon Glegg, which touch on\nnumerous aspects of the talk.

\n\n

Most recently, I spoke at the Melbourne offices of Zendesk as part\nof their really good Software Art Thou? lecture series that they host for the Melbourne\ndevelopment community. I’m excited about the result: they have a good\naudiovisual team and put in some serious post-production effort on the\nvideos, and the result is by\nfar the best video of “Real Software Engineering”. The talk\nitself is improved in numerous ways, and the video is really well\ndone. (And sure enough, during post-talk discussions I got some\nvaluable new pointers to relevant material.)

\n\n

If you’ve never seen this talk, or are interested in revisiting it,\nthis is the one you should watch. If you show the talk to classes or\nmeetups, please use this version.

\n\n

I’m grateful to Zendesk (and especially Jeffrey Theobald) for the\nopportunity to speak to so many great developers in Melbourne, and for\nthe excellent video!

\n\n

Software Art Thou: Glenn Vanderburg — Real Software Engineering

", "url": "http://vanderburg.org/blog/2018/01/10/real_software_engineering.html", "image": "http://vanderburg.org/blogimages/glv_rse.jpg", "tags": [ "programming", "software engineering", "talks", "blog" ], "date_published": "2018-01-10T14:00:00-06:00", "date_modified": "2018-01-10T14:00:00-06:00", "authors": [{ "name": "Glenn Vanderburg", "url": "http://twitter.com/glv", "avatar": "http://vanderburg.org/images/glv.jpg" }] }, { "id": "http://vanderburg.org/blog/2016/06/12/mdt-4-building-trust.html", "title": "Building Trust", "summary": "Clear and effective communication is the foundation of good teams.", "content_text": "When are you the happiest and most productive at work? For me it’s when I feel part of something meaningful. That my work actually matters. When I work with people that I respect and value, who show equal commitment to and appreciation for my work. When I actually look forward to going to work because I know that no matter how tough is the problem I have to deal with, I’ll still enjoy working through it with my colleagues. Some of my fondest memories are actually some of the most grueling days of my career. I find that my best work happens when I can be myself and don’t have to second-guess people’s agendas or intentions. When I trust that what I’m doing is what I should be doing and I trust the people I do it with implicitly. I’m a firm believer that the foundation of any healthy team is trust. So as a manager trying to build a cohesive team, most of your efforts should focus around building trust. And trust is important in several different directions—between: you and your team—that is, you as an individual and also as a representative of the company you and the company leadership—without trust in the company leadership you will find it impossible to do your job team members your team and any other teams that interact with or depend on your group (internal or external to the company) When people ask me about the first thing they should focus on when joining a new team, I tell them, “Focus on building connections and earning their trust.” I clearly remember those colleagues that helped me through my first few months at every single one of my jobs, and what an impact they had helping me get up to speed, building my confidence, supporting and encouraging me. You build trust by being: present or visible responsive and accessible honest and open (saying what you think—in a constructive way—and raising your hand when you make a mistake) reliable (doing what you say you are going to do) consistent So far, I haven’t said anything that is specific to distributed teams. But clearly a lot of it is related to communication: how you communicate, and how others can communicate with you. So this is all an application of Rule #1. You have to communicate deliberately, clearly and predictably. Out of sight should never be out of mind. In my experience, there are two key areas to focus on that will produce the best results for a distributed team. First, set very clear expectations with team members from the moment they consider joining the team. If the team is interviewing a candidate or someone who wants to transfer to the team, be very explicit about how the team works and what will be expected. This is important on any team, but especially on a distributed team, because the situation might be quite different from what the candidate has experienced in the past. Second, commit to improving communication and creating opportunities for employee engagement regardless of where they are located. It’s very important to be mindful of the different personalities, backgrounds and skill levels in the team, because those differences will have a considerable impact on how team members might prefer to engage. If you manage a truly distributed team you will face some other serious challenges: how to communicate across time zones and how to effectively communicate with people from different cultures, or for whom the company language is not their first language. So with that in mind, how do you go about building a communication plan for you and your team that will help you build that trust and keep everyone engaged? In upcoming posts, I’ll share some of the approaches I’ve found most useful. I’ll group them around three different goals: Collaborating on day-to-day work Building team identity Developing and promoting an engineering- and company-wide culture", "content_html": "

\"BuildingWhen are you the happiest and most productive at work? For me it’s when I feel part of something meaningful. That my work actually matters. When I work with people that I respect and value, who show equal commitment to and appreciation for my work. When I actually look forward to going to work because I know that no matter how tough is the problem I have to deal with, I’ll still enjoy working through it with my colleagues. Some of my fondest memories are actually some of the most grueling days of my career. I find that my best work happens when I can be myself and don’t have to second-guess people’s agendas or intentions. When I trust that what I’m doing is what I should be doing and I trust the people I do it with implicitly.

\n\n

I’m a firm believer that the foundation of any healthy team is trust. So as a manager trying to build a cohesive team, most of your efforts should focus around building trust. And trust is important in several different directions—between:

\n\n\n\n

When people ask me about the first thing they should focus on when joining a new team, I tell them, “Focus on building connections and earning their trust.” I clearly remember those colleagues that helped me through my first few months at every single one of my jobs, and what an impact they had helping me get up to speed, building my confidence, supporting and encouraging me.

\n\n

You build trust by being:

\n\n\n\n

So far, I haven’t said anything that is specific to distributed teams.\nBut clearly a lot of it is related to communication: how you communicate, and how others can communicate with you.\nSo this is all an application of Rule #1. You have to communicate deliberately, clearly and predictably. Out of sight should never be out of mind.

\n\n

In my experience, there are two key areas to focus on that will produce the best results for a distributed team. First, set very clear expectations with team members from the moment they consider joining the team. If the team is interviewing a candidate or someone who wants to transfer to the team, be very explicit about how the team works and what will be expected. This is important on any team, but especially on a distributed team, because the situation might be quite different from what the candidate has experienced in the past.

\n\n

Second, commit to improving communication and creating opportunities for employee engagement regardless of where they are located. It’s very important to be mindful of the different personalities, backgrounds and skill levels in the team, because those differences will have a considerable impact on how team members might prefer to engage. If you manage a truly distributed team you will face some other serious challenges: how to communicate across time zones and how to effectively communicate with people from different cultures, or for whom the company language is not their first language.

\n\n

So with that in mind, how do you go about building a communication plan for you and your team that will help you build that trust and keep everyone engaged? In upcoming posts, I’ll share some of the approaches I’ve found most useful. I’ll group them around three different goals:

\n\n", "url": "http://vanderburg.org/blog/2016/06/12/mdt-4-building-trust.html", "image": "http://vanderburg.org/blogimages/ss_building_trust.jpg", "tags": [ "management", "distributed teams", "remote work", "telecommuting", "communication", "trust", "blog" ], "date_published": "2016-06-12T21:10:00-05:00", "date_modified": "2016-06-12T21:10:00-05:00", "authors": [{ "name": "Maria Gutierrez", "url": "http://twitter.com/mariagutierrez", "avatar": "http://vanderburg.org/images/maria.jpg" }] }, { "id": "http://vanderburg.org/blog/2016/06/02/mdt_3_rule_number_one.html", "title": "Distributed Teams Rule Number One", "summary": "Deliberate communication is essential on distributed teams.", "content_text": " Distributed teams and colocated teams are similar in some ways, and different in many others. But there is one underlying difference that is so basic it has an impact on everything else: Rule #1 of distributed teams: Communication doesn’t just happen. In a colocated team, there is a lot of communication that happens naturally, without anyone ever thinking about it or planning it. Some of this is really obvious. Team members go to lunch together, or grab coffee, or sometimes share drinks after work, and conversation naturally includes work topics. Employees overhear nearby conversations (and join in if they feel they have something to contribute, or want to learn more). But there are also things you might never have considered. People notice when people are sitting together or meeting together, and from that collaboration they infer that something is happening. They see interesting information left on whiteboards. They notice reference books left on desks, thereby understanding what tools or technologies are being considered for other parts of the system. They see expressions of stress, excitement, or confidence on the faces of peers and managers. They think out loud, or ask nearby coworkers for help in working through ideas. All of those things are passive forms of communication. People are quite good at communicating with each other and drawing conclusions from the patterns they see—so good, in fact, that it’s almost as natural to most people as breathing. That means that a lot of valuable communication happens in a colocated team implicitly, without anyone ever planning it or even thinking about it very much. You can’t depend on that kind of thing happening on a distributed team. I mean, sure … people still communicate, and ask each other for help, and have conversations in chat rooms where people can “overhear”, and so on. But there’s more friction, more overhead, and so unless you’re deliberate and intentional about it, it won’t happen as much. At this point, you might be thinking, “It sounds like distributed teams are inherently worse for communication.” But colocated teams have their own issues with communication, often directly related to how easy and casual it is. Think about it: you’re relying on a lot of accidental communication. It’s great that it all happens so easily, but it could actually benefit from being planned and considered a little more. People will learn important things the hard way, and then not take the time to communicate that to the rest of the team. Or an impromptu gathering will make an important decision, but forget to validate the decision with important stakeholders (or to communicate it to everyone who must follow through with implementing that decision). And background information, such as the rationale behind a decision, is frequently lost. Those things happen in distributed teams, too. But a distributed team typically does much more of its communication in writing, and can have more opportunities to review, disseminate, index, and archive team communication. Plus, as with anything else, focusing on something and giving some thought to the best way to do it can pay important dividends: people become more conscious of how they’re communicating, and of whether the medium is the appropriate one for the kind of information involved. They are more deliberate and careful about how they communicate. Because this is rule number one, several of the posts in this series will be about communication: the different tools, styles, and techniques that are required to make sure that the right communication is happening both within and beyond your distributed engineering team. Start paying attention to all of the kinds of communication that happen in an office, and ask two questions about it: How could a distributed team get some of the same benefits? How could we make this communication more valuable by taking it a little more seriously?", "content_html": "

\"communication\nDistributed teams and colocated teams are similar in some ways, and different in many others.\nBut there is one underlying difference that is so basic it has an impact on everything else:

\n\n

Rule #1 of distributed teams: Communication doesn’t just happen.

\n\n

In a colocated team, there is a lot of communication that happens naturally, without anyone ever thinking about it or planning it.\nSome of this is really obvious.\nTeam members go to lunch together, or grab coffee, or sometimes share drinks after work, and conversation naturally includes work topics.\nEmployees overhear nearby conversations (and join in if they feel they have something to contribute, or want to learn more).

\n\n

But there are also things you might never have considered.\nPeople notice when people are sitting together or meeting together, and from that collaboration they infer that something is happening.\nThey see interesting information left on whiteboards.\nThey notice reference books left on desks, thereby understanding what tools or technologies are being considered for other parts of the system.\nThey see expressions of stress, excitement, or confidence on the faces of peers and managers.\nThey think out loud, or ask nearby coworkers for help in working through ideas.

\n\n

All of those things are passive forms of communication.\nPeople are quite good at communicating with each other and drawing conclusions from the patterns they see—so good, in fact, that it’s almost as natural to most people as breathing.\nThat means that a lot of valuable communication happens in a colocated team implicitly, without anyone ever planning it or even thinking about it very much.

\n\n

You can’t depend on that kind of thing happening on a distributed team.\nI mean, sure … people still communicate, and ask each other for help, and have conversations in chat rooms where people can “overhear”, and so on.\nBut there’s more friction, more overhead, and so unless you’re deliberate and intentional about it, it won’t happen as much.

\n\n

At this point, you might be thinking,\n“It sounds like distributed teams are inherently worse for communication.”\nBut colocated teams have their own issues with communication, often directly related to how easy and casual it is.\nThink about it: you’re relying on a lot of accidental communication.\nIt’s great that it all happens so easily, but it could actually benefit from being planned and considered a little more.\nPeople will learn important things the hard way, and then not take the time to communicate that to the rest of the team.\nOr an impromptu gathering will make an important decision, but forget to validate the decision with important stakeholders (or to communicate it to everyone who must follow through with implementing that decision).\nAnd background information, such as the rationale behind a decision, is frequently lost.

\n\n

Those things happen in distributed teams, too.\nBut a distributed team typically does much more of its communication in writing, and can have more opportunities to review, disseminate, index, and archive team communication.\nPlus, as with anything else, focusing on something and giving some thought to the best way to do it can pay important dividends:\npeople become more conscious of how they’re communicating, and of whether the medium is the appropriate one for the kind of information involved.\nThey are more deliberate and careful about how they communicate.

\n\n

Because this is rule number one, several of the posts in this series will be about communication:\nthe different tools, styles, and techniques that are required to make sure that the right communication is happening both within and beyond your distributed engineering team.\nStart paying attention to all of the kinds of communication that happen in\nan office, and ask two questions about it:

\n\n
    \n
  1. How could a distributed team get some of the same benefits?
    2. \n
  2. How could we make this communication more valuable by taking it a little more\nseriously?
    3. \n
", "url": "http://vanderburg.org/blog/2016/06/02/mdt_3_rule_number_one.html", "image": "http://vanderburg.org/blogimages/separate_fish.jpg", "tags": [ "management", "distributed teams", "remote work", "telecommuting", "communication", "blog" ], "date_published": "2016-06-02T10:00:00-05:00", "date_modified": "2016-06-02T10:00:00-05:00", "authors": [{ "name": "Glenn Vanderburg", "url": "http://twitter.com/glv", "avatar": "http://vanderburg.org/images/glv.jpg" }] }, { "id": "http://vanderburg.org/blog/2016/05/31/mdt_2_distributed.html", "title": "Terms: “Distributed,” “Remote,” and More", "summary": "Words matter on a distributed software team.", "content_text": "One of the earliest challenges we faced in building our team at LivingSocial was eliminating “us and them” attitudes between the “locals” and the “remotes”. That sentence should give you a clue about the problem: the words we use are important, and they affect the way we see other people and ourselves. Therefore, one of the ways we solved the problem was to rethink our choice of words. The opposite of “remote” is “local.” At least in terms of associations and connotations, those words carry value judgments. Used literally, “remote” describes places, and means that the places are challenging and time-consuming to reach. But we also use “remote” in reference to people: those who are withdrawn, cold, or hard to communicate with. Calling the on-site developers “local” and others “remote” helped to reinforce a class distinction, where everyone perceived the remote developers—at least a little bit—as second-class citizens. That affected how the “local” developers worked with the remote folks; perhaps worse, it also affected how remote developers saw themselves, causing low morale and a sense of isolation. The result was reduced productivity and retention. Additionally, apart from the cultural issues, those terms encouraged two different sets of communication and coordination patterns. Teams comprised mostly of “local,” on-site employees would naturally adopt a culture and communication style appropriate to a colocated team (impromptu conversations, mostly voice communication). Teams of “remote” developers would depend much more on email and chat. This meant that we effectively had two teams: the developers who worked at headquarters, and those who worked remotely. That wasn’t what we were aiming for. We chose to start emphasizing the term “distributed.” Rather than a team with some local and some remote developers, we were all on a distributed team. The words “remote” and “local” aren’t forbidden, and in some contexts they’re still the right words for a legitimate distinction. But the emphasis—especially when speaking about the whole team or our work style, collaboration techniques, and communication patterns—is on the word “distributed”. It took a while to change the vocabulary throughout the organization. But after that, it didn’t take too long before we started seeing the positive effects. In this series we will talk about several specific ways that on-site and remote employees can choose to work in the same way, easing communication and collaboration across the organization. For now, it’s sufficient to say that adopting this vocabulary was a big morale boost for the remote employees, and helped to build a more unified team. There are other terms that some people use, and that we considered. You might call a team that emphasizes satellite offices rather than working from home a “multi-site” team, and many teams that engage in offshoring fit that model. Multi-site teams have some of the same challenges, plus some additional problems; in our opinion, choosing a multi-site strategy sacrifices many of the benefits of a fully distributed team. Two other terms are found in the titles of the Wikipedia pages that address the issues we’re discussing: Virtual team and Telecommuting. While there’s nothing necessarily bad about those terms, they didn’t resonate as well with us. I doubt that anyone on the team at LivingSocial would say there’s anything “virtual” about it: it’s very real, with a vibrant, dynamic culture. To say that a team like ours is “virtual” implies that the most important thing about “real” teams is that they sit together, and that’s silly. And “telecommuting” seems to describe tools and techniques rather than the team itself; at best, just like “local” and “remote,” it refers to individuals on the team rather than saying anything about the team as a whole. Words can divide and belittle, or they can build up and unify. And even neutral or positive words, chosen poorly, can distract us from what’s important. The right words can make a huge difference. We saw things start to change for the better at LivingSocial when we focused on the term “distributed” as a word that included all of us. That’s why we’ve titled this series “Managing Distributed Teams”.", "content_html": "

One of the earliest challenges we faced in building our team at LivingSocial was eliminating “us and them” attitudes between the “locals” and the “remotes”.\nThat sentence should give you a clue about the problem:\nthe words we use are important, and they affect the way we see other people and ourselves.\nTherefore, one of the ways we solved the problem was to rethink our choice of words.

\n\n

\"Grover\nThe opposite of “remote” is “local.”\nAt least in terms of associations and connotations, those words carry value judgments.\nUsed literally, “remote” describes places, and means that the places are challenging and time-consuming to reach.\nBut we also use “remote” in reference to people:\nthose who are withdrawn, cold, or hard to communicate with.\nCalling the on-site developers “local” and others “remote” helped to reinforce a class distinction, where everyone perceived the remote developers—at least a little bit—as second-class citizens.\nThat affected how the “local” developers worked with the remote folks;\nperhaps worse, it also affected how remote developers saw themselves, causing low morale and a sense of isolation.\nThe result was reduced productivity and retention.

\n\n

Additionally, apart from the cultural issues, those terms encouraged two different sets of communication and coordination patterns.\nTeams comprised mostly of “local,” on-site employees would naturally adopt a culture and communication style appropriate to a colocated team (impromptu conversations, mostly voice communication).\nTeams of “remote” developers would depend much more on email and chat.\nThis meant that we effectively had two teams: the developers who worked at\nheadquarters, and those who worked remotely.\nThat wasn’t what we were aiming for.

\n\n

We chose to start emphasizing the term “distributed.”\nRather than a team with some local and some remote developers, we were all on a distributed team.\nThe words “remote” and “local” aren’t forbidden,\nand in some contexts they’re still the right words for a legitimate distinction.\nBut the emphasis—especially when speaking about the whole team or our work style, collaboration techniques, and communication patterns—is on the word “distributed”.

\n\n

It took a while to change the vocabulary throughout the organization.\nBut after that, it didn’t take too long before we started seeing the positive effects.\nIn this series we will talk about several specific ways that on-site and remote employees can choose to work in the same way,\neasing communication and collaboration across the organization.\nFor now, it’s sufficient to say that adopting this vocabulary was a big morale\nboost for the remote employees, and helped to build a more unified team.

\n\n

There are other terms that some people use, and that we considered.\nYou might call a team that emphasizes satellite offices rather than working from home a “multi-site” team, and many teams that engage in offshoring fit that model.\nMulti-site teams have some of the same challenges, plus some additional problems;\nin our opinion, choosing a multi-site strategy sacrifices many of the benefits of a fully distributed team.

\n\n

Two other terms are found in the titles of the Wikipedia pages that address the issues we’re discussing:\nVirtual team and Telecommuting.\nWhile there’s nothing necessarily bad about those terms, they didn’t resonate as well with us.\nI doubt that anyone on the team at LivingSocial would say there’s anything “virtual” about it:\nit’s very real, with a vibrant, dynamic culture.\nTo say that a team like ours is “virtual” implies that the most important thing\nabout “real” teams is that they sit together, and that’s silly.\nAnd “telecommuting” seems to describe tools and techniques rather than the team itself;\nat best, just like “local” and “remote,” it refers to individuals on the team\nrather than saying anything about the team as a whole.

\n\n

Words can divide and belittle, or they can build up and unify.\nAnd even neutral or positive words, chosen poorly, can distract us from what’s important.\nThe right words can make a huge difference.\nWe saw things start to change for the better at LivingSocial when we focused on the term “distributed” as a word that included all of us.\nThat’s why we’ve titled this series “Managing Distributed Teams”.

", "url": "http://vanderburg.org/blog/2016/05/31/mdt_2_distributed.html", "image": "http://vanderburg.org/blogimages/grover_local_remote_wide.jpg", "tags": [ "management", "distributed teams", "remote work", "telecommuting", "virtual teams", "terminology", "blog" ], "date_published": "2016-05-31T10:00:00-05:00", "date_modified": "2016-05-31T10:00:00-05:00", "authors": [{ "name": "Glenn Vanderburg", "url": "http://twitter.com/glv", "avatar": "http://vanderburg.org/images/glv.jpg" }] }, { "id": "http://vanderburg.org/blog/2016/05/26/mdt_1_managing_distributed_teams.html", "title": "Managing Distributed Software Teams", "summary": "Introducing a series on distributed team management by Maria Gutierrez and Glenn Vanderburg.", "content_text": " Remote software work is increasingly common. At the beginning of my career, it was almost unheard of. But over the years it has grown steadily. I’ve been working from home for 10 years now, and when I gave a talk on the topic two years ago, fully half of the audience were working from home on a daily basis. But there are still challenges. For the past five years, I’ve been a part of a large software team that is heavily distributed: more than 60% of the LivingSocial engineering team works from home, spread across several time zones and a few countries. At its peak, the team was about 180 people, with well over 100 developers working from home or in small satellite offices or coworking spaces. At the start—even after we had a substantial number of remote developers—the team managers worked at the office. That is a very common model. But eventually, as the team changed and grew, we found ourselves with managers working remotely, too. From 2013 through early 2016, my colleague Maria Gutierrez and I worked from our homes (me in Dallas, Maria in Edinburgh) as Engineering Directors, managing distributed teams ranging in size from 30 to 80. We made a lot of mistakes, but we also got a lot of things right, and we learned a lot from successes and failures alike. And at every step, we received valuable feedback from others at every level of our organization. It seems like a good time to start sharing what we’ve learned. More companies are trying distributed teams. There are many reasons to do so. Here are just a few: A company might choose that direction, as LivingSocial did, to make it easier to recruit excellent developers. A company might want to provide more flexible working arrangements for its employees. One company might acquire or merge with other companies in different cities. Talented developers may wish to relocate for personal reasons, and the company might decide to “go distributed” rather than lose the valuable skills of loyal, dedicated employees. The company might move its headquarters to a different part of the city, with some team members asking to work from home rather than endure a longer commute. Maria and I would like to share our experiences with those who might be starting down a similar path. In coming weeks, we’ll be blogging here about how to be effective in managing distributed software teams.", "content_html": "

\"Dilbert

\n\n

Remote software work is increasingly common.\nAt the beginning of my career, it was almost unheard of.\nBut over the years it has grown steadily.\nI’ve been working from home for 10 years now, and when I gave a talk on the topic two years ago, fully half of the audience were working from home on a daily basis.

\n\n

But there are still challenges.

\n\n

For the past five years, I’ve been a part of a large software team that is heavily distributed:\nmore than 60% of the LivingSocial engineering team works from home, spread across several time zones and a few countries.\nAt its peak, the team was about 180 people, with well over 100 developers\nworking from home or in small satellite offices or coworking spaces.

\n\n

At the start—even after we had a substantial number of remote developers—the team managers worked at the office.\nThat is a very common model.\nBut eventually, as the team changed and grew, we found ourselves with managers working remotely, too.\nFrom 2013 through early 2016, my colleague Maria Gutierrez and I worked from our homes (me in Dallas, Maria in Edinburgh) as Engineering Directors, managing distributed teams ranging in size from 30 to 80.\nWe made a lot of mistakes, but we also got a lot of things right, and we learned a lot from successes and failures alike.\nAnd at every step, we received valuable feedback from others at every level of our organization.

\n\n

It seems like a good time to start sharing what we’ve learned.\nMore companies are trying distributed teams.\nThere are many reasons to do so. Here are just a few:

\n\n\n\n

Maria and I would like to share our experiences with those who might be starting down a similar path.\nIn coming weeks, we’ll be blogging here about how to be effective in managing distributed software teams.

", "url": "http://vanderburg.org/blog/2016/05/26/mdt_1_managing_distributed_teams.html", "image": "http://vanderburg.org/blogimages/ss_vidconf.jpg", "tags": [ "management", "distributed teams", "remote work", "telecommuting", "blog" ], "date_published": "2016-05-26T09:10:00-05:00", "date_modified": "2016-05-26T09:10:00-05:00", "authors": [{ "name": "Glenn Vanderburg", "url": "http://twitter.com/glv", "avatar": "http://vanderburg.org/images/glv.jpg" }] }, { "id": "http://vanderburg.org/blog/2016/05/10/seeking.html", "title": "Choose Me To Lead Your Distributed Software Development Team", "summary": "I have three years of experience leading a large, geographically distributed team of software engineers. I'd like to help another company build on that experience.", "content_text": " After a little over five years, I’m moving on from LivingSocial. What’s next for me? Well, I’m looking for the right position. At LivingSocial, we’ve spent five years learning how a distributed software development team can be really effective. I’d like to help another company build on that experience. For the past three years I’ve been one of the leaders of our engineering team, overseeing a department ranging in size from 30 to 50 software developers and managers (part of a larger engineering team of about 150). The majority of those people—including me and other senior managers—have worked from home. It hasn’t all been smooth sailing, but we built a great team, learning valuable lessons about how a geographically distributed team can collaborate, manage work, recruit, train, mentor, maintain a healthy culture, and continually improve. I’ve enjoyed being in the middle of that, working closely with our VP of Engineering and CTO, as well as the other department directors and the managers on my team. It’s been a wonderful opportunity to add a new dimension to my 25 years of experience as a developer and software architect. In the software industry, remote work and distributed teams are becoming increasingly common. Many companies now have employees who work mostly from home or from other locations. And there are good reasons to pursue that as a strategy. But running a distributed team is different from running a colocated team, and it’s difficult to do it well. Most companies aren’t seeing as much effectiveness from their distributed teams as they (and the teams) would like. If you are building a distributed team and would like a senior, experienced engineering leader with solid technical chops to help you succeed, please contact me: Email: glenn at this domain CV: https://www.linkedin.com/in/glennvanderburg", "content_html": "

\"Me\nAfter a little over five years, I’m moving on from LivingSocial.\nWhat’s next for me?\nWell, I’m looking for the right position.\nAt LivingSocial, we’ve spent five years learning how a distributed software development team can be really effective.\nI’d like to help another company build on that experience.

\n\n

For the past three years I’ve been one of the leaders of our engineering team, overseeing a department ranging in size from 30 to 50 software developers and managers (part of a larger engineering team of about 150).\nThe majority of those people—including me and other senior managers—have worked from home.\nIt hasn’t all been smooth sailing, but we built a great team, learning valuable lessons about how a geographically distributed team can collaborate, manage work, recruit, train, mentor, maintain a healthy culture, and continually improve.

\n\n

I’ve enjoyed being in the middle of that, working closely with our VP of Engineering and CTO, as well as the other department directors and the managers on my team.\nIt’s been a wonderful opportunity to add a new dimension to my 25 years of experience as a developer and software architect.

\n\n

In the software industry, remote work and distributed teams are becoming increasingly common.\nMany companies now have employees who work mostly from home or from other locations.\nAnd there are good reasons to pursue that as a strategy.\nBut running a distributed team is different from running a colocated team, and it’s difficult to do it well.\nMost companies aren’t seeing as much effectiveness from their distributed teams as they (and the teams) would like.

\n\n

If you are building a distributed team and would like a senior, experienced engineering leader with solid technical chops to help you succeed, please contact me:

\n\n", "url": "http://vanderburg.org/blog/2016/05/10/seeking.html", "tags": [ "employment", "blog" ], "date_published": "2016-05-10T13:35:00-05:00", "date_modified": "2016-05-10T13:35:00-05:00", "authors": [{ "name": "Glenn Vanderburg", "url": "http://twitter.com/glv", "avatar": "http://vanderburg.org/images/glv.jpg" }] }, { "id": "http://vanderburg.org/blog/2016/02/16/about-clo.html", "title": "About Cló", "summary": "At Clojure/conj in 2014, I spoke about Cló, a project to implement the algorithms of the TeX typesetting system in Clojure. This is a short status update.", "content_text": "A little over a year ago, I gave a talk at Clojure/conj called Cló: The Algorithms of TEX in Clojure. It was very well received, and a surprising number of people were interested in the project (which at the time was only partly complete, unreleased, and in the middle of a substantial redesign). A few people have been asking me about the status, so here it is: it is only partly compete, unreleased, and in the middle of a substantial redesign. There are several reasons for that. The first one is that my job has kept me quite busy, with little time left over for a hobby project. But that wasn’t everything. At the time I gave the talk, my mother was experiencing medical problems that would, over the next few months, bring her to her death on 20 April 2015 at the age of 95. In many ways it wasn’t a sad occasion: 95 is a ripe old age, and her quality of life had been poor for a long time, so the point of this isn’t to solicit condolences. But caring for her in those final months, the funeral, and then arranging a move for my dad a short time afterward took up most of my time. But around the middle of 2015, I did start to get back to Cló again. And I realized something right away: before rebuilding Cló with my revised goals, I needed to become a better Clojure programmer. Cló was the largest Clojure program I had ever worked on, and the first one where I was in charge of the design. So as I returned to the project, I found myself trying to do several challenging things at once: Decipher the mind-mangling complexity of TEX’s code; Separate the optimizations from the essence of the algorithms; Recast those thoroughly procedural algorithms into a functional style; Correct the initial design mistakes from my first version of Cló; and Level-up as a Clojure programmer. I can’t see a way around doing the first four simultaneously, but the last one can be done all by itself. I realized that it would be smart to get that one out of the way first, by practicing Clojure on a simpler project. That project is snergly, a Clojure implementation of the algorithms in Jamis Buck’s wonderful book Mazes for Programmers. Toward the end of summer, before my job got too busy again, I built a command-line Clojure application that covered the first five chapters of the book. More recently, starting with a conference trip in early December and continuing through the Christmas holidays, I got that code working in ClojureScript to produce an animated, browser-based display. Along the way I’ve learned a lot (about both Clojure and ClojureScript, Om Next, Prismatic schema, and test.check). I think I’m ready to take another run at Cló. The next time I have some spare time to hack on something, that’s the project I’ll be working on.", "content_html": "

A little over a year ago, I gave a talk at Clojure/conj called\nCló: The Algorithms of TEX in Clojure.\nIt was very well received, and a surprising number of people were interested in\nthe project (which at the time was only partly complete, unreleased, and in the\nmiddle of a substantial redesign).

\n\n

A few people have been asking me about the status, so here it is: it is only\npartly compete, unreleased, and in the middle of a substantial redesign.

\n\n

There are several reasons for that. The first one is that my job has kept me\nquite busy, with little time left over for a hobby project. But that wasn’t\neverything.

\n\n

At the time I gave the talk, my mother was experiencing medical problems that\nwould, over the next few months, bring her to her death on 20 April 2015 at the\nage of 95. In many ways it wasn’t a sad occasion: 95 is a ripe old age, and\nher quality of life had been poor for a long time, so the point of this isn’t\nto solicit condolences. But caring for her in those final months, the funeral,\nand then arranging a move for my dad a short time afterward took up most of my\ntime.

\n\n

But around the middle of 2015, I did start to get back to Cló again. And I\nrealized something right away: before rebuilding Cló with my revised goals, I\nneeded to become a better Clojure programmer. Cló was the largest Clojure\nprogram I had ever worked on, and the first one where I was in charge of the\ndesign. So as I returned to the project, I found myself trying to do several\nchallenging things at once:

\n\n\n\n

I can’t see a way around doing the first four simultaneously, but the last one\ncan be done all by itself. I realized that it would be smart to get that one\nout of the way first, by practicing Clojure on a simpler project.

\n\n

That project is snergly, a Clojure implementation of the algorithms in\nJamis Buck’s wonderful book Mazes for Programmers. Toward the\nend of summer, before my job got too busy again, I built a command-line Clojure\napplication that covered the first five chapters of the book. More recently,\nstarting with a conference trip in early December and continuing through the\nChristmas holidays, I got that code working in ClojureScript to produce an\nanimated, browser-based display. Along the way I’ve learned a lot (about both\nClojure and ClojureScript, Om Next, Prismatic schema, and test.check).

\n\n

I think I’m ready to take another run at Cló. The next time I have some spare\ntime to hack on something, that’s the project I’ll be working on.

", "url": "http://vanderburg.org/blog/2016/02/16/about-clo.html", "tags": [ "clojure", "blog" ], "date_published": "2016-02-16T17:17:00-06:00", "date_modified": "2016-02-16T17:17:00-06:00", "authors": [{ "name": "Glenn Vanderburg", "url": "http://twitter.com/glv", "avatar": "http://vanderburg.org/images/glv.jpg" }] }, { "id": "http://vanderburg.org/blog/2016/02/15/back_again.html", "title": "Back Again", "summary": "A blog post by Glenn Vanderburg.", "content_text": "After a break of several years, I’ve decided to start blogging again. I never decided to stop; I simply found myself not having much to say in a blogging context. But lately I’ve found myself wanting to write more. So I’ve converted my old rublog-based setup and I’m ready to go. Expect more updates soon.", "content_html": "

After a break of several years, I’ve decided to start blogging again.

\n\n

I never decided to stop; I simply found myself not having much to say in\na blogging context. But lately I’ve found myself wanting to write more.\nSo I’ve converted my old rublog-based setup and I’m ready to go. Expect more\nupdates soon.

", "url": "http://vanderburg.org/blog/2016/02/15/back_again.html", "tags": [ "blogging", "blog" ], "date_published": "2016-02-15T18:25:00-06:00", "date_modified": "2016-02-15T18:25:00-06:00", "authors": [{ "name": "Glenn Vanderburg", "url": "http://twitter.com/glv", "avatar": "http://vanderburg.org/images/glv.jpg" }] }, { "id": "http://vanderburg.org/blog/2011/01/31/cohesion.html", "title": "Cohesion", "summary": "An etymological explanation of cohesion as a software design concept.", "content_text": "Developers I encounter usually have a good grasp of coupling—not only what it means, but why it’s a problem. I can’t say the same thing about cohesion. One of the sharpest developers I know sometimes has problems with the concept, and once told me something like “that word doesn’t mean much to me.” I’ve come to believe that a big part of the problem is the word “cohesion” itself. “Coupling” is something everyone understands. “Cohesion,” on the other hand, is a word that is not often used in everyday language, and that lack of familiarity makes it a difficult word for people to hang a crucial concept on. I’ve had some success teaching the concept of cohesion using an unusual approach that exploits the word’s etymology. I know that sounds unlikely, but bear with me. In my experience, it seems to register well with people. Cohesion comes from the same root word that “adhesion” comes from. It’s a word about sticking. When something adheres to something else (when it’s adhesive, in other words) it’s a one-sided, external thing: something (like glue) is sticking one thing to another. Things that are cohesive, on the other hand, naturally stick to each other because they are of like kind, or because they fit so well together. Duct tape adheres to things because it’s sticky, not because it necessarily has anything in common with them. But two lumps of clay will cohere when you put them together, and matched, well-machined parts sometimes seem to cohere because the fit is so precise. Adhesion is one thing sticking to another; cohesion is a mutual relationship, with two things sticking together. This is also why we refer to a sound line of reasoning, for example, as coherent. The thoughts fit, they go together, they relate to each other. This is exactly the characteristic of a class that makes it coherent: the pieces all seem to be related, they seem to belong together, and it would feel somewhat unnatural (it would result in tight coupling!) to pull them apart. Such a class exhibits cohesion. No glue is required, you don’t have to build extra code to make the pieces fit together; the pieces hang together naturally because they’re closely related. In contrast, sometimes a class will seem to have its fingers in way too many parts of your system. Such a class is adhesive, and that’s not what we’re looking for. And whereas coherent means things fit well together, we use the word “adherent” to refer to a follower, and there’s a connotation that the follower isn’t necessarily wanted: a hanger-on. There’s another common word that stems from the same root: “inherent”. Something that adheres sticks to something else, and two things that are coherent mutually stick to each other, but something that is inherent isn’t stuck to something so much as it’s embedded: it is an integral part of the other thing, tightly and inextricably bound. Although you don’t hear them very often, the two sister words “inhere” and “inhesion” are real words, as well. So cohesion/cohesive/coherent occupy the middle territory between the sort of arbitrary, forced relationship of adhesion/adhesive/adherent and the integral, unbreakable relationship of inhesion/inhesive/inherent. That mental picture often helps me make wise decisions when I’m designing and refactoring. I want to build classes that are cohesive, not adhesive.", "content_html": "

Developers I encounter usually have a good grasp of coupling—not only what it\nmeans, but why it’s a problem. I can’t say the same thing about cohesion.\nOne of the sharpest developers I know sometimes has problems with the concept,\nand once told me something like “that word doesn’t mean much to me.” I’ve\ncome to believe that a big part of the problem is the word “cohesion” itself.\n“Coupling” is something everyone understands. “Cohesion,” on the other hand,\nis a word that is not often used in everyday language, and that lack of\nfamiliarity makes it a difficult word for people to hang a crucial concept on.

\n\n

I’ve had some success teaching the concept of cohesion using an unusual\napproach that exploits the word’s etymology. I know that sounds unlikely, but\nbear with me. In my experience, it seems to register well with people.

\n\n

Cohesion comes from the same root word that “adhesion” comes from. It’s a word\nabout sticking. When something adheres to something else (when it’s\nadhesive, in other words) it’s a one-sided, external thing: something (like\nglue) is sticking one thing to another. Things that are cohesive, on the\nother hand, naturally stick to each other because they are of like kind, or\nbecause they fit so well together. Duct tape adheres to things because it’s\nsticky, not because it necessarily has anything in common with them. But two\nlumps of clay will cohere when you put them together, and matched,\nwell-machined parts sometimes seem to cohere because the fit is so precise.\nAdhesion is one thing sticking to another; cohesion is a mutual\nrelationship, with two things sticking together.

\n\n

This is also why we refer to a sound line of reasoning, for example, as\ncoherent. The thoughts fit, they go together, they relate to each other.\nThis is exactly the characteristic of a class that makes it coherent: the\npieces all seem to be related, they seem to belong together, and it would feel\nsomewhat unnatural (it would result in tight coupling!) to pull them apart.\nSuch a class exhibits cohesion. No glue is required, you don’t have to\nbuild extra code to make the pieces fit together; the pieces hang together\nnaturally because they’re closely related. In contrast, sometimes a class\nwill seem to have its fingers in way too many parts of your system. Such a\nclass is adhesive, and that’s not what we’re looking for.

\n\n

And whereas coherent means things fit well together, we use the word\n“adherent” to refer to a follower, and there’s a connotation that the follower\nisn’t necessarily wanted: a hanger-on.

\n\n

There’s another common word that stems from the same root: “inherent”.\nSomething that adheres sticks to something else, and two things that are\ncoherent mutually stick to each other, but something that is inherent isn’t\nstuck to something so much as it’s embedded: it is an integral part of the\nother thing, tightly and inextricably bound. Although you don’t hear them\nvery often, the two sister words “inhere” and “inhesion” are real words, as\nwell.

\n\n

So cohesion/cohesive/coherent occupy the middle territory between the sort\nof arbitrary, forced relationship of adhesion/adhesive/adherent and the\nintegral, unbreakable relationship of inhesion/inhesive/inherent. That\nmental picture often helps me make wise decisions when I’m designing and\nrefactoring. I want to build classes that are cohesive, not adhesive.

", "url": "http://vanderburg.org/blog/2011/01/31/cohesion.html", "tags": [ "software", "development", "blog" ], "date_published": "2011-01-31T10:43:59-06:00", "date_modified": "2011-01-31T10:43:59-06:00", "authors": [{ "name": "Glenn Vanderburg", "url": "http://twitter.com/glv", "avatar": "http://vanderburg.org/images/glv.jpg" }] } ] }