Reading 06

I do not believe that companies should be forced, or even consent, to put backdoors into their products, for a number of reasons. The greatest among these is the folly of attempting to create a secure system with a backdoor. It is, by definition, impossible to have a completely secure system that also contains a backdoor. This is because the backdoor can theoretically be accessed by anyone that knows the code or sequence that triggers this. This would usually be the one the backdoor was designed for, say a government entity. But there is also nothing stopping nefarious powers, such as enemies of the state and oppressive regimes, from finding and using the same backdoor for their own ends. This also extends to government-approved or enabled encryption standards, which allow an entity to snoop on the plaintext. It is impossible to create a truly secure code that can be easily decoded by a third party, regardless of intentions. Therefore, the weakening of security, while perhaps useful in specific cases such as this, is ultimately a gained vulnerability in our technology that can be exploited by any third party with sufficient knowledge and resources.

 

The second concern that I hold is that this requirement is far beyond the reasonable reach of the government. For one, it is forcing a public entity to put its own time and resources into creating this back door, for which they will not receive any help or remuneration from the government. This sets a dangerous precedent of putting the burden on public companies to assist when the government requests it. While Apple can of course probably deal with this expense without any repercussions, other smaller companies may not be as financially blessed. I also worry about the precedent that this would have for future cases of private information access. Not only has it been shown that such software can be created, but it would be a simple matter to point a judge in the direction of this case, and thus force Apple to use the backdoor software again and again, despite the FBI’s claims that this will be a one time occurrence.

 

Ultimately, I believe that Apple has a responsibility to protect its users, not to track them and prevent them form misuses of the products they create. I do not believe that the company should put its customers at risk of various crimes such as spying and identity theft simply to prevent another crime. This strikes me as a lateral transaction. To those claiming that people should not be worried because they “have nothing to hide,” I would ask them to review history. No one has anything to hide until the time is right. The United States was founded by men who had plenty to hide from the British government, even though they did not have much to hide prior to that. It is for this reason that they included such protections in the constitution, to help protect citizens in future events. The relinquishing of liberty for an increased sense of security is a scary proposition to weigh.

Project 02

Podcast

 

In my experience, the most important parts of the guide all relate to preparedness. It is absolutely essential that you practice interview questions before hand. When I say practice, I don’t mean simply read the books, but actually do mock interviews on a white board. Learn to talk out loud, and work with your peers to get real experience. This will not only make you more comfortable with the questions that will be asked, but also generally better at communicating your responses and working together with the interviewer. As we tried to make clear in the podcast, an interview is a two-way conversation, it is not simply the interviewer sitting in silence while you write mystic code on a whiteboard.

 

The second piece of the guide that I want to emphasize is the side projects. The kind of work that engineers do in industry is remarkably different from the pure, somewhat sterile problems that are often addressed in academic classes. Having experience working on your own projects will help prepare you for what industry coding will be like, although probably with less structure. Secondly, it gives you great talking points in interviews. Interviewers love to see passion and interest, and having a side project that you are excited to talk about is a great way to cover both of those bases. I feel that it is a lot easier to talk about personal projects than school projects, which usually have a pre-defined goal and requirements. With a side project, you can choose the area that you are interested in working in, and all of the goals of the project, yourself.

 

This leads into the topic of school goals and curriculum fairly well. I appreciate that the goal of a university is not necessarily to help you find a good job, but rather to educate the students as best they can, and to really stretch minds. I don’t think this should change, the benefits of a broad education are well described. However, the teachings and curriculum should at least keep in mind that most of the students will be heading into the industry once their studies are completed. Therefore, while it shouldn’t be the key of the classes, they should keep pace with the expectations that industry has of students. Unfortunately, I do not think the Notre Dame CSE curriculum does this. They way it is currently laid out, students often do not learn the skills they are expected to know for internships and interviews until after the time has passed. I know that I personally have had to teach myself most of data structures and algorithms so that I would be prepared for interviews at major tech companies and be competitive with applicants from other universities.

 

I know that the curriculum is improving, and I am very excited for this. The combination of Fund Comp II and data structures into one class seems to me both logical and easy, and is something I have been pushing for since I took those classes. This will make students much more competitive when applying for internships during the first semester of their junior year, as many technical interviews center on data structures such as binary trees and hash maps. I still think the curriculum could be improved more however. I would like to see the opportunit for students to begin taking coding classes, such as the Script Based Programming class offered to non-CS majors, during their freshman year. This both allows students more of a chance to get a feel for computer science, and allows those who already know they want to major in it to build their skills as early as possible. Overall however, I am very happy with the changes that are beginning to take shape.

Reading 05

The Therac-25 accidents are some of the worst software mistakes we know of. I really feel for the engineer who wrote this software (it has been stated as being only one engineer), as he was working on such a complex system that I think many if not most software engineers would have made similar mistakes. While the physical cause of the accidents was the removal of physical fail safes from the Therac-20 to the Therac-25, in theory the replacement of physical fuses with a software fail safe should be an equal system. Therefore, I agree with Nancy Levenson’s analysis that “To attribute a single cause to an accident is usually a serious mistake” (http://courses.cs.vt.edu/professionalism/Therac_25/Therac_1.html). Ultimately, I see two key issues that led to the engineering errors so essential to the Therac-25’s demise: a poor user experience and poor engineering practices.

 

I will first grant that the Therac was created in a time when interface design was not nearly as good as it is now. However, there were two key issues that let this problem fester. The first is that the error code “Malfunction 54” which was presented every time the problem happened, was undocumented. This in turn meant that operators had no way of discovering what had gone wrong, if anything. If there is no way for the operator to investigate, then they will quickly lose interest and brush it off as unimportant, when in reality this error was an important indicator of what had happened to their patients. The second is that no wait screen or interrupt existed to prevent the operator from doing important tasks while the machine was moving its equipment into position. This is of course what the actual error was.

 

At a more scientific, engineering level, the proper protocols were never followed during the testing and verification of this system. Software tests were not implemented, Fault trees never designed or tested. These oversights skipped important steps that likely could have caught the issues that plagued the Therac-25 (integer overflows? Should be easy to check). This is an issue that needs to be a addressed at a company / cultural level. If management does not encourage employees to follow good practices and leave time for them in planning, it will be very difficult to prevent bugs in the product, regardless of the complexity of the end product.

 

Ultimately, it strikes me as interesting that both of the errors that led to accidents (the interrupt during setup and the integer overflow) could have been prevented from causing harm to patients by a simple physical inspection of the machine prior to usage. As the extreme radiation was a result of pieces not being correctly in place, this strikes me as something that would be very easily to visually confirm and thus prevent deaths. While the software obviously needed to be fixed so as to ensure correct operation, a 30 second check seems worth a human life.

 

As a future software developer, I want to strive to make sure that I follow the correct engineering practices. I have learned in my internships the importance of testing, and studying this problem simply re-iterates that concept. Well-designed and documented systems will create safety and efficiency for both me and those that follow me and work on the systems I do. Large projects need to be approached with future maintainability and testing in mind from the beginning. And, if God forbid the worst should happen, it is important that blame not be placed on an individual. Software is a team effort, through better or worse.

Reading 04

I think that Codes of Conduct have their purpose, which is different for each kind of group listed in the question: companies, organizations, and communities. Obviously, companies need to provide some form of a code of conduct; their human resources department probably requires it. In a company, this is very useful. A code of conduct can help ensure a comfortable working environment, and thus keep employee productivity high. In a smaller community, such as an open source project, I believe the value of the Code of Conduct diminishes significantly. At a company, workers are spending a large amount of their time together. More importantly, they must share resources such as bathrooms and fridges. In an open source community, where all communication happens online, this is not an issue. Therefore, the scope of the code of conduct is diminished significantly. It is now attempting to regulate simple textual communications. This reminds me of the statistic that words only compromise 10% of human communication, with the other 90% being boy language and tone. Similarly, the vast majority of the usefulness of a code of conduct lies in its discussion of physical interactions and workplace etiquette, as opposed to textual conversation. I am of the opinion that most communities do not need an explicit code of conduct as such, but can rather rely on their community leaders or moderators to ensure a productive and valuable environment.

 

That is not to say that a simple code of conduct is invaluable to these groups. However, looking at some of the resources provided, these codes try to cover a much larger amount of topics than I think are necessary. The Apache and Linux kernel codes of conduct are good examples of simple, to the point discussions on community behavior. These are in stark contrast to the Geek Feminism code of conduct called out in the article “An anonymous response to dangerous FOSS Codes of Conduct” which attempts to explicitly list as many possible forms of inappropriate behavior as possible (ex: “simulated physical contact”). This is a losing battle, and it is better to rely on the community to create an air of collaboration than to bring up as many points as possible and threaten retribution. This instead creates an air of fear in the community as members attempt to ensure they are not breaking any rules. Furthermore, relying on moderators and the community at large as opposed to a document is a much more versatile approach, as it allows new standards and expectations to be ingrained in the identity of the group as quickly as the people can agree, as opposed to the alternatives of either altering the code on a consistent basis (probably with some form of voting or other oversight) or simply not paying attention to change at all. That is why I believe that it is best for online communities to have a short, general code of conduct as opposed to a list of laws. To liken it to government, I prefer the judiciary to the penal system.

Reading 04

I think that Codes of Conduct have their purpose, which is different for each kind of group listed in the question: companies, organizations, and communities. Obviously, companies need to provide some form of a code of conduct; their human resources department probably requires it. In a company, this is very useful. A code of conduct can help ensure a comfortable working environment, and thus keep employee productivity high. In a smaller community, such as an open source project, I believe the value of the Code of Conduct diminishes significantly. At a company, workers are spending a large amount of their time together. More importantly, they must share resources such as bathrooms and fridges. In an open source community, where all communication happens online, this is not an issue. Therefore, the scope of the code of conduct is diminished significantly. It is now attempting to regulate simple textual communications. This reminds me of the statistic that words only compromise 10% of human communication, with the other 90% being boy language and tone. Similarly, the vast majority of the usefulness of a code of conduct lies in its discussion of physical interactions and workplace etiquette, as opposed to textual conversation. I am of the opinion that most communities do not need an explicit code of conduct as such, but can rather rely on their community leaders or moderators to ensure a productive and valuable environment.

 

That is not to say that a simple code of conduct is invaluable to these groups. However, looking at some of the resources provided, these codes try to cover a much larger amount of topics than I think are necessary. The Apache and Linux kernel codes of conduct are good examples of simple, to the point discussions on community behavior. These are in stark contrast to the Geek Feminism code of conduct called out in the article “An anonymous response to dangerous FOSS Codes of Conduct” which attempts to explicitly list as many possible forms of inappropriate behavior as possible (ex: “simulated physical contact”). This is a losing battle, and it is better to rely on the community to create an air of collaboration than to bring up as many points as possible and threaten retribution. This instead creates an air of fear in the community as members attempt to ensure they are not breaking any rules. Furthermore, relying on moderators and the community at large as opposed to a document is a much more versatile approach, as it allows new standards and expectations to be ingrained in the identity of the group as quickly as the people can agree, as opposed to the alternatives of either altering the code on a consistent basis (probably with some form of voting or other oversight) or simply not paying attention to change at all. That is why I believe that it is best for online communities to have a short, general code of conduct as opposed to a list of laws. To liken it to government, I prefer the judiciary to the penal system.

Reading 03

Work life balance is an issue that has been on my mind a lot recently. As I begin my career after graduation, I am trying to be very conscious that I do not get so caught up in my work as to make it my life, like so many new tech workers seem to have a tendency to do. At a high level, I see no reason why employees, both men and women, can’t “have it all” so to speak. What it really comes down to is both the company and the employee settings reasonable expectations from a professional perspective. That was what stood out to me the most about Anne-Marie Slaughter’s story: the insane requirements of her job in Washington. She was expected to live states away from her family, work extremely long hours, and only go home on the weekends.

 

It seems to me very reasonable to be able to manage a 40 hour work week and a family. The problem arises in the US work place when “ambition” and “dedication” are equated with spending 60, 70, or 80 hours a week at work. As Vicky Shabo said, “We’ve seen that upper income, well-educated workers don’t take leave because they think they will be viewed negatively, won’t be taken as seriously, their commitment will be questioned, and they will lose out on opportunities for advancement.” This is where the real issue arises with “having it all”. Being ambitious is perceived here as making your work your life, and yet now people are surprised when they can’t also live a family life at the same time. This requires change on two fronts: public perception and company culture.

 

First, the public needs to accept that people can be dedicated to their job and yet still exist outside of it. Its so interesting that at work people are often expected to multitask, and yet when those same employees do it in life, people call them uncommitted. People need to be able to recognize that those who truly have their lives together are the ones who have established a balance. Secondly, companies need to recognize that balance is good. I am a firm believer that overexerting at work leads to decreasing returns. In my experience, its necessary to take breaks and clear your head, or else you will get stuck on problems. I would also be remiss to not mention the effect that burnout has on employee performance, and this concept seems particularly relevant to software engineering as so many people have issues with it. Companies should actively encourage a balanced lifestyle instead of subtly encouraging employees to work constantly. I don’t mean they should force workers to work shorter hours, as this is obviously less practical. Rather, they should make a life outside of work part of company culture. Have outings and family events at work, offer good vacation and maybe travel stipends to encourage workers to be active outside the office. This will lead to happier, more productive workers. This combined with a US culture shift can open the opportunity for workers, both male and female, to truly “have it all” and balance a strong career and a good family life.