A very simple way of looking at the world is to consider a binary option. One can put out statements like “there are only two kinds of people in the world…” and make a gross oversimplification of the nuances that is life. With that preface, I’m going to state that there are two kinds of people in the world: hackers and engineers.
Artists and Scientists; Hackers and Painters
When I was a child, my father used to tell me that there were two kinds of people in the world: artists and scientists. Artists, he said, are temperamental and unruly. They do work when they like, slack off when they like. Scientists on the other hand, are methodical, disciplined people. They do work whether or not they like it or not. Being of Asian extraction * Hey, I’m Asian. I’m allowed to make stereotypical comparison of my people , the implication was of course that the artist was to be a counter example of what I should become — the scientist. I should be like a scientist: disciplined, and methodical. I was brought up thus, although as anyone in my family can attest to, I’m the least disciplined of all.
About six years ago now, I came across Paul Graham’s book, Hackers & Painters. In it, the titular essay, Hackers and Painters made a clear connection between hackers and painters. PG argues that hackers are like painters in that they’re both makers of things. And like painters, hackers are often visited by muses, causing work to come in cycles.
In a follow up essay in the book, titled The Good Bad Attitude, PG went further in defining what a hacker does. A hacker, according to PG, are generally disobedient. And this is a good thing, because innovation and disruption can only come from such good bad attitudes.
“Temperamental” (work comes in cycles) and “unruly” (general disobedience) pretty much summed up what my father had called “artist-types”. The comparisons are pretty clear. Except, this was the first time I had read anything that that put these “artist-type” attitudes into good light. I decided that I did indeed fit into that mold called the “hacker”.
In the six years since, I have done a bunch of stuff, and learned a lot more. If you had asked me six years ago, immediately after I had read Hackers and Painters, I’d have told you that people are hackers, or they aren’t. I now think I was mistaken.
Instead, imagine there exists a continuum of personalities dependent upon the level of discipline, or rigour required of one’s work. Over to the left, you would have artists, whose works are relatively free from rigour * see also: post-modernism, and why I keep ragging on it , and over to the right, you would have scientists/scholars, whose work is extremely rigourous. In the middle somewhere, you would have hackers and engineers. Conversely, it can also be seen as the art-science continuum of works. If I were to imagine it in picture form, it’d look something like this:
There are no positive or negative connotations associated with rigour, or lack thereof * Of course, there will be people like Luce Irigaray who could try to claim that I’m making a sexed statement by favouring scientists to the right and oppressing the arts because I labelled it on the left . I use rigour here in the sense of academic rigour. In academia, particularly the sciences, one’s work must be able to stand up to the scrutiny of one’s peers, and there are objective ways of doing so. It isn’t so with being an artist. Using pg’s painters as an example, there are so many subjective ways of determining what is a good painting and what isn’t. I do not get Jackson Pollock, but there are many who do.
Objectivity and subjectivity of the work, in my opinion causes rigour. The more objective the work is, the more rigour is required. Rigour is often associated with words like ‘standards’, ‘rigid’ and ‘bureaucracy’. Indeed, ‘rigour’ shares the same root word as ‘rigid’: ‘rigere’, which means “to be stiff”,
At any one point, one’s personality may fall anywhere into one or more bits in the continuum. There may be days when you feel inspired to create something new. There may be days when you feel like sitting down and researching things that had been bugging you. There are days when you feel somewhere in between, and you just get stuff done.
While much has been said about what hackers are, not much has been said about what engineers are. In part, it’s because engineering is a much older endevour than hacking, it’s been more or less formalized, most usually as a profession, not a psychographic. In this essay, I shall try to describe the psychographics of the engineer.
The Engineer is the Hacker’s evil twin * edited. The original said “Mirror Universe counterpart” instead of evil twin, but I wasn’t sure if anyone would get the reference. I’m not too sure about the connotations of evil twin either . They share some features, and differ greatly in others. Where the hacker despise rules, the engineer loves them (or at least loves creating them). To the engineer, a sense of orderliness is good, while the hacker is perfectly okay with chaos. The engineer starts out with established processes and things, and works towards creating original work, much like scientists as described in Hackers and Painters. Hackers work on things that interest them, while engineers are fine with rote. Engineers are thorough, occasionally overly so.
The engineer does share points of commonality with hackers though — both are makers and both get stuff done. While scientists can totally immerse themselves into research and often go into the deep end * How often have you lost yourself in Wikipedia or TVTropes? , and artists lose themselves in their work of art; hackers and engineers are people who get things done. Yes, both psychographics are prone to yak shaving, but in general, both psychographics try to solve the immediate problem at end.
On the topic of yak shaving, I believe that there is a difference between what artists and scientists do, and what hackers and engineers do. Where artists and scientists get lost in the depths of their work, hackers and engineers who are prone to yak shaving get lost in the breadth of their work. This is a marked difference between painters and hackers, scientists and engineers.
Like the hacker, the engineer is a stickler for details. The engineer’s attention for detail is not driven by a relentless pursuit of beauty, rather, she pursues correctness. She relies on the her knowledge and known conventions to make things. While in some views this would make the engineer a mere implementor without a shred of creativity, I would argue that this is not the case.
Both engineer and hacker tinker and experiment too. They just do it in different ways. The hacker is a freeform tinkerer, while the engineer is a structured tinkerer. Engineers tend to do it in a more methodical manner than the hacker, which is often thought off as more risk-averse than the risk-taking hackers.
Engineers and hackers are essentially alike, and they only differ in methodologies and motivation. My theory is that the level of knowledge determines whether a maker falls into being a hacker or being an engineer,
Scientists were the original hackers. Science as a profession in the earlier centuries, and indeed to the turn of the 20th century were very much undisciplined. Self-experimentation were common — so much that popular fiction has banked upon this as a trope: surely one has heard of the mad scientist?
There is a fascinating book I read once — Guinea Pig Scientists. It is a highly accessible book, and quite well sourced too * If you’re wondering why I read books for children, I must let you know I have a whole collection of Manga Guides to X . In it the authors recalled the tales of famous scientists who were keen self-experimenters. What remained in my memory the most was JBS Haldane, partly because he was actually a well known scientist whose works I have read before. Haldane was famous for self-experimentation. He self experimented to the point where he even went deaf trying to decompress, and suffered some damages to his backbone.
Had Haldane been a computer programmer, he would be writing programs by trial and error, debugging all the way. In short, a hacker.
Rigour came much later in the field of science. As more and more information begun to be shared between more scientists in their respective fields, it became clear that a framework of sorts needed. Afterall, if two chemists cannot agree on the same objectives of their experiment, or what constitutes progress in their work, then what is the point? Soon it became solidified into proper rigour. You must do hypothesis testing to do science, for example.
I believe the same is happening with the computer science industry. As the industry matures, it will become more rigourous. Dave Gelperin wrote an article called The Growth of Software Testing [PDF] in 1988. In it he and his co-author pointed out that software development had went from debugging-oriented development to a demonstration-oriented development (in which a software must be shown to satisfy specification), to a destruction-oriented development (in which the goal was to find errors), to a evaluation-oriented development (in which the goal was to be able to measure quality in software), to a prevention-oriented development (in which the goal was to detect and prevent faults).
Today we find an abundance of rigour on testing software — from BDD to TDD. I would wager that this will only solidify until such a point where there is one common set of rigour, much like hypothesis testing is the backbone of rigour in the sciences.
Where does this leave the hacker? The hacker hasn’t gone anywhere. Rather than treating hackers and engineers as static personality archetypes, I imagine being a hacker or an engineer as a hat that people wear — makers especially so. The difference between the hacker and the engineer is what kind of maker a person is, at the given time and place and situation.
In Hackers and Painters, pg railed against the institutions that makes computer science a science. Hackers just want to hack, not write papers, he wrote. By and large, I think that would remain the same. It is also important, in my opinion to separate the field/profession from the psychographic. Being a programmer does not preclude one from wearing a hacker hat. Neither does being a Nobel Prize winning physicist * Again, were Richard Feynman be a software developer, we’d probably consider him to be the god of hackers .
The hacker’s unruliness as previously pointed out, is disruptive. Refusing to abide by conventions often lead to significant breakthrough.
Linus Torvalds bucked all conventional processes of building software. Instead of carefully crafting software in isolation, he opened it up to the world. As recounted by Eric S Raymond in The Cathedral and the Bazaar, this was shocking.
Even so, Linus is not a sloppy coder. He is in fact quite the opposite. The source code for the Linux kernel is an amazingly beautiful piece of work. There is clearly discipline involved when it was created. One could almost say that he was wearing an engineer’s hat while hacking away at Linux.
Six years ago, I would have said that being a hacker or an engineer were inherent qualities of a person, particularly of makers. I now think that we occupy different psychographics for different fields and for different functions.
Startups do not operate in single fields. For example, a search engine startup operates both in a business field (i.e. running the business and doing business admin stuff) and the software development field (i.e. creating the search engine software).
While startups often operate in more than two fields, I will use these two as an example. Imagine that there are two co-founders in a startup. Both are programmers and are maker-types (which is to say they like creating things), but A has more experience and knowledge than B. B however, has had more experience in running a business. When approaching the business side of things, I find B to generally be the engineer, while A would prefer to hack around and play around. B would know more about the pitfalls from what A would suggest, creating a structure/framework from which the startup ventures. For example, B would know that certain taxes would have to be filed in certain ways, but A doesn’t and would come up with a beautiful but illegal hack.
However, when it comes to the software development side of things, their roles would switch. For example, A would have very good reasons to insist a DVCS like git or mercurial is used, whereas the less experienced programmer might see this as a hindrance to his hacking.
When it comes to a solo bootstrapper, it gets interesting. One could be hacking a piece of code out with the knowledge and self-discipline of an engineer. Or one could be engineering a solution, but exploring the solution space like a hacker does. An example for the former case would be Linus Torvalds hacking the Linux kernel — he was hacking around a fork of MINIX when Linux was created. He did so with a lot of engineering precision * Yes, I am aware that Linus is not solely responsible for the kernel, but he set a very good engineering precedent when he open sourced it and invited users to beta test his kernel . An example of the latter would be Richard Feynman’s discovery of quantum electrodynamics * A well known story by now: He was hacking around with the wobble of frisbees while working on quantum elecctrodynamics. This led to his Nobel Prize. .
The hacker and the engineer, when put in a room and tasked to create something together, will often be at loggerheads. Despite this, I would highly recommend having a good mix of engineer-types and hacker-types in a startup.
Since makers occupy different psychographics (hacker or engineer) depending on situation, this can be put to good use. In fields where there can exist a hacker and an engineer, the hacker serves as fresh eyes to old problems, finding loopholes and interesting fixes, while the engineer serves as a grounding element for the hacker. The tax example from above is a good example of this.
The fact that roles switch depending on context is also a good fact to exploit. pg talked about qualities of empathy required in a hacker. Switching roles is good empathy training. While most of the time the role switch will occur when the startup is in a different operating field (for example, A is a hacker in the field of running a business and an engineer in the field of software development; vice versa for B), it still is good practice if startup co-founders can recognize what roles they’re playing and recognize the need to empathize.
The engineer would feel frustrated that his years of experience goes unheeded by the hacker, and the hacker would feel that her ability to hack is impeded by additional layers of bureaucracy set up by the engineer. When this happen, this would actually be a very good time to empathize with one another — look at the world in the other person’s shoes, maybe walk a mile or two, so to speak.
At this point, I would like to point out that I do not believe everyone to have hacker qualities. There will be always some people who cannot stomach the slightest amount of risk taking or disobedience. There are some people who insist on following rules to a T. These people in my opinion, while they may have a place in a larger ecosystem, do not fit well in a startup. You want people who can switch between being a hacker and an engineer.
On the other hand, if a startup deals with highly mission-critical software (for example things that can cause loss of lives), there should be more engineer-type thinking than hacker-type thinking. I think Mike Taylor’s NASA Supremo analogy is very apt in this scenario. Of course this does not stop a few enterprising hackers to do something crazy with a dynamic language like Python, like controlling 30 tonne heavy equipment with Python.
Hacking is not new. The term is, but hackers have existed for millenia and will exist for millenia to come. From Gallileo to Feynman to Torvalds, there will always be troublemakers who are willing to look outside the box, be disobedient and innovate.
For software, I concur with Paul Graham. We’re living in the glory days of software hacking. But as the industry matures, engineers are starting to rise as a class too. They may not be as glamorous as hacking, but they will be the foundation of software.
Above all, the most important thing is to keep moving. Keep making things. It doesn’t matter if you’re a hacker-type maker or an engineer-type maker. Makers move the world.