Floundering in Ignorance

One of the most enlightening experiences I had in college was collaborating on a software project in a large group. After struggling with the social dynamics and the difficulty of the project, I learned about a concept described by Philip Armour called the "Orders of Ignorance." This concept provides a framework for understanding difficulties in software development and illuminates the source of our struggles.

Armour explains that in life there are various orders of ignorance. The 0th order is knowing something, or having an answer. The 1st order is awareness of a lack of knowledge, or having a question. The 2nd order is a lack of such awareness, or not even having a question. The 3rd order is not having a way of discovering what is unknown. My group’s main difficulty dealt with the 3rd order of ignorance: we did not know how to proceed once we chose a problem to solve.

Originally, the group leader decided that we would build a product to help system administrators easily view a computer system’s status. We hoped that building an interactive web interface with real-time graphs would enable system administrators to easily identify system-related issues. While we understood the problem we wanted to solve, we could not figure out what information the user would need. We did not know which kinds of data should be displayed together, how to analyze and display the data in a meaningful way, or how to empower the user to dive deeper and inspect the data more thoroughly. The group leader had the best understanding of system administrator needs, but he was often unavailable and ineffective in communicating his desires, leaving our group to flounder.

Ultimately, the group decided that the project was too hard and we switched to one we understood better. Looking back on the experience, I now realize things that we could have done to succeed with the original project. In other words, I no longer have 3rd order ignorance concerning the situation; I know processes we could have used to find questions and figure things out.

First, we should have just started building something. We could have made a simpler version of our product to report at least one piece of the data in real-time. Not only would this have helped us progress in building the product, but it also would have likely given us new ideas about displaying system data. In other words, we should have tried to discover through building. Armour calls this process of resolving 2nd order ignorance hacking. Hacking almost always makes 3rd order ignorance impossible by definition.

The second thing we could have done is to ask for help. If we had just made the connection between our struggles and 3rd order ignorance, this would have solved the problem. We could have sought help from our professor, done more research, or talked to other students who might have had more experience with system administration. Each of these sources might have given us direction.

This experience of applying the orders of ignorance to my situation after I had already failed makes me wish I had understood them better at the time so that my group could have succeeded. While the other project we worked on represented a great learning experience, giving up on the first project leaves me with a bad taste in my mouth. Other software developers should also have an understanding of these principles. This could help companies, open source groups, and programming hobbyists succeed where they might otherwise fail.

(Philip Armour's "Orders of Ignorance" can be found in Appendix B of his book, The Laws of Software Process: A New Model for the Production and Management of Software)

Knowing your limitations as a working student

October was a bad month for me. I was falling behind in school and I was unproductive at work. The worst part of this for me was the feeling that I was cheating my employer. I only worked three days a week and was assigned to large projects. I felt bad because I spent lots of time figuring out what I was doing and what I needed to do next instead of making progress on the assignments. Also, school pressures were distracting me from work. Luckily, I had a great manager who helped me adjust my responsibilities and encouraged me to take a day off from time to time to catch up in school. From this experience, I learned that I need to be honest with my employer about my limitations or any hesitations I have about a particular assignment. The ACM's Code of Ethics states,

"A computing professional has a responsibility to request a change in any assignment that he or she feels cannot be completed as defined. Only after serious consideration and with full disclosure of risks and concerns to the employer or client, should one accept the assignment."

I wish that I had been wise enough to understand this concept before. I hope other working students and new working professionals can learn this lesson without the pain of hard experience.

Work for it. Care about it.

I am a computer science student, and as such, I have learned a lot about open-source software. I recently had the opportunity to work on a project called OpenSeadragon during my internship at FamilySearch.org. I found working on the project deeply satisfying. I was able to contribute to code many people use, simultaneously contributing back to the open-source community that I rely on so much as a programmer. A year ago, I knew almost nothing about open-source software. Now I feel strongly that it is an initiative worth supporting and contributing to. It is because of the effort I invested into open-source that I care so much.

Another example of this can be seen in Cliff Stoll's personal account of chasing a hacker in his book, The Cuckoo's Egg. Because of Stoll's background as an astronomy student and a programmer, he recognized the value of computer networks and research sharing. But it wasn't until he worked for months to catch a hacker in his system that he really began to feel passionate about network security. Usually we invest in what we care about, but just as often we care about what we invest in.

Working with intellectual property is scary

The other day Goldman Sachs was at my college campus trying to recruit computer programmers. As the recruiters described how wonderful it is to work for Goldman Sachs, I couldn't help but recall an article I read about how Goldman Sachs prosecuted a former employee, Sergey Aleynikov, for stealing intellectual property. I don't know all the details of the case, but essentially, Aleynikov was trying to do what was right and legally required by open source software licenses and contribute code that he created back to the open source community. I would never work for a company like Goldman Sachs, because I believe that open-source is a good thing and ought to be promoted, not discouraged.

You can check out some of these articles for more information about the trial: Vanity Fair, Above the Law, Forbes

So much to read, So little time

Recently, I added Y Combinator's Hacker News to my RSS feed. I quickly learned that there were more interesting articles posted than I could possibly read. My main purpose in subscribing to Hacker News was to become a better programmer, yet I found myself reading articles on how to run a successful startup and how healthy eating is an engineering problem. Later, I decided to just do a Google search for "how to become a better programmer." In the first few hits I found an article with a list of specific suggestions and measurable tasks that I could do. Most of the time, more information (like from Hacker News) just takes our focus away from actually doing anything worthwhile. I could continue reading articles about becoming a better programmer, but until I actually implement the ideas in the articles, I am just wasting my time.