The Great Resume Rewrite

I spent all day writing.

But it had to be done.

My work. My way. My resume.

Because MWMW ("My work, done My way") is the Golden Key to happiness. (But we'll blog about about that another time).

I don't have very many regrets in life, but one of them is that I didn't reject the irrational advice and conventions that got imposed on my resume through the years, both by well-meaning and trusted advisors, recruiters, employers, and so forth. That will never happen again. Because from now on, it's MWMY. You know what I'm talking about:

• Ridiculous and contrived stylistic conventions, such as omitting the subject of a bullet point, because that subject happens to be yourself, repeatedly.
• Boilerplate text, cliches, corporate-speak, and management buzzwords. 
• Evasion, manipulation, and "spin."
• Arbitrary length prescriptions.
• A bureaucratic tone attempting convey objectivity and solidity, but in reality conveying stodginess and stupidity.

So I took out my resume, started right from the top and rewrote it straight the way down. I found I had to do in in several passes. Each time I came back to the top and restarted, it got better. And it just keep getting better and better.

I mentioned before, in my post where I resolve to do this rewrite, that I would report back on the results. To quote myself, which seems fun:

Contrarian resume is coming. I'm going to be 100 percent grammatical, spelling out the first person for every one of my many accomplishments. It's all about me, as indeed it should be, being my resume, so "I" and "me" are going to be a major element. (I'll report here later with the final count, so be sure to check back here in a couple of days.) I also will pay no attention to length at all. I will only concern myself with showcasing relevant experience. If I fall one word over to another page, that's the way it's going to be distributed. If it takes 10 pages, so be it. I'm going to highlight my short-term projects, as well, by explaining that the instability was the clients, not mine. I might even mention that I resent them for it.

In short it's going to be fresh, honest, clear, relevant, personal, non-deceitful. It's going to be a blast to write it.

So this is fun time;  review time!

And, there are all kinds of interesting results and things to reflect on, as well! For instance, have you ever noticed how easy it is to just glibly throw out a statement about something you're going to do, and then, later, you find out that "the devil is in the details?"  This coming note is a great example of that, and a good illustration to pass on to management about how surprises often arise, despite our best intentions and often things are not as simple as we always assume.

I realized, in attempting to count my use of "I", the following:

• Simple word-finding/word-counting doesn't work well on the document, because "I" is a letter component of many words, and gets caught by the count programs in places where it should not get counted.
• Me, however, also needs to be counted.
• So also, do contractions, such as:
• I'm
• I'd
• I'll

I ended up hand-counting about 60 self-references using variations of the 1st person-pronoun. So that's pretty good. I imagine that would raise a red-flag with the scanning software that started me down this pathway. 

The length of the resume, including all the relevant material I wished to include ran well over the conventional recommendations.  I hit 4 pages, double the conventional Whiz-dumb. 

Just to establish that these conventions are commonplace, and held even by the best of people, here is what Cracking the Coding interview says -- a book I highly recommend, by the way, not for it's resume advice, but for it's approach to career development and interview questions:

In the US, it is strongly advised to keep a resume to one page if you have less than ten years experience, and no more than two pages otherwise. Why is this? Here are two great reasons:

• Recruiters only spend a fixed amount of time (about 20 seconds) looking at your resume. If you limit the content to the most impressive items, the recruiter is sure to see them. Adding additional items just distracts the recruiter from what you'd really like them to see.

• Some people just flat out refuse to read long resumes. Do you really want to risk having your resume tossed for this reason.

If you are thinking right now that you have too much experience and can't fit it all on one page, trust me you can. Everyone says this at first. Long resumes are not a reflection of having tons of experience; they're a reflection of not understanding how to prioritize content.

As you saw in my former posting, I'm a contrarian about this advice. Does that mean that I'm not reasonable about it? Far from it! Here is the logic of the way I think, formulated into a response to the above:

Yes, I'm in US, and I do indeed wish I could be in the UK instead, where a Curriculum Vitae is commonplace. But since we're stuck with the US, and I agree with your assessment that recruiters, and for that matter, the actual people hiring spend only 20 seconds or less, "looking at [my] resume." I will note a point or two. 

I tend to think that far less than 20 seconds is spent. Probably between zero and seven seconds. I base this estimate on the kind of queries I receive by email from recruiters who have "searched" my resume. Further support for this estimate comes from the number one, almost universal first question which hiring interviewers always ask: "I know I have your resume here, BUT would you please describe your recent experience for me first, before we get started discussing the details ..."  

If I limit the content, as you suggest, the recruiter (or hirer) is still NOT going to see the most impressive items. He's never going to see them. Adding additional items will NOT be a distraction, because there has never been attention focused on the document in the first place. 

Furthermore,  if someone "flat-out" refuses to read a "long" resume -- and I challenge the notion that ANYTHING over a page or two can be, by any stretch of the imagination, considered "long," I want them to toss it. 

I'm interested in working with people who are able to  read, like to read, and, frankly, are not burdened by supporting detail and explanation. By the way, will the analysis documentation and specification of the software I produce be less than a page or two? Does it show a failure to properly delimit, prioritize and hierarchically organize if my documentation is longer than a page or two?

Finally, I would like to address the issue mentioned about prioritizing content. I agree that prioritizing content is extremely important. And for this reason, I do employ the reverse chronological method which is common and conventional. Experience becomes increasingly irrelevant as it ages, and so this approach allows a natural and organic tapering of emphasis. The reader can decide for himself at what point the experience becomes no longer relevant for consideration. Yet he can, if he wishes, follow the logic of the career path back from it's origins. Since this convention has a rationale, I will retain it.

After adding myself back into my resume and adopting a human tone, my resume is such a pleasure to read. I read every word of it out loud to myself before sending it on to the recruiter. The honesty of the whole document is just so refreshing. For instance, here are two of my favorite snippets:

• When this naughty Government Sponsored Entity got caught cooking the books, I was brought in to provide a rules-engine based effort to re-cook those books, by reposting every trade from the bond model to the sub ledger and general ledger.

• Naturally, my on-shore team had to re-develop everything “delivered” by the offshore team. 

I Remain,

TheHackerCIO

Teamwork's Just Another Word for Shifting Blame

Lyrics aren't TheHackerCIO's profession, but I'm sore tempted to write them about the evil Idol of "Teamwork." Perhaps, to the tune of that old standard, "Me & My Bobby McGee." Something like:

 "Shifting blame was easy, Lord, when we were screwed and blued ..." 

Or, 

"Teamwork's just another word for Shifting All the Blame ... "

I know whenever I hear people singing praise to "Teamwork," that 5-9s of the time (i.e., 99.999%, for those of you unused to uptime claims), they are euphemistically referring to a Blame-shifting subterfuge, rather than a productive collaborative effort. 

Recently, for example, Beth Comstock angered TheHackerCIO with her conventional Whiz-Dumb -- so typical of the Bureaucratic Hidebound Enterprise (where TheHackerCIO has unfortunately spent the majority of his career) -- that "There is No Lone Genius; Hire a Team". 

Which, in response, elicited my very popular posting, Never Hire the Greatest Scientist The World Has Ever Known, mostly focused on Newton, but which could just as well be generalized to "Never Hire the Greatest Minds the World Has Ever Seen," and broadened to include many other notables, including Rene Descartes, or, in more modern times,  Einstein, who noted of himself:

"I am a horse for a single harness, not cut out for tandem or teamwork; for well I know that to attain any definite goal, it is imperative that one person should do the thinking and commanding" [ref: here]

Can you envision the HR department interview? So, Mr. Einstein, are you a Team player? 

So many today seem to worship at the alter of the "Team Player." In my experience, the "Team Player," is either one who is too junior to work independently, without senior direction and supervision, or one who wishes to have others involved in his work products, so that blame is either difficult to assess or to attribute to one agent. I can't really see any other advantage to it. 

As the reference cited notes, this also was the belief of Descartes, the founder of Analytic Geometry among myriad other things. He noted in his Meditations, as summarized here, that:

"the works of individuals are superior to those conceived by committee because an individual’s work follows one plan, with all elements working toward the same end. He considers that the science he learned as a boy is likely flawed because it consists of the ideas of many different men from various eras." 

Frankly, anyone can verify these claims very simply: just sit on a committee. Almost any committee will do. But, especially, on a "Steering Committee." You wouldn't allow a committee to steer your car, bus, or plane, but suddenly everyone goes mystically silent when someone proposes the same thing for directing hundreds of millions of dollars worth of technology and equipment. Wreckage everywhere is the result, uniformly. 

None of this means that there isn't value to be found from collaboration. But, the benefit that does accrue comes from and is made possible by the individual achievement of the actors involved. Individual achievement is a "basic." It's a fundamental. It's a basis, on top of which collaborative synergies can layer in and develop. To put that down is to destroy the very underpinnings of achievement. Only an HR department can do that effectively. 

I Remain, With Single Harness, 

TheHackerCIO 

Bookishness & Geekiness

Internally I think of it as "My Geeky Book Club." And so I refer to it with my wife. But, the official name is LAJUG Study Group,  and last night the remaining faithful few finished up the Performance Book:

 Java Performance by Charlie Hunt and Binu John

Now, our group will take a little break, and read a few articles, specifically: 

• Hackers & Painters: by Paul Graham
• The top 9+7 things every programmer or architect should know: by Brian Du Preez

Paul Graham is a Technologist everyone should know about. Read his essays, if you haven't already. The link above will give you a start. He's a successful entrepreneur and now runs Y-Combinator , which is the best incubator for tech startups to get into. Not so much for the money -- you won't get that much -- but for the in-house expertise on starting tech companies, which is incomparable, and invaluable. 

Invaluable, in that it can't be valued, because it's value is too high. That's one of those problem words that always bothers me, because there are other reasons I can think of why something might be invaluable. For instance, working at a multi-billion dollar enterprise is experience that is invaluable: it can't be valued, because it is worthless. They lied about their desire to transform their technology, or at any rate they have no serious desire to step outside of their comfort zone and really accomplish much of anything. So the time spent working there and the experience overall is invaluable. This is another word to put on my list of peculiar english expressions along with inflammable, which means flammable! But we don't want to get confused here and we need to get back to geekiness and books and articles!

After next weeks session on the two articles linked above, we'll move into BDD and Cucumber. My copy has arrived from Amazon, but I haven't imbibed yet. So comments will have to come later.

As to last nights discussion, none of us are too enamored with the Performance Book, so we ventured fairly wide in our chatting.

One early topic was a comparison of several books from the past, and what was learned from them.  I noted that the Azul presentation, in my view, was far superior to this book. I felt that the Azul presentation answered questions and raised my understanding about Java Performance and Garbage Collection. In contrast, while this book answered some questions and improved my understanding somewhat, for everything I learned, I became aware of ten more questions, issues, and conditioning factors, which were NOT explained. Thus I was left with the feeling that in some sense I knew less than what I started with. Yes, I had gained knowledge, but I had gained more awareness of how lacking that new knowledge was than I had gained in new knowledge. This is kind of a difficult point to explain succinctly, but the pattern is: to understand A, you must understand Q, R, S, T, U and V to enter into a proper comprehension of A and it's implications. And here is are a few more details about A. But in the meantime, if you want to know about Q, R, S, T, U, and V, please consult the references at the chapter end. That is the pattern of what I felt from reading through this Performance Book.

By contrast, with the Azul presentation, I learned basic principles, and then saw an analysis of existent JVMs in the context of those basic principles. That's an extraordinarily good structure for any presentation. And it didn't leave me with tons of unanswered nagging problems and issues.

Another member noted that with the Generics book, it had been confusing, and he concluded that the Java community should have "just said no" to Generics.  I've always found them confusing as well. And I prefer keeping a language simple. 

He also noted that with the Concurrency book, while many of the corner cases were disturbing, there were lots of tips and "don't go there" advice that was well worthwhile.

Then there was some discussion about NRU: Not Recently Used. That's kind of interesting, this this is distinguished from the LRU (Least Recently Used) algorithm with which we are all familiar. Apparently, NRU is less precise, but has less bookkeeping overhead. 

Everyone was kind of surprised to learn that with a Java start command (-XX LargePageSizeInBytes) you can alter the page size all the way up to a Gigabyte! Not sure when I'd want to do this, but it's quite interesting. Perhaps an application might be able to tune to page size. Have to think about that one.

On p. 549, we got hit with a countervailing opinion that "pessimistic locking may provide better performance." But the conventional Whiz-dumb has it that optimistic locking will provide better performance. We discussed this for some time and came to see that really it depends on what the statistical likelihood is of lock failure, in your particular environment. If you're likely to fail on a particular lock, then it actually improves performance if you pessimistically lock! But I don't think anyone ever notes this nearly obvious fact, or stops to consider what their particular environment likelihood of failure is. 

So, that wraps up a difficult, demanding, and marginally rewarding read. I'm still a better person for having worked through it. But I would really love to take the Azul presentation and compare it to the Book chapters on the JVM. Perhaps, if Azul provides us with their slides, I'll do that.

I Remain, Ever Reading, and Ever ...

TheHackerCIO

Blued; NOT Screwed!

Blued; NOT Screwed! Which is to say "Zinged"!

TheHackerCIO is fluent in Spanish. So Azul Systems is "Blue" to him. Last night at the LAJUG we were amazingly lucky enough to get a tremendous presentation on Java Garbage Collection from the CTO and Cofounder of Azul Systems,  Gil Tene.

Azul, for those who don't know, make a JVM which, while it costs money, resolves a lot of the performance problems commonly encountered in Java environments.


TheHackerCIO is never tempted to Lionize anyone, or write puff-pieces about any product. What set this presentation apart were the following:

• factual information about all available GCs was the main thrust of the talk.
• Zing (Azul's product) was only mentioned briefly at the end.
• Basic terms were defined, some in cleverly clear ways that made for greater retention
• Basic principles were developed.
• Principles of GC operation were then examined in the context of those basic terms and principles, so that everything was brought into a coherent whole.
• The focus was on understanding the Mechanism, not on explicating the JVM flags. As Gil put it "Once you understand how it works, you can use your brain" to figure out the flags. TheHackerCIO likes that. Always use your brain.
• A lot of misinformation and fallacies were debunked. Turns out, surprise, surprise, the Conventional Whiz-Dumb is wrong much of the time. 

The presentation was so superior to the Performance book, that in my mind it formed a perfect contrasting concrete. If only the Performance book we are studying had been written in this manner, we would have all been happy campers. 

I took pages of notes, and I suspect that I'm going to have to break them out over several days. But, you have to start somewhere. And what better place than his attention step?

He began by claiming that most of what people "know" about GC is wrong. Then he told a story

Early in Azul's history they encountered an application taking 18 second pauses. This was somewhat embarrassing for a pause-less JVM, so they investigated. What they found was that every class had a finalizer that set all instance variable references to null. 

Notice that this is the right discipline for a C++ environment. But it's dead wrong for Java. Dead objects cost nothing to collect! Except, when you put finalizers on them! This is a perfect example of how people fail to rethink new technology in the context of it's own spirit and intent and continue to use it in antiquated, outdated manner. But that is a major topic for yet another day's blog, and was not a topic of Gill's talk. 

So, despite the Conventional Whiz-Dumb:

• GC is extremely efficient. Much more so than malloc().
• Dead objects cost nothing to collect (Except when you put finalizers on them!)
• Those pauses you eliminated from your 20 minute test are not really gone. They just got pushed out to 30 minutes. Your times may vary, but the pause just got pushed out to a later time!
• There will be a 1s per live GB pause. This is not really tunable. The only way around it is Zing.
• No, GC doesn't mean that you can't have memory leaks.

Even I fell for some of these in times past. But this is getting long. 

I would say in conclusion that rarely have I been so impressed by a company's values. The talk we scored came from Azul honoring the commitment of a junior sales engineer to speak to us in October, but who had left the company. In the absence of anyone local to fill in, the Cofounder/CTO hopped on a plane to give us the promised presentation. TheHackerCIO deeply respects keeping commitments and  can't think of a more paradigmatic example. More on GC will follow. 

Stealth is a Thing of the Past

A friend expressed sorrow, the other day, that they had revealed their "idea" at a Hackathon. Now, it was in the public domain. Now the idea was available for anyone to steal.

This was the common, conventional Whiz-Dumb, back ten years ago.

But it's very wrong-headed. It's an outdated way of thinking.

Ideas are easy to generate. They're a dime a dozen. Some are good, some are bad, most are in-between. But none will generate a successful company without an enormous investment of sweat equity. And it's unlikely that anyone is going to invest that amount of work into something that they are not passionate about.

Now, in my experience, the people who pitch their ideas at Hackathons, or for that matter anywhere,  lack sufficient passionate commitment to their own ideas! How easily they give them up. I'm not talking about tweaking them. I'm not talking about pivoting into a slightly different market. I'm talking about completely abandoning one idea in favor of another. This may not, necessarily, be a bad thing, if the idea was not good enough. But it clearly shows that a single-minded commitment to make something, and make it work is a rare commodity! And if even the originator scarcely has it, how likely is it that someone else will steal it?

That's why "stealth"  is a thing of the past.

If you want your idea to succeed, you're going to have to get your idea out there in front of lots and lots of people. The more you hide it away, the less likely you are to engage others in your behalf to help further your idea. Especially in todays tight capital market, where most startups need to be "lean," you're going to need to count on the sweat-equity factor to protect your idea.

You're going to have to accept that others know about your idea, but that they are unlikely to invest their lives in stealing it away from you, because they have cool ideas of their own!

So, stick to your idea (assuming you believe it's good), and prove it out by getting it in front of as many people as you can. If you're lucky, you'll excite enough passion in a few that they will join you and together you can invest your life-blood in making your idea a reality!

I Remain,

TheHackerCIO

Never Hire The Greatest Scientist The World Has Ever Known

Once again, The HackerCIO is ticked. He's reading Beth Comstock's article:

How I Hire: There Is No Lone Genius

Since there is no Lone Genius, there must have been no Newton. And, obviously, no one should ever hire anyone like Newton. It isn't that everything Beth suggests is wrong. But consider how Newton contradicts this popular, conventional Whiz-Dumb. By her standards, one of the greatest, most innovative minds of all time should have been avoided by employers!

I don't know if Newton -- or for that matter, the very notion of the Lone Genius -- is romantic. Maybe the hacker soul isn't compatible with grokking that idea, but I know for certain that Newton was a complete and total lone genius. Experience and research about Newton indicate that his lasting success -- namely, in laying the foundations of modern physics -- resulted not a whit from any collaboration or teamwork. Newton never had any collaborator or competitor who drove him anywhere -- other than, perhaps, crazy. In fact, his competitions with Robert Hook had nothing but a negative effect on him and resulted in a reluctance to publish which only hampered the development of Science. He almost didn't publish his creation of the Calculus because of his competitive experiences.

Plenty of innovation resulted from this loner: The Calculus. The Physical Science of Mechanics. The Physics of Light.  Seems like he'd be pretty useful in a startup. Seems like a man with a biography called "Never At Rest," might have had a decent work ethic. 

Now consider the 4 traits proposed by Beth for hiring, but against the backdrop of Newton:

1) The fish out of water. Newton, the Loner, was the ultimate fish out of water. 

2) Someone who can FIO (Figure It Out).  Again, this non-team-player was the ultimate in FIO, fortitude and creativity. This is an employee who couldn't figure out the Mechanics of The Celestial Universe, so he invented Calculus as a tool. That sounds like the paradigm case of FIO!

BTW, I would never hire anyone who worked for the Peace Corps.

3) Candidates with design training. Newton learned tool-making and doll-house miniature building, as a child. Seems to me like design training. Again, these aren't team sports.

4) The well-balanced player. I doubt if Newton would be characterized as well-balanced, but he certainly balanced his equations! He mastered Calculus balancing it with Physics, as well as Alchemy/Chemistry and Religion. And on the business side he superlatively managed and led the Mint in the project of the complete recoinage of England. Pretty good business administration for a lone genius who never had a friend.

TheHackerCIO hates it when people denigrate the lone genius. Genius of any variety must be celebrated. Hired. Encouraged.  If only we could find plenty of these loners/geniuses. I'd hire every damn one! And he hates it when people worship the false god of teamwork. I hate prejudice against single player sports, too. Tennis is one-on-one competition. That doesn't teach life lessons?  What about the lessons of Golf, where you can play against EVERYONE, including yourself! Now there's a model for corporate emulation!!!

Why is it that while everyone loves innovation, they hate the lone innovator?

I Remain, With Edge Honed,

TheHackerCIO