Friday, October 25, 2013

4 Things 4 Your "To Do" Lisp

  1.  For those who have never played with a functional programming environment, an easy way to do so is to use this web-site. It's been around forever; I used it over a decade ago! But it's a very easy online tutorial for the Lisp functional language. It has the additional virtue of learning what you know and what you don't. 
  2. After you've played with this a bit, you'll be in good shape to start learning Clojure. That way, you can get access to the whole ecosystem of Java, while still retaining the best of what Lisp has to offer. Go here for practice.
  3. Use this web site, to learn more about Clojure. 
  4. Break your head against Monads. Google "Monad Tutorial" & work your way through them, in the vain attempt to find one that really explains clearly and simply what they are & why they are so useful & how you're going to get 10x the productivity by using them. When you find one, please let me know. 
If you find me ambiguous about Clojure, it's because I kind of like it, but I find it a steep learning curve. And I haven't been able to get to the power level of that curve yet.  Your mileage may vary. 

Still, it's excellent to break out of your paradigm and explore another language. "A new language a year" is one of the tips I've seen for staying "Technically Fit." So, playing a bit in the functional realms is definitely a plus for getting you out of the Object Oriented world. 

I Remain



Thursday, October 24, 2013

3 Ways to Keep Technically Fit

Q are wonderful sponsors of my Technology Radar Group, so I don't mind plugging them. If I call them Headhunters, I'll get a nasty-gram, so I won't do that. :-) But they do recruit people. In the technology space.  And I haven't seen any irritating spam from them. They sponsor a whole lot of technology Meetups, and for that I'm deeply grateful.

So I didn't mind giving them some advice on how Technical Fitness is at least as important, if not more so, than Physical Fitness. Although, naturally, both should be attended to. Mens sana in corpore sano. But we hear so much more about physical than technology fitness!

So read here about:

 Three Ways to Keep Technically Fit,

by He, Who Is Know As,


The 10x Engineer

Shanley attacks the "Myth" of the 10x Engineer in her blog.

 On the other hand, in Quora, there is an interesting discussion positing the existence of 100x and 1000x engineers.

Is this a myth?

One point Shanley makes is that:
There is no conclusive body of scientific research to suggest that the 10x engineer is in fact a real phenomenon, much less one that provides us with a deep and actionable understanding of the factors, conditions and stipulations of their existence. 
Make no mistake. I'm going to disagree with Shanley. But first, I'll partically agree. There is no scientific research to back up this notion, because controlling the variables is extremely difficult, if not impossible. Also, finding an objective measure of productivity is problematic.

That doesn't mean that the phenomenon is unreal. It means that science -- at present -- is unable to study it. There are plenty of things that fall outside of the purview of the Scientific Method of Experimentation, controlled variables, and double-blind-placebo-controlled systematic testing. Political behavior, for example, cannot be subjected to this, despite the misnomer of "Political Science."

However, as to the 10x engineer, I can cite plenty of anecdotal evidence: while recognizing that this is not scientific, nor an attempt to establish the fact scientifically. Using a concrete example to think about has a lot of positives advantages; keeping our ideas tied to reality being one of the most important!

At one client we had a Programmer/Analyst, Bill, we'll call him, who designed and wrote detailed specifications for approximately 60% of the modules to be developed. The remaining 40% were divvied up between the other 8 team members. And the complexity of the 60% was far in excess of anything found in the other 40%. Bill's were basically the crucial accounting and financials portion, while the rest were less important ancillary functions. Nice to have, but unessential. I got one of these areas -- how to monitor the Oil and Natural gas production relative to the lease provisions and actual cost of production.

That's pretty close to an order of magnitude more work being performed by Bill than by the rest of us. This was borne out by the programming staff who were ramped up on each team to code the final product. Bill's team was close to 20 or 25 (it's hard to specify exactly, because team size is not a constant value in most projects; they expand and contract).  The other teams all put together amounted to about the same.

That didn't mean that Bill was better than us. Yes, he was more productive. He got a whole lot more done than any of us. I didn't really envy him the position. He was the one who was always there late into the evening, while I went home to my wife. He was the one who had trouble getting away even for lunch, or a coffee break, while I headed out to Downtown Subscriptions for a premium Expresso.  But he was also recognized as indispensable to the project. At one point, his rate got increased above ours. But only about 10-15 % higher. Not enough to compensate him for the additional effort required, in my opinion. I don't think Bill was 10x better, whatever "better" means. He wasn't 10x more intelligent, either. But he was 10x more productive, there is 0 doubt.

But I didn't begrudge Bill his extra rate premium. I didn't resent him for the overtime hours. And I didn't envy the security he attained through his work. I merely reflected that with another such worker, the team would have been complete! Of course, it hadn't been possible to locate another such worker. And I don't know of any process or method for so doing. They seem to arise spontaneously. I can assure you that if I had interviewed Bill, I would never have guessed him to be a 10x outlier, in advance. I don't think Google would have selected him; I doubt he was very good at brain-busting puzzles. I don't think that having him write a spec at the white-board would have helped anyone spot the potential.

But Bill's accomplishment I celebrated and uphold to this day as spectacular, inspiring, and praise-worthy. Without it, the team would have needed another ten employees and the product would have been much worse, in accordance with the Cartesian Law that the more minds involved, the less the stamp of one clear integrating plan. [Cf. the Mediations] Why should Bill's accomplishment be denigrated, denied, or claimed to be mythical? The achievement was Herculean, heroic and Heroes should be rewarded.

In contrast, Shanley claims of the 10x Engineer, that:
It over-focuses on the role of the individual and individual contribution in success, reinforcing Silicon Valley’s tendency towards hero worship, elitism and destructive individualism while ignoring the context of situation and privilege.
This is bizarre. How can you possibly "over-focus" on individual contribution, when that is the basis for any collective accomplishment? What is wrong with worshiping Heroes for their accomplishments? What in the world has situation and privilege got to do with this? In the case I used above, "Bill," was in reality a minority and a woman, and hardly came from a privileged background. She was brought in at the beginning, just like everyone else, so there was no situation there. And she was told, "If the client doesn't like you, you're out of here, pronto!," as she related to me at one point. So, I'm sorry, I must have missed out from Shanley how I should not uphold the accomplishments of a minority female struggling against prejudice and stereotypes and yet producing an order of magnitude more work than anyone else on the project!

I'm sorry (OK, I'm not, but it sounds good, rhetorically) but ANY individual accomplishment an order of magnitude greater than the other team members is worthy of hero worship, worthy of considering that person an "elite," and far from destructive. In fact, it is pure inspiration for us to strive toward this as a goal. The more productive we are, the better our lives will be, and the better-off everyone will be.

So please, let's not have any more of this gratuitous attack on the "Lone Genius," or the "10x Engineer."  Let's recognize that there are amazing outliers. Let's celebrate them. Let's be encouraged to emulate them.

[part 2 may be read here.]

I Remain,


Wednesday, October 23, 2013

Cucumber Word salad

Great attendance & surprises indeed last night at the GeekBookClub, more properly called the LAJUG Study Group.

We began the new book: The Cucumber Book, seen above.

It's a bit Ruby-esque, but applicable to Java via the download of cucumber-jvm, which I'll need to investigate.

So, I got my MacBookProRetina loaded up with Ruby as a prerequisite for the Cucumber install, and followed the appendix without serious issue to get a working cucumber installation up to try things out. And I entered the first bits of chapter two's "First Taste," and got the same results.

Apparently, the whole Cucumber/BDD -- or Behavior Driven Development -- is based around attempting to provide a communication tool that can involve business people as well as developers in producing executable specifications.

To begin with Cucumber is a command line tool.

That's cool, to the inner Hacker that constitutes TheHackerCIO, because GUIs are for those who can't Hack. Your mileage may vary.


There is a sort of word salad of technical terms in the cucumber suite, so here is a quick glossary ...

feature is  a flat file that contains plain-text, ordinary language descriptions of one or more scenarios.

A scenario is a list of steps for Cucumber to work through. These scenarios must follow a particular syntax so that Cucumber can work through them.

Gherkin is the name for the syntactical rules required of the scenarios. Gherkin uses keywords such as Feature, Scenario, Given, When, and Then to provide the needed structure to the DSL.

The steps, or step-definitions are where Ruby programs actually get bound to the specification, thus making them executable.

The essential point of all this is to make it possible for business -- that it, non-technical -- people to get involved in writing acceptance tests. That seems like a good thing.

The big surprise in last nights discussion was in one new, first-time attendee. Newcomers are freely and warmly welcomed at our book club; at whatever level and from whatever technology background. And this newcomer was already very familiar with both Ruby and Cucumber!

So, instead of a discussion among people all eager to learn a new technology, we had an interaction with someone who already new and HATED the technology! That was a twist! This person was coming to try to see whether she could be convinced of the value of Cucumber from the Pragmatic Programmer book!

We spent quite a bit of time trying to understand what her issue was with the tool, and we all quite happily viewed a demo of how Cucumber works, which she whipped up for us on her Macbook and ran.

Seeing a live demo on the spot certainly made it a lot easier to grasp the whole essence of Cucumber. It's amazing how much superior a tutorial is to reading, no matter how much I like reading.

So, you'll have to stay tuned for future blog postings to see what we learn about Cucumber and whether it's useful or a pain! No matter what the verdict is, new technology needs to be learned about and evaluated. And so ...

I Remain, Ever Learning, and ...


Tuesday, October 22, 2013

Lucky Startups

Some startups are so lucky they immediately latch onto revenue. They never need to raise capital. I don't know why I can't be lucky enough to stumble upon one of these, but I have colleagues who have.  I know of two: one in NY, where my colleague works night and day to stabilize their technology needs. And another one here locally where I considered taking a perm position as CTO or VP of Development.

And another Stealth startup I know of, I believe, could attain this, if only they could get another 20-30K of Angel investment. They just need a little more code in place and they could start to get the revenue rolling in. They wouldn't be profitable immediately, but they would be well into revenue without serious investment capital.

The Stealth Startup, BTW, is a thing of the past. But I've blogged about that already.

I'm installing ruby in preparation for tonight's cucumber discussion at the GeekBookClub. Details will follow tomorrow.

I Remain,


Monday, October 21, 2013

An MBAhole

Valuing and dis-valuing are two sides of the same coin! To love spicy-hot foods means, inversely, that you don't care that much for bland fare. And so, the passionate values of TheHackerCIO lead quite naturally to an equally strong distaste for some things in the technology world.

One of those distasteful subjects are the many MBAs brought in by the typical Pathological Enterprise (those bloated Behemoths of paycheck-collectors) to direct and manage technology projects. The reductio ad absurdum of this practice is bringing in the The Big 8-6-5-4, a Government Created Financial Oligopoly nominally created to put Official Blessing on company documents. But they have taken it upon themselves to cash in on their unique position by pretending to understand technology as it applies to financial systems. TheHackerCIO can count at least a dozen times where he had to suffer alongside these consultants. His very first experience with them was the waste of a year of his life and career in tending and overseeing a doomed package implementation. Here was where the familiar pattern was first revealed: 
  • Deliverables that were technically in order, but didn't provide the needed functionality.  
  • Dispute with the client about the contract.
  • Project put on hold.
  • Legal takes over.
  • Project failure & cancellation.
I'm not sure if it is technically true, but rumor held that this particular consulting group used their Legal Department as a profit center. And such appeared to be the case, at least on this occasion. 

Why anyone would hire an accountant when they need a programmer is beyond me. Can you imagine a startup doing that? "Yes, Bill, I know you asked for 3 Ruby programmers, but I found these excellent recent graduates of a major, prestigious university who know all about Anthropology, Sociology, and Psychology, and are backed up by an organizational expertise in accounts-payable, accounts-receivable, and inventory-control. Plus, they've all been through a 10 week "boot camp" on how to manage your projects." Yeah, that would fly.

One of their characteristic gambits is the initial use of top-level experts who really know their stuff. But these quickly dissolve into the woodwork and are replaced by ambitious 21-year-olds whose knowledge of technology is about as deep as a kiddie scripter, but who has been trained in a boot camp that methodology can replace expertise in producing results.

The combination of youth and arrogance is typical and particularly ugly. And so, that's why I call this particular phenomenon: The MBAhole.

TheHackerCIO no longer works on projects with MBAhole defined management.

But he will offer free advice to those who chose to do so.

Instead of putting accountants in charge of your technology project management, put your legal department in charge of it. That way, they'll be ready when the project gets closed down.

I Remain,