A Headhunter Hoist on His Own Petard

Fridays are unusual.

This morning, particularly so.

TheHackerCIO breakfasted with a Headhunter.

And made him a offer!

Said headhunter was expecting to hunt, but found himself the hunted.

It just doesn't get better than this.

You may wonder why the author of "Why Hackers Hate Headhunters" would like one.

Well this one wanted to understand technology. He asked intelligent questions.  He wanted to meet me face to face. He didn't even text while we ate. He was on time. He was interesting. He was intelligent. He wanted a long term relationship.

In short, he was too good to be a headhunter. So I turned the tables on him, and asked him to consider doing some Business Development on the side for my boutique. We need people like that.

So the upshot is, that the Engineer -- or in this case -- Recruiter was hoist on his own headhunting petard, which is great sport, according to Shakespeare.

I Remain,

TheHackerCIO

The Apostle of Conceptual Integrity

Conceptual Integrity Part 2

[note: Click here to read Conceptual Integrity Part 1]

TheHackerCIO bit off more than he intended.

After yesterdays post about Conceptual Integrity, he rummaged around the library to dig out The Mythical Man Month, that classic Geek tome by Frederick P. Brooks. While I was at it, I realized that I bought, but never finished reading his follow on work, The Design of Design.

I last read the Mythical Man Month on it's 20th anniversary -- 1995. And the Second edition features an essay in which he notes that the Central argument (of the whole book) is Conceptual Integrity! And, indeed, following the index, there are 13 entries. There are 15 more in The Design of Design. And far from repudiating the idea as outdated, he states in that essay that "Today I am more convinced than ever. Conceptual integrity is central to product quality. "

So, the series is going to have to be lengthier than I had initially imagined. This topic is one of the great ones, and it enters into direct opposition to some rather highly touted modern approaches, namely so-called "Patterns" and "Pattern Languages," and certain agile and TDD approaches, which explicitly reject attempts to architect things, and prefer to write something that "works" and slowly refactor it into a final product.

Today, I'll just put forth the minimal essence of his theory. I can simply use his 2nd anniversary chapter "Propositions of the Mythical Man Month: True or False," which he abstracted and condensed to challenge people to examine and test. I count 7:

• A sharp team is best -- as few minds as possible.
• A team of two, with one leader, is often the best use of minds.
• Conceptual integrity is *the* most important consideration in system design.
• To achieve conceptual integrity, a design must proceed from one mind or a small group of agreeing minds.
• Separation of architectural effort from implementation is a very powerful way of getting conceptual integration on very large projects [Small ones too].
• If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs no apology.
• A conceptually integrated system is faster to build and to test.

Compare this to the propositions of Paul Graham:

• Design usually has to be under the control of a single person to be any good. 
• You can stick instances of good design together, but within each individual project, one person has to be in control. 
• After the talking is done, the decision about what to do has to rest with one person.
• A lot of the most famous scientists seem to have worked alone. 
• Design by committee is a synonym for bad design.
• Good design requires a dictator
• Good design has to be all of a piece
• If a design represents an idea that fits in one person's head, then the idea will fit in the user's head too.

Forthcoming: Part 3

I remain,

TheHackerCIO

Conceptual Integrity Part 1 ... or Why Committees Can't Do Doodly

Last night at DevTalk LA (that Geeky local book club), having finished our book, we read two articles. We do this in-between books, to allow members a little extra time to get the book in-hand. Next week, we'll start the eagerly anticipated RESTful Web APIs by Richardson & Amundsen.

Add caption

RESTful Web APIs

This book appears to be a complete rewrite of their earlier RESTFul Web Services (2007). It was, by universal acclamation of Dev Talk LA, one of the better books we've recently read, and advance opinion holds the re-write to take things on the next level and clear up all our questions.

The two articles can be (and should be!) read on-line here:

•  Design and Research by Paul Graham
•  Why Why Functional Programming Matters by Reg Braithwaite

We spent most of the time on Paul Graham's essay.

If you haven't read Paul Graham, you need to stop reading here and get on with it. Buy his book. Read his essays. Just do it. The short-version of why is this: Paul Graham is a twice-successful Startup enterpreneur who built his success upon technical excellence. He's a big proponent of the rapid development he found possible through the use of Lisp, of which his is an advocate and presently is designing/promoting Arc, a Lisp derivative of his own. But there are two additional factors that make him a compelling figure.

First, he's done something other than technology. He's also a painter. And the interplay of what he has learned from both shows clearly in his very insightful and reflective essays. Secondly, he understands, in a very no-nonsense way the value and importance of passion. From last nights essay, for instance, came this timeless quote:

To make something good, you have to be thinking, "wow, this is really great," not "what a piece of shit; those fools will love it." 

Which brings us to the point of today's essay.

Conceptual Integrity.

It's important.

Really important.

Paul Graham gets it, too.

As he puts it, (highlights mine)

Notice all this time I've been talking about "the designer." Design usually has to be under the control of a single person to be any good. And yet it seems to be possible for several people to collaborate on a research project. This seems to me one of the most interesting differences between research and design. 

There have been famous instances of collaboration in the arts, but most of them seem to have been cases of molecular bonding rather than nuclear fusion. In an opera it's common for one person to write the libretto and another to write the music. And during the Renaissance, journeymen from northern Europe were often employed to do the landscapes in the backgrounds of Italian paintings. But these aren't true collaborations. They're more like examples of Robert Frost's "good fences make good neighbors." You can stick instances of good design together, but within each individual project, one person has to be in control. 

I'm not saying that good design requires that one person think of everything. There's nothing more valuable than the advice of someone whose judgement you trust. But after the talking is done, the decision about what to do has to rest with one person.
Why is it that research can be done by collaborators and design can't? This is an interesting question. I don't know the answer. Perhaps, if design and research converge, the best research is also good design, and in fact can't be done by collaborators. A lot of the most famous scientists seem to have worked alone. [ed. note: see my "Never Hire The Greatest Scientist The World Has Ever Known"] But I don't know enough to say whether there is a pattern here. It could be simply that many famous scientists worked when collaboration was less common. 

Whatever the story is in the sciences, true collaboration seems to be vanishingly rare in the arts. Design by committee is a synonym for bad design. Why is that so? Is there some way to beat this limitation? 

I'm inclined to think there isn't-- that good design requires a dictator. One reason is that good design has to be all of a piece. Design is not just for humans, but for individual humans. If a design represents an idea that fits in one person's head, then the idea will fit in the user's head too.

I wanted to collect these ideas into one place and last night was a wonderful impetus to do so.  But this posting is already too long, so it looks like we have to kick off a series. And what a wonderful topic for a series! Conceptual Integrity. And, I'm very happy to have one of my heroes, Paul Graham, give as forceful and thoughtful a kickoff as could be imagined.

I Remain,

TheHackerCIO

Start With a Soldering Iron

Close followers of TheHackerCIO will know that he's in major retooling mode. Fresh back from Karate in Japan, he's retooling not only his Kata, but his technology. He's donned the white belt for a fresh look at tech from hardware up.

From the basics. The fundamentals.

It was increasingly clear from last year that I needed to get hardware back in my life.  Sitting in our CIO and CTO offices, listening to our classical music leaves us far too detached. We need to get physical, physical. We need to get to the hardware. At the AT&T Hackathon several months ago, the hardware hackers impressed and inspired me with the "wearables" they concocted.  And now, it's easier than ever to get involved with Rasberry Pi -- whatever your age -- and do some interesting hardware/software projects that interact with the environment in interesting ways.

I wish I still had the URL to an essay I read years ago about how to become a "guru" at programming language X. [I no longer remember the exact question, or language, and Google hasn't helped source it]

The advice given, I'll never forget:

1. Start with a soldering iron ...
2. move on to mastering operating systems ...
3. now learn networking ...
4. and assembler ...
5. Start working up the High Level Language Stack. A lot of optionality here. Perhaps:
    C
    Java [forget C++]
    Python
    Lisp

Which short-list gives us a good basis in procedural, and then functional languages. Maybe throw in Prolog for a declarative language.

There are other considerations, of course, but this makes a good overall syllabus. And it's more or less the program I'm embarking on for the next good while.

Bought an Asus laptop as working fodder for the review: I'll start by picking up the new-to-me windows 8 touch-screen nomenclature and interface, then re-partition it to become a dual-boot ArchLinux and Windows box.

I already learned that, unsurprisingly, as CDs and DVDs are increasingly scare on laptops, recovery disks in Windows are now just USB sticks. And, they only take 512M, which easily fit on the 7G stick someone was nice enough to give me at the SCALE 12 conference last month. All of this is good to know, and once again, helps keep everything real.

Keeping It Real,

TheHackerCIO

WhiteBelt Ninja

Karate has increasingly influenced TheHackerCIO's approach to work. Now freshly returned from training with the Grandmaster in Japan, where I achieved Ichi Kyu (1st Degree Brown Belt, one rank below Black Belt), and where my daughter also made Shodan (Black Belt), there is a tradition enforced at our Dojo which speaks volumes.

A new Black Belt must spend the first month wearing a White Belt.

That's right. You line up in belt-order back at the very beginning. The place where you entered. It isn't so much about "humbling," you, or keeping you from getting "puffed up."

As the GrandMaster says, "Black Belt means now you learn *real* Karate."

And, in essence, it's time to rebuild all your skills from the basics on up  -- reworking and retooling them in accordance with how you *should have* learned them in the first place, had you known then what you know now.

I'm experiencing a little of this just as an Ichi Kyu. And so, I took advantage of the fact that my training journal -- now 4 years old -- was notably lacking in pages; not to mention the fact of my newly achieved level, to establish a new training journal and Commonplace Book.

I haven't blogged about Commonplace Books -- they are really just an advanced journaling technique (that, interestingly, derives from ancient traditional learning methods dating back to the Greco-Romans and that were commonly employed up through the Age of Enlightenment) They make an excellent organizational device that improves techno-journals and they very easily coexist with regular journals. I'll blog about how to use them one day.

But not only am I using this refreshed mindset to improve my Karate and discipline.

I'm applying what I have learned from Karate to the rest of my life. The discipline must spill over, if it's to have any lasting impact on a life.

So, today, I went out and got a latest book for the Comp TIA A+ Certification. I know, it almost seems ridiculous -- what am I going to go to work fixing computers? But really, every ten years or so, you ought to go back and systematically revise what's been going on in the hardware world.  From there, I'll go back to retool on Java 8, or possibly Linux.

It's great being a White Belt.

Starting From the Beginning,

TheHackerCIO