The Story

What about 'Knowledge of Philosophy'?

I recently read that there are only three interview questions:

1. Can you do the job?
2. Will you love the job?
3. Can we tolerate working with you?

In the past, I haven't had a lot of trouble with these three. My problem is:

4. What's with the PhD in philosophy?

There are plenty of reasons not to fret about this. I doubt my answer matters much given my ability to answer the other three. Plenty of people take a non-linear career path, and there are lots of reasons to get a PhD--it has helped me to get noticed, if nothing else. Finally, a PhD in, say, computer science probably wouldn't give me any more special knowledge than one in philosophy, because what I would have studied would have been so specific and so quickly dated. Still, the question comes up often enough in normal conversation that I'd like to be able to give a reason more interesting than 'broadening my intellectual horizons' and shorter than my dissertation. Here's my attempt.

A degree in engineering (and some experience in the field) shows you how to solve problems, but it doesn't provide much help in figuring out questions like 1) What should I solve? 2) What is it right to solve? At Penn State, the main recruiting industries were military. I knew that I didn't want to kill people, but I didn't know much besides that. I lacked direction, and the only guidance I got from my computer ethics class (Ayn Rand) wasn't particularly helpful. (She says: go do great things, but what were those things I should be doing?) My philosophy classes were more promising, but they really only whetted my appetite.

In grad school I focused on moral and political philosophy. That is, instead of trying to prove or disprove God's existence or understand how we can know anything, I was interested in: 1) What is the Good? and 2) What is the Just? These problems were particularly difficult because, like most non-fanatics, I didn't think there could be just one answer. But my moral intuitions gave me reason to suspect there had to be some kind of answer. It's that space between 1 and infinity that's tricky.

It took some work, but eventually I became a philosophical pragmatist. I realized that, like most philosophers today, I thought I had accepted that there was no Absolute Truth when I was really still hankering after It. Pragmatists have a good explanation of relativism without believing that whatever you think is the right thing to do. (If you're really interested, start here). You simply can't accept that there are multiple right answers and keep asking the same old questions, like 'What is the Good?' or 'What is the Just?'

James figured out a new way of thinking with an old name

Pragmatism involves bringing scientific thinking to all areas of life, including moral and political questions. What most people don't realize is that science has become relativistic in the 20th century. From Heisenberg's uncertainty principle to Godel's incompleteness theorem, scientists have stopped looking for absolute truths and now couch their hypotheses in terms of the highly-specific and reproducible experiments. One cannot extrapolate beyond those experiments for all situations and times. Brian Cox often says that there's no good reason to assume scientific 'laws' will hold for any amount of time--we simply find that they do so in many situations.

Pragmatism is important for thinking about technology in at least two ways: 1) It helps us reconcile morals with science. For example, if new technologies make the consequences of our actions very widespread, we must become more knowledgeable about them in order to realize our moral principals. 2) On a social scale, it shows us how to think about technology and the greater good. For instance, instead of thinking about technology as just a tool or as the savior of mankind, we should look at how some technologies help us solve certain collective action problems. In either case, the main point is to look at concrete problems and technologies, not technology, morality, or justice in general.

All this is very brief, but that's because it's what my blog is all about: applying principles to specific problems. I still tend towards the overly-philosophical side, but I'm getting there.

Technology and Collective Problem-Solving

"Technology" signifies all the intelligent techniques by which the energies of nature and man are directed and used in satisfaction of human needs; it cannot be limited to a few outer and comparatively mechanical forms.
--John Dewey

In a previous post, I explained how many philosophers, including Heidegger and Marcuse, see a rift between ethical reflection and technology. They worry that the means-ends thinking at the heart of technology can cause us to ignore other kinds of reflection--especially about who we want to be, what we hold to be just, and how we can lead more meaningful lives.

There is obviously a difference between painting a picture and developing a manufacturing plant to make paints and brushes, but what's wrong with solving problems? Is it really so dangerous as philosophers--who aren't typically known for being technologists--seem to think? John Dewey says no, arguing that all inquiry has a technological component insofar as it is meant to solve problems. If moral inquiry helps us solve problems, it's as technological as lasers and airplanes are. Theories are just tools for solving problems.

Understanding technology as problem-solving may seem impossibly vague, but it's actually very powerful. Whenever considering a new gadget, theory, or way of doing things, Dewey suggests we ask: what is the problem this is meant to solve? Remarkably, many new products don't seem aimed at solving any problems, or at least not any serious ones.

What about the problem of collective decision-making? Humans have created two lasting technologies for this purpose: representative governments and markets. Governments are good at ensuring certain behaviors that its people think should be ensured. They define and enforce justice, including the means of determining what justice is. This wasn't always the case and took many years of trial and error. Life used to be filled with a lot more anxiety, because the world was so much more unpredictable, and the means of determining fairness were uncertain.

Althingi, where Icelanders have solved problems since 930 CE
Governments, however, can only solve certain problems. They're bad at picking market winners, for example, and they're slow to react to change. They are good at prohibiting certain behaviors, but it's hard for them to make citizens moral, healthy, intelligent, or cultured. As Cass Sunstein argues in his book Nudge, the best governments may be able to do is incentivize certain behaviors so that people will make the right choices on their own.

Markets, on the other hand, provide a highly responsive way of determining what people value and what should be produced. As Friedrich Hayek recognized, markets aggregate people's individual choices and values and thus collectivize intelligence in a very efficient manner. Markets will always have the input of more people than governments as well as higher levels of participation. And, since people often know what they want better than 'experts,' markets can be more rational than governments.

Unfortunately, many things cannot be quantified in dollar values, such as the environment, health, or justice. We can adjust markets so that they take hidden costs into account, as cap-and-trade systems do, but these work best when you have a metric that can be easily tied to cost. Another criticism of markets is that people do not always act rationally, as Daniel Kahneman and other behavioral economists have shown. Even if we know what we want, we can't be sure to act accordingly.

Given the limitations of governments and markets, Deweyans turn to small groups for salvation. There are many interesting examples of small-scale collective problems solving, such as the rebirth of Pittsburgh or river management in Mexico, but it's hard to see how such solutions will scale. As our interactions become ever more global, we need globalized methods of collective decision making.


For these reasons, Clay Shirky and other technologists point to the internet as a possible third way of making intelligent choices collectively. It's not enough to say that the internet connects people. The idea of the internet as a 'Global Village' has become a joke, as new technologies help us filter each other out like never before. What Shirky points to is the way the internet lowers barriers to participation. Shirky's poster child is Wikipedia, which, like most internet phenomena, displays a long tail of participation. Many people work together, though the vast majority only contribute a little.

Lowering barriers is great, but it is probably not enough if we are to find a third way to compete with governments and markets. Can new technologies help us better solve collective problems? The question becomes ever more pressing as big players like Google, Microsoft, and Facebook become ever bigger and structure the ways we interact more and more. Not being evil is not the same thing as providing venues for increasing collective intelligence. What other problems should we be trying to solve?

The OO Factor

TIOBE releases statistics on the popularity of programming languages every month. The methodology behind the study is not without its limitations, but it's definitely worth checking out. The information is culled entirely from search engine statistics, and there are some difficulties interpreting the data, as the popularity of languages forms a long tail. One of the best things about the study is that they have data going back 25 years (though I'm not entirely sure how).

I don't want to start any arguments about whether your favorite language is increasing or decreasing in popularity. Instead, I'm interested in what this data means for your career. Chad Fowler likens your investment in a language to financial investing. You might pick ole faithful and get consistent returns, or you might take a gamble and hit the mother load. Here are some of the lessons I think are worth noting.



1) All of the top languages are object-oriented (with the exception of C). Whether you specialize in Java, C++, or C#, you're OO. These languages are far from being identical, but their similarities are much greater than their differences. It's a testament to the OO paradigm that it has enabled the development of enterprise applications with reusable code in a wide variety of syntaxes and styles. Really I'm shocked by how popular C still is, as it is not technically an OO language.

Category	Ratings Sep 2011	Delta Sep 2010
Object-Oriented Languages	56.2%	+1.7%
Procedural Languages	37.7%	-2.5%
Functional Languages	4.3%	+0.5%
Logical Languages	1.8%	+0.3%

2) Everything else is a grab-bag. After the top 10 or 20 languages, you have a long tail of less popular languages, especially procedural languages. I see Haskell, Scala, F#, and a whole bunch of languages I've never heard of. It's tough to pick one of these to focus on. Will Erlang experience a meteoric rise now? Will COBOL finally bite the dust?

3) Conclusion: Diversify your knowledge resources. In a market like this, all you can do is diversify. It's a good idea to become familiar with a couple of OO languages and development environments, though I'm not going to spend all my free time learning Java in the off-chance that Microsoft platforms take a nose dive (which this article suggests might happen). If you're a Windows-only programmer, download Linux, Eclipse, and do some Android programming.

Once you have those bases covered, it's hard to say what you should learn next. For this reason, I think about learning languages in much the same way as I thought about studying philosophy. If you want to learn philosopher X, reading his/her works will only get you so far. You also have to read lots of other philosophers to understand what X is responding to and what makes X different. In the same way, languages develop historically in response to the successes and failures of other languages. If you really want to learn an OO language well, you'll have to understand what makes it different from Prolog, Lisp, and some of the other alternatives out there. That way, you'll be able to better understand and articulate why the approach you want to take to solve a problem is the right one. That's a valuable skill in any market.

Links:

-Chart of the evolution of programming languages

Determining Your Value

This summer I took a break from my extra-vocational studies to reflect upon my career and my plans for the future. There are a surprising number of software career books out there, but I turned to the Pragmatic Press for the Passionate Programmer by Chad Fowler, a saxaphonist/programmer (with no relation to Martin Fowler). I love that the Pragmatic Programmers are passionate about things other than programming, such as woodworking, aviation, or music, but I'm not crazy about the name of the book. I guess the idea is to play off of the Pragmatic Programmer.

A lot of Fowler's advice is common sense, though common sense is not always so common. One of Fowler's most interesting suggestions for me was: your value depends upon your ability to give different people what they need. Writing elegant code, keeping up on the latest technologies, or other technical skills are only a small part of your value as an employee of a company, as you are likely to have a lot of different demands from a lot of different people.

Salespeople could care less about how elegant your code is unless your poor skills lead to performance issues with their reports. Your managers are primarily concerned about managing you. If you are difficult to manage--such as by not showing initiative or not keeping them informed of your bottlenecks--you become less valuable. Your users need someone who understands what they actually do and who can speak their language. If you don't learn their vocabulary, you're not a good programmer. Your teammates need someone they can count on, such as when the production system goes down or you break the build. HR needs you to fill out timesheets. Finance needs you to bring in more money than you cost. If you can't do any of those things, you're not a good programmer.

This piece of advice really hit home with me because, as a philosophical pragmatist, I've long held that there are many factors that could determine a thing's value. Whether or not that thing is valuable to you depends upon how those factors impact you. We often think of a rotten tomato as being bad, but it's only bad if you want to eat a tomato. If you want something to throw at a comedian, it might be just what you need. There's nothing intrinsically good or bad about a rotten tomato. There's no category of 'tomato-ness' that it's not living up to. It's just a rotten tomato.

In the same way, there's no one thing you must do in order to be an excellent programmer--not even programming. Many developers think that they're under-appreciated geniuses who should get paid proportionately to how smart they are. They don't have to worry about writing coherent emails, filling out paperwork, dressing appropriately, or staying after 5:00 PM when the server goes down at 4:59.

If you don't think about your value in the right way, you will not be able to articulate your value when it's time to talk about raises or starting salaries. A great interview question is: "I see you cost X dollars last year. How did you return on that investment?" Often, we're so used to being bombarded with technical questions and thinking about our value from a technical perspective that we cannot answer such questions very well. This is a habit that you should try to break.

It does take some work to become a great programmer. A good way to start is: instead of asking yourself what you need to accomplish today, ask yourself what you need to do for the people who depend on you. Prioritize accordingly.

Links:

-William James's Pragmatism: A New Name for Some Old Ways of Thinking. The first two chapters are classic.

Software Gardening

The Pragmatic Programmer has a lot of nuggets. Here's one:

The most common metaphor for software development is building construction. Using construction as the guiding metaphor implies these steps:

1. An architect draws up blueprints.
2. Contractors dig the foundation, build the superstructure, wire and plumb, and apply finishing touches.
3. The tenants move in and live happily ever after, calling building maintenance to fix any problems.

Well, software doesn't quite work that way. Rather than construction, software is more like gardening--it is more organic than concrete. You plan many things in a garden according to an initial plan and conditions. Some thrive, others are destined to end up as compost. You may move plantings relative to each other to take advantage of the interplay of light and shadow, wind and rain. Overgrown plants get split or pruned, and colors that clash may get moved to more aesthetically pleasing locations. You pull weeds, and you fertilize plantings that are in need of some extra help. You constantly monitor the health of the garden, and make adjustments (to the soil, the plants, they layout) as needed.

I'm trying to think this metaphor through, as, until now, I had not questioned the metaphor of architecture. Intuitively, I have a sense for what Hunt and Thomas mean. After all, these guys started the Agile Alliance, which takes the 'waterfall' or linear model of software development as its main target. The four main principles of the Agile Manifesto are:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

I have done some organic gardening, so I have a little experience to draw upon to understand what Hunt and Thomas are getting at.

The first thing I learned gardening is that you cannot start from scratch. No matter how much pesticide you spray or soil you import, there are soil, drainange, water, sunlight, insect, animal, and other conditions that shape what will grow and what won't. The earth has been here a lot longer than your garden has. In the software world, you don't begin at the beginning either. You have a team's knowledge and relationships, IT infrastructure, available languages and platforms, customer expectations, and the market of existing competitors and third party vendors, to name a few. And, of course, the majority of work as a software developer is not development but refactoring existing code.

The second thing I learned is that things rarely work out the way you planned and that you have to adjust to these events. One year, a groundhog ate almost all our butternut squash. Another year there was a tomato blight. We built an electrified fence to cut our squash losses, and we made sure to not plant tomatoes in the same place next year. In software, you have to do what you can to contain unexpected events. This happens at a macro and a micro level. For instance, on a micro level, code should be robust enough to handle exceptional situations. At a macro level, it should be flexible enough to handle change. For instance, in order to best adapt to increasing demand, your system should designed to scale. If you might have 10 million new customers in a month, you must make sure that your database architecture can adapt to that demand.

The last main thing I learned is that to be a good gardener, you have to be able to learn. No one is born with a green thumb, but some people learn more quickly than others what works and what doesn't. It's a lot easier to start gardening if you know some people who already garden. And no matter how much reading you do, there is always more to learn, because there are always new things you have to deal with. The same is true for software development. Many programmers are 'book-learned' and can't apply their knowledge, or they are narrowly knowledgeable about a handful of languages or platforms. It amazes me when I hear people describe themselves as either back-end and front-end programmers, because a good programmer must be both. If you follow Hunt and Thomas's advice, you'll learn a language a year!

Of course, gardening doesn't sound quite as cool as architecture, but good architecture follows many of the same practices outlined here. For example, modernist architects are accused of ignoring site specificity and simply plopping down skyscrapers in the middle of thriving urban ecosystems. If you don't learn from previous projects, you'll get a bunch of haunted shells like those that make up Dubai's skyline. Buildings are much less malleable than code, but that is all the more reason not to use them as a model.

Links
-An interview with Andy Hunt and David Thomas about software gardening

Pragmatic Programming

I'm a big fan of Andy Hunt and David Thomas's Pragmatic Programmer (2000) and the series of books they publish at the Pragmatic Bookshelf. You might think this is because I wrote my dissertation on John Dewey, a famous member of a group of philosophers called the American Pragmatists. To be sure, philosophical pragmatism has a lot in common with what we commonly mean by the word "pragmatic." For instance, the Pragmatists thought traditional philosophical questions were abstracted from the problems they were really meant to solve. Philosophers asked "What is the beautiful?" without working with artists who were trying to make more beautiful art. They asked "What is the good?" apart from the moral dilemmas of actual people. And they tried to define "What is truth?" in abstraction from rival truth claims.

In short, philosophical pragmatism eschews head-in-the-clouds questions and focuses on solving problems. Any reflection that is not grounded in solving a problem risks being disconnected from practical consequences. It might even make us worse at solving problems by narrowing our thinking by theories that are untested by experience.

Though there are dangers to pure theory, I find most technical books (and blogs) to slide too far to the other side of the spectrum between theory and practice. These books are often written in the form: "If you want to do X, do Y." If you want to build an index on a table, here is the command. If you want to inherit one class from another, use this syntax. If you want to create a web service, you must create this kind of a connection. Such books are often so focused on the trees that you never see the forest. They are pragmatic in the sense that they don't give you a bunch of high-falutin' theory that you'll never use, but they aren't really pragmatic in the sense of helping you solve real-world problems.

Why is that? Technical books are often useless because they assume you know what the problem is, and anyone involved in software development for long knows that this is rarely the case. If I know that I need to create an index on a table, I can read a tutorial on creating indexes. But maybe what I really need is to write better queries. Or perhaps I need to normalize my table architecture and make more use of clustered indexes rather than throwing non-clustered indexes at performance problems. I might be using a relational database when I should be using a document store. It could be that my company's code review process needs to be improved so that issues like this are handled by database programmers and not our support staff. Perhaps performance isn't even what I should be worrying about, and the biggest problem facing my company is writing more robust code. Once you start to delve into even the simplest of problems, you can open a Pandora's box of other questions that change your understanding of the matter at hand. The reason I like the pragmatic programming books is that they go beyond the nut-and-bolts approach and provide us with concepts to help us better prioritize and deal with the problems we actually face. In an ideal world, everyone would write perfect code. But in the real world, we are always in the process of improvement, and we need conceptual tools to determine what is most in need of improving.

One of the best recent examples I've seen of the kind of truly pragmatic conceptual tools I'm talking about is Brent Ozar's hierarchy of database needs. We all know that our databases could be more secure, robust, and responsive, but what should we focus on now? Well, if we aren't backing them up, we need to create a maintenance plan ASAP. Then we can worry about security, and so on. The point here is not that Ozar's hierarchy is perfect. As he himself says, the problem with doing backups isn't that we don't know we should be doing backups (I hope); the real problem is that the technology and business groups haven't worked together to prioritize what is most important. And a major cause of such a communication breakdown is the lack of a vocabulary to describe the problem the teams face.

I haven't seen a hierarchy of generalized software development needs, but Hunt and Thomas provide many tools to help you and your team develop your own. The base of the pyramid might be having a version control system, and then a ticketing system could come next. In the middle we'd want to make sure our code is orthogonal, or highly de-coupled. Finally at the top we could turn to documentation. Priorities will vary from place to place and from time to time, but without a language to talk about them, we cannot intelligently decide what to do next.