Monthly Archives: January 2016

How much does the manifesto reflect my thoughts? A fair amount. How much do I identify with the portrait of C.S. Irish? Somewhat. In writing the two documents, Tim, Heather, and I tried to pick out the most recognizable stereotypes for Notre Dame Computer Science students. As with most stereotypes, they’re mostly true, but not all of them apply to every member, including me.

Is that a bad thing? Maybe it depends on the stereotype. If it’s a mean stereotype, it can make people feel bad. But if it’s a nice stereotype, why should the stereotyped individual have a problem with it? One might argue that there’s no such thing as a nice stereotype, that stereotypes have a negative connotation. But we can certainly make positive sweeping statements about a group – call it a generalization.

The danger with generalizations is that they lead to false assumptions about the minorities in the group. Whether it’s good or bad, the minorities are being misrepresented.

So is there any harm in someone thinking you’re really nice just because you go to Notre Dame? Or someone thinking you’re good at basketball because you’re really tall? It could lead to a misunderstanding, but it’s like being given a 95 on an exam when you really only earned an 85 – it doesn’t hurt, and you could pretty easily correct it if you wanted to. Or you can let it stand.

It does not seem like there’s anything wrong with stereotyping unless the stereotype is malicious (all malicious things are bad anyway), but is there anything good to make them worthwhile?

Is it helpful to be able to deductively reason that a particular Notre Dame graduate will be a good employee because Notre Dame graduates generally are? Seems helpful. Stereotypes can help simplify the complex ideas, traditions, and culture of a group to a level that is understandable by an outsider.

So if the CEO of a company knows she wants good employees who are good people, she knows she can hire people from Notre Dame, despite not necessarily knowing why they’re good people. The CEO doesn’t need to understand the myriad factors that influence a Notre Dame student’s life and makes him or her such a wonderful person, so her job is easier.

What distinguishes a good stereotype from a bad one? You could argue that stereotypes that paint a group of people in a bad light are bad. It’s probably worth avoiding them, but they do help accomplish the job of simplification. The real nasty stereotypes are the ones that aren’t true. They may have once been true, but something changed and now an entire group is being misrepresented to the rest of the world.

The presence of a manifesto can be helpful or hurtful – it depends if the entire group is on board with it, or if just one member created it. One person could write up a manifesto and proclaim that it describes the essence of the group, but if the author is part of the group’s minority, you get the problem of misrepresentation again.

If a group mostly agrees on a manifesto, on the other hand, it can be a unifying force – a source of culture. I couldn’t really tell you where the one Heather, Tim, and I wrote falls since we’re just 3.

Standard

interview for culture

A great cultural fit is vitally important for a new hire. I believe a great cultural fit who is an average-level developer will far outperform a great developer who is only an okay cultural fit at a company.

Why – My Experience

First of all, it is important that a company has a culture. I’m not too hung up on what every company chooses, but like Alexander Hamilton, I believe everyone should stand for something. Not only does it provide a basis for important decisions, it helps to attract like-minded people. There is danger in some types of homogeneity (stagnation, close-mindedness, backwards progress), but not when it comes to core beliefs – in fact, a group is cohesive and productive when its members share similar belief systems, this is how tribes are formed.

Sam Phippen uses the word tribe in a negative light. He claims it is human nature to form tribes, but that tribes beget ineffective hiring practices – that CS people just hire more CS people, and CS people aren’t always the right people for the job.

If hirers are simply looking for people with the same training that they have, that would be problematic. But if the main goal of an interview is to discern the cultural fit, technical background will never be the only factor in a decision, so you don’t have to worry about a company becoming a homogenous group of algorithm prophets. Because surely a Notre Dame Computer Science graduate could hold the same core values as a Ruby bootcamp graduate – say, they both believe that interaction with the customer is essential to a well-run business. Then you start to develop a tribe.

What It Means For The Interview

The technical skills of the interviewee are going to be tough to assess – the readings made that exceedingly clear. But why worry about it when you have the most “successful” hirers like Google publishing their methodology. So give them four interviews, a pair programming assignment, an inter-departmental interviewer, and a fun lunch break – trust that you can get a sense for their technical prowess.

Focus on figuring out who the candidate is. Unfortunately, you are probably going to have a more subjective rubric for this section. Fortunately, the questions you want to ask are easier to ask and easier to answer.

Q: Do you like working in teams?

A: Yeah, I played Ultimate Frisbee in college, so building something as a team comes naturally to me.

Q: Why do you like programming?

A: I view it as a form of expression. And I believe I can create a positive impact for others.

Q: What do you do in your free time?

A: I’m really passionate about the outdoors and relationships, so I like to go on adventures with my friends.

These questions do not have right answers, but they give the interviewer a sense for what the interviewee is like. What’s important to them, what motivates them? The interviewee ought to feel comfortable answering these questions, and in many cases, it should become clear pretty quickly if the candidate would be a good cultural fit.

What It Means For the Career and Company

If every new hire’s core values ring true with the company’s, you have a tribe. Lone wolves survive, tribes thrive. Twenty-five people working toward a common goal will accomplish a lot more than just one person working toward a goal.

When a group of people is motivated by more than just a bi-monthly paycheck, you get buy-in. Much like I’d take a great cultural fit/medium developer over a great developer/okay cultural fit, I’d take 25 people who drew inspiration from a set of core beliefs over 125 people who signed up to have a job.

I interacted with a half-dozen recruiters while searching for a job. Some were satisfactory, some were peppy, some were exceptionally competent at their jobs, but only one was excited to talk to me every time I sent her an email or called her, and that’s where I will be working next year. Did I choose that company because of the recruiter? Partially, some indeterminate amount. Not because she was an awesome person, but because only someone who really buys into her company would be so passionate about her job. And everyone I’ve met there is the same way.

They conducted a two-way behavioral interview – they wanted to get to know me, and they wanted me to get to know them. That, in itself, was important, but I also felt like I fit in with them, and that’s a pretty great feeling to have going into my first job.

Standard

what is a hacker?

The nature of a hacker has changed dramatically over the course of computing’s relatively short history. This is inevitable – as the circumstances change, so do the inhabitants, and the circumstances have evolved greatly, from advancing technology to software’s growing prevalence in the world today. But the central ethos has remained consistent.

The readings mention phone phreaks as some of the original hackers: benignly exploring the features and intricacies of a system, at times exposing flaws and loopholes. That is the original hacker ethos, and from it, many related but distinct ethea branched, some similarly benign, but others malicious.

The hacker culture does not lend itself to self-promotion. Hackers, in accordance with the personality outlined in “A Portrait of J. Random Hacker,” do not seek validation from the mainstream (though they do often seek it from each other). This is evidenced by groups like WikiLeaks and Anonymous, who pride themselves on anonymity. While these groups, hacktivists perhaps, are not the phone phreaks, they do possess the same selfless quality.

The result is that many people today understand hacker culture only (or at least initially) as portrayed by the media. TV shows and movies that celebrate a rebellious, quirky youth with seemingly supernatural power at a terminal paint the hacker to be a hero. While there are still some who discover the “traditional hacker lifestyle” on their own, there is a growing number of interested people who are drawn to the idea of computational superpowers.

That crowd may not be as counter-cultured or low-key as the traditional hackers – they may be more focused on earning money or saving the world – but does that preclude them from boasting the hacker title?  Brett Scott seems to think so, dismissing this crowd as yuppies. Scott says they’re ruining the hacker culture with gentrification.

The average hacker profile is undoubtedly changing, the compass is shifting, but that isn’t a bad thing. As I said earlier, the circumstances are changing, so change in the people is natural. Paul Graham’s notion of a hacker is modern and accepting. He compares hackers to makers like artists and writers.

Hearkening back to my previous post, the hacker Graham describes is the software developer I described. Not the computer scientist and not the software engineer, but the curious, artistic individual who seeks to use knowledge of coding to create something. That is a step away from the phone phreaks, but I believe the ethos is the same: experiment with the capabilities and limits of a system, do something cool. So while the first hackers toyed with phone lines, today’s hackers cobble together intuitive, interactive mobile applications and code libraries. The material has changed but the central ethos has remained.

Paul Graham’s comparison to painters is romantic and appealing to someone like me, who is frightened by the inhuman component of programming but attracted nonetheless to its potential for expression.

Beauty. Empathy.

Two words with which I strongly identify.

To me, creating something beautiful has inherent value – it need not contribute any further to be deemed useful to society. That is, no doubt, an artistic belief that might make certain computing aficionados scoff, but to them I would suggest reading Graham’s comparison of hacking and painting. It is compelling in so many ways.

Creating a cool application does not start with a master plan drawn out in points and plots. It is an iterative process that starts with a rough sketch and proceeds, often unmethodically, through a variety of stages, never really reaching completion. That sounds an awful lot like the development of a painting or a story.

For software that is aimed at anything other than pure self-expression, which is likely the majority, empathy is the most important quality a developer can possess. If you intend for other people to use your software, there is nothing more relevant than how those people want to use it.

The developers behind TurboTax did a fantastic job empathizing with tax payers. Many developers, when asked to develop a tax-paying application on the internet, would look up the government tax forms and create electronic form versions for users to fill out. While that may save an ounce of trouble, it is as unpleasant for users as filling out the forms with a pen.

TurboTax, on the other hand, has a beautiful interface that asks the user simple questions – the type of question one feels accomplished after answering, like your name or birthday or marital status. “Ha, this is like a quiz I know all of the answers to” is a great sentiment to have while filling out taxes. The developers clearly spent some time thinking about what users would like and used that as the driving principle for their software.

I love developing with the principles of beauty and empathy floating around in the back of my head. So I am a Paul Graham hacker. I am not the portrait of J. Random Hacker – I am like him in some ways, but J. Random Hacker is just one hacker. There are many of us, and we’re all alike.

Standard

computer science: art, engineering, science?

Computer Science is a science. Interested parties methodically explore novel concepts in an effort to further the frontier of accepted practice.

Software development is an art. Developers use tools to create something that can be enjoyed by others, whether for function or for purely aesthetic reasons.

Software engineering is a third field dealing with software that requires a certain level of rigor, robustness, and reliability.

So when you sit down at your computer to type out some code, you could be doing any of the three, perhaps simultaneously. To me, there are clear distinctions between the three that I will elaborate upon and that are often blurred or misrepresented by others.

Computer Science lives primarily in the halls of universities. Student of computer science begin by learning the basics of programming – pointers, basic structures, memory allocation. They build up to knowledge of data structures, operating systems, algorithms, and more, but ideally, they fundamentally understand how their program will run, all the way down to the transistor – the (current) basic building block of a computer.

This breadth of understanding enables them to pick a spot and dive deep – to investigate a novel concept. This could be developing a new algorithm for a known problem or using known algorithms for new applications. There are metrics (e.g. temporal and spatial complexity) to evaluate findings like in other fields of science, and peer review is an important aspect of successful research.

Creating an app on your mobile device to count how many hops you make on a pogo stick is not science – it is software development, an artistic expression. Millions of lines of code are probably written everyday* by people seeking to create a new app, a new website, or a new way to animate a cartoon character.

Developers may roughly follow a scientific method, hypothesizing about what might work, testing out a couple of different solutions, and then implementing one, but there is a notion of software development lingering in the back of every software developer’s mind: everything can be rewritten. If your new app crashes, find the bug, fix it, and release an update. If your website does not lay out properly, adjust your formatting and hit save – next time someone loads the page, it will be different. As Ian Bogost notes in his piece in The Atlantic, software developers are often treated to the ease of rapid repair.

This is a major distinction from engineering. An engineer of a bridge cannot try out one support scheme and easily replace it if the bridge cracks – safety and a lot of money are at stake. An engineer designing the brakes of a car cannot go with “the best he’s got,” he is responsible for meeting a certain standard set by someone who figured out how good car brakes should be. It’s okay if your pogo stick hop-counting app crashes after you hit 100, it’s frustrating at worst.

*Didn’t look this number up but I can’t imagine it’s more than an order or two of magnitude off.

But there is software that is undeniably engineered. That bridge designed in part by civil engineers may also contain a monitoring system that ensures there is never too much weight or that detects small fractures in the material. The car brakes need to deal with frictional heat, but they are likely also controlled in part by the car’s central computer. Whoever writes the software for the bridge and the car is definitely an engineer. He is subject to the same safety standards as the other engineers.

Bogost had two points suggesting that software development is growing increasingly informal. He implied that its growing informality discounted it from being an engineering discipline. While his first point about ease of rapid repair was sound (if limited to certain types of development), I disagree with his second point – that software is becoming more isolated.

Marc Andreessen wrote a short paper arguing that software is eating the world, and the evidence is compelling. While there are certain applications of software development that stand essentially on their own, it is naïve to say that software development as a whole is becoming isolated when, in fact, it is becoming more and more integrated into all aspects of our lives.

So writing code doesn’t necessarily make you an engineer, a scientist, or an artist, but it could make you any or all of them.

 

 

 

 

Standard

intro to me

My name is Patrick Hansen; I often go by Pat. I grew up in Vienna, Virginia, the last stop on the Orange Line of the DC metro. My big brother graduated from Notre Dame last year and is at Wash U’s medical school for the next seven years. My little sister is in third grade and likes to create things using a rainbow loom. My mom teaches high school english, and my dad is a retired lawyer.

I am a captain of Notre Dame Ultimate, the club ultimate frisbee team here. Notre Dame Ultimate is comprised of 90 cool guys and girls currently on the team plus a couple hundred wonderful alumni who remain actively involved. We are split into guys and girls A and B teams (four total), and we travel to tournaments around the country in the spring. This year, the guys A team is going to North Carolina twice, Tallahassee, and St. Louis before the postseason starts.

With what little free time I have outside of school and ultimate, I enjoy spending time outdoors, hiking, skiing, backpacking, sailing.

As a computer science major, I enjoy taking a theoretical perspective to look at algorithms and data structures, but most of all, I enjoy the power to express myself and affect the way other people experience their mobile devices. Due to the ubiquity and imposed necessity of mobile devices in the lives of Millenials, I believe there is great opportunity in the field of mobile software development. While I am amazed and impressed with the capabilities of mobile devices, I am also wary of our reliance upon them and the negative impact they can have on our lives, especially socially. With that in mind, I seek to create software that people can interact with meaningfully without sacrificing interpersonal relationships with other people.

I love the chance to look at a field of study from a new perspective. Taking an ethical look at computer science and engineering is a neat chance to explore the interdisciplinary nature of the subject. I am excited to see which issues my peers are most passionate about and hear their views on them.

Hinted at above, I believe a potential loss of interpersonal relationships is the most serious ethical issue in computer science and one that I’d enjoy discussing with Professor Bui and classmates. It is important for software developers and designers to keep that in mind as we create more and more immersive software experiences.

Standard