Thursday, February 14, 2008

interview with russ tokuhama

russ was the first real hacker that i knew. when i was going through school i was lucky enough to be able to ask russ all kinds of tough questions. he introduced me to emacs and helped me through some b-Tree stuff and even lisp assignments. russ was a lot of help. the great thing about it was that i knew that there were normal people hacking away. the little time i spent with russ gave me a short glimpse into "real world" hacking. it showed me that hackers weren't some nerdy unsocial animal locked in some cubicle typing away.

the one thing that i have tried to do through the years, is figure out away to work with russ on a project. i'm still trying to figure out how that will work, because i can learn a lot from someone like him.

thanks russ for all that you have done to help me get to where i am. i continue to learn from you.

here is how this interview works. the questions that i ask are highlighted in bold. russ's responses are in italics.

What was it about software that drove you to this industry?

As an telecom engineer at the local telephone company in the 80s, we used programs written in BASIC on an HP2000 minicomputer to generate the materials list, labor hours, and project cost for work orders in the switching centers. While these programs speeded up the process of cranking out work orders, there was a certain amount of distrust of their output. Some it was in response to edge cases that didn't make sense but were mandated by the engineering management as acceptable. This fueled a desire to know more about writing and getting programs to work properly.

I took an evening class on programming languages but dropped out due to a heavy work load and because I was totally clueless about programming; the thought process, how to organize things, and language syntax. Try learning Fortran, COBOL, and a couple more languages in an eight-week course after learning BASIC. It seemed like there were too many ways to do things and no clear direction to move in. The good thing was I was introduced to "The Elements of Programming Style" [1]. There seemed to be
some hope of understanding how to fix programs that did stupid things. I wanted to help my fellow engineers get their jobs done and have some higher level of confidence in the programs that they used. It was always frustrating to work with programs that blew up or had subtle errors in their output that you couldn't trust them. Some of the guys that wrote the programs used clever tricks that made it hard to debug their program when things didn't work right. How good is that? By the way, there a few
women engineers but only one was an computer science graduate and did work on some of the programs.

Can you elaborate about the steps that you took that guided toward to software?

When I graduated from college with an Electrical Engineering degree, the only class that I had in programming was in PL/1. We punched 80-column cards, passed the set of cards through a window in the computing center, and waited a day or so for the output; whatever that was (hopefully it compiled and ran). I didn't want anything to do with computers. Who would with that kind of environment?

Ten years later, while working at the local phone company, I took an intro class to programming. We used BASIC on a paper terminal (keyboard and printer in one device; no screen) with a 300 bps dial-up link. The programs that I used for my engineering work ran on the same set-up.

Six years later, I got the opportunity to learn UNIX (The AT&T System V flavor) and C. "The Unix Programming Environment" [2] and "Advanced UNIX Programming" [3] were my bibles. Two coworkers and I wrote a replacement for an aging (no more hardware and software support) realtime system that the telephone company used to send the time and charges for long distance calls to hotels so that they could put them on the guests' bills before the guests checked out. Those were the days of dial-up networking. Of course, "The C Programming Language" [4] was right there, too. It actually took me three years to understand it. Only by diving into a nontrivial project and living and breathing it did things finally start to sink in. I still love C.

The UNIX philosophy of small programs that do one thing right and are composeable resonated with me (think "has-a" in OOP and Decorator pattern). I used a combination of an awk script (precursor to Perl) and a tiny C program wrapped by a shell script to decode the long distance telephone billing tape so that some other programmers could debug and reconcile the normal billing tape processing that ran on the Tandem (fault-tolerant minicomputer) and the IBM (mainframe) systems. There wasn't any easy way to "see" what was on the billing tape so fixing problems in customers' bills was difficult. That was a fun challenge that had clear monetary benefit for my employer.

I also looked at Forth (invented by Charles Moore for controlling large telescopes at observatories; you'll find it in Sun's boot prom). I didn't have a formal background in systems analysis and design so I tried to read as much as I could get my hands on. "Starting Forth" [5] and "Thinking Forth" [6] gave some advice on how to think about and design programs. I didn't program much in Forth but I tried to apply the ideas to whatever language I was programming with. I read Byte magazine a lot. I tried to understand the articles that I read and get ideas from them that I could apply to my programming. "The Mythical Man-Month" [7], "Programming Pearls" [8], and "The Practice of Programming" [9] are some of the books that I've read that have influence my software development and system administration activities.

While working for the local telephone company, I took evening classes in data structures and algorithms using Pascal and completed other classes on software engineering, databases, and systems analysis. I even completed a masters degree in Information Sciences. Since then I have taken other classes in software engineering and operating systems.

While working for the Information and Computer Sciences (ICS) Department at the University of Hawaii at Manoa, I learned Java, Extreme/Agile Programming, Design Patterns, Object-oriented programming, and Test-Driven Development by reading books, articles, wikis, and blogs and by diving in and trying it out. When I graduated from college, a civil engineer agreed to talk to me as kind of a practice interview even though he didn't have any job openings. He gave me the best advice which was that if I thought that I was done learning when I graduated from college I was mistaken. I would have to teach myself and learn what was needed to do my job whatever that was.

1. Kernighan, Brian and Plauger, P. J.; The Elements of Programming Style
2. Kernighan, Brian and Pike, Rob; The Unix Programming Environment
3. Rochkind, Marc J.; Advanced UNIX Programming
4. Kernighan, Brian and Ritchie, Dennis; The C Programming Language
5. Brodie, Leo; Starting Forth
6. Anderson, Anita and Tracy, Martin; Thinking Forth
7. Brooks, Frederick; The Mythical Man-Month
8. Bentley, Jon; Programming Pearls
9. Kernighan, Brian; The Practice of Programming

Wow, that is an awesome journey. It is interesting to compare your journey with the relatively easy journey that students in ICS are taking. It seems that these kids are spoiled, in that they think that taking their 2 1/2 years of ICS classes means that they earn the right to start being a developer. These students probably have no idea what "attack the essence" means or where it comes from. In my opinion, there seems to be real disconnect between school and the real world. Keep in mind that I think the disconnect works both ways. Maybe school isn't "teaching" the right things and maybe the real world isn't embracing the right things. I've said for a while that the students are clueless, but now I'm also thinking that the real world is also clueless. Something seems wrong.

So, here is the next question. Do you agree with my opinion that there is a disconnect between school and the real world?

Yes! One fundamental problem for the disconnect is unrealistic expectations of what the other one wants.

The traditional premise of colleges and universities is to provide students with a foundation from a wide range of disciplines and thinking so that they can use their own heads and tell what is right and what is wrong. In other words, be good citizens. Engineering being an applied science leans more towards having some tie-in with the real world.

I have an undergraduate degree in Electrical Engineering but I don't think that I was really prepared to go out into the real world and do any "engineering work". I had no clue what "engineering work" was. I didn't know what to expect, what was going to be expected of me, or what areas of electrical engineering study that I needed to concentrate on in order to be prepared for a particular company.

My eyes were really opened by a consulting electrical engineer when he told me that his company's work mostly centered on almost rote application of laying out of wiring that meets building code specifications. He was very honest in saying that there wasn't any "design" work in the sense that I would be given a problem and had to design a solution that fit the budget of the building project. My early work with the local telephone company as a switching systems engineer was similar to what he described. I followed industry and company accepted practices. There were standards to follow and stick to.

As far as computer software development goes, if I were graduating from college now I think I'd be in the same state of cluelessness. I wouldn't know what would be expected of me because I wouldn't have thought to ask someone who worked in the industry. This may be one way that the real world can help students and schools. Students can get a clue; not just seniors about to graduate (the usual focus of employer fairs and recruiting visits). Schools can get a clue by listening to what skills and/or conceptual areas are lacking or weak in new graduates that are hired or in their current employees.

Another unrealistic expectation is that the real world can tell students what to study and can tell schools what to teach. The real world has a tremendous variety of jobs and a lot of times a job title or position description doesn't begin to describe what is needed to do the job or what kind of skills or educational backgrounds are needed to be successful in performing a job. Besides, there are many clueless managers and supervisors. What you get from them may be very distorted so should schools or students follow what they're being told? A school can't mold its curriculum to what a handful of local businesses say that they need. What about providing their students with the basics and skills to find employment outside of the local economy?

As you can see, the disconnect is very real for various reasons. While it may seem a frustrating waste of time, having representatives from various employers meet with students to clue them into what would be expected of them may make a difference for some of the students. Advisers and professors may also benefit from this by getting a better feel for that to suggest to students when asked for advice or a least provide contacts so that students can do some investigation on their own.

Internships may be another way to clue students and employers in. They are often sold as a way to give students a peek into the "real world" of professionals but often the business isn't really prepared or able to mentor and develop professionals from students. For example, the lure is "earn while you learn" but when a project or a task needs to be done there's a lot of context that isn't technical but is all about the corporate culture; they way they do things. That can't be imparted in a couple of weeks and it varies tremendously from company to company.

It's not about perks (for example, Google) but the way that things are done, the way that things really get done, and the way that people interact with each other. How are the managers? From the top level to supervisor or even down to the project lead. What are their interactions with other managers and with subordinates? What are the interactions between the subordinates within a group and between groups? The dynamics of personnel interaction are very complicated.

Another difficulty that school has that's different from the real world is the time frame. In the real world, projects have deadlines. But, the project scope and time scale (days, weeks, months, years) are not easily scaled down to a one semester (12-16 week) class. To make things worse, if course content spans two semesters and different instructors, there is more of a disconnect between the two leaving students confused or having no idea how things fit together. Of course, this happens in the real world, too. Projects or tasks get put on hold because of higher priority items. Then, you've got to go back and get started all over again when you pick it up again. The focus should not be trying to duplicate the real world but, instead, trying to make the concepts meaningful to students so that they'll know how to apply them. Business schools use case studies to get students to think about how to arrive at a good solution and not just the right answer when there isn't any right answer.

One thing that intrigued me when I read about it was the ETC, Entertainment Technology Center, at Carnegie Mellon University. Check out: They're claim to fame is a MET (Masters of Entertainment Technology) program that prepares students to work at places like Pixar, Industrial Light & Magic, or Electronic Arts. The thing that sets them apart from others is their close ties and interaction with industry. A number of their faculty come from industry or have worked in industry. They even have a Global Director of Career Services. Check out the faculty at: Carnegie Mellon says that they have a deep tradition of "hands on".

Despite all of this, there's no guarantee that a student will find employment with a company nor that an employer will find a qualified new hire. Only time will tell. The thing that you may notice looking at their faculty page is that where their faculty are now is not necessarily where they had initially set their sites when pursuing their undergraduate degree. Life is what you make it.

So for students going out in to the real world, they need to realize that they are responsible for improving themselves. For employers, they'll need to find ways to help their employees do their best and become the best that they can be. Sounds like the Army (lol) but the reality is that it's about people and people helping one another to do better. The other choice is the bucket of crabs where everyone that
tries to go up gets pulled back down by the others.

Very interesting. Thanks for the great responses. One last burning question.

It seems that we totally agree about the disconnect. So, as a manager how do you tell if a new grad applicant has what it takes to make it? I recently got into a debate about what types of skills a company should look for in a new grad hire. Early on, I thought the best thing to do was look at the applicant's software skills; for example, subversion use, unit testing, refactoring, algorithms, etc. That path got me a little frustrated because I was not finding those skills in new grads. So, I think I switched to looking for smart people that can learn and think outside of the box (thinking that the software stuff can be taught). The realization was surprising for me; I never thought I would think that way. But, I think I'm almost forced to. Its a sad thing.

The question is what kinds of things that you look for in a superstar new grad hire? Or even do those superstars even exist now days? Your thoughts.

Are there superstars? If there's a guy or gal that seems to be a superstar, I tend to be very suspicious. I'd be wondering where their heart at? Are they looking to help or hinder? You want a guy that can fit in with the team. You want them to be able to express their ideas but also be willing to compromise or back off without feeling like they need to get revenge and mess things up. You'd like to be able to trust that they'll get the work done. You'd like to have them care about the work that being done by not only themselves but the entire team.

I just bought "The Pragmatic Programmer" by Andy Hunt and Dave Thomas (first published 2000). I've skimmed it at Borders on several occasions. The first two tips from that book are "Care About Your Craft" and "Think! About Your Work". That's basically what I'd be looking for. They count these as the characteristics of a Pragmatic Programmer: early adopter/fast adapter, inquisitive, critical thinker, realistic, and jack of all trades. I have their Ruby and Rails books and their ideas resonate with me.

I was going to give a list of questions to ask during an interview and a list of things to look for during the interview from the answers that a candidate gives. Since I haven't that means that there's just no formula to follow. You can follow what Joel Spolsky (Joel on Software - Chapter 20: The Guerilla Guide To Interviewing) has to say. But, what we really want to do is get the job done and have fun doing it. So, why not find people who want to do the same? If you get people who don't,
you won't be happy or get the job done.

I do have to qualify things and say that I'm not a manager. I have been on interview committees. I have recommended a candidate for hire provided someone was going to mentor that person if hired. Unfortunately, that never panned out. Since that time, I think I've come around to realizing that mentoring a person is very difficult. It's too easy to micromange them thinking that you know better and even that you know it all (in the context of the job).

[end interview]

my thoughts
if there is on thing that you take away from this interview it is what russ thought was the best advice given to him:

He gave me the best advice which was that if I thought that I was done learning when I graduated from college I was mistaken. I would have to teach myself and learn what was needed to do my job whatever that was.

the other striking thing is that russ still pushes on the learning process. i'm not sure, but i think he doesn't really have a need for ruby on rails, yet he quenches his thirst for knowledge by learning new programming languages and frameworks. he does that because he wants to continually learn (kaizen) and he follows the "Care About Your Craft" mantra!

1 comment:

Randy Cox said...

Very insightful! I like your comment:

"You'd like to have them care about the work that being done by not only themselves but the entire team."

I think caring and earning trust for each other is paramount to a great team.

Thanks for the great interview.