Fluent Essays

I updated two files about this chapter and one document about the writing requirements, you dont need to read the all content of the article. You can find 1-2 directions from the two files to discuss and describe your opinions from the chapter. Write the approximately 300 words of your opinions.The requirements of Individual Weekly AHA! Papers has been updated. individual_weekly_aha.docx lesson1.pptx li_et_al._2015.pdf Unformatted Attachment Preview Individual Weekly AHA! Papers Hopefully throughout the semester, students will occasionally gain deeper learning/insights that they will find especially useful in their personal or professional lives. I call these kinds of insights “AHA’s!” because they often occur to us seemingly out of nowhere. These AHA’s! are not usually fact-based pieces of information, but are usually integrative ideas about how to apply IT in personal professional lives, how to interact with others, or perhaps to how to be more effective in your endeavors. To this end, every week or so (or more often if the student prefers), each student should think deeply (i.e., reflect) on their thoughts and sentiments as it relates to the course (e.g., principles discussed, technologies used in the course, online vs. traditional learning, personal experiences from the course or team project or extra readings or videos, etc.), and write down their thoughts that might be “AHA!-worthy.” Each AHA! paper should be approximately 300 words in length (minimum 250 words), have a meaningful title, and be uploaded as a single Microsoft Word document (.doc or .docx) to the “Dropbox” on the published due date. Beginning Software Engineering CHAPTER 1 Software Engineering from 20,000 Feet Software and cathedrals are much the same. First we build them, then we pray.—Samuel Redwine There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. The other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.—C.A.R. Hoare Beginning Software Engineering • • • • • • • • Requirements Gathering High-Level Design Low-Level Design Development Testing Deployment Maintenance Wrap-Up Beginning Software Engineering • Requirements Gathering – Identify customers – Write down requirements – Refine requirements so they’re precise enough for developers – Use cases and “what if” analysis Beginning Software Engineering • High-Level Design – Design major subsystems – Database – Classes – User interface – External interfaces Beginning Software Engineering • Low-Level Design – Refine high-level design until the pieces can be implemented Beginning Software Engineering • Development – Write the code Beginning Software Engineering • Testing – Testing • Unit testing • System testing • Regression testing – Bug fixing – Bug tracking – More testing The longer a bug remains undetected, the harder it is to fix. Beginning Software Engineering • Deployment – The application is installed for the users – There are several deployment strategies – Requirements may include: • • • • • Database servers Network Computers Training Support • Parallel operations • Data conversion and maintenance • Bug fixes Beginning Software Engineering • Maintenance – Bug fixes – Changes – Additions and enhancements Beginning Software Engineering • Wrap-Up – Gather information about the project – What went right? – What went wrong? Beginning Software Engineering • Summary – High-Level Design – Low-Level Design – Development – Testing – Deployment – Maintenance – Wrap-Up 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering What Makes A Great Software Engineer? Paul Luo Li*+, Andrew J. Ko*, Jiamin Zhu+ Microsoft+ Seattle, WA {pal,jiaminz}@microsoft.com The Information School* University of Washington ajko@uw.edu Abstract—Good software engineers are essential to the creation of good software. However, most of what we know about softwareengineering expertise are vague stereotypes, such as ‘excellent communicators’ and ‘great teammates’. The lack of specificity in our understanding hinders researchers from reasoning about them, employers from identifying them, and young engineers from becoming them. Our understanding also lacks breadth: what are all the distinguishing attributes of great engineers (technical expertise and beyond)? We took a first step in addressing these gaps by interviewing 59 experienced engineers across 13 divisions at Microsoft, uncovering 53 attributes of great engineers. We explain the attributes and examine how the most salient of these impact projects and teams. We discuss implications of this knowledge on research and the hiring and training of engineers. Index Terms—Software engineers, expertise, teamwork In this study, we sought to remedy the lack of specificity, breadth, and rigor in prior work by investigating the following about software engineers: •   What do expert software engineers think are attributes of great software engineers? •   Why are these attributes important for the engineering of software? •   How do these attributes relate to each other? To answer these questions, we performed 59 semi-structured interviews, spanning 13 Microsoft divisions, including several interviews with architect-level engineers with over 25 years of experience. The contribution of this effort is a thorough, specific, and contextual understanding of software engineering expertise, as viewed by expert software engineers. In the rest of this paper, we detail our current understanding of software engineering expertise. We then discuss our interview and analysis methodology, the attributes we discovered, and the implications of this knowledge for software engineering research, practice, and training. I.  INTRODUCTION Software engineering research has considered a vast number of factors that affect project outcomes, from process and tools, to programming languages and requirement elicitation. We rarely give consideration, however, to one of the most fundamental components of software engineering: the engineers themselves. Specifically, what makes a software engineer great? This basic question is at the foundation of nearly every part of our world’s rapidly growing software ecosystem: employers want to hire and retain great engineers, universities want to train great engineers, and young engineers want to become great. And yet our understanding of what characteristics define software engineering expertise still lacks specificity, breadth, and rigor. The research we do have on this subject is directionally sound, but often too indirect or abstract to form a foundational understanding of software-engineering expertise. For example, some research has considered experiences of new hires [1][2], finding that engineers need to contribute value to the team, not become blocked (i.e. have self-efficacy and be persistent), and effectively navigate large organizations. Other research hints at important attributes, but only indirectly. For example, research on teaching novices [3] and programmer productivity [4][5] indicate experts are generally more productive: producing solutions faster, producing more in the same amount of time, and/or having fewer bugs. Software engineering education research is another source of information about software engineering expertise, but it is prescriptive rather than descriptive. For example, several studies suggest what ought to be in the ACM Computing Curricula [6][7][8][9], arguing that engineers need knowledge of technical areas and techniques such as programming fundamentals, verification/validation, and project management. 978-1-4799-1934-5/15 $31.00 © 2015 IEEE DOI 10.1109/ICSE.2015.335 II.  RELATED WORK Much of our knowledge of software engineering expertise come from studying new engineers rather than experienced ones. For example, the closest work to ours is Hewner and Guzdial’s investigation of what employers in a small game company look for in new graduates [2]. The authors interviewed and surveyed over 30 engineers, managers, and artists about qualifications for recent graduates. The authors identified programming skills as well as people skills, like the ‘ability to work with others and check your ego at the door’. In addition to biases for the gaming industry, the authors also suggested differences in expectations between new and senior hires. Begel and Simon’s 2008 ICER paper performed a similar investigation [1], following 8 new hires at Microsoft for 4 weeks and examining their daily tasks. The authors found that novices need to identify ‘tasks that have an impact’, to be ‘persistent’ (avoid lack of self-efficacy), and to collaborate effectively in a ‘large-scale software team setting’. However, it was unclear whether experienced engineers had similar issues. Some works are prescriptive, offering recommendations, but often providing few insights into why topics are (or are not) important. For example, Lethbridge [10] surveyed 168 software professionals about the relevance of computer science education topics from the ACM Computing Curricula [6]. A notable exception is Kelley’s work examining star performers, including software engineers at HP and Bell Labs [11]. The authors prescribed nine working strategies and described how they lead to high productivity—blazing trails, knowing who knows, 700 ICSE 2015, Florence, Italy proactive self-management, getting the big picture, the right kind of followership, teamwork as joint ownership of a project, smallI leadership, street smarts, and show and tell. Other works have considered related occupations such as “Information Technology” [8] and “Information Systems” [12]. Many of the needs, like ‘supporting existing portfolio of applications’ and ‘analyze business problems and IS solutions’ were directed towards selecting software rather than creating it. Some insights into software engineering expertise have come from luminaries. At OOPSLA 2003 [13], Brechner—a director of development training at Microsoft—discussed the need for design analysis, embracing diversity (e.g. other nationalities), multidisciplinary project teaming, large-scale development, and quality code. Dijkstra, in his Turing Award speech [14], argued that good developers create obvious and elegant solutions, constructed with provable correctness. These attributes are likely important, but the luminaries were probably not aiming to exhaustively or rigorously identify key attributes. Popular press and best-practice guides have also considered the topic. In a New York Times’ interview [15], Bock— Google’s vice president of people operations—indicated that a software engineer’s ability to learn on the job was critical, also claiming that human judgment, inspiration, and creativity were more important than technical knowledge. Similarly, McConnell [16] argued that effective developers, in addition to technical skills, had various personality traits like being humble about their intelligence, curiosity, and intellectual honesty. Comparisons of novices and experts also reveal insight into software engineering expertise, showing that experts are more productive, systematic, and well-prepared [3][17][18]. Sackman et al., in one of the first comparisons of developer productivity in 1968 [5], found that completion times of programming and debugging tasks can vary as much as 28:1 between the best and worst engineers. Researchers also suggest qualitative and environmental differences. Robillard et al. [19] found that effective developers were more methodical and better at recognizing relevant information. Ericsson et al. [20]—origin of the meme that 10,000 hours of deliberate practice is needed to achieve expertise—found that attaining expertise required time, materials, teachers, and facilities. Research into various aspects of teamwork suggests other important attributes. Simon’s research into effective organizations [21] argued that setting, communicating, and alignment of goals within teams are important. Gobeli et al. [22] found that effective conflict management (e.g. confronting and give and take) are important for successful projects. Research on collaborations [23][24][25][26][27][28] suggests that expert Experience  Level  \  Product  Type   Experienced  titles:   SDE  II,  Senior  SDE,  Senior  Dev  L ead   Very  Experienced  titles:   Architect,  Technical  Fellow,   Partner  Dev  Manager,  Partner  Dev   Lead,  Principal  Dev  L ead,  Senior   Dev  Manager,  or  Principal  SDE   Totals   software engineers have knowledge of code ownership, the technical domain, and argumentation skills. While related research is extensive, few works directly address software engineering expertise. Those that do, focus on a narrow subset of factors. In our work, we give greater breadth, depth, and rigor to our understanding of software engineering expertise than the current literature offers. III.  METHOD Ideally, an empirical study of software engineering expertise would sample a wide-range of software companies, software products, and company cultures. As an initial effort, we tried to approximate the ideal by interviewing experienced engineers at Microsoft, a large company with a diverse set of software products and engineers. We chose face-to-face semi-structured interviews to identify an exhaustive list of attributes with detailed and contextualized understanding of their meaning and importance. A key decision in our method was determining whose subjective opinions of software engineering expertise could be considered credible. Licensure and accreditation of engineers is still uncommon. The ACMs definition of software engineers as people who produce software for earnest use’ [6] is vague. We therefore used the approach utilized by researchers of human expertise [20], basing our definition of expertise on people having achieved some degree of recognition as software engineering experts. We selected engineers at or above the Software Development Engineer Level 2 (SDEII) title. These engineers were confirmed as experts by other engineers via the hiring or promotion processes. Based on prior work, we aimed to obtain a stratified random sample of engineers across two important dimensions: product type (10 major divisions at Microsoft plus one for all others including Skype, Data Center Ops, and Distribution) and experience level (‘experienced’—titles at or above SDEII—and ‘very experienced’—titles at or above Senior Dev Manager— typically with 15+ years of experience). We used the corporate address book, which the 1st author had access to as a full time Microsoft employee. We randomly sampled engineers in the 22 strata in a round-robin fashion with 3 employees each round, aiming for at least 2 informants in each stratum. Of the 152 engineers we contacted, we interviewed 59 (39\%), see Table 1. The interviews were semi-structured and about 1 hour in duration. We started by describing our study, explaining how we located the interviewee, asking permission to record the interview, informing them that all personally identifiable TABLE 1. STRATIFIED RANDOM SAMPLE OF EXPERIENCED ENGINEERS AT MICROSOFT Ad   Corp   Server  &   Windows   Bing   Dynamics   Office   Phone   Windows   Xbox   Platform   Dev   Tools   Services   Other   Totals   2   2   2   2   2   3   3   6   3   2   2   29   3   3   3   2   3   2   2   5   2   3   2   30   5   5   5   4   5   5   5   11   5   5   4   59   701 ICSE 2015, Florence, Italy Fig. 1. Model of attributes of great software engineers, with attributes we discuss in detailed in bold. information will be removed, and detailing their rights to refuse to answer any question and to have their responses removed later. We began the interview by asking: “I want to start by learning a bit more about you. What software products, at Microsoft and elsewhere, have you worked on?” This helped us to establish rapport and facilitated informants’ reflections; this prior history was later removed during transcriptions to preserve anonymity. We then asked: “Think back to someone youve worked with that you thought was a great software engineer. What were some attributes that made the person great in your mind?” We asked follow-up and clarification questions for attributes that we thought were interesting (e.g. novel, vague, or counter to prior informants). In the second part of the interview, we asked about attributes that either lacked clarity or (we thought) might vary in interpretation. As we learned more about the attributes from interviewees, we updated the set of attributes we inquired about (once every ~10 interviews). For time considerations, we limited our discussions to 5 attributes of interest. We closed the interview by restating the purpose of the research and asking interviewees whether they had anything else to add. To analyze the more than 60 hours of interviews and 388,000 words of transcripts, we used a grounded theory approach [29]. We began with open coding, identifying and assessing all excerpts that discussed attributes of great software engineers. Once we developed our initial attributes, descriptions, and groupings, we made a selective coding pass through our data— consolidating the attribute set. To validate our interpretations, we then solicited the help of a Senior Software Development Engineer (3rd author) to analyze roughly 1/3 of the interviews, developing her own attributes, definitions, and groupings, and then consolidating with the initial set. We made a final pass through all transcripts to produce the final set of attributes. decision-making models based on theory and experience; who grow their capability to produce software that are elegant, creative, and anticipate needs; who evaluate tradeoffs at multiple levels of abstraction, from low-level technical details to bigpicture strategies; and whom teammates trust and enjoy working with. To give readers a sense of how the attributes interconnect, we present a model of the 53 attributes in Fig 1. We organize the attributes into internal attributes of the engineer’s personality and ability to make effective decisions, as well as external attributes of the impact that great engineers have on people and product. Making effective decisions involved recognizing situations as well as knowing alternative courses of action, likely outcomes, and values of outcomes. The external attributes focused on great engineers applying their emotional intelligence and decision-making models to their software, their teammates, and the potentially millions of users and stakeholders they serve via their software engineering efforts. Many of the attributes are applicable to many professions, and some, to simply being a good person. Our objective was to identify, among all possible attributes, the set that expert software engineers viewed as important for the engineering of software. More importantly, we aimed to provide a contextualized understanding of why these attributes are important in real-world practice. In the rest of this section, we provide a description of each attribute and quotes from informants (including their title and division when this information would not reveal their identity) that capture the sentiment in interviews. Due to space limitations, we focus detailed descriptions on attributes that we felt—based on prior work—were particularly interesting. A.  Personal Characteristics Informants mentioned 18 attributes of engineers’ personalities (see Table 2). With attributes like passionate and curious, these concerned who great engineers were as people. For many attributes, informants felt that the attributes were intrinsic to the engineer—formed through their upbringing— and were difficult (if not impossible) to change. IV.  FINDINGS Our analysis identified a diverse set of 53 attributes of great software engineers. At a high level, our informants described great engineers as people who are passionate about th ... Purchase answer to see full attachment