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 

The First 2 Iron Laws of Hacking

Everyone has to code in TheHackerCIO's household.  So my teenage daughter has embarked on studying Python. It's kind of a "shop" class for her.

And there are two iron laws I need her to know immediately. Unfortunately, TheHackerCIO will be like Cassandra -- the daughter of Priam rather than the NoSQL database. That is, he is doomed in advance that he won't be believed, although he will speak the absolute truth.

But that's generally the way between parents and children.

The first iron law is: "You didn't backup enough." Back up early; back up often; back up redundantly. If you just backed-up your code, then back it up again. Unfortunately, the only way to really learn this is through sad experience. After losing a complete day's work you will start to see the importance of this. I'm sure all my coding readers will remember their own backup moments. I love my Macbook Pro Retina for it's separate "time-machine" disk. When I mess up, I just go back in time and pull out what I erroneously deleted or otherwise ruined. I never code without it plugged in.

The other iron law of hacking, is "Always Hack Code." If you have left off writing code, then you have left the world of tech relevance. Practice, practice, practice. Practice makes perfect. All those other cliches. As another blogger says, use ABC: "always be coding." Or as github puts it: "Push code every day." They even have a tracker on their Repo, so you can see how well you've met that standard.

If my daughter can get these down early, she'll be ahead of the game.

I remain,

TheHackerCIO

Geeky Book Club Had Neither Me nor a Book Last Night

TheHackerCIO is in crunch mode to meet deadlines for client delivery, so I had to miss my GeekBookClub (LAJUG study group) last night. So, the poor club remained wanting in two essential ways:

• an incredibly brilliant, scintillating commentator, such as TheHackerCIO.
• a book to discuss.

A book club without a book!

A geeky club without a geek! At least, without one normally in attendance.

What a situation.

The club has finished Java Performance and typically reads articles in-between books for a week or two. Next book up is The Pragmatic Programmer on Cucumber.

I'm very sorry I missed the discussion of the Paul Graham article, Hackers & Painters. If you haven't read Paul Graham's essay, you need to stop reading my blog now, go there, and read it. Then read it again. Then poke around reading his other essays.

I'll explain why in another post, or possibly, an essay of my own!

I remain, Hacking in Crunch Mode,

TheHackerCIO

Don't Give Back to the Community!

Mentoring isn't about giving back to the community. It's about taking. Because you take more than you give, when you Mentor someone.

In the Karate dojo, oftentimes a senior student is assigned a junior or beginning student to teach a Kata (stylized "Forms," that teach certain techniques). This is not because the Grandmaster is busy or too lazy. It's because in teaching others you learn yourself.  Not only do you consolidate what you have learned, but you become aware of beginner's mistakes in a way that you might not have focused on before. You start to realize all the small details that you now recognize immediately, and compare them to how puzzling they were at an earlier stage of learning.

Aside from learning, there is the enthusiasm aspect. Working with beginners, you see a raw enthusiasm which you may have lost as you lost your own hunger to attain excellence, and the ever illusive perfection. Seeing an eager beginner tends to reawaken that hunger. And enthusiasm is infectious.  And God knows, we need an epidemic of this -- especially in the hidebound large Enterprise, where loads of "Mere Paycheck Collectors" infest every department, including the technology departments. A  pandemic of passion for work would make the world a better place.

This is why someone recently coined the term "reverse-mentors" to describe the inverse relationship between a Mentor and his protege.

If you're not selfishly getting more out of Mentoring that you're putting in, then you're not doing it right.

I remain, Ever the Taker,

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!