Welcome to our continuing series of CodeProject interviews in which we talk to developers about their backgrounds, projects, interests and pet peeves. In this installment we talk to Ted Neward, "The Dude of Software".
Who are you?
My name is Ted Neward, though some refer to me as "The Dude". Some have called me the "Dr. House of Software", but others call me "The Dude of Software", which is more fun. (Though I do reserve the right to my House-ian moments.) "Dudearino", "Big Dude", and "Ted" are also equally acceptable.
You know, most of the time people call me whatever they want—I'll answer to pretty much anything.
I work here in Redmond, though not for "those guys"; I do consulting as well as a lot of speaking and writing on software topics for conferences and magazines through Neward & Associates, LLC. Most recently I worked with Neudesic, LLC, a .NET consultancy.
And I teach programming at Bellevue Community College here in town.
And I'm working on a book for O’Reilly on the intersection of philosophy, psychology, and software.
Really, I just kind of hang out, drink White Russians and, you know, try to help people find the rug that really ties the whole system together.
What do you do?
Most of the stuff I've done exists behind the corporate firewall or NDA, so there's not much I can talk about, unfortunately. (Lawyers just really need to learn to abide, man.)
The most commercial I ever worked was real early in my career, when I contracted for Intuit on Quicken 5 for Windows. That was kinda fun—all this 16-bit C code that they "flipped the bit" on to go to 32-bit, but it was still all C code that they had been polishing since Quicken 1 for the most part. Cool stuff, man.
Today, I do a lot of architectural consultation, some SOA, some Java/.NET interop, connected systems kinds of stuff, some NoSQL, and some mobile, like iOS and Android.
And I run a workshop at conferences called Architectural Katas, for architects or would-be-architects, so they can practice architecting a system. Fun.
I've done a bunch of other stuff too, but it's all resume stuff, man. Boring.
What is your development environment?
Kinda depends on the project — I spend a lot of time in the Java space as well as the .NET space, and I do a lot of research into a lot of different languages and frameworks, so I actually have a bunch of different environments.
I have a couple of MacBook Pros, both of which have VMWare running on them, and I have a bunch of PC laptops: two IBM Thinkpad T42p's, because that was just a workhorse machine and I loved it back in the day, a Dell D630 that I picked up from salvage somewhere, and a current Lenovo W510 monster that is my current VMWare host for a bunch of different VMs for different languages and platforms.
Plus I've got about a half-dozen Android tablets of different shapes and sizes, another half-dozen Android phones, an iPad, iPhone 4S, iPhone 3GS, couple of iPods, and there's probably a Palm Pilot V hiding out somewhere in my office, just because.
Languages… I'm a language whore, man. C#, F#, Java, Scala, JavaScript, CoffeeScript, Ruby, Groovy, Nemerle, Boo, Clojure, Lisp, Scheme, Erlang, Haskell, Lua, Yeti, Frege, Prolog, D, R, OCaml, Google Go, Dart… they're all fun to track and play with.
One of my favorite things to do is periodically go out looking for even more languages to explore and play with — I'm contemplating porting Piet over to .NET, for example, just for fun. And the same guy who created Piet has a language called Zombie that I don't think has ever had an implementation written, so I'm thinking about doing a .NET or JVM implementation of that. Maybe on Parrot instead. Dunno.
About the only language I haven't used is Perl. Perl sucks.
Oh, I try to play with them all — they all do something interesting.
I'm going to do an article before too long on Oak, which is this really interesting dynamic-based web framework that feels a lot like you're in Ruby, but you're not, you're in C# and running in ASP.NET, and it's kind of this cool "best of both worlds" vibe going on. That feels kinda interesting.
And in the Java world, I'm playing with the Play framework, which is a web framework that really runs with the strongly-typed statically-typed type system that Scala has; I'm thinking that an F# equivalent would be really powerful to explore. And it's got the message-passing semantics within it (in a library called Akka) that Erlang touts so much.
But what's really at the top of my list right now is Elm, which is a Haskell-hosted language for building Functionally-Reactive Programming systems on the Web. It's kinda trippy when you first look at it, because you're wiring up functions that will be fired as data streams out of particular event sources (like mouse position and button clicks and stuff), so it feels like you're doing event processing, but it's a lot more than that. And it's exactly the same stuff that Erik Meijer was talking about when he built Reactive Extensions for .NET (and JavaScript, and now Java and a few other places).
What is your coding pet peeve?
Aw, man, they're all good for something. Everything that somebody does in a programming exercise, they did for a reason. It's just that sometimes we just lose sight of what the reason was.
Hungarian made sense in a language that didn't have real good type system support, but in an age when things like IntelliSense and "hovering tooltips tell you the type of the thing" features in your IDE. Today? Depends, does it feel like it's helping you see the code more clearly? Or is it a pain to have to type all those little weird characters first? Go with what feels good and looks right.
Myself, I like to put the curly braces on the next line, but seriously? It's like a keystroke to fix it however you want it with any kind of modern IDE, so why are we still arguing over this kind of stuff?
Or then you get into languages like VB or F# or Python, where there are no braces, just keywords or indentation, and there's no debate anymore.
How did you get started programming?
It was called Little Brick Out, and this is going waaaaaay back to the Apple II+ that we got back in 1978. Dad insisted that if I wanted to play the game, I had to learn how it was put together first, so he printed out the Applesoft Basic source code for it, and kinda led me to believe that you had to look at the source code every time you wanted to run a program. (I learned differently before too long, but, still….) Then I learned about Apple-Trek and a couple other games, and I thought, "Dude! That's cool — I want to do my own version of that!")
I didn't really think about programming professionally until I was in college and in my third year of school there. Me and my two roommates were working on building a computer version of Supremacy (think Risk but with economics and nukes), because we liked to play it so much. That was all C++ and Windows, which we were all teaching ourselves.
One of my roommates saw a want-ad for a local business looking for a full-time programmer, and man, he double-dog dared me to go interview for it. Now, as you know, among guys, there is no more serious challenge than a double-dog dare — to lose is to, like, lose your manhood. Always let the winner get the first slice of pizza. Or something. So I interviewed, and I was kinda shocked when they called me back for a second interview — out of like 40 people I was one of 4 finalists. I didn't get the gig, but it was like, "Whoa, people will PAY me for this?"
People who've seen my Twitter feed and read my blog kinda know where I am on this; I just posted a couple of blog posts on some of the inherent arrogance and hubris that I see in the "Software Craftsmanship" movement (and “More on Craftsmanship” in response to some of the comments, and my “Last Thoughts on Craftsmanship” to wrap things up).
For the most part, I think the dev community is a pretty cool group of people, but man, are we arrogant. I mean, I sit around and listen to software developers, and you'd think we were just the most amazing people on Earth, and why haven't like all the politicians and scientists and religious leaders come to their senses and asked us how to solve all the problems?
True story: I'm down in New Orleans for TechEd back in 2010, and there was a party at the New Orleans Aquarium. It was just a month or two after the big BP oil spill down there, and I'm standing with like four other guys in front of the "Gulf ecosystem" exhibit, sponsored by BP. And we started to get into this discussion of all the things that BP should've done to shut down the oil spill, and all of a sudden I'm thinking, "Wait a minute, here's five guys that have no background in marine biology, no background in oceanic engineering, no background in chemical engineering whatsoever, talking like we know exactly what the experts who've studied this for all of their lives, who are out there right now trying to solve the problem, should do, like we know what the hell we're talking about."
It was kind of eye-opening: we software guys have this really amazing tendency to tell people what they should and shouldn't be doing, or how they should or shouldn't be doing it, and we actually expect people to change the way they live their lives at work or at home just because we tell them that. And yet, when a doctor says the same thing to us, off to the Internet we go, to prove them wrong, because somewhere on the Internet, somebody said something that contradicts the guy who's spent his entire life studying medicine.
It's not ill-intentioned. We're not bad people. We just kinda get used to being the experts around technology so much, and it's a subject that so many people just don't understand at all, and I think we kinda get suckered into being seen as experts so much that we fall into the trap of thinking we're experts in EVERYTHING. And yet, when you go look at the real experts in our field — Stroustrup, Odersky, Syme, Kernighan, Ritchie, all of those guys — it's amazing how humble they are. I wish more developers would spend more time listening than talking.
But for all that, is there a different industry I'd rather be in? No way, man. Every group or crowd has their Walter who takes things a little too seriously most of the time, shouting "shomer shabbas!" like it's an excuse, but you know what? In this group, he fits in. We don't look twice at him (unless he pulls a gun on us and tells us to mark it a "zero", of course), and that kind of acceptance is just COOL.
What advice would you offer to an up-and-coming programmer?
I wrote on this, too, in Managed Coder: Advice to a New Programmer if you want to see the full thing, but I'll quote from it:
At my first professional programming job working for a startup company named Tangible Vision, I met Hussein Dalmouti, VP of Development, who taught me what I think is the most important lesson a programmer can learn-that of "egoless programming".
Egoless programming's roots lie in the book, "The Psychology of Computer Programming" by Jerry Weinburg, 1971. Weinburg describes a style of development environment relying heavily on peer reviews. He coined the phrase to describe programmers who had worked within this environment for some significant period of time. And at its heart, his philosophy-that code improved when multiple pairs of eyeballs are looking at it and either implicitly or explicitly judging it-sounds eerily familiar to developers familiar with Agile principles and specifically that of pairing.
"But egoless programming means more than just putting your code in front of somebody else's eyeballs for judgment. Over 30 years later, Lamont Adams wrote an article for techrepublic.com in which he laid out "Ten Commandments for Egoless Programming":
Understand and accept that you will make mistakes.
You are not your code.
No matter how much “karate” you know, someone else will always know more.
Don’t rewrite code without consultation.
Treat people who know less than you with respect, deference, and patience.
The only constant in the world is change.
The only true authority stems from knowledge, not from position.
Fight for what you believe, but gracefully accept defeat.
Don’t be “the guy in the room.”
Critique code instead of people - be kind to the coder, not to the code.
I think every young programmer should aim to be an egoless programmer — I think only good can come from following that.
And take a break. Seriously. Step away from the keyboard and do something totally non-tech. Go bowling. Read "The Dude De Ching". Or something.
