Are you an Engineer or a Scientist?

I just got done reading an excellent article by Roman Snitko. I agree almost 100% with everything he says. However, I felt that the idea could have been developed and executed better. I’m not writing this because I feel that his original piece sucked. Rather I’m writing this because I like the idea he comes up with and want to see it have an impact. So here’s my shot.

(I should say that some of what I say might disagree with what Roman says. I did say almost 100%.)

The engineer

People tend to associate “engineers” with people who get things done and solve real-world problems. Thus, I feel that Roman’s “dudes” can be thought of as the engineers of the programming community. Engineers are the ones who want to make something and get it in peoples’ hands as quickly as possible. It just so happens that that product is a piece of software.

You can recognize an engineer because they’re usually saying things like “So what if it’s not perfect? It works!” or “That sounds like a great idea, but I don’t think we have time for it.”

The engineer’s biggest weakness is that they seem to not think about much past their current deadlines. Yes, it’s important to meet those deadlines. But you do plan on writing software after meeting those deadlines, don’t you? To make up for this, they must call upon the expertise of the scientist.

The scientist

The interesting thing is that almost every field of engineering has a corresponding field of science. Scientists are people who find better ways of doing things without necessarily considering their practicality. It’s fashionable to talk about how disconnected these types of people are from reality, but the truth of the matter is that engineers can’t do the things they can without scientists. Scientists are the ones who want to build great software. It just so happens that that software is also a product people will use.

You can recognize scientists because they’re usually saying things like “So what if it works? It’s an ugly hack!” or “Software schedules should reflect what needs to get done, not the other way around.”

You might have already guessed the scientist’s weakness: they tend to not get along with deadlines very well. To make up for this, they must call upon the abilities of an engineer who can transform their great ideas into reality.

So who’s right?

This way of looking at things is a bit of an oversimplification though. It’s really not that engineers don’t want to make a great piece of software or that scientists don’t want to make a great product. It’s really a matter of priority. Scientists would rather write a great piece of software than a product. Engineers would rather make a product than a great piece of software.

Unfortunately, both sides are a bit disconnected from reality. In the software world, a great product usually is a great piece of software. It’s also unfortunate that someone who can make both things happen is extremely rare if not nonexistent.

Thus, it is ideal for these two sides to be in a state of healthy conflict. They need to recognize that the other side has a point sometimes (as hard as that can be).

So which one are you? And how do you work with the other side?

Pimp my Interactive Interpreter

A couple of things that bother me about Python’s interactive interpreter:

  • Having to import commonly used modules like sys.
  • Not having history stored across interpreter sessions.
  • No tab-completion.

Of course, things like iPython and bpython help, but I generally prefer just a plain old python interactive interpreter session. Plus, the above three problems are easy to solve without installing any extra packages, but the way to solve them is documented in somewhat obscure locations. The solution?

First, create a file somewhere with the following text (I save mine to ~/.pystartup):

import atexit
import os
import readline
import rlcompleter
import sys
histfile = os.path.join(os.environ["HOME"], ".pyhist")
except IOError:
readline.parse_and_bind('tab: complete')

atexit.register(readline.write_history_file, histfile)
del os, histfile

Then, you just need to add a line to your .bashrc, .zshrc, or whatever else your shell uses:

export PYTHONSTARTUP=~/.pystartup

…and viola! Your interactive interpreter has just been pimped.

If you’re on Windows, I’m afraid I have bad news. This probably won’t work for you without using cygwin (as you will need readline).

How to Write: A Programmer’s Guide

I love writing. I think I have talent in writing. But that doesn’t necessarily mean what I’m writing is good. To become a good writer, you need to put in work and experience. Here are some things I’ve learned along the way:

Practice makes perfect – It’s indisputable that great athletes like Michael Jordan and Wayne Gretzky have a lot of talent. But that doesn’t mean that they were able to go into the major leagues on their first try. Similarly, you might have talent, but it takes practice to unlock that talent. If you don’t have talent, you can still become good at writing. It just takes more time and patience. Blogs are perfect for this. Rest assured of one thing: if your writing sucks, nobody will read your blog. That’s actually a good thing because that means you can write all the stupid things you want and no one will read them until you get good at writing.

I know you’ve heard it a thousand times before. But it’s true – hard work pays off. If you want to be good, you have to practice, practice, practice. If you don’t love something, then don’t do it. -Ray Bradbury

Write because you want to – How many people have you met that “really needed to start blogging”? Don’t write because you think it’s good for your career or because programmers “need” to have a blog. I write about programming because I love writing and programming. If you love programming but not writing, then chances are your time is better spent writing code.

Love is easy, and I love writing. You can’t resist love. You get an idea, someone says something, and you’re in love. -Ray Bradbury

Just write it down – When you write something the first time, it will suck. Therefore, if it doesn’t suck at first, it hasn’t been written down.

Writing is no trouble: you just jot down ideas as they occur to you. The jotting is simplicity itself—it is the occurring which is difficult. -Stephen Leacock

Edit – In this sense, writing isn’t a whole lot different than coding. When you start coding something, the most important thing is just to start coding and not worry about it being perfect. But no code worth writing is perfect the first time around. You have to test it, break it, and make others read it to see if it’s clear. Writing for humans is no different. You must be as merciless in your writing as you are with your code.

I’m not a very good writer, but I’m an excellent rewriter -James Michener

Naked Came the Null Delegate part 6: The Great Destructor

“Did you think I wouldn’t figure it out?” Seymour asked his new companion.

As she slowed down to enter a critical section, she replied: “Find what out?”

Seymour smiled. She really must have thought he was a null pointer. “You’re one of the unix gang aren’t you?”

His companion visibly suppressed a look of surprise. She denied the allegation: “I don’t know what you’re talking about. Unix? Never heard of it.”

Seymour laughed at her pathetic denial. “Well, since you’re not a unix process, you obviously can handle it if I send you a SIGKILL.”

“Please, Seymour, DON’T DO IT!” his companion exclaimed in sheer horror. Once she composed herself, she asked: “How did you know?”

“Simple. You knew not only which directory I was in, but you also knew what line of the file I was in as well. You’re grep. And this is your bike, find.”

Grep was stunned. Generally speaking, only other members of the unix gang knew about her, much less her bike. There was something else to this Sharpton fellow she couldn’t put her finger on… Just then, the two of them were attacked by vimpires.

Fortunately, grep came prepared. “Reach in my backpack and pull out my :q gun,” she said. Seymour didn’t need to be asked twice. He pulled out a strange-looking, yet surprisingly simple gun.

“It’s not working!” Seymour exclaimed in frustration. Grep already knew what the problem was: “Oh my god. It can’t be. These vimpires have… unsaved changes! I don’t know what to do. That’s the only vim command I know!”

Sharpton had an idea. He set the gun into :help mode. After a few more tweaks, he had it working. He took aim at one of the vimpires. The vimpire disappeared, only leaving a file whose name ended with a tilde. A look of surprise, even horror, came to grep’s face.

“What’s the matter? Can’t understand how a Windows process could do something like this?” Seymour said with a smirk.

“No,” grep said soberly. “These aren’t vimpires. They’re…”

Just then, the creatures disabled viper-mode, an artifact of the long-since assimilated vimpires. The horrific creatures were amorphous blobs that swallowed everything they touched. Then they spoke with a chillingly collective voice. “We are the Emacsen. You will become inferior modes. Prepare to be assimilated. Resistance is futile.”

The Emacsen fired strange, curved projectiles at them.

“Don’t let the parenthesis hit you!” grep warned. “They’ll turn you into one of them.”

“I didn’t plan on it! All these parenthesis are just too ugly.” And yet, Seymour was intrigued by the parenthesis. They seemed to be created by some ancient force, something much older than either he or grep. Then he realized where he had seen the parenthesis before. They were from a fairy tail his mother used to tell him when he was a first-generation object.

“No… they can’t be powered by…” Seymour started to ask.

Grep cut him off. “I’m afraid they are. Some time ago, Darth Stallman, the Great Destructor, was able to harness the power of Lisp which he used to create the abominations that are before us now. Nobody has been able to stop them. They adapt too quickly. Stallman doesn’t even have to compile them. They can modify themselves. Our only chance is to find Grandmaster Steele in JVMland.”

Seymour was livid. “JVMland?! No, there’s no way. I hear they still don’t have true generics there. Or true delegates for that matter.”

Grep was patient. “Yes, well Grandmaster Steele is the only one who can help us harness the power of Lisp to defeat the emacsen. I hear that someone in JVMland is working on a new form of Lisp.”

And so Seymour and grep set out on a voyage to a faraway land. Little did they know what was coming, for Darth Stallman had a plan that was straight out of a child process’s nightmare: he was going to bring about the great segfault.

Coming soon… Part 7!

How to be Creative

Remember what it was like to be a kid? Adults always told me that I could be anything I want when I grow up. And having a strong imagination was considered a good thing. Of course, as an adult, imagination tends to be looked at as a distraction from real work at best.

I may groan about this from time to time, but there’s good reason for this. I can imagine the neatest castle, but it does me no good if I just have enough wood to build a trailerhome.

Here’s the thing though, being creative requires that you unlearn the things that make you a practical adult from time to time. I think this is why creative types can earn a reputation for being so impractical: they are. In fact, it’s part of the job description.

So how does one remain practical while being able to unlock their inner childish creativity? Personally, I’m more concerned with losing my ability to be childish as I age. No matter what you do, there’s always someone to remind you how to be an adult. When was the last time anyone told you that you need to be more immature? Or that you are too practical?

I think the key is to keep in touch with what excites your inner child as you become a wise adult. What can be more powerful than someone with the imagination of a child and the adult wisdom required to make it real?

Caring for your extravert

As an introvert, I really appreciate The Atlantic’s Caring for Your Introvert.  However some statements make me a bit uneasy.  Like this one:

 Extroverts are easy for introverts to understand, because extroverts spend so much of their time working out who they are in voluble, and frequently inescapable, interaction with other people. They are as inscrutable as puppy dogs. But the street does not run both ways.

I don’t think that’s true at all.  I think that introverts misunderstand extraverts as much as extraverts misunderstand them.  As Jung said (quoting from Psychological Types):

Just as the introvert who tries to get hold of the nature of extravert invariably goes wide off the mark, so the extravert who tries to understand the other’s inner life from the standpoint of externality is equally at sea.

You see, extraverts have difficulty understanding introverts because they’re always thinking of them in extraverted terms.  But it goes both ways.  Introverts are constantly analyzing extraverts in introverted terms.

So how do extraverts work? In her book Personality Type: an Owner’s Manual, Lenore Thomson (an introvert) tells a story about how she used to conduct lectures on type. She’d give out a personality test, then pass around type descriptions and invite the students to comment. The introverts in the class would get excited and ask a lot of questions. The extraverts wouldn’t say anything at all. However, all of the extraverts would approach her after class to ask if the type description seemed accurate.

The introverts in the room were happy to take a test, read a description, and come to a conclusion. The extraverts needed an external point of reference to form their conclusions. This is what you constantly see among extraverts. In fact (since the majority of these classes are usually introverted), if she gave the same test again two or three classes later, the extraverts would score evenly between being introverts and extraverts.

This is why extraverts can get so cranky with introverts who don’t talk much. They don’t give the extravert a point of reference to work from.

Another characteristic of extraverts is that they’re constantly aiming for things they see as being bigger than the Individual. For programmers, we can see this by looking at Paul Graham’s essay on great hackers, albeit from a very introverted standpoint:

Business types prefer the most popular languages because they view languages as standards. They don’t want to bet the company on Betamax.

Graham was probably referring to extraverts when he talked about “business types”. After all, I know plenty of geeks who have the same attitude. Here’s the point that Graham is trying to make: great hackers like good languages. Therefore businesses should use good languages to attract great hackers. Extraverts see things a bit differently though. They understand that programmers won’t always want to use the most popular language. And it isn’t that that isn’t important to them. It’s just that they’re putting the needs of the greater organization ahead of the needs of its individual workers.

Introverts might see this behavior as being controlling, and indeed that might even be the case if the extravert sees their behavior as undermining the greater good. But the reality of the situation is that the extravert is putting both their own and the introvert’s needs behind that of the larger whole.

In this case, the extravert would do well to listen to Graham (Graham could also learn something from the extravert, but this is about understanding extraversion). An organization can’t meet it’s goals if it doesn’t have the support of the individuals that work for it. At the same time, one has to admire the extraverted attitude. I’ve seen extraverted hackers put aside their personal desires to choose tools that benefit the organization more than themselves, even if they strongly hate that tool.

One thing that should be noted here: I speak in terms of absolutes (“extraverts do this”, “introverts do that”), but this is bit of an oversimplification. Everyone has an introverted and extraverted side to them, and you might occasionally see introverted behavior from extraverts. Generally speaking, one side is dominant, but that doesn’t mean that one can’t learn to tap into their other side.

Here are a few things an introvert might do to better get along with an extravert:

  1. Phrase things in terms of what the benefit is to the greater organization if possible.
  2. Be assertive. It’s good to learn to get along with extraverts, but do so in such a way that you can still be true to yourself.
  3. Remember, if an extravert is constantly interrupting you to get your thoughts, it means they respect your opinion. Be polite and try to find a way to help them in such a way that they don’t have to interrupt you.

What The Daily means for iPad news

I must admit to being pleasantly surprised by The Daily, News Corporation’s daily newspaper for the iPad. It’s not because of the content. There are plenty of other apps by better established and more reputable news organizations out there. That’s not to say that the content is terrible though. It’s not the right wing drivel (with emphasis on drivel, not right wing of course) that you would expect from the people who brought you Fox News. It’s just that the content is rather light and without very much in-depth analysis.

No, my surprise centers more around The Daily coming from the same people who run MySpace rather than it coming from the same people who bring you Fox News. Let’s face it, News Corp dropped the ball with MySpace. Under News Corporation’s watch, MySpace went from being the top social networking site to being the laughing stock of social networking sites.

That said, News Corp may well redeem themselves with The Daily. The Daily makes the iPad feel like a viable content platform. In short, it’s what the New York Times and all the other big names in news should be doing in terms of iPad content.

What makes The Daily so great? Well, the other players treat the iPad as a glorified newspaper or magazine. They take their content, put it on the iPad, and there you go. But the iPad is capable of doing so many other things than this.

For instance, why are images so… static on every other news app? Ok, you can blow them up. With The Daily, you can pan around on larger images. You can zoom in and zoom out. Some pictures even give you a panoramic view. Or, turn the page and you see a brief video.

What’s even more interesting is the possibilities this brings up. For instance, it might be possible to have a map of a war zone. Or perhaps you could have interactive widgets that help you to visualize the deficit.

Whatever the case, The Daily is a step in the right direction for iPad news apps. Now, if we could just combine its features with great news, I think the iPad would have its next killer app.

Get results

In Joel’s now famous (some might say infamous) blog post about hiring, he asserts that you should look for an employee who is smart and gets things done. Let’s stop and think about a variation of that question now. What should a person, as an employee of a company, do to succeed?

I left a comment on Hacker News that basically boiled down to two things:

  1. Get results.
  2. Make sure people know you’re getting results.

…and that’s it. We can sit and philosphize about the ideal startup employee all day (and I’d probably join in!), but at the end of the day, results are all that matter. Let me expand a bit on these points.

I’m sure the vast majority of programmers winced a bit when I said that “results are all that matter”, while the vast majority of evil bosses patted themselves on the back. Let’s face it, everyone has had that boss who told us to “Just forget all that documentation, testing, version control, and process nonsense and just get things done for Christ’s sake. Results matter, not that bullshit!” Let me be clear: I’m not that guy. I’m pro-documentation, pro-testing, pro-version control, pro-process, and pro-other things I’m not thinking about. I support those things because I want to get results. Not that I necessarily do those things as often as I probably should, mind you.

After all, none of those things are an end in themselves. How often does anyone say “The best part of this commit is the documentation!”? But you should still write documentation because it will help you and your coworkers get results later on.

The second point is something I wouldn’t have included at one point in time. After all, results should speak for themselves, shouldn’t they? Sadly, reality doesn’t work that way, and point 2 oftentimes trumps point 1. Perception is reality. You might have built the feature or service that will make it big for your company. But that doesn’t matter if nobody realizes what you built and how great it is.

One issue that has been brought up is that I should add a third point: don’t be an asshole. I must admit that I’m a bit ambivalent on this subject. It’s not that I’m pro-assholes. I’ve dealt with assholes before, and I don’t want to create that kind of work environment. That said, I think that a person is allowed to be an asshole X% more if they’re getting results. We can debate the value of X, but I say that at a minimum it’s non-zero. Especially if it’s in the name of getting more results.

Thus, I don’t think a third point is necessary. You should be kind to your coworkers as long as you can do so while getting results.

So, to wrap this up, I think this makes a pretty good set of criteria to evaluate your actions as an employee of a startup (or any company!). Are you getting results? And do people know about those results?

An engineering primer for designers

So Michael Lopp wrote an incredible piece on how designers’ minds work.  Now as engineers, let’s be honest:  we need designers.  I have yet to meet any engineers who would disagree with this (and aren’t one of those rare designer/engineer geniuses or aren’t incredibly dumb and disconnected from reality).  I know how hard designers have to fight at times to be heard in an organization that is dominated by engineers.  But at the same time, I know how hard engineers have to fight in an organization that is dominated by designers.

I think the most fundamental disconnect is illustrated by this story in Michael’s blog post:

Someone in charge saw the first working prototype of the product and said, “This looks like an engineer threw it together”, (you nod) and “We need a designer to fix this up” (blank stare).

You: “Fix what up?”

Person in charge: “I don’t know… it just needs to… look prettier.”

Designers who have not yet bolted from this article, yet, are now standing on their chairs screaming at the screen as they read this: “I KNOW THAT GUY.”

Yeah, I know him, too. He’s an idiot, but he has good intentions.

I don’t think this engineer is an idiot. But I could see how one might get this impression. The engineer is probably thinking more along the lines of “What’s wrong with it? Could you give me an itemized list of all the things that are wrong with the design? I’ll have them fixed by the end of the week.”

It helps if you understand that the engineer and the Person In Charge (PIC) almost literally aren’t speaking the same language. What the PIC in this case (hopefully) means to say is “You’re more focused on the engineering aspects of this. Let’s bring in someone who’s more experienced with design who can help you do a better job with the design aspects.” The problem is that this isn’t what the engineer is hearing. The engineer is hearing “You have the job title ‘engineer’, therefore you know nothing about design. We need someone who has the job title ‘designer’, because that job title means that they know everything about design. Things will be so nice once we don’t have to worry about you silly people who are labeled ‘engineers’ messing up the design.”

Hopefully, it’s clear to you why this is a bad thing. But because I’m sure there are others out there who aren’t as smart as you, I’m going to spell out why the engineer feels this way, and I’m only going to use one word to do it: meritocracy. You see, we engineers have this grand delusion that an idea should always be accepted based on its merit rather than who came up with it. If an engineer can come up with a good design, who cares? If the designer can come up with a good engineering design, who cares? If the janitor can catch that off-by-one error that’s making the servers crash, more power to him.

I say that this is a grand delusion not because this isn’t a good ideal to shoot for, but because things aren’t that simple. Where this idea breaks down is probably the subject of another blog post, but it probably isn’t relevant anyway. You’re never going to convince the engineers to give up on their grand delusion anyway. The good news is that you don’t need to. You just have to convince them that you have a role in this grand delusion. Here are a few ways you can do this:

Drop the smug attitude, and (politely!) encourage the engineer to do the same. Let’s face it, the biggest problem that engineers and designers run into is one of ego. I, as an engineer, am just as vulnerable to this weakness as anyone else. Pay attention when an engineer starts talking as though they’re the only ones who know anything about good engineering, and you inferior designers know nothing. Your likely first instinct that you should try to bring them down a notch is almost certainly wrong and will probably only make things worse. Rather, you should stroke their ego a bit to get them to listen to you. Try something like this: “You certainly have an engineering prowess that I’ll never be able to have. But every once in a while, I have ideas that make sense from an engineering perspective. Could you at least humor me a bit?” At the same time, try to avoid doing the same thing. Since you don’t really have any control over what the engineer is saying, imagine them saying the same thing as I pointed out above, but with “designer” substituted everywhere you see the word “engineer”.

Make it clear that you’re here to collaborate with them. For every engineer out there that thinks designers exist solely to add unnecessary but pretty fluff to their software, there exists one designer out there who thinks engineers exist solely to translate their designs into software. Engineers are certainly different from designers, but at the end of the day, we’re both human beings with similar needs. We both hate slow software that crashes all the time. We both like software that we can understand how to use. We both want to make software that people will love. We both like working with people who work with us rather than shoehorning us into some role that they’re forced to put up with.

Try to be an “amateur engineer”. The best designers I work with are ones who can pleasantly surprise me with how well they can contribute to the engineering side of the business as well as the design side. Here are a few miscellaneous things you might try doing:

  • Learn to code, especially in Javascript. You don’t have to become an expert. But you should definitely have some knowledge of what engineers go through on a day-to-day basis.
  • Learn to use version control and code review software. Many times, designers don’t realize how much work needs to happen every time they say “Can you make this 1 px taller?” Now, bear in mind that I don’t expect you to enjoy using something like git, nor do I expect you to be an expert at it. That said, I’m floored when a designer checks changes into git instead of expecting me to do all the boring work and making the interesting decisions themselves.
  • Make suggestions. The next time you hear engineers trying to figure out how to solve a problem they’re facing, make a suggestion. Now, realize that your suggestion probably is every bit as silly as you suspect it is. But that doesn’t make it wrong. In fact, you may surprise yourself. Every once in a while, a non-engineer will say “This may be a silly idea, but why don’t we try doing x?”, and it will turn out to be a good suggestion. But even if it isn’t, hopefully the engineers you work with will be willing to explain why your idea won’t work, and you might learn something.

Try to involve engineers in design decisions. Ideally, engineers should be trying to involve themselves in design decisions as in the last point, but you can’t control other peoples’ actions. The next best thing will be for you to encourage engineers to be more involved in design decisions. Sometimes you run into designers whose workflow consists of two steps: 1) Come up with a few designs. 2) Choose the best one based on an A/B test. These people usually forget step 1.5: ask others what they think. Now the fortunate thing here is that you probably can’t get engineers to get involved in every trivial design change even if you tried. But just as engineers may be surprised if you can offer good engineering advice, you may be pleasantly surprised by the design advice engineers get.

All these things will have the effect of making decisions less about who’s the engineer and who’s the designer, and more about what’s best for the project you’re working with them on. And ultimately, I think that’s a good thing. But if you do things right, you can hold on to your ability to be the designer, while gaining the ability to play engineer when need be. The end result is a designer who is a well respected member of a team, rather than a second fiddle to the organization’s engineers or a smug know-it-all that everyone has to put up with.