A Time to Never Delegate

I have an important principle for your career; an original insight from TheHackerCIO:

Everyone always stresses the importance of learning to delegate. But it's equally as important to know when NOT to delegate.

Never delegate if you fear you can't do something. Keep the responsibility; own the problem even if you seek out help to accomplish the task. Yes, this pushes you out of your comfort zone, but that's not a problem. In fact, that's the benefit!

If you delegate from fear, you will avoid all of the learning. And today, continual learning is the number one issue. For everyone.

I Remain,

TheHackerCIO

Assholes Revisited

Recently, Joyent, the Node.js corporate side chose to make a public fool of themselves by being assholes about a pronoun. It would be funny if it weren't so perverse, but these paragons of "tolerance" and "empathy" would have no problem instantaneously firing someone for using grammar correctly.

As TheHackerCIO mentioned before, the old-fashioned Grammar pedants were a bit silly, but at least they wouldn't fire someone for a grammatical lapse. The Political Correctness crowd is an order of magnitude meaner, less tolerant, and lacking in empathy.

Naturally, they put this "empathetic firing" forth while linking to  this slideshare, about "Dealing With Assholes." [note: the actual site is called "Assholes are killing your project, but the link in Joyent's blog is called "dealing with assholes."]

I took some time to view the slideshare, because I just had a run in at a client with a major asshole, and so I'm thinking about them quite a bit. I was quite amused to read this slide:

What is an Asshole? Two Tests 

1. After talking to the asshole, does the target feel oppressed, humiliated, de-energized, or belittled?
2. Does the asshole target those less powerful?

I'm pretty sure that  Ben Noodhuis -- the unfortunate, correct grammarian,  would have felt oppressed, humiliated, de-energized, and/or belittled if he had been under the power of UnJoyent and had been summarily fired just before Christmas for grammatically correct use of pronouns. Furthermore, AssholeJoyent.js were indeed targeting those less powerful -- specifically, anyone who works for them.

Then there was this slide:

Word of mouth transforms one asshole into an avalanche

How do you fix it?
    personal interactions: have a conference
    provide expectations: Nobody knows your culture when they start. Do you want them to learn it from an asshole? Provide a code of conduct.

Again FascistJoyent did NOT have a personal, private conference, did they? Instead they published publicly in order to brag about how fascist they were about pronouns. In other words, they skipped the word-of-mouth, and moved straight on to the avalanche. And I wonder if they could provide us with a copy of their code-of-conduct, with proof that it existed prior to their blog-posting, where they specified that use of gendered pronouns was an instantaneous firing offense.

As to my own wisdom about assholes, I'll have to talk more about that another day.

In the Meantime, I Remain,

TheHackerCIO

Fire 'em All!

Joyent will fire you for grammatical incorrectness. They blogged about it here. To insist on principle that pronouns have a gender is an instantaneous, walk-you-out-the-door, firing offense!

And it isn't just Node.js who wishes they could fire for this, but also the employer of the unfortunate offender, who in a much more cowardly fashion said here, that they would fire him, but didn't mean that literally. Except they did. I'll let another commentator describe it:

Quoting Isaac Roth:

If Ben can’t learn, we’ll fire him. [Edit: See comment below. This is not meant literally.]

Huh? How in the world that cannot be literal? You have created a poisonous environment with your coworkers/employees, where they can be held at gunpoint and be told "or you learn, or I'll fire", where learning means agreeing with your point of view, whether is correct or not. If you think you are a leader you are dead wrong.

Your extreme "political correctness" is nothing more than a fascist regime.

TheHackerCIO thought that old-fashioned Grammar-Nazis were a bit over the top, but this newer breed of Politically-Correct-Grammar-Nazis make them look like plush dolls.  Moreover, this is claimed to derive from "empathy!"

If this be empathy, then I call for eliminating it from the workplace.

It's a "zero tolerance policy."

I Remain,

TheHackerCIO

Abolish HR Departments Now!

Little is better than seeing your own opinion voiced independently! TheHackerCIO was thrilled to see one of his own deeply held & radical views put forth by Bernard Mayer, in his article Why We No Longer Need HR Departments.

Euphemism is automatically suspect. At least in my book. Why this ubiquitous change to HR? My father worked where they had a "Payroll and Personnel" department, which is far more honest and straightforward. At least it named a proper and true function for the department. And it was far more concrete and lacked the BS-factor.

Do people really believe that the individuals at their companies are resources? Are they really "Human capital," to be managed along with the "Financial Capital?" And,  perhaps, as interchangeable quantities?

Of course, as one commentator notes, (Kristen),  a lot of the "work" of "HR" departments is really "Submission to the Forced Regulations Imposed by Government." In which case, the department should be honestly named to reflect this. I know that Wall Street firms -- some of the most highly regulated firms in existence -- have departments of "Compliance." I prefer "Department of Submission," but compliance is probably acceptable: it's at least honest, even if too neutral.

But Bernard says it all much more forcefully that I. Well, OK, nearly as forcefully, and certainly with more detailed argumentation. Read him for yourself.

I Remain,

TheHackerCIO

My Work Done My Way

Life always entails the possibility of error. TheHackerCIO, however, learns from his errors. He doesn't "Move on without assigning blame." If he's to blame, he's the first to assess it of himself. Self-honesty is the basis of integrity. 

Even all the experience in the world doesn't prevent error. 

For instance, TheHackerCIO actually resigned from a client contract once! 

He happened to work for one of the stupidest managers ever seen in the technology world, at a BHB -- or Bureaucratic Hidebound Behemoth (AKA a "Large Enterprise"). Not only was this manager as stupid as ever a manager could be: we're talking Dilbertian levels here, but was also, actually evil. Not in the humorous sense of Catbert. Rather, in the sinister manner of a dishonest, and mean-spirited person.

Here's how you can get pushed into doing the wrong thing before you realize it.  Here's the case-study.

I had been assigned the task of documenting a specification for a proposed development project, where the lead developer was not available for consultation. All right, I'm a worker. I do what I'm told.  With no developer to ask, I have to make assumptions. Then, before I know it, there is a review meeting scheduled with the end-user. OK, but I have to get some face-time with the lead developer prior to that. Then, the lead developer, who is working from home and has no time for me comes back and it turns out that a number of assumptions made in the spec are wrong and need to be changed.

Now is the time to inform the manger. So TheHackerCIO levels with this in-duh-vidual. The spec is wrong; the review is tomorrow; and even if I worked continuously from now until the review, I couldn't get the changes documented for the review. We need to reschedule it.

But the manager said, "Just go ahead and review it. We don't have time to reschedule the meeting." 

And this is the point where I made my error.

I thought, OK, I'm a contractor & it's my job to do what I'm told. 

That's an excellent work-ethic, but it misses out a crucial point. One that became clear by retrospective analysis.

Implicit in this demand was a requirement for me to present a known falsehood. It was the most uncomfortable review I ever participated in. I realized, afterward, that it was because I wouldn't lie, yet felt reluctant to be forthcoming about the nature of the document being reviewed. I can damn well assure the gentle reader that I will never do that again. And, as a matter of fact, shortly after that review,  I resigned from the position. I told them that I didn't think I fit in with their way of doing business. That's for sure!

But it's only by doing a retrospective like this that you can learn what you will damn sure never do again.

The lesson brought home a crucial value for me. I want to do my work my way. I won't ever again be pressured into doing someone else's work some other way. And part of doing my work my way is understanding the full spec of anything I program or build. I advise this of any junior programmer: don't program something you don't fully understand. If the spec is lacking, recast it yourself and review it with the other spec-writer, as a means of communicating your understanding of what is to be done & what you will, in fact, do. And don't spec something without being able to talk to the key people. Don't try to do something unless you're actually able to! 

I Remain, With Edge Intact

TheHackerCIO 

E Versus T at a Riot

CEOs in one panel discussed with CTOs in another at last Friday's LACTO Forum. A kind of "E" versus "T." Surprisingly, both groups agreed.

A major discussion point centered around CEOs influence in the company. Especially, about the unintended consequences of their comments. It's almost as if CEOs need to distinguish between ex-cathedra pronouncements, and ober dicta. For those of you who aren't lawyers, and TheHackerCIO hopes that's everyone: ober dicta are statements said in passing -- they are remarks, or observations, -- and are not legally binding. Both the CEOs and CTOs were troubled by how such a passing remark could affect the direction of the team.

If this new direction is not communicated to the rest of the team, then it can result in different people or groups pulling in differing directions. The CEOs were troubled by this unintended consequence. The CTOs suggested that it was the duty of everyone, and especially senior management to re-validate such directional messages across the organization. That way, by enhancing communication, the CTO can at least know if a questionable direction has been posited: he can investigate in private with the CEO, if necessary, and a formal position can then be established for everyone.

The CEOs further lamented that this can even extend to unintended consequences from their seeming enthusiastic about something!

Personally, I've never experienced this problem, but it's good to file away for the future.

The CTOs had an interesting technique for communicating with the CEO about a proposal. So long as it's not wrong headed altogether, instead of saying "no," just say, "OK, but that will take 4 more engineers and we will deliver 4 months later than scheduled." This is an excellent bit of advice, and reminds me of the negotiations used in Agile programming.

The event was hosted by Riot Games, who are awesome -- both for hosting us, and for their well -organized development. They provided a tour to those interested, and TheHackerCIO is always interested in technology tours! This one is particularly heartening, because the Agile artifacts are all up on the walls everywhere you go. Post-its are in particular places to indicate remaining work and burn-down charts track the progress on every sprint. The tour-guide mentioned that in their post-mortem analyses, every time they missed out on cross-functional teams, they had problems. It's kind of cool at Riot that you can see the whole pipeline of their work as you move down the hallway: from creative inception and content development, to more technical elaboration and finally to testing/ playing. They even have simulated cafes -- because many of their game users have their User Experience in a computer cafe.

All in all, a most profitable session!

Why TheHackerCIO Doesn't Outsource

Every week outsourcing companies contact me. I get at least 4-5 emails and yesterday, a colleague I worked with 6 years ago called to offer outsourcing services!

TheHackerCIO doesn't do foreign outsourcing. 

I've heard anecdotal stories about wonderful success with foreign outsourcing. But, frankly,  anecdotal evidence is highly suspect to TheHackerCIO. I listen to it politely. I'm too kind to call they liars. But I don't accept it. Not for a moment. 

Not when I daily see the mess created by one such foreign outsourcer, who: 

• selected a package for the client, of which they use less than 5% of the functionality.
• wrapped JSON in XML-RPC, because they couldn't get the JSON to work end-to-end.
• misspelled variables all over the place, in code from which database column and table names were generated. That is where you CAN NOT fix them without unloading the database, altering the schema, reloading the database, and coordinating this with code changes. I am particularly unforgiving of this, because any decent IDE will flag a misspelled word. But now, these subtle misspellings are potential problems and errors in the code base. For the foreseeable future.

I also managed a foreign offshore team of twenty plus developers on a project for a major financial client on the East coast. When the code arrived to us, it was unusable. We scrapped it, and buttressed our on-shore team to quickly attempt a re-write. Particularly shocking was the fact that even the simple modules were messed up and needed rework. We gained absolutely zip from our foreign outsourcing attempt. 

TheHackerCIO would take the management blame if he deserved it. I proactively attempted to the best of my ability -- and frankly, to the best of anyone's ability -- to ensure that they understood the requirements and the special framework within which the code had to work. But to no avail.

At an LACTO Forum meeting, a specialist on foreign outsourcing told us that to be successful, you had to travel frequently over to the foreign site and spend face-time, do team-building, etc. That doesn't fit into the business model of a small boutique consulting firm. 

So, I believe that it possibly can be successful. Well, OK, I'll leave the jury out on that one. But even if it could be, the only way it could is completely unworkable in the context of my business. So, I'll pass on the Outsourcing. And thank you very much. 

If you depend upon quality, delivery time, or even just actual delivery, I can't imaging a higher-risk approach than outsourcing. In fact, I think the only reason it came into vogue was from Pointy Haired bosses who read about how much money could be saved by doing it. And who never had any success with it any time they ever employed it. 

TheHackerCIO says, "Just say no, to outsourcing."

I Remain,

TheHackerCIO

Where is Your Technology Radar

Today TheHackerCIO is preparing presentations. Tomorrow he'll present on "Your Technology Radar" to a gathering of Chief Technology Officers in Silicon Beach, held monthly at Clearstone Venture Parners. If you're a CTO in the greater LA area, the LA CTO Forum is a great place to learn from colleagues and to get advice about problems or pointers to resources.

Technology Radars are an important tool to keep up with Tech. Invented by Martin Fowler of ThoughtWorks, they are produced twice a year. Lots of developers I work with await the latest Radar release with considerable anticipation. Our local Los Angeles Java Users Group has a weekly book club / study group, which sometimes spends a session discussing Radar items.

The idea, in essence, is to take inventory of all of the emerging technology that the consultants are seeing and getting interested in as part of their field work and recreational work. :-) Then the list is reviewed by the participants and assigned to one of 4 quadrants on a circular graphical display:

• Techniques
• Platforms
• Tools
• Languages & Frameworks

A circular graphic lends itself naturally to the notion of a Bulls-Eye. Accordingly, the outer ring represents an assessment of "hold", and successive inner rings progressively become more positive, ranging from 

• Assess
• Trial
• Adopt

The Bulls-Eye, therefore, consists of those Techniques, Platforms, Tools, Languages, & Frameworks that should be adopted. A further graphical device is used for each "blip" on the Radar screen, to show change by placing a triangle around those "blips" that have changed since the last issued Radar. A circle, by contrast means the item has remained at the same level. To put it all together take a look at an example of one quadrant of a Radar:

And spend some time reading the May 2013 Technology Radar from ThoughtWorks.

The real point is, you shouldn't be depending on ThoughtWorks Technology Radar. Where is your own personal Radar? You need to be the one actively driving this process of systematic evaluation. To read more about this, read this article and, if you're in LA, join the Technology Radar Group and start working on your own Radar.