Now is NOT the time to write an assembler
(August 4th, 2005)
I’ve interviewed hundreds of people for software positions over the years, but few of them stand out like the guy who wanted to write his own assembler. Let’s call him Bob the Builder or just Bob for short. In the first fifteen minutes of the interview Bob had proclaimed his intent to write a better editor, make system, and assembler. There may have been one or two more, but it was the assembler that stuck with me. For every item on Bob’s list there was a litany of very legitimate and very specific complaints. He was sure he was just the man for the job of rewriting each one. You can say one thing about Bob, it takes a lot of brass to believe you know enough to write a better assembler than the legions of folks who have already done it.
I had a different interview with a “senior” engineer that would never have stuck out if I hadn’t been thinking of Bob. Let’s call her Natalie Merchant or Natalie for short. Natalie was some kind of anti-Bob. She had been working as an engineer for almost 8 years and couldn’t identify one piece of software she was proud of having written. What she did do, however, was proclaim quite loudly that she would never write a single line of code if she could find it for sale or free (with the former preferred due to its generally higher quality). How, I asked, do you determine if a piece of software is suitable for your needs? “It’s not too hard; you can always change what you need if the software isn’t a good match.” When I showed her a piece of obviously broken code she looked at it and said, “it looks like it should work just fine.” Of course Natalie was looking for a job as a manager.
The Bobs and the Natalies of the world, the Builders and the Merchants, represent two extreme world views. They are the build and the buy of the build vs. buy dilemma. I don’t want to try to answer the unanswerable question of who is right, but ask yourself this question: who would you rather have working for you if you ran a software development company? To me the answer is easy: Bob.
Bob looks at software and sees opportunity for improvement. He’s confident he can do it. Natalie just wants to find a way to get the job done and trusts others to do it more than she trusts herself. Bob may never be pleased with the software we write, but he can probably be counted on to at least write some of it. Natalie, on the other hand, may be great at finding creative work-arounds for customer issues, but I don’t think we can expect her to come up with elegant technical solutions. It’s also easier to keep Bob’s tendencies in check. I can always tell him to fix element A and rewrite element B later, but what do I do when I need Natalie to get her hands dirty? Bob may eventually quit if he doesn’t get to rewrite things, but Natalie will never quit (which is much worse). Also, what company doesn’t have something it really does need to rewrite?
To be honest, I’m pretty sure Bob’s eyes were bigger than his stomach and I’m glad we didn’t hire him. People that far out on the edge are a little too far. I am even more glad we didn’t hire Natalie. No matter how hard you try to avoid it some Natalies wind up in every company and the last thing you need is another one. You need at least two Bobs to clean up the mess made by just one Natalie.
The funny thing is that in the years since interviewing Bob people have written a better editor, a better make system and even a better assembler. We’ve seen better search engines and better compilers. Hardly a single piece of technology hasn’t been done over and been done better. I wonder if Bob played a part in any of that.
February 27th, 2006 at 2:46 pm
[…] Managers need to learn to understand the tendencies of the team members. Every team will have Natalies and Bobs and Karls and they will all introduce complexity in their own ways. Some will import complexity, some will write complexity and some will expand upon complexity. The challenge is to learn to spot these tendencies and then to educate them about complexity and how they can work to avoid it. […]
April 26th, 2007 at 7:41 pm
The better assembler isn’t as freakish as it sounds.
Bob may have done some work with mainframes. They already have better assemblers than PC:s, and now bob may want to do samething with PC:s that he was able to do with mainframe.
Some of them should be considered higher level languages than java or C++, while keeping advantages of assembler.
May 1st, 2008 at 10:59 am
This is an awesome post.
May 1st, 2008 at 7:10 pm
There is a weird thing with people in a regular IT department where there are no programmers. They all seem to just search for software and hunt and peck at buttons.
For that stuff I’ve always gone straight for the documentation or manual and just had it right away. If there were parts that didn’t work that well I would just write them. Those IT guys would just search and search for better software or wait with baited breath for a new release.
The world should be taught to program. I’m sure c/c++ is popular enough for it to be taught in schools. I remember learning basic on an apple II. I was screwing around with the hires graphics mode when everyone else was working on the command line projects. Now they teach office and how to use a computer. Stuff that they would teach an elderly person. The real problem is that c/c++ doesn’t have an API. I wouldn’t subject first-time programmers to java because there are just too many things to learn for the code to not still look like gobblygook by the end of the semester. Languages with built-in APIs will be the norm in the future. We will probably be teaching Python to kids some day on their issued iphones or iclones or whatever.
I just hope all new hardware launches with the tools to write software for it for the next 20 years. Look at the Amiga, they made ethernet cards that connected to the scsi port. That is ingenious.
May 1st, 2008 at 10:48 pm
Hi, Bob!
Seriously: I’d prefer if C/C++ is taught by somebody with a clue - and most high school/college intro teachers are not that person. I’d also prefer C/C++ to be your second language - after Lisp, or possibly Smalltalk. (Insert your preferred derivatives for those two)
May 1st, 2008 at 11:02 pm
While I agree with the main idea, here’s some food for thoughts (I’m assuming the very black and white nature of this whole article, since there are some Bob’s who can manage themselves well and some Nathalies that know the intricacies of IT):
Bobs usually don’t work very well in corporate environments unless Nathalies keep them on track. Bob’s are hard workers, because they’re passionate, but they also tend to over engineer or get demotivated on projects that do not challenge their technical skills sufficiently.
Nathalies keep an eye on the bottom line. They want to ‘buy it’ because they know ‘buying it’ is cheaper than ‘writing it’, as long as what you buy matches what you require. They also know Bob’s tend to leave the company when they get bored, therefore leaving their half-finished projects to die or worse.
To be fair, the comparison between Bob and Nathalie should present a competent but overzealous software engineer against an efficient, but slightly technologically deficient, middle manager.
Assuming that Nathalie is as good at project management and strategic IT decisions as Bob is at writing low level code and optimizing complex algorithms, then Nathalie should be a natural complement to Bob rather than an element to avoid at all costs.
So, who manages your Bobs?
May 1st, 2008 at 11:50 pm
That was the most pointless story I have seen today.
May 2nd, 2008 at 12:02 am
The problem with Natalies managing anything is that they are not technically competent and their design decisions will affect the bottom line more in the long run, whether you have Bobs to make up for those shortcomings or just have a newbie with little more technical skill than Natalie has. If you expect Bob to leave because Natalie forces him to use a kludge of random (buggy) tools for development, you should also expect a hard row to hoe when searching for Bob’s replacement.
May 2nd, 2008 at 5:49 am
Okay, I guess I’ll stop writing that assembler then.
If only you had told me three years ago.