Removed HTML entities.

book.json

@@ -191,7 +191,7 @@
                 "santos16": "Ronnie E. S. Santos, Fabio Q. B. da Silva, Cleyton V. C. de Magalhães, and Cleviton V. F. Monteiro. 2016. [Building a theory of job rotation in software engineering from an instrumental case study|https://doi.org/10.1145/2884781.2884837]. In Proceedings of the 38th International Conference on Software Engineering (ICSE '16). ACM, New York, NY, USA, 971-981.",
                 "schiller14": "Schiller, T. W., Donohue, K., Coward, F., & Ernst, M. D. (2014). [Case studies and tools for contract specifications|https://doi.org/10.1145/2568225.2568285]. In Proceedings of the 36th International Conference on Software Engineering (pp. 596-607).",
                 "seaman97": "Carolyn B. Seaman and Victor R. Basili. 1997. [An empirical study of communication in code inspections|http://dx.doi.org/10.1145/253228.253248]. In Proceedings of the 19th international conference on Software engineering (ICSE '97). ACM, New York, NY, USA, 96-106.",
-                "sedano17": "Sedano, T., Ralph, P., & Péraire, C. (2017). [Software development waste|http://dl.acm.org/citation.cfm?id=3097385]. In Proceedings of the 39th International Conference on Software Engineering (pp. 130-140). IEEE Press.", 
+                "sedano17": "Sedano, T., Ralph, P., & Péraire, C. (2017). [Software development waste|http://dl.acm.org/citation.cfm?id=3097385]. In Proceedings of the 39th International Conference on Software Engineering (pp. 130-140). IEEE Press.", 
                 "sfetsos09": "Sfetsos, P., Stamelos, I., Angelis, L., & Deligiannis, I. (2009). [An experimental investigation of personality types impact on pair effectiveness in pair programming|https://link.springer.com/article/10.1007/s10664-008-9093-5]. Empirical Software Engineering, 14(2), 187.",
                 "sharp04": "Sharp, H., & Robinson, H. (2004). [An ethnographic study of XP practice|https://doi.org/10.1023/B:EMSE.0000039884.79385.54]. Empirical Software Engineering, 9(4), 353-375.",
                 "shetterly17": "Shetterly, M. L. (2017). Hidden figures. HarperCollins Nordic.",

chapters/communication.md

@@ -6,12 +6,12 @@ It turns out, however, that communication plays such a powerful role in software
 
 Because communication is so central, software engineers are constantly seeking information to further their work, going to their coworkers' desks, emailing them, chatting via messaging platforms, and even using social media<ko07>. Some of the information that developers are seeking is easier to find than others. For example, in the study I just cited, it was pretty trivial to find information about how wrote a line of code or whether a build was done, but when the information they needed resided in someone else's head (e.g., _why_ a particular line of code was written), it was slow or often impossible to retrieve it. Sometimes it's not even possible to find out who has the information. Researchers have investigated tools for trying to quantify expertise by automatically analyzing the code that developers have written, building platforms to help developers search for other developers who might know what they need to know<mockus02,begel10>.
 
-Communication is not always effective. In fact, there are many kinds of communication that are highly problematic in software engineering teams. For example, Perlow<perlow99> conducted an [ethnography|https://en.wikipedia.org/wiki/Ethnography] of one team and found a highly dysfunctional use of interruptions in which the most expert members of a team were constantly interrupted to &ldquo;fight fires&rdquo; (immediately address critical problems) in other parts of the organization, and then the organization rewarded them for their heroics. This not only made the most expert engineers less productive, but it also disincentivized the rest of the organization to find effective ways of _preventing_ the disasters from occurring in the first place. Not all interruptions are bad, and they can increase productivity, but they do increase stress<mark08>.
+Communication is not always effective. In fact, there are many kinds of communication that are highly problematic in software engineering teams. For example, Perlow<perlow99> conducted an [ethnography|https://en.wikipedia.org/wiki/Ethnography] of one team and found a highly dysfunctional use of interruptions in which the most expert members of a team were constantly interrupted to "fight fires" (immediately address critical problems) in other parts of the organization, and then the organization rewarded them for their heroics. This not only made the most expert engineers less productive, but it also disincentivized the rest of the organization to find effective ways of _preventing_ the disasters from occurring in the first place. Not all interruptions are bad, and they can increase productivity, but they do increase stress<mark08>.
 
 Communication isn't just about transmitting information; it's also about relationships and identity. For example, the dominant culture of many software engineering work environments--and even the _perceived_ culture--is one that can deter many people from even pursuing careers in computer science. Modern work environments are still dominated by men, who speak loudly, out of turn, and disrespectfully, with sometimes even [sexual harassment|https://www.susanjfowler.com/blog/2017/2/19/reflecting-on-one-very-strange-year-at-uber]<wang16>. Computer science as a discipline, and the software industry that it shapes, has only just begun to consider the urgent need for _cultural competence_ (the ability for individuals and organizations to work effectively when their employee's thoughts, communications, actions, customs, beliefs, values, religions, and social groups vary)<washington20>.  Similarly, software developers often have to work with people in other domains such as artists, content developers, data scientists, design researchers, designers, electrical engineers, mechanical engineers, product planners, program managers, and service engineers. One study found that developers' cross-disciplinary collaborations with people in these other domains required open-mindedness about the input of others, proactively informing everyone about code-related constraints, and ultimately seeing the broader picture of how pieces from different disciplines fit together; when developers didn't do these things, collaborations failed, and therefore projects failed<li17>. These are not the conditions for trusting, effective communication.
 
 When communication is effective, it still takes time. One of the key strategies for reducing the amount of communication necessary is _knowledge sharing_ tools, which broadly refers to any information system that stores facts that developers would normally have to retrieve from a person. By storing them in a database and making them easy to search, teams can avoid interruptions. The most common knowledge sharing tools in software teams are issue trackers, which are often at the center of communication not only between developers, but also with every other part of a software organization<bertram10>. Community portals, such as GitHub pages or Slack teams, can also be effective ways of sharing documents and archiving decisions<treude11>. Perhaps the most popular knowledge sharing tool in software engineering today is [Stack Overflow|https://stackoverflow.com]<atwood16>, which archives facts about programming language and API usage. Such sites, while they can be great resources, have the same problems as many media, such as gender bias that prevent contributions from women from being rewarded as highly as contributions from men<may19>.
 		
-Because all of this knowledge is so critical to progress, when developers leave an organization and haven't archived their knowledge somewhere, it can be quite disruptive to progress. Organizations often have single points of failure, in which a single developer may be critical to a team's ability to maintain and enhance a software product<rigby16>. When newcomers join a team and lack the right knowledge, they introduce defects<foucault15>. Some companies try to mitigate this by rotating developers between projects, &ldquo;cross-training&rdquo; them to ensure that the necessary knowledge to maintain a project is distributed across multiple engineers.
+Because all of this knowledge is so critical to progress, when developers leave an organization and haven't archived their knowledge somewhere, it can be quite disruptive to progress. Organizations often have single points of failure, in which a single developer may be critical to a team's ability to maintain and enhance a software product<rigby16>. When newcomers join a team and lack the right knowledge, they introduce defects<foucault15>. Some companies try to mitigate this by rotating developers between projects, "cross-training" them to ensure that the necessary knowledge to maintain a project is distributed across multiple engineers.
 	
 What does all of this mean for you as an individual developer? To put it simply, don't underestimate the importance of talking. Know who you need to talk to, talk to them frequently, and to the extent that you can, write down what you know both to lessen the demand for talking and mitigate the risk of you not being available, but also to make your knowledge more precise and accessible in the future. It often takes decades for engineers to excel at communication. The very fact that you know why communication is important gives you an critical head start.