‘Get posts and letters, and make friends with speed. Never so few, and never yet more need,” so said the Duke of Northumberland in Shakespeare’s Henry IV Part 2.

It could almost be a motto of our times, in which we have so many ways to sharing important information with each other or in the case of Twitter, communicating the banality of everyday life with complete strangers.

In March this year, Twitter celebrated its sixth birthday and announced it has 140 million users who send out approximately 340 million tweets each day.

The person credited with building the API, now one of the most important on the web, is Alex Payne who joined Twitter in 2007 when the site had 100,000 users worldwide.

After three hectic years Alex left Twitter to co-found and become the CTO of BankSimple (now Simple) a community or social bank, an antidote to large corporate banks which adopt the traditional pursuit of fleecing customers, mis-selling financial products and offering complicated banking to their customers for large sums of money.

Alex left Simple to concentrate on the craft of programming languages. As well as coding and writing (he co-authored Programming Scala with Dean Wampler) he’s an angel investor and adviser to a number of early-stage companies including Sprint.ly, Lucky Sort and Datadog.

RM:

Alex, can you remember first conscious encounter with technology and how did you learn to program?

AP:

When I was fairly young, a friend’s parent brought home a bulky early laptop (I wish I could remember the make and model), and I was entranced by it, particularly the notion of running distinct programs with results as varied as word processing and games. That was probably the first time I became aware of general purpose computers (as distinct from a technology like, say, a video game system). I remember wanting to understand exactly what could be accomplished from the prompt, and being handed a manual.

A few years later, my fifth grade teacher had collected old Macs, which ringed her classroom and were available for use if you got your other assignments done. Needless to say, I raced through quizzes and worksheets in order to be able to spend time on the computers. We were pointed towards simple Logo and BASIC programs, and I was hooked. I was extremely lucky that the school system I was in had made an effort to have computers in every classroom, as I was able to continue experimenting with programming with every passing grade.

I’d really say that the first proper programming I did was an assignment for a biology class. We had to construct a diagram of a cell. I asked the teacher if I could write a program that would produce the diagram, as I was eager to try out this Java language that I had acquired a book about. Trying to run an early version of Java on an end-of-lifed 68k Mac was an exercise in absolute frustration, but also great preparation for the sort of day-to-day hassles you run into as a professional programmer.

RM:

Who were your early formative influences in technology?

AP:

It’s probably a cliché to say, but William Gibson, Neal Stephenson, and the other cyberpunk science fiction authors really drew me into considering the societal and cultural impact of technology. I also picked up WIRED back when it still retained some of the edge of Mondo 2000, the cyberpunk zine from which it emerged, and I was a dedicated reader of the hacker monthly 2600. Most of early formative influences came out of that hacker/cyberpunk/cyberpunk branch of the technology community.

RM:

Together with Dean Wampler you wrote a well-received book about Scala. How did you go from programmer to author? Are there other writing projects that you’re working on?

AP:

At a conference several years back, I ended up in a conversation about emerging programming languages with editors at both O’Reilly and Pragmatic Programmers. We’d been using Scala at Twitter for about a year at that point, and I was really happy with the results. Both editors walked away convinced that they needed to do a book on Scala, and it just so happened that I ended up working with the fantastic Mike Loukides at O’Reilly, who in turn paired me up with Dean.

I’d been writing about technology online for years, so while a book was a much longer-form project and a much bigger challenge, it wasn’t at all unusual for me to spend much of my free time writing.

On wrapping up the Scala book, I was eager for another big writing project. I’d like to do a history of programming languages in general, one that’s accessible to a less technical audience but still meaty enough for geeks to get something out of. I’m not sure when that project will come together, but I’m always thinking about it and gathering materials for it.

RM:

Presumably you don’t hold with the view that Scala is too complex and too oriented towards academics in the world at large?

AP:

I don’t think that Scala is too geared towards academics and research at this point in time. Typesafe, the commercial entity behind Scala, is making a big push to get Scala into the enterprise. Most of the recent changes to the language have been in the spirit of broader commercial adoption.

I do think that Scala pushes the boundaries of how many features a language can have without burdening the programmer, and I’d like to see fewer features in the language going forward, not more. That said there’s enough Scala code in production that it’s safe to say the language is not too complex to use. People manage just fine with it.

RM:

What’s the short list of languages that you want to play with more?

AP:

Pretty much everything in this year’s Emerging Languages Lineup is something I’d like to play with. Roy, Elm, and Julia are particular standouts from that list.

RM:

Do you feel there’s a general tendency to ignore what I suppose could be called the archaeology of technology and somehow rediscover some of this stuff and learn to appreciate it and benefit from having done it?

AP:

When I first got into programming and started attending conferences and such, I rarely heard much about what had come before. In the last few years I think that’s improved. I’m currently on my way back from the Strange Loop conference where there were multiple sessions that took a historical view on technology. That’s encouraging, but talks like that are only reaching a fairly small and self-selecting portion of the technology/developer community.

I still see a ton of wheel-reinvention in the technology world. As a community, I think we’re too quick to reward the creation of any new software, protocol, library, or standard without first considering if it really moves the state of the art forward and contributes something meaningful and new. Marketing and hype can still easily overwhelm a more measured long-view approach to technology. That’s just a factor of human nature, though; we’re wired to crave novelty.

Part of the reason I’d like to work on the history of programming languages book is to combat that lack of historical perspective. I don’t blame people for not doing their own “archaeology”, particularly when they’re at the beginning of their career and having to absorb a ton of what’s out there currently. If we had better resources from which people could learn about the history of technology, I think more people would take advantage and approach their work in a broader historical context.

RM:

Your answer raises another age-old question. Gerald Weinberg put forward the argument in his The Psychology of Computer Programming in the early 1970s: should code be owned by one person who is the only person who ever touches it or should everyone on a project collectively own all the code so anyone can alter it at any time?

AP:

I believe in a more team-oriented approach to code ownership. I think it’s inevitable that mature engineering organizations will see a substantial amount of specialization, and that responsibilities will have to be divvied up by business unit, expertise, or whatever criteria makes sense. Today, teams tend to collaborate across API boundaries, whether those APIs are libraries of code or logically separate services. Anyone on a team that provides an API should be able to modify and improve it. Under the right circumstances, teams should have porous boundaries and patches should fly in every direction, but that requires a lot of trust, communication, coordination, and business problems that lend themselves to that mode of work.

RM:

Is education is the answer to developing better software and that somehow we get out from the ‘we must do it first no matter how buggy it is’ way of thinking? And is this thinking innate or produced by popular culture?

AP:

I’ve worked with programmers from all sorts of educational backgrounds over the years, from self-taught hackers to Ivy League PhDs. Across that spectrum; I haven’t seen a strong correlation between formal education and code quality. The desire and ability to produce quality code is partly about teaching programmers good engineering practices, but mostly about an individual’s sense of craftsmanship. “Craftsmanship” is a popular bullet point in mission statements in technology organizations, for what that’s worth, but I think it’s more of an innate character trait than something that can be cultivated just by beating an organizational drum.

RM:

Are you coding as much these days as you used to? How do you go about designing a new piece of software? Do you sit down at a computer and start coding or do you sit with a pad of graph paper, or what?

AP:

The amount of time I spent coding fluctuates depending on what I’m doing, personally and professionally. At the moment, I’ve got a fair amount of time on my hands to code, which is great. I like solving business problems and doing more people-oriented stuff, but there’s a satisfaction that I only get from a good day of programming.

How I code depends on what I’m coding. For anything that requires coordination with data stores or other external processes, I’m likely to sketch a bit on paper. For something that’s more self-contained, I’ll just get right to the keyboard. Either way, I usually put a skeleton in place and then proceed to a largely test-driven development style. I’m a stickler for package management and good project setup, so I tend to get that stuff out of the way before I really get into the code.

RM:

Have your ideas about language design changed over time?

AP:

Absolutely. Like a lot of programmers at the beginning of their careers, I used to be very extreme in my language preferences: “oh, that language sucks, anyone who uses it has no idea what they’re doing, you have to use Language X,” that kind of thing.

Over time, as I’ve studied a variety of programming languages, I’ve adopted the philosophy that every language has its redeeming values. I certainly still have my preferences about the languages I want to program in day-to-day, but on an academic level I think there’s always something to learn from how languages are designed and implemented. In fact, the languages that you find most off-putting probably have the most to teach you.

RM:

How much does a choice of language really matter? Are there good reasons to choose one language over another or does it all come down to taste or taste?

AP:

Choosing a language of the right general sort for your problem matters. For example, if you’re building a system, you will be happier working in a systems language (Java, Scala, C++, and Go). Which particular language you choose within the category relevant to your problem probably matters less. Just be sure that you’re comfortable with whatever trade-offs come with your chosen language (availability of commercial support, release schedule, etc.). Usually, the combination of language category and particular trade-offs will quickly narrow down your options to just one or two.

RM:

I have to ask you one question about Twitter. What was your first impression of the company?

AP:

Like many, I found Twitter pretty silly at first blush. I was eager to see a technology that was clearly more accessible than blogging, but I made the assumption that many did when they first saw Twitter that it would just be used for trivial communication. It wasn’t until I’d used it for a couple of months and integrated it into my communication tool set (along with IM and email) that I realized how transformative it could be. Twitter’s combination of pithy observations, reporting, either professional or amateur, and personal updates is just so compelling, even if it can be crazy-making at times.

RM:

Do you think about becoming a business owner? What’s your next big project?

AP:

I can see starting a company in my eventual future, yes. I’m not sure what my next big project is yet though.