Imposter

Before I begin, I would like to ask that you do not mention my name in association with this blogpost.  While I am fine with quotes from this post being read aloud in class, I request that you do not identify me as their author.
-----------------------------------------------------------------------------------------------
I am an imposter.

I am a fake, not a real programmer but a Computer Science major who masquerades as a “junior coder.” I am a person that Sam Phippen would refuse to hire, for I am just one of the “every final year CS student he currently knows” instead of a coding bootcamp graduate. I am wearing the mask of a true CS major, for I have squandered this absolutely amazing education by sliding through my Computer Science classes by the skin of my teeth. Even though I have passed all of my classes, I have learned so little about programming that, if asked, I could not program a linked list in any coding language. Sure, I could easily tell the basic theory concerning a linked list, but creating one, especially in a short time frame?  That would be impossible.

I really am just an imposter.

Because of this attitude, I have had nothing but terrifying and embarrassing experiences with the technical interview process. Too nervous and too busy trying to juggle schoolwork, activities, and applications to study, I have gone into interviews so nervous that I could not even code a simple function. All I felt afterward was embarrassment and shame, for I could discuss the time complexity of a function but struggled to write a simple class in C++.  Since that failure, I tried skimming through Cracking the Coding Interview and going to workshops about technical interviews, but this preparation did not bestow any confidence or optimism about obtaining another internship or a job. The prospect of continuing this search does not excite me whatsoever; I am terrified and disheartened because I know that immediate rejection is right around the corner.

Imposter.

 Jeff Atwood reaffirms my fears about the hiring process, saying that “it is better to reject a good applicant every single time than accidentally accept one single mediocre applicant.”  I am one of those mediocre applicants, destined to be rejected simply because of my nervousness and my inability to work quickly and accurately. Due to these fears and the troubles I have in technical interviews, I wish that tech companies would approach their hiring process in a more uniform manner.

While I would like to entirely rid the interview process of its technical components, I do understand its importance, as highlighted within the reading for this week and the quote in the previous paragraph. One aspect of this hiring process that I dislike, however, is the inconsistency of question difficulty across companies’ tech interviews. For example, one company my hire you, as Dan Kegel says, “if you can successfully write a loop that goes from 1 to 10 in every language on your resume, can do simple arithmetic without a calculator, and can use recursion to solve a real problem.” In other interviews for a similar position, however, you may be asked to write an algorithm on a whiteboard in 15 minutes or recall ideas and concepts from every single one of your past Computer Science classes. Also, it is a little concerning that other engineering disciplines are not quizzed in the same manner that Computer Scientists are, for I know Mechanical Engineers, for example, who have gone through countless interviews without once being questioned about their engineering knowledge.  While I realize that every field of practice, position, and company require different skills and that we should be able to adapt to these differences, the disparity between question complexities is tiring for interviewees.

Based on what was said in the articles, I believe that companies should adopt the job shadowing format for their hiring process. Interviewees would spend a day partner-programming with a senior in the company, and by the end of the day, the senior programmer would access the interviewee and decide whether or not to hire the junior coder.  In my opinion, this format would probably be very successful, as all other forms of interview do not accurately capture how a young graduate would operate as a member of the workforce. Quincy Larson agrees with me on this point, saying that “virtually every developer I’ve talked with agrees that one’s ability to write algorithms from memory on a whiteboard has almost nothing to do with real day-to-day developer work.”

Whiteboard questions force programmers into unnecessary perfection.  We are messy creators, where about 70 percent of our time is spent fixing and tweaking the little mistakes we make during the construction of our art.  Therefore, I believe, as Sam Phippen says, that whiteboard questioning and other forms of rapid but technical testing are “really not fair. Immediately you’re randomly filtering for people who are good at a kind of thinking which most programmers don’t encounter every day. Worse than that, you’re going to knock a lot of people’s confidence.”

This is true in my case; these interviews, as I have explained before, completely destroyed my confidence concerning technical interviews and obtaining a software position at a company.  In all honesty, I probably could be successful in such interviews if they were not daunting, complicated, and nerve-wreaking for a simple Computer Science graduate, but because of these factors, there is only the smallest of chances that I will obtain a job in Computer Science upon graduation.

Therefore, I truly am a Computer Science imposter.

Hacker. Writer. Painter. Computer Scientist.

If you asked me, before this class, if I was a hacker, I probably would have laughed at you and would have inwardly scoffed at such a question. Many in the general populace believe that all computer scientists are hackers, secretive geniuses working at odd hours to steal information from businesses and governments.  At least, was my general opinion of hackers before I began studying Computer Science and a stereotype that I may have harbored for a while even as I started my career at Notre Dame. No, I would tell you, I am definitely not one of those criminals, as The Mentor insists all hackers are.

 I create code for “morally sound” causes, not for breaking into secure information, and I will continue to hold myself to such a standard when I leave Notre Dame. I’m not interested in tweaking or exploiting software for the sake of curiosity, discovery, or fame; I want to design my own beautiful code that, through its execution, tells a story. I am not a hacker, not a destroyer, but an artist who writes and paints in code, simply utilizing this tool as an end of achieving my means of sharing my stories with the world.

I am not a hacker.

According to the readings for this week, however, I just might be one.

In the essay Hackers and Painters, the author write that hackers “are trying to write interesting software, and for whom computers are just a medium of expression, as concrete is for architects or paint for painters.” This quote in particular struck me, as I have always considered myself, contradictory to most, a coder who simply uses this medium of communication to tell stories through art and gameplay. Therefore, this article partly convinced me that I was a hacker, an unconventional creator, but I still was not sold on this definition of a hacker. The definition of hacking, presented in The Word “Hacker” seemed to fit my original thoughts concerning this act; “it's called a hack when you do something in an ugly way. But when you do something so clever that you somehow beat the system, that's also called a hack.”

Based on these two modes of thought, I now believe that hackers are explorers, fueled by curiosity and potentially an adversity towards authority, who break the limits of code and share their discoveries with the rest of the world. The way they approach their explorations into code differ based on hacker; some may cheat the system with ugly code that works more on lucky coincidence than purposeful skill, but others may be able to produce aesthetically beautiful code that to them, is a form of art.

Based on this definition, there are a few fundamental ideas which encompass the hacker archetype. One such idea would be that of complete control over their medium; as stated in The Word “Hacker,” “"hacker" connotes mastery in the most literal sense: someone who can make a computer do what he wants—whether the computer wants to or not.”  I believe that hackers must exhibit a rare form of brazen confidence, for this belief would encourage them to explore the depths and reaches of a computer’s ability as well as other coders’ work.  Hackers also must be unruly, willingly able and enthused to dabble areas that they should not go and be excited to break into forbidden and secure systems. In tandem to their unruliness, hackers also must “carry an ethic of disdain towards systems that normally allow little agency on the part of ordinary individuals” (Scott, The Hacker Hacked).

Possessing a certain skill, creativeness, and grace is also essential for hackers’ arsenals, as their job demands that they create beautiful and subtle tweaks to code or scripts that cannot be easy detected by other users. To conclude this hacker archetype, these code artists must show passion and care for both their victims and those they hope to aid.  With this understanding of users, hackers can slip more easily into the cracks of code because they empathize with its creators and users.  As Hackers and Painters states: “empathy is probably the single most important difference between a good hacker and a great one.”

Overall, the idea of having a creative, painter-like hacker continues to strike me as odd; I always thought of hacking an ugly and destructive and not a work of art.  Also, despite being a harmful, illegal act, hackers were mostly portrayed in a positive light throughout the given articles. These code manipulators were almost praised for their efforts despite criminal nature of their works, which, for the most part, surprised me. Other than that, however, the definitions of hacker presented through these articles seemed fairly standard for someone coming from a computer science background; if they were written by someone outside the major, my reaction to their ideas would have probably been a mix of confusion and amusement.

I believe that Brent Scott in The Hacker Hacked presents one of these stereotypical, positive definitions of hackers; he says that “the emergent tech industry’s definition of ‘hacking’ as quirky-but-edgy innovation by optimistic entrepreneurs with a love of getting things done.” This description, in a way, fits me perfectly, as I love to work on “quirky” projects that allow me to shape code to fit my personal ideas. Alongside this definition, I also fall into many of the descriptions given in A Portrait of Random J. Hacker: wearing no makeup and work-out clothes even though I hate sports, reading in my spare time, and eating mounds of Chinese and Mexican food.  Therefore, based on my choice of degree, my creative outlook concerning code, and my personal preferences, you may truly say that I am a hacker.  Based on my personal definition of a hacker, however, I lack the disdain of authority, the rebelliousness and unruliness, and the sense of pure curiosity that all hackers must exhibit.

So, if you were to ask me again if I am hacker, I might look at you thoughtfully for a few seconds before saying one word.  No.

A Cautionary Tale of Talents

Before I begin, I must say that it was a bit surreal and nostalgic to unearth this old blog from my first semester here at Notre Dame.  I initially decided to use this blog out of pure convenience (and beginning of the semester laziness), but looking back on my old posts, I am glad that this blog will serve one final purpose as I conclude my time at Our Lady’s University.

All nostalgia aside, my name is Lauren Kuta, and I am currently a senior Computer Science and English major. Upon graduation, my dream careers include becoming a novelist or a digital animator, producing elements and works for either movies or video games.  After taking this class, I hope to gain a better understanding of the ethical and moral responsibilities that Computer Scientists have when constructing programs, and with this knowledge, I hope to be able to make the right decisions when faced with a moral dilemma in the workplace.

Based on the interactions that I have witnessed online, I believe that one of the most pressing issues that Computer Scientists face could concern copyright and fair use laws surrounding both code and other resources.  Copyright laws can be confusing and ambiguous, and ignorant coders can easily fall victim to plagiarism if they do not carefully analyze these regulations.  Looking at the topics listed on the schedule for this course, though, I am interested in discussing outsourcing and Visas in the context of Computer Science, for I did not initially consider the impact that these elements would have on my chosen field.

The Parable of Talents, despite its age, addresses this impact that humans and other elements constantly have upon fields of study and society’s development.  As human beings, it is our duty to cultivate and share our talents with the world, instead of burying them out of fear or supposed, false necessity. If people use what they have learned to benefit society, then, their gifts will not only aid those directly involved but will also reward the giver as well.

Personally, this story relates to me because in being exposed to Computer Science at a volatile age, I was given the opportunity to learn and appreciate a skill that others will never begin to understand. I was lucky; my parents could afford to send me to a special summer camp that, without it, I would have never dreamed that I could understand Computer Science.  Because of this opportunity and my relative success in the pursuit of my talents, I now have an innate duty to use Computer Science for the benefit of society, just as it is my duty to pursue my other talents with the goal of bettering the human race.

However, to quote Uncle Ben from Spiderman, “with great power comes great responsibility.”  As a Computer Scientist, I cannot haphazardly toss my work out into the world; before exposing society to my work, I first must ensure that my work can be called “a talent,” a helpful product that would not cause harm to anyone in any foreseeable circumstance. Bill Sourour discusses this issue of understanding in his article “The Code I’m still Ashamed of”; blindly programming a “harmless” quiz concerning prescriptions for young girls, Sourour indirectly caused the death of a teenager because of the ethical flaws in his code. Society as a whole is also not educated on the harm that coding can inflict, as Benedida mentions in his blogpost “The Responsibility We have as Software Engineers.”  He states that “most people have a pretty good idea of the trust they’re placing in their doctor, while they have almost no idea that every time they install an app, enter some personal data, or share a private thought in a private electronic conversation, they’re trusting a set of software engineers who have very little in the form of ethical guidelines.” Because of society’s inherent ignorance toward software, my duty as a Computer Scientist also encompasses the moral implications that code carries; if I ignored such ethics, my talents would quickly become lost and wasted.

Upon worrying about the potential ethical consequences of publishing code, however, people may become too afraid, too concerned about hurting others, to openly give of their talents.  They are then similar to the man who buried his talents in the soil out of fear, leaving his gift to rot and receiving nothing upon his master’s return. Therefore, Computer Scientists must overcome their fears of imperfection and use their talents tactfully and thoughtfully, understanding the weight of even the smallest line of code.  With proper caution, Computer Scientists, including myself, can utilize our talents and passions to create code that only aids the technological advancement of our society.