Show, Don't Tell Me (part 2)

click here for part 1

A midcourse correction is happening on this posting. It doesn't happen often. But I want to get to the point of "Show, Don't Tell Me," without waiting for the whole inductive example from the chapter of the aforementioned book.

Instead, I'm going to separate out the points from that book for a later discussion.

For now, TheHackerCIO wants to explain the awesome power of showing over telling.

There are a few indicators for seasoned technologists. If you don't back-up like a maniac, then you're still not seasoned. And,  if you believe something will work just because someone says it does, or because the manual says so, then you're still wet behind the ears. The principle that captures this is that of "Show, Don't Tell Me."

A perfect illustrative example of this arose this week.

We were working with an unfamiliar device: new to TheHackerCIO, anyway. It was a Magnetic Stripe Card Writer. You know these ubiquitous cards with a magnetic stripe down the back. They follow an ISO 7813 standard of three tracks of data. Our project involves writing on them, which is something I've not done before. It's pretty fun, actually. I printed a picture on the front of a card, and put my name and several numbers of my choosing on one last week.

But this was probably only because I had an experienced engineer helping me out!

As it turns out, the "storybook," as we call the sample program, won't work! The experienced engineer knew what to change, because he's worked on other mag writers. But it simply points out the necessity of calling for a demo.

If you haven't seen a demo from the vendor with your own two eyes, then you've all you can assume you've got is vaporware. Even if you've seen it, you still need to exercise caution about what you conclude, but at least it's a start.

That's why show, don't tell me is so crucial.

And it's also why TheHackerCIO is very dubious about claims found in books and elsewhere. Why is there so little in the way of backing demos for claims about -- well, everything! For instance, in the aforementioned book, the claim is made that:

"Relational databases could also be run as separate servers for different sets of data, effectively sharding the database. While this separates the load, all the sharding has to be controlled by the application which has to keep track of which database server to talk to for each bit of data. Also, we lose any querying, referential integrity, transactions, or consistency controls that cross shards." [reference: p. 8]

There is so much in this statement which is questionable, that I don't even know where to begin. You lose querying capabilities cross shards? In DB2 UDB, the database supports creating what are called partitioning keys. These have to be a primary key, but allow the distribution of certain key-ranges on specific backing devices (device placement), thus improving performance.  Such a tablespace is called a "partitioned tablespace." And there is no problem querying across the partitions. This is essentially the DB2 support for sharding.

In Wikipedia, sharding is defined as "a horizontal partition in a database ..." And in DB2, table partitioning is exactly that: a horizontal partition, based upon Primary key range. The RDBMS, namely DB2, explicitly supports this: there is no application involvement required! The application doesn't have to be aware of where the partitions are placed.

And, as the link above indicates, there is no problem querying across the partitions. Been there, done that. So I can't imagine what I'm missing about the storybook quote. I can't see any loss of querying, RI, transactions, or consistency controls across partitions in DB2.

Now, maybe this author is thinking about Oracle RAC, or some other DBMS. But the point is, there are other RDBMSs than Oracle or Microsoft Fecal Server! There's a whole world out there.

But I'm an open-minded technologist. Show me the problem you are talking about. Show, don't tell me!!! Put up an example of how you lose these features with your sharding, then I'll learn specifically, and precisely what you mean.

I'm going to be calling more and more for Show Don't Tell.

I Remain,

TheHackerCIO

Who Will Interview the Interviewer?

Quis custodiet ipsos custodes? Who will guard the guards?, asked Juvenal. And indeed, TheHackerCIO wonders, when applying for a job, and going through the interview process: 

who will interview the interviewers? 

It's actually more important the interview you do to them, than the interview they do to you. Because they may not be the right place for you to work. They may not adhere to your values. They may be Dilbertian.  In fact, they probably are. 

TheHackerCIO is lucky in this regard. He has a special answer to the question:

The sorting hat will!

He can use his sorting hat, which you are reading this very moment, to interview those interviewers! Those who are irritated by his approach grasp it almost immediately, and can sort themselves out. Out of his life, to be precise. It's his special "pre-screening call," but to be self-performed.

So, for those interested, possibly, in working with TheHackerCIO ...
For those who are considering hiring him ...
For those who may want to interview him ...

You need to go through the sorting hat. Spend some time poking around it.

Start with the FAQ and NAQ.

Be sure not to miss his professional values.

Then consider carefully the questions that arise: will this kind of fellow fit in with our culture? Is he the kind of person I want to have work for me? Should I spend my time and his in taking this further? If you've been sorted, I look forward to speaking with you!!!

I Remain,

TheHackerCIO

The Return of Technology Radar Group

Technology Radar Group

You can't keep a good man (or Meetup) down!

The Technology Radar Group got thrown out of the prior venue, owing to bad behavior of it's members. OK, while true, it wasn't quite as bad as it sounds. There wasn't a riot. People RSVPed to the Meetup and never showed up, which isn't very good manners. And the host, understandably, was upset at it, so they suggested, as Management Speak would put it:

"that the Technology Radar Group seek other opportunities."

So, that's what we did. And we hit on a wonderful one!

iRise, a locally headquartered software development shop has graciously agreed to host the Technology Radar group. We're going to continue with our schedule, as before. The first non-holiday Monday of each month, we will meet. The details, and to join, should you be local, may be found here.

In additional news, because TheHackerCIO is a busy busy beaver, there is now a chapter in Silicon Valley. The venue of that chapter is to be determined. But TheHackerCIO will be spending about 50% of his time in Silicon Valley starting QII 2014, so I would expect the first Meetup to be scheduled then.

So,

• if you're in Silicon Beach, click here for details and/or to join.
• if you're in Silicon Valley, click here for details and/or to join.

And stay tuned as TheHackerCIO will be doing a detailed presentation on Technology Radars, this year. Of course, you won't be able to see it unless you subscribe. So go to the widget now and subscribe to TheHackerCIO, which also gives early and exclusive access to the also forthcoming essays.

I Remain,

TheHackerCIO

Wednesday Returns to Geek Book Club

The LAJUG Study Group, or Geek Book Club, as I prefer to call it has extended me an extraordinary honor, in light of my long-time attendance, and allowed me to dial-in remotely on Tuesday nights, to participate, even though I'm 2,000 miles away.

So, beginning next week, Wednesday will return to reporting on what came from the discussion the night before.

It means TheHackerCIO will have to be up from 10:30-12:00pm, rather than the more palatable 7:30-9:00 -- but hey, he's a night-owl anyway.

The next chapters of the Cucumber book will be discussed.

I Remain,

TheHackerCIO

The Secret Recipe For Dealing With Assholes

A few weeks ago, TheHackerCIO promised to reveal his secret recipe for dealing with assholes.

He used it a few weeks ago himself.

Because at that time, he had a major asshole encounter.

First note the extreme dedication of TheHackerCIO to his work. He made himself available over a holiday weekend for testing and bug-fixes -- trying his utmost to speed delivery of code and shipping of product. A holiday weekend!!!

But, as the old saying goes, "no good deed goes unpunished."

Major Asshole -- who is politically connected, corporately speaking  -- doesn't find it necessary to actually provide a bug report that describes what he expects the Server API call to return and what he encounters instead. He just wants the server developer to "figure it out," on an API he has never before seen and for which he has no documentation.

That's when the power of the secret recipe comes into play.

"Just don't!"

You can't deal with assholes.

As an extremely wise philosopher said, "you can deal with a fool, but you can't deal with a damn fool."

An asshole is the modern term for a damn fool.

So, the secret recipe is to simply walk. And the only way you can do this is if you have plenty of cash in the bank. That gives you the liberating power of not giving a shit. You see, if I had to have the pay from this client, I couldn't have risked it by doing the right thing and leaving the jerk alone with his jerkhood. I would have had to cater to him, try to sooth him, try to placate his irrational jerkiness. And he would have continued to spread it as wide and thick as he could get away with.

By simply not caring; because I could easily miss out on a months billing or more; I was able to walk away until the company came to their senses and found a decent person to perform the testing with.

It's a tremendous power, money. It's not so much about what you can buy with it. It's about the freedom it can buy you. Freedom not to put up with BS. Freedom to walk from the A-holes.

TheHackerCIO doesn't mind sharing the secret. But he knows that only a very select few possess the discipline required to live debt free, as he does, and put away the cash to liberate themselves from stupidity. Most people will continue to deal with assholes, because they have to. And that's a shame.

Don't do it.

I remain,

TheHackerCIO

The 10x Engineer (part 2)

[part 1 may be read here.]

ITWorld linked to TheHackerCIO's blog on "The 10x Engineer", can be read here. Rereading your own posting has a strange feeling. There's always so much more one could have written. But there is only so much time in the day for blogging. Or in the night, as the case may be. In fact, my blog postings are written at night, after a hard-days hacking for clients. But I pop in and re-read them quickly before posting, just to try to keep typos at bay.

The additional point I should have made about 10x Engineers are two-fold. First, there are plenty more anecdotal examples I could have specified. At one very recent client, their team-lead/head-developer  (let's pretend her name is Sally, so we can distinguish this anecdote from the previous instance which featured Bill!) easily produces more than all the rest of her team, which is on the order of 10.  I never got a full head-count, for several were remote, so I don't know exactly. But you get a sense of it from hearing the names and adding them into the known quantities in the home office.

The second point, which is far more important, derives from both this example and the previously cited one. In both cases, with Bill & Salley, they each  not only were at least an order-of-magnitude more productive, but also an order-of-magnitude harder workers! Any time I stopped into the office, no matter how late, Bill was hard at work, headphones plugged in, and plugging away. Sally seemed to live at the office, working often until midnight and at least one day on the weekend.

So there's a major cost to being a 10x engineer. You shoulder a great deal of the burden. You become Atlas.



I Remain,

TheHackerCIO

Hacking isn't illegal!

In the media blather about the Target security breach, we once again see ignorance about the term "hacking." The ignorant media seem to think that what the crackers did to Target is hacking. We know, as technologists, of course, that hacking is developing clever code. I suppose we technologists bear part of the blame as well, given that we have things like the "Certified Ethical Hacker" designation for pentesters.

So it leaves us with a complicated dance. On Wikipedia the disambiguation page found here, itemizes three basic meanings:

1. Hacker (computer security): (this is the so called "black hat", or cracker)
2. Hacker (hobbyist): "who makes innovative customizations or combinations of retail electronic and computer equipment." This is more akin to Edison's "muckers."
3. Hacker (programmer subculture): who combines excellence, playfulness, cleverness and exploration in performed activities.

Naturally, this blog follows the sense #3. When TheHackerCIO hacks, he combines excellence, playfulness, cleverness, exploration, and I might add creativity and innovation to the code he creates.

I Remain, offering new clarity,

TheHackerCIO

This is The Sorting Hat!!!

TheHackerCIO's blog is his Sorting Hat.

It separates the diamonds from the dunghill.

Those who appreciate his professional values and reality-focused, brutally-honest approach will adhere to him. Those who don't appreciate him, or don't appreciate his questioning,  such as some unknown members of a certain forum for CTOs in the Los Angeles area, learn from this blog that they should have no truck with him. Because the questioning will never cease. Questioning is fundamental.

Question early; question often; question everything; question assumptions, especially! Because an active intelligence demands it. I should rather question too much, and learn TMI, than timidly fear to raise my voice. I've been accused of many things, but timidity has never been one of them.

There is nothing better in the world than having your own sorting hat for it! So, I love my blog! It's already sorted out a number of people with whom I had mistakenly associated. And now, that mistake has been eliminated. Thank you, O Mighty blog!

Not only a sorting hat, but my blog is now functioning as a resume, of sorts!  I'm sure you've heard of using Github as a resume. And in fact, TheHackerCIO needs to put some code samples out there for that very purpose. This year. But this blog fulfills a similar function: possibly even better. It chronicles my professional life. In another year, a reader will be able to see the range and reach, the breadth and depth of issues and problems with which TheHackerCIO has dealt.

It's almost in need of a jingle, similar to that of the Wall Street Journal, whose motto is "The Daily Diary of the American Dream." Mine ought to be, "The daily professional journal of an exceptional senior technology executive, who is in love with his work." Just doesn't seem catchy, though.

I Remain,

TheHackerCIO

Outsourcing Allegedly Reinvented

This should be fun! TheHackerCIO was contacted recently with a reasonably intelligent query about outsourcing from a foreign-outsourcer. Surprising isn't it? The claim from this vendor is that I should reevaluate my opinions based upon their reinvention of the whole field. Now that's a claim that makes TheHackerCIO stand up and take note. After all,  about an entirely different issue, that of working with or for the Big-4, I wrote this, which can be sourced here:

I'm an open-minded guy. Perhaps Accenture, or one of the Big-4 has completely renounced these points I mentioned above and embraced becoming the best technology-defined consulting house in the world to rival ThoughtWorks and other specialized boutiques. But I kind of doubt it. I kind of think that rumors would have spread out in the tech world. And I generally hear rumors ... 

The wonderful thing about full honesty and transparency is that you can state your observations and evaluations based upon them, and if you somehow missed something, you can still be open to learning something new. That's part of being an active learner. But that is, also, a topic for another posting.

The principle of being open-minded, which is a forthcoming promised blog posting, as applied here, means that I could be wrong about outsourcing. There could very well be techniques I know nothing about which "reinvent" the concept and make it workable, profitable, and wonderful. Perhaps I missed something. 

[Before I get onto analyzing this claim, let me observe a few points about keeping confidences. I'm going to put this out as a formal warning, but if you don't tell me something is confidential, then it isn't. That's just the way it works. Always has. Always will. TheHackerCIO always keeps confidences. I love Britain for their development of this principle. I love the writing in snail-mail of "Private and Confidential" which ensured (in better times) that the contents would not be read to another. But you have to tell me, to obtain this confidentiality. And this sales-person didn't. So, I regard the entire contents as open to my blog, subject only to a judicious removal of names to somewhat protect the identity of the writer.]

Now let's see the claim, and then break it down. Here, in courier font, is the email to me about the reinvented outsourcing:

========================================================================
Hi James

Thanks for the candid reply!

I went through the FAQ section and would agree the reasons for your apprehension for the foreign outsourcing.

I believe the solution of the problems you mentioned in the blog gets sorted by the risk free evaluation of 14 days. Those 14 days comprises no documentation but hard core coding. If you are not satisfied with the quality of work, we part ways without any single penny investment from your end!

I would love to share more details if you can give me a slot of 20 minutes where we can discuss and change the notion- "TheHackerCIO says, "Just say no, to outsourcing."

You can also go through the few blogs of ours in your spare time:

<deleted>>
========================================================================

This, then, claims that they have a solution to my apprehensions and offers me a risk-free two-week trial. All they ask for is 20 minutes to explain. I wouldn't feel right using up 20 minutes of valuable time from them without reading their blog postings, to which they pointed me, so I did that. I'm reproducing parts of them here together with my comments.  My comments will be highlighted in yellow:


source: here

7 Excellent Ways to Ensure IT Outsourcing Success

Outsourcing is no more a new concept. Hundreds of companies, startups and large enterprises, have already experienced the benefits of IT outsourcing. By now, many outsourcing vendors have also nailed down processes and innovations to ensure outsourcing success.

Based on our experience of serving thousands of customers worldwide for over a decade, we have found some of the ways to ensure that your outsourcing initiatives are successful.

#1: Coding Standards
Product or a solution development is just a starting point for your IT initiatives. You need to ensure that the IT solution is scalable. At the same time, it needs to be maintainable and therefore, it should be developed using appropriate coding standards. Do confirm with your outsourcing vendors about the initiatives they are taking to ensure high quality of coding standards. Many a times, outsourcing companies pay very little attention to this and leave it to a one off training session to the developers. Our experience tells us that to ensure high quality coding standards from developers, the developers need to be continuously trained and mentored for that. This, of course cannot happen through one training session or even a series of training sessions. The developers need to be trained continuously at the subliminal level.

TheHackerCIO comments: We had that, and it didn't help. They didn't keep them very well and it didn't contribute to successful code delivery.

#2: Documentation
Documentation is one of the most important but often neglected aspect. We have observed that especially with SMEs, documentation is never taken seriously. Do understand how the requirements are captured and documented. The best approach is to capture the requirements through some tool and have documents created through that. This ensures that you and the outsourcing partner are always on the same page as far as the specifications are concerned.

TheHackerCIO comments: believe me, we had plenty damn documentation. They were a CMM level 5 certified crap producer. 

#3: Trial (Really??)
It won’t be an exaggeration to say that you should blindly go for an outsourcing vendor who offers free service trial or money back guarantee. You have nothing to lose in this. In fact, it depicts the confidence of the outsourcing vendor about the quality of service.

TheHackerCIO comments: we had that, and believe me there is still plenty damn to lose (i.e., precious time, missed deadlines) when the useless crap gets delivered.

#4: Technical System Analysis
Many a times, non-technical business owners hesitate to start with IT initiatives because of the obvious apprehension of being not able to come up with a right technical solution. Check with your outsourcing partner if it can offer a System Analysis phase wherein; a knowledgeable Business Analyst understands your business requirements and comes up with a business solution. You can then approve the solution approach before proceeding with the actual development. This can help you get started quickly without having to worry about in-house technical expertise.

TheHackerCIO comments: Oh yeah, having an incompetent business analyst as well as incompetent coders will help. Having a business analyst with a thick incomprehensible accent operating in a bizarre time-zone and without the benefit of any face-to-face time, will produce a superior result. 

#5: Reporting
One of the very important, rather the most important aspect of IT outsourcing is reporting. You feel in a better control of things if you can get a daily update on what has happened through the day. Insist on daily reports. You, as the outsourcer, are entitled to know what your project developers have worked on, how much the project has progressed, if there are any issues and if there are any clarifications required. This can help you ensure that the project is not delayed due to sheer non-communication.

TheHackerCIO comments: The daily status meeting achieved bugger-all, except for making me get into the office too damn early every day, to catch them before they went home for the day. 

#6: Agile Billing
As startups or small enterprises, it is not possible to set aside hefty budgets for IT initiatives. In such situations, flexibility about weekly payments can become very convenient. Check with your outsourcing partner for weekly billing option. Through this, you can ensure weekly deliverables and also not burden yourself with large billing at the end of the project. This will also help you gauge and assess your spend on the project and the value you are deriving out of that.

TheHackerCIO comments: This never was an issue & I don't see that it bears on the crappiness of outsourced deliverables.

#7: Closure Feedback
After every phase closure, ideally the outsourcing partner should ask for feedback – what worked, what did not, what could have been done better and what was really good. While feeling happy about successful implementation is good, it is important that the failures are captured too. This helps in learning and improving in future.

TheHackerCIO comments: Believe me, we gave plenty of feedback: "I've thrown away better code than you delivered."

Do you have any more tips to share based on your experience?

TheHackerCIO comments: Yes, my big tip is this: "Just say no, to outsourcing." Read why here.

========================================================================
source: here

5 Myths Of Application Development Outsourcing Busted

When Small and Medium size businesses look for an outsourcing partner they get into the trap of evaluating outsourcing companies based on technical expertise and hourly rates. Based on our experience of over a decade of serving SMEs with their outsourcing initiatives, here’s our list of the 5 most common myths about application development outsourcing:

#1: Once defined, specifications cannot change

We all understand that in any application development, the specifications need to evolve because of changes in market conditions, user requirement or business requirement. You cannot freeze the specifications to the tee at the very beginning of the project always. Your outsourcing partner needs to be your partner in true sense and must align with the changing requirements.

TheHackerCIO comments: I can't even get decent deliverables when the specs *don't* change. If I change them mid-stream, I'll get crap-squared rather than just crap. Or maybe crap-cubed. 

#2: Resources are always shared unless you pay a high rate

Not true – having a dedicated developer does not always come at a premium. The developer working on your project is your team member and almost like your employee, so should be working solely on your project. This gives him/ her an opportunity to get completely involved in the project, understand it in depth, come up with new suggestions and innovative ideas, understand your business goals and understand your objectives.

TheHackerCIO comments: We had dedicated crappy staff from the outsourcer, it didn't help.

#3: Less control over implementation

One of the most common outsourcing myths is that the outsourcer loses control over the project. This is not true if you, as the outsourcer, have direct access to the allocated resource i.e. the developers who are working on your project. When you work directly with the developer and have a regular channel of communication established with him/ her directly, you can have a complete control over implementation –whether there is any technical issue, usability problem, or possible delay because of requirement change, you will know it upfront.

TheHackerCIO comments: not a myth. If you aren't there, you have no control over what's going on. You can't really know what anyone is doing in coding until they complete it an turn it over for examination. But there is an order of magnitude more control over developers whose code can be looked at while it's a work in progress, than in someone thousands of miles away.  

#4: You have to pay extra for project management, architecture and quality assurance

Outsourcing does not mean that you have to pay for every hour and every minute of each resource and for all the support the resource requires to do his / her job. If the majority of the project execution is being done by the technical developer, then you should get some time of the supervisor and quality auditor for free. Such support resources are shared, required only to intervene for specific items to assist in smooth execution. So as an outsourcer, you should not be paying for the mandatory support eco-system your resources need to execute efficiently.

TheHackerCIO comments: True, we didn't have to pay extra for the PM, architecture, and QA of the crappy, unusable deliverable. 

#5: Teams cannot ramp up, or down

Being a SME, it is quite understandable that changing business requirements can make you change the scope of the application which could require involvement of additional resources at a later stage or for a period when as many resources may not be required. You should have an option to anytime scale up or scale down the team and get the project executed without compromising on quality or timelines and irrespective of the team size, you need to have complete control over the implementation.

TheHackerCIO comments: The teams we worked with ramped up to produce more shit according to schedule. They kept the schedule very well. We just had to redevelop everything on-shore once it was delivered. 

So there you have it – 5 myths busted. The next time you evaluate an outsourcing partner remember hopefully these won’t feature in your list of questions !

TheHackerCIO comments: I'm not so sure that they're busted, and I won't be asking these questions. But that's because I won't be evaluating an outsourcing partner. Outsourcing sucks. 

========================================================================
source: here

7 Point Checklist for IT Outsourcing

Small and Medium size businesses have increasingly leveraging outsourcing for their IT requirements or software product development initiatives. Apart from cost, there are many strategic as well as tactical benefits of outsourcing.

While the benefits are very clear, to get the most from your outsourcing initiatives, here is a 7 point checklist which you can refer to:

#1: Business solution vs. Technology Solution

While looking for external expert help, don’t look just for a technology vendor. You need an outsourcing partner who can understand your business and offer a solution to your business problem and does not come up with merely a technology solution. The firm therefore needs a different talent pool and also a different culture to be able to think beyond technology and about the business.

TheHackerCIO comments: They were crap at technology, so I'm sure they were fully as competent at understanding the business as they were at understanding technology.

#2: Past Experience

You don’t want to be the guinea pig. Look out for an outsourcing partner who has good experience of solving similar business problems using various technologies. The company should be able to demonstrate its credibility and work through some work samples or case studies.

TheHackerCIO comments: I was told that we had prior references within our own company. But nothing was ever seen. Even so, reference-checking is a very limited exercise. No one gives out references that trash them. 

#3: Communication Channels

Transparency in communication can make or break your outsourcing initiatives. Make sure that you have clear and periodic communication and review channels which will help you know the progress, milestones, issues, changes etc. and help you keep the outsourcer informed about your goals and objectives.

TheHackerCIO comments: We had a full CMM Level 5 certified vendor, so believe me we had communications policies, procedures, and bullshit up the wazoo.

#4: Skills and Knowledge

Rather than going with a group tech-savvy individuals, who cannot operate as a team, choose the right team which is a good mix of technical, project management, technology architecture and quality assurance skills.

TheHackerCIO comments: Now I have to interview them all remotely and with thick accents. 

Righty- ho.

#5: Know the Person!

It is important that you get a chance to directly interact with the person who is working on your project. In such case, it becomes as easy as walking to the desk of your team member. While building a personal bond, this also enables you to describe your vision, your goals and your exact requirements to the person who is working on your project. No gaps anywhere!

TheHackerCIO comments:Yeah, I got to know the outsourcer too damn well. 

#6: Hiring Process

Whenever possible, understand the hiring process of the outsourcer. Know how the people are hired and trained. That will tell you a great deal about the kind of people you can expect to work on your project and their capability to assist you with your business challenges.

TheHackerCIO comments: I understood it. They hired the cheapest shit they could find whenever they had a paying client. 

#7: Agility

When your business is new or the product is being conceptualized or you need to quickly respond to your market changes, ensure that you choose an outsourcing partner who can cope up with fast changing requirements. This enables you to quickly take out a feature, test it in market and refine your strategy appropriately.

TheHackerCIO comments: I see no evidence that foreign outsourcers can even do a competent job when business is old and well understood and the market isn't changing. There is even less chance that they can do a competent job with fast changing requirements. 

========================================================================

This concludes the blogs pointed to by this claimant. Nothing has been offered that remotely indicates any reinvention of outsourcing. Whereas I had wanted to investigate, and probably would have spent 20 minutes on the phone, had this sales-person not bothered to point me to these blogs, now it's different. Now, I'm not even willing to waste 20 minutes talking to them. Now they have to email me a justification for how they have "reinvented" outsourcing in a way that will assuage my apprehensions.  Now they're screwed. They promised and failed to deliver, as do all the outsourcers, in my experience.

I Remain,

TheHackerCIO

Techno-Journaling (part 2)

click here for part 1

Now comes the digestion step.  This was the very part that the client didn't grasp and was reluctant to pay for. This is not merely a typing exercise, to write up the notes. If you had a little better handwriting than I, you could probably give the TAJ to a reasonably competent secretary ... sorry ... I forgot those had been done away with ...  you could probably give them to a reasonably competent administrative assistant and get a typed set in short order. Nor, as I told the reluctant client, was this an exercise in calligraphy! The point is to digest the material, question it,  and recast in more precise form, which goes into the client journal (now to be called the CJ).

The formal method is quite simple. One starts with an item in the TAJ. It is weighed: do I grasp this fully, or are there questions? Is there a contradiction between this and something else I came across? Then, all the information contained in the item is rewritten in precise, formal, full sentences in the CJ.  If something is uncertain and such a statement cannot be written, then a precise, formally stated question, or questions thought necessary to be able to enter such explanatory sentences must be entered in their place. I use a special marker for questions in my CJ, prefacing them with a big "Q" in the margin.

At the end of this process, the TAJ's contents are completely covered, and it may be treated as the name indicates: throw it away.

The process represents a systematic method for grasping and wrapping-your-mind around the problems, issues, difficulties, needs, wants, and considerations which otherwise would be overwhelming and take a long time to master. This method reduces the task: Just capture everything you can get in the TAJ. That alleviates the issue of forgetting: the decay function of short-term memory is notorious. Then, those cryptic, telescoped bullet points can be expanded over the next few days into proper, thought out questions or proper thought out formulations of fact. That's huge.

One bit of advice. You should begin the process of transfer from the TAJ to the CJ as soon as possible, because memory will dim over time and you may find that months later you don't even remember what you meant by a particular statement.

Now we can return to the story of the reluctant client who didn't want to pay for a write-up of the notes. That client didn't understand that this is the means by which TheHackerCIO masters the details of the project and moves into a position to offer technology recommendations. It's not optional. It's a way of processing the information. As I said before, this isn't some calligraphy exercise! After the explanation, the client mostly understood, but it reminded me of how much others could benefit from using journals in their own day-to-day work.

This doesn't exhaust the full power of techno-journaling. There are the mastery journals, but that's a topic for another time. I hope you find journaling as useful as I have, but as with everything, your mileage may vary.

I Remain,

TheHackerCIO

If You Like It, Promote It

TheHackerCIO is a trader: he trades value for value. I don't want some piddling money from this blog, so I don't have a "contribute" widget. I don't want to stick it to your privacy by getting ad revenue from attracting you here, either.

So, if you get value from my blog, pay me back. 

How?

Promote it!

Post links to the ones you particularly like in LinkedIn, Facebook, Twitter, whatever social networks you're on. 

I'm planning to promote the blog this year. So help me out.

And while your at it, follow me on @TheHackerCIO

Following me and promoting me is promoting Hackathons, so if you believe in them, please just do it now.

You're also promoting the kind of rational, sane, value-based, and fun technology values that you read here every day.

And I'll consider the pay more than adequate!

:-)

I Remain,

TheHackerCIO