NT3R

A blog that needs work.

Writing a Technical Book: First Contact

I have never written a book before. This past November I managed to write fifty-thousand words, which is by some measure a novel (hence National Novel Writing Month), but, at best, was the beginning of a story; barely even a first draft. Aside from this annual foray into writing, the thought of writing a book likely wouldn’t have crossed my mind until next November.

But then I got noticed.

It may just be for a technical book, but its still exciting to me. As I said, I have never written a book before.

It’s time to change that.

I’m not (likely) the only person who has wanted to write a book before, and while I can’t argue that what I will learn will apply to all aspects of publishing, I do think that what I learn could be useful to someone. As the process progresses, I’ll be doing my best to explain what goes into publishing a (technical) book.

Before I start, there is some advice from a programmer I admire that I might seem to be ignoring. Yes, it does make more sense to write something for the web and self-publish if you are so interested, but to me, this is a learning experience that requires “less effort” (comparatively) than self-publishing. I imagine that will be a topic for a whole other day though.

For the purposes of these articles, I’m assuming you’ve already decided that you want to take the ‘publisher’ route (vs. self-publishing). That being said, let’s dig into how things have gone so far!

“Book Trek: First Contact”

I was contacted without any prior interest. Because of my work on StackOverflow, I was contacted by a company called Packt Publishing about writing a cookbook on Highcharts, a javascript charting library that I happen to answer a lot of questions about on StackOverflow.

My first thought when this all took place was, “is this legit?”. Certainly, people don’t get contacted at random to write about books, or do they?

Yes, they do. As I tried to curb my excitement (but nonetheless posted for everyone to see) I learned that the same company had also contacted other people I know about writing books on niche libraries. That did deflate my ego a bit, but more importantly, it began a process of asking a lot of questions. Many of the questions I would have would (fortunately) be answered by the publisher’s site for authors and details about royalties, but I nonetheless went out and read as much as I could find on writing a technical book (and I would stronly recommend reading over those articles).

But this is more than just a narrative about how I was contacted, and in no way do I want to leave this process of imagining what questions to ask to the reader: Regardless of whether or not you’re approaching a publisher or they’re approaching you, there are some questions you’ll want to ask yourself about your book:

  • What is this book about? What is it not about? What might it be about?
  • Who am I writing the book for? Who is the audience?
  • What does the reader need to know before hand? What is the reader’s background?
  • What are the most important things that I want the reader to learn about?

For a many of these questions, I already had the answers (an “Author Relationship Executive” provided them through our early communications), or the publisher was kind enough to provide tips and documents to help me flesh out the details of the book; they even included a whole package for authors outlining a lot of details about writing a book, and how their process works. However, there were some questions that I needed to ask the publisher:

  • How much is the advance, and when is it paid out?
  • How much are royalties?
  • What is the timeline of the book?
  • Would I be the sole author of the book?
  • What is the editorial process of writing the book?
  • How will the book be promoted?

Many of these questions were easy for them to answer, and gave much needed context for me. I learned that the advance is paid out based on the progress of the book (1/3 after the first drafts are completed, 1/3 after the final drafts are completed, and 1/3 when the book is published), that they were looking at 6 months for all first drafts to be completed, and a lot of other important details to let me know what I was getting into.

However, given that I still didn’t know a lot about publishing, more research was necessary:

  • How much are royalties / advances typically?
  • Is this a good publisher? Have other authors had problems with them in the past?
  • Is anything deducted from royalties?

There are likely other questions that you’ll have, but they can always be answered further down the line. This is just a chance to ask questions before really digging into the book. This isn’t about setting things in stone, it’s about getting an idea of what the book is and getting a feel for the publisher and publishing process

And, while this information is all great, you might be wondering what to do if you haven’t been contacted by a publisher. From what I’ve found there are at least two other publishers who (fortunately) include details about becoming an author with them: O’Reilly and Apress.

“The Outline Limits”

After I’d had the chance to ask a few questions, I (and likely the publisher) was be eager to continue on with the process. The acquisitions editor let me know that the next step was to fill out some information about myself for the publisher, which I suspect was for some sort of proposal or to let them know what else I could write about in the future, and to prepare an outline for the book.

This seemed like a reasonable request of me. I quickly learned it was not.

Writing a book is hard work; that is not surprising to me. However, writing a cookbook-style book is different than writing an ‘ordinary’ book: Cookbooks have recipes. Recipes are easy to write, but writing an outline for a cookbook is hard because you need to know the recipes before you write the book. Writing the outline meant that I needed to think up all the scenarios that a person may want to use or integrate Highcharts into their project. Yes, they had suggested a few topics, but it is still very difficult to imagine how someone might use a special purpose library: we’re not talking about a language, or a framework, but a tiny little library that makes really cool charts.

He had suggested three working days to submit the outline, and given that I was busy, I didn’t put much thought into it at the time. When I actually sat down to write it, the outline took me nearly fifteen hours to write. Is that indicative of all outlines or projects? No, certainly not. It does illustrate that its important to give the outline some thought. Fortunately, I imagine that the actual writing of the book should be more straightforward since all the recipes are decided.

At this point, a schedule was suggested, basically a draft of each of the twelve chapters every two weeks. Is this reasonable? I don’t really know. What I did learn is that the publisher is usually somewhat flexible. I was originally going to ask for a two week headstart, but instead opted to ask for a month headstart, which was not a problem.

I’d strongly recommend putting a lot of thought into your outline. Since it is the backbone for your book, it will be a big factor in whether or not people will want to pick up the book or not. Also, the more time you spend on the outline, the less time you’ll have to think about the actualy writing (at least, for a cookbook). Negotiating with your editor is important, and will become more apparent when I talk about…

“The Contract”

Admitedly, I’m still working through this stage. The editor has received my outline and proposed schedule, has given the green light, and all that’s left (aside from the writing of the book) is signing some paperwork, including the contract.

The contract is a really long document, and it likely has a number of terms that you don’t agree with. For example, mine had a clause about future works, claiming that I would have to provide Packt with the first option to publish my next two books. Since I might consider self-publishing for my next books, and since I don’t know how this whole process will end up with Packt, I asked to have the clause removed, which they did.

You can’t get everything changed of course. The document is to outline what you’re to deliver, what the publisher is to deliver, and what protections both of you have so read it carefully. Some of the documents I pointed out earlier can provide better details about contracts, and I’m sure I’ll provide more detail when I’ve made it through the whole way.

That’s where I’m at right now. I’m sure I will have more detail as I actually dig into the writing of the book, and make my way through the first drafts, but hopefully, this has given some insight into the publishing process so far.

Hiring Is (Mostly) Bullshit

I was having a conversation with a friend of mine about a possible fit at our company. We’d worked together in the past, and are good friends, and I thought that our rapport would help to solidify our engineering team. Unfortunately, having just come out of school, he doesn’t have a lot of work experience, and his previous work placements are not at AAA places. That doesn’t bother me per se, but, I explained that my coworkers likely would not be as sympathetic as they had not worked with him.

“I don’t understand why I’m being penalized for not working in my free time,” he told me. “It’s like the chicken and the egg problem: how do I get experience for a job if I need the job to get experience?”

Ignoring the fact that there are lots of ways to get experience, the point remains that you still need to demonstrate that experience somehow. It got me thinking about the hiring process, specifically ours, but hiring in general.

I decided to revisit some old favourite articles. In particular, I was reading Steve Yegge’s Done and Gets Things Smart. After reading that, and reflecting back on a few panels from Anime North, I came to this conclusion:

Hiring is bullshit.

I don’t mean that it is unnecessary, or untrue, or unfair (though it is, a bit); just that it is misleading. It is misleading in a way that you think you understand what is going on right up until the point that you do not.

Suppose that you are in a position to find work. Suppose as well that you find a company that is hiring; you’ve noted that the company has been hiring for the position for quite some time. Let us further suppose that you are actually a perfect fit for the job, that you apply, and that you get an interview. For whatever reason, you don’t get the job. What happened?

Well, as you may have guessed, hiring is bullshit, but that’s not very specific. To be more specific, hiring is not an exact science: there’re a explicit job requirements (those advertised), implicit job requirements (cultural fit, team fit, etc.), perceptions of the candidate (and their perception of your company)… the list goes on, but all of these are inputs to an ill-defined system terminating at whoever is responsible for hiring. All of the inputs are weighted, but you’re not entirely sure how (hirer or hiree), and even if you did know, the inputs aren’t so much weighted as they are a set of preference relationships…

If that sounds complicated, that’s partly because I’m complicating matters, but also because people are really bad at hiring people who aren’t themselves. I’m by no means the first person to come to this conclusion.

Frankly, I’m not an expert, but it seems like a very difficult problem (with low yield) to develop the ‘perfect’ hiring system, mostly due to those pesky implicit requirements, and ill-defined explicit requirements. People just don’t know what they want.

Why do we continue to hire as we do then? If you’ve ever read a book on the job search (like, say, What Color is Your Parachute?) or just happen to know, you’ll know that companies try to do as little work hiring as possible. I don’t mean to say that they’re lazy, but an example is in order. Below I’ve listed a preference relationship as for how companies typically hire (abridged from my 2008 copy of the aforementioned book):

  1. From within
  2. From proof
  3. From a friend or business colleague’s referral
  4. From a referral from an agency they trust
  5. From an ad they’ve placed
  6. From a resume

You should notice two things about this: first, that people look for jobs in the exact opposite way, but more importantly, the further down the list you go, the more work is involved. I don’t blame employers, because its a lot of work vetting people, but it still remains that employers are lazy.

“It’s not what you know, but who you know”, you might say. You might also look at the list above and say that it wreaks of nepotism or other abuses of the system. That is possible, but how do you pick the ‘best’ candidate when you don’t really know what you want?

Well, in the absence of knowing what you want, and knowing how to evaluate someone, you just have a series of cruder and cruder proxies. An interview (or a resume, or whatever) is a crude proxy of knowing you. Since it is unlikely that the person hiring you has ever worked with you personally, all the communication up to the hiring decision is the employer getting a more refined view of you. All that information is a proxy of what its like working with you.

The whole process is just a complex set of communication, starting with you who you are, what you can do, and what you’re capable of and the employer trying to verify these claims and responding with the same information about themselves.

To make matters worse, you (as a potential employee) are competing against lots of other people, you have no idea where they are relative to you (assuming an objective measure), and might even have an edge because they program in their spare time. The playing field is not fair.

It’s unreasonable to get out of bed on a snow day, when school has been cancelled, and turn the downtime into six hours of work on an extra credit physics lab. It’s unreasonable to launch a technology product that jumps the development curve by nine months, bringing the next generation out much earlier than more reasonable competitors. … It’s unreasonable to walk away from a good gig in today’s economy, even if you want to do something brave and original. … It’s unreasonable to devote years of your life making a product that most people will never appreciate. Fortunately, the world is filled with unreasonable people. Unfortunately, you need to compete with them.

Seth Godin

So if employers don’t know what they want, are lazy, are bad at hiring people that aren’t themselves, and the playing field isn’t fair, what can you do?

Be really good, and really lucky?

Really, I wish I had better advice, but based on what I’ve read, that’s all that can be done. You have control over what you learn, how you communicate, and how much you practice, and those ultimately affect the goal of being really good. As for being lucky, just look for opportunities. I have gotten where I have because I have been fortunate, and not a total idiot.

I can’t claim that our hiring isn’t bullshit, but if you’re a front-end developer who loves python and javascript, you can contact us. At least then you just need to be really good.

HotelTracker: Beginnings

I might have mentioned going to Anime North a few weeks ago. I might have also mentioned, as part of that, the hotel troubles that I had gone through before hand.

Organizing everything for attending a convention can be stressful enough as is: Getting enough people for a group, booking the right number of hotels rooms, figuring out transportation, distributing the passes, collecting all the cash; it can be a serious pain, but it is one that I typically take in stride.

The biggest pain this year was, as mentioned, having our hotel rooms cancelled unexpectedly, without warning. To elaborate more on the circumstances, I had only received any notice whatsoever because I had booked extra rooms, and was giving the extra rooms away as a favour. When one of the rooms was being transferred, the other party had been told that the reservation had been cancelled, and thus the other party alerted me. This lead to a series of phone calls wherein I filed several complaints with the hotel, sought any sort of recompensation, and deperately sought out alternative means to obtain a room. Had I not done that person a ‘favour’ I would not have been alerted at all, despite booking more than seven months in advance. The hotel was overbooked and they “couldn’t do anything about it”.

You might expect this is the point where I start a crusade. Fire the social media cannons! Call up anonymous! Get outraged!

I’ll admit, I’m still sore about the situation, but I don’t think that being outraged is really going to accomplish much, nor that I would get very far with. I’m also not convinced such action is necessary as it appears that the hotel will be losing the ‘Doubletree’ moniker, which I suspect means that the hotel has suffered enough complaints to become disenfranchised. I can only speculate, of course.

No, I would rather talk about what I did to improve the situation, and improving the situation is necessary as the hotel is already fully booked for next year. Really.

More than a year ago, as github would tell me, I started on a project called HotelTracker: a crude python script that effectively scraped Anime North hotels for availability. The goal of the project was, and continues to be, developing a tool that can help other people find out about hotel availability. It’s come a long way since its inception, but there are still many changes and improvements to be made.

I realize that I don’t often talk about technical subjects on this blog, and when I do I tend to focus on things at a higher level, and I hope that I can continue to talk about subjects at a high level… but I think that there’s a lot of opportunity to explain the process of going from an idea, to a concrete implementation, especially with HotelTracker, as its a relatively simple software project. I want to talk about how it started, how it has come along, and where it is going. As a software developer looking to become a better developer and a better writer, I’m hoping to post about HotelTracker more often in special blog posts like this one.

While I may not have succeeded at getting a hotel room yet, I’m hoping that HotelTracker will find me a room, and, in the long run, other people as well. I’ll have to tell you all about how it got startedanother time though.

How to Get Noticed

A recurring theme on this blog is that of careers and the job search… not because I’m constantly looking or anything, but mostly because of my own track record, and how I seem to have accumulated some experience on the matter. Ocassionally, I take people down a notch (unintentionally) or issue imperatives, or even vent or just observe. Most of the time, these posts just end up read by friends and family, which I appreciate, with the ocassional post reaching a lot further.

… that is a lot of self-references…

In any case, I don’t have a magic formula for success. I haven’t perfected or even begun to master the way to reach out to broader audiences; those are things I have yet to experiment with. But, I do know how to get noticed (to some extent), and I’ll share those methods with you today.

They are by no means secret, or the fastest means, but they will work in the long run.

No memes this time folks (sorry).

Do Good Work
No tricks here, just do good work. Whatever that work is: be it a blog, or a comic, or a novel. Work at it, make it the best you can, make a lot of mistakes; just keep working on whatever it is until you have good work. Keep at it!

Speak up
Let people know about what you’ve done! You don’t need to brag, but share what you’ve created. Expose your work to the world, and bear the criticisms; take the praise, and whatever else comes.

Why do I bring this up? Earlier this week, I was approached about writing a book. A technical book mind you, but a book nonetheless.

So what?

I’m certainly capable of writing a book, but the fact of the matter is that someone reached out to me; someone approached me about writing a book as a result of my stackoverflow account.

Someone noticed me. Of no particular action or promotion of my own.

And that’s what I mean. I do good work on Stackoverflow and elsewhere, and even though I don’t say much about it, that work is there: it exists; it is out for the world to see. I have spoken up, to some extent.

And that’s all it takes anyone to be noticed. Just those two simple things. They are by no means the fastest or only ways, but they do work.

Right Person, Wrong Team

It’s not surprising that I’ve been talking about how we lost a team member lately. Firing people just sucks, for everyone involved. It sucks, and as much as I had said that I’m over it (which I am), there’s one little lesson that I’ve been leaving off until now.

I think it’s important that I preface this ‘advice’, as I should preface all ‘advice’:

  • n = 1: This is merely my experience; I can’t claim that it applies in the general case
  • It came from me: who doesn’t like a little self-deprecating humour, eh?

Hiring is tough; there’s no shortage of articles on the topic. The prevailing advice is hire smart people and get out of their way. It’s all about the team.

Of course. It’s so obvious! Just build a team of amazing people.

Nope, that’s not it. Not quite. Let me explain by way of poor analogy:

“A person is smart. People are dumb, panicky dangerous animals and you know it. Fifteen hundred years ago everybody knew the Earth was the center of the universe. Five hundred years ago, everybody knew the Earth was flat, and fifteen minutes ago, you knew that humans were alone on this planet. Imagine what you’ll know tomorrow.” – Agent K, Men In Black

I knew how to build the perfect team. I’d read all the articles: Find people who are smart and get things done; find the people who aren’t on the market; hire the top 1% (not just the 1% who apply). I’d read it all (well, not quite; I’ve yet to embark on reading Topgrading).

But these articles, as famous and valuable as they are, are taken from a very particular perspective. Usually, they’re from the perspective that you have a team and you’re adding on to it. Or worse, they’re talking in generalities (which I am certainly not guilty of) about hiring technical talent. And, while that’s helpful, it just doesn’t quite apply to my circumstances.

And that is because the team is what matters, at first, at least.

In this case, we hired a smart person; I have no regrets about that. Unfortunately though, that person just wasn’t as dumb, panicky, and as dangerous as the rest of the team, to stretch a metaphor too far (which, to be honest, works in this case; it makes our team sound really badass).

When you have a small team like ours, more than anything, the team has to get along and work together. There can’t be a lot of internal conflict: conflict kills companies in the same way that a lack of funding (usually) does. It really helps if the team works in similar ways, communicates (even to the point of overcommunication), and has a similar culture. It doesn’t matter if your team is a bunch of superstar A-players if it doesn’t function.

In our case, we needed a high-functioning, agile team instead of a bunch of rockstars. That meant that we had to take a look at our team, and how we worked, and evaluate if that team would succeed. We determined it would not, based on past experiences, and acted accordingly. And so, we had to let that smart person go.

To put it more directly: Right Person, Wrong Team.

And really, it’s not mindblowing that sometimes, there is a person on the team who is not a good fit, but when you’re in the trenches, its hard to see the forest from the trees (apparently, I’ve never met a metaphor that I didn’t like).

Sometimes, it doesn’t matter how smart you are if you can’t work with those other dumb, panicky, dangerous animals.

In Over Your Head

As you may know, the last couple weeks have been hectic, to say the least. The combination of different stresses from work and hotel shenanigans really got me down.

For the first time, in a very long time, I felt in over my head.

I think grumpy cat has something to say about that:

First off, notice the past tense? I felt in over my head. I am no longer feeling that way because I’m over it. Over the course of the last weekend, I had the chance to attend Anime North, which is often an uplifting experience to me, as I may have mentioned. The newfound optimism from the trip has given me the opportunity to re-examine what that ‘in over my head’ feeling really means.

It means knowing and overcoming your limits

I’m not saying that what I’ve experienced is the furthest I’ve been stretched, nor the worst I am likely to face (I fully expect things to get worse in the short term), but what happened taught me a valuable lesson in what I am capable of. Working late nights, early mornings, weekends, sure, that will do in the short term, but on week three of get this project done I was definitely feeling it, and by that I mean I’ve only really recovered just now.

Despite what a pain it was, I learned about my breaking point, my point where returns diminish dramatically. I also learned how long it takes me to recover. I also learned a lot about how much stress I can take and how hard it is to balance work and other aspects of live, but knowing what I know now, I’m better equipped for future incidents.

It means making mistakes, and learning from them

“There are known knowns; there are things we know that we know. There are known unknowns; that is to say, there are things that we now know we don’t know. But there are also unknown unknowns – there are things we do not know we don’t know.” – Donald Rumsfeld

There’s plenty that I know that I don’t know; those mistakes are to be expected (e.g. I know I need to do caching properly, but that doesn’t I know how to do it properly) but there’s also a lot that I didn’t know I didn’t know (continuing in the parlance of the quote). I leaned on my team members, as I had to in order to get the project done, and I didn’t know that the team member wouldn’t work out and would ultimately need to be let go; Can’t say that I saw that coming. I also forgot a lot about how our system is set up, and consequently, had to relearn a lot.

Being in over my head meant I needed to learn to really take charge and be on top of things in a way that was never really necessary previously. It meant I had to make some tough choices and be able to live with them. Also, if you don’t make mistakes and aren’t under some pressure, how are you to learn and progress?

It means knowing that you’re awesome

Being under pressure means that you’re awesome. Why? Because people are depending on you. That means that you provide some vital service that (presumably) only you can provide. If you can deal with that pressure and fear of failure, then you’ve come out on the other side stronger and more prepared than before. Heck, even if you’re being held under and fight for air, just surviving is something.

And, I mean, if things get too bad, being under pressure and all, they probably can’t get much worse, right? Only so much shit can hit the fan.

… Probably.

The next time I’m in a bind, sure, I might not be at my best, I might not be fully prepared, I might feel pretty crappy, but that doesn’t matter because being in over your head isn’t the end of the world.

Why You Shouldn’t (Have a Bad Time)

I have been putting this off for a while; almost two weeks at this point.

At first, I was going to entitle this Why you shouldn’t fire your first employee, launch your first major customer, and have your hotel reservations accidentally cancelled in the same week, but that was getting a bit long in the tooth, and I kept finding outer things to complain about. I think that paints a bit of a picture as to why things have been delayed.

But let’s take this and make it a positive experience. Let’s take a look at what good fortune has come out of these circumstances. I’m going to touch briefly on what happened

On firing your first employee

I’ll admit, this was not easy. At my company, we aren’t exactly bursting out the seams with staff, so every person matters, and losing a team member is rough, as its both difficult to hire a suitable replacement, difficult to explain to the person that things are not working out, and difficult to deal with the lack of that extra set of hands in the interim.

What good came out of this? If you’ve ever been in a situation where it feels like the entire team is being brought down by one member, then you should know how good it feels when either the project is completed, or that person is removed from the team. In as much as that’s a marginal good, the loss of one teammate also means a gain in terms of my experience: I now know what its like to see an employee from hire to fire, and the ups and downs involved in that process, which really conjures up the common idiom of hire slowly and fire quickly

… and Launching your first major customer

The above in combination with launching your first customer can be… troubling. We managed to deliver the project on time, but there have been quite a few weekends and late nights in order to get it all done, and we had to work down to the wire to do so. I’m still working my way back to a normal level of stress after all the hard work and hacking that needed to be done to get things in order.

On the upside, we managed to get an opportunity with a particularly large brand, and we saw what good we are capable of doing (at the cost of having a big mess to clean up, but hey, progress).

… and having your hotel reservations cancelled

This one is a bit random in comparisson. Every year (almost) for the past many years, I’ve been attending Anime North in Toronto, and, generally, I reserve the hotel rooms. Because the rooms tend to book up quickly, I wrote this script which posts to twitter if there is at least one room available at the hotel. It’s not perfect, but it gets the job done and its better than nothing. This year, despite booking in November, I got bumped because the hotel overbooked. I won’t get into too many details (this time) but needless to say, the reservations were cancelled and now at some inconvenience and with little notice I have had to obtain lodging elsewhere.

What have I learned from this mess? Build a better mousetrap so to speak: either make the script better, and possibly book rooms automatically, or just book earlier (which I would rather not, as I feel it is rude to the event organizers).

There were a lot of other unfortunate things that took place, but what’s important is to keep on keeping on and not have a bad time.

Because honestly? It’ll all be better, in the grand scheme of things.

Customers Don’t Care About Your Code

Wow, I sure hope that this code was written using test-driven development in an agile environment … said no customer, ever.

Let’s face facts. Customers don’t care about your code.

It’s nothing personal: They don’t care about anybody’s code.

You care about code (hopefully). Your team cares about code (again, hopefully), but customers? Nope!

What does that mean for you, a developer? If the customer really doesn’t care about your code, then there are some interesting conclusions that you can draw.

  • You’ve probably heard that version one of your software will suck, and that you should ship it anyway. I’ll assure you that this is not the case; version two will probably suck as well. Before I had joined a startup, I thought that this talk was absurd, clearly version one of something couldn’t be that bad… Regardless, the take-away from this is you need to learn from your mistakes quickly, move on, and improve as you go along. Unfortunate as it is, “there’s never enough time to do it right, but there’s always enough time to do it over.”

  • Customers do care about your product. They care about how easy it is to use, how it responds, and what it looks like. Unless you’ve got some serious bottlenecks, don’t worry so much about whether or not a solution is inefficient (unless that’s your business); focus on achieving what it is that the customer needs to do, or better yet, learn what it is that the customer wants to do.

  • Customers not caring about your code is not a license to be stupid; it’s a license to be mindful of the decisions that you make. It means being aware of what areas the customer is likely going to need next, and making it possible to extend those areas, and improve on them.

  • Accessibility, security, internationalization and all those -ity’s and -ion’s are important, because they build trust with the customer.

It’s by no means an epiphany, but the past few days its been on my mind. No one cares about your code but you, so focus on making a good product for your customer instead.

Running Out of Ink

I might have mentioned that you should do something every day. Lately, I haven’t been the best example of this, but its a goal I strive for nonetheless. However, there comes a time when you just run out of steam; the ink pot is dry, for the time being.

Now, under the circumstances, you might reflect back on past entries of mine, tell me that I’m full of something (hint: it’s brown and sticky!), and that I should stuff it and get back to work. To that I would say, “Sorry mister boss man! It won’t happen again, honest!”

Ha ha ha ha ha.

I do seem to put an emphasis on getting things done, but there are times when you get worn out, or just tired of doing something, perhaps even bored with it. You might run out of ideas for your blog, for example, because you can’t think of anything else job-related to talk about, and you aren’t looking so you don’t really have anything to add.

Ahem

When you’ve “run out of ink”, so to speak, consider the following:

Y U NO THINK ABOUT WUT UR DOIN?

Why are you working yourself so hard? Why are you bored? Why are you sick of whatever it is that you’re doing?

Is it because the thing you’re working on is hard? Is it supposed to be hard? (If so… tough?)

Maybe you’re working on the wrong things; things that don’t really matter to you. Things that you feel obligated to do but you really don’t need to do. Maybe you’ve made commitments you really don’t need.

Think about why you’re doing what you’re doing; you might learn that you really shouldn’t be doing it. Alternatively, you might rekindle why it is that you enjoy doing what you’re doing.

I’m writing this blog mostly for myself (though, if it became super popular for whatever reason…), so I don’t mind getting hung up on the topic every once in a while.

Try something else

When I was younger, I played a little gem called Blast Corps where the objective of most levels was to destroy everything in the path of a giant nuclear truck. The truck, of course, would drive ever so slowly forward into buildings and whatnot, and the slightest touch would trigger a detonation. Anytime you were doing something stupid in the game (like trying to get out of a vehicle with no way to get out), it would tell you to try something else.

So, if you’re doing something stupid, like going around in circles trying to get back into something, try something else

Move on!

Take a break

Uh-Duuuuuhhhh. Don’t beat yourself up.


Just keep going

Didn’t I just suggest taking a break? Well, yeah, but different strategies work at different times. I want to post a blog entry every week, so, I can’t really take a break if I want to accomplish that (see thinking about why you’re doing what you’re doing above).

Often times, getting something started is difficult, but continuing is easy. If you’re doing something like writing, you can often get unstuck by just writing something, even if it is the wrong things. Or, as I did for NaNoWriMo just sit down and do something for some time period.

Conclussion

If you’ve ever run out of ink, just try one of the above. The strategy you pick might not necessarily give stellar results, but often times you just need a push in the right direction rather than perfection.

My Leaky (Job) Honeypot

Jobs. Jobs jobs jobs jobs. Hopefully you won’t get too sick of that word, because I reckon I’m going to be tossing it around quite a bit in this here blog.

Have you ever had to look for work before, and conduct a real job search? No? Lucky you.

If you have, you know how much of a pain in the ass it can be. Scouring job boards online, loading up your resume shotgun (or minigun, as the case may be) and firing away, all hoping that might work out (you fool). In as much as that will eventually work, it can be pretty exhausting just relying on those two methods, and I wouldn’t be surprised if you missed out on certain opportunities; opportunities that you might not have known about. Enter the honeypot.

If you are a savvy computer security expert (which I am… not), you might recognize the word honeypot; If not, you might know of a certain Disney bear who often gets into a spot of trouble regarding the contents of a honeypot. Today, we are not concerned with silly ol’ bears.

A honeypot is a sort of trap: It lures in prey, like a fly, with something tempting and alluring, like… honey. If that made sense to you, that’s fantastic, because I just realized how phenomenally stupid it sounded. In computing, it’s a bit more specific, referring to a trap to detect or deflect access to some unauthorized access of a system, either to learn more about the attacker, or to keep the attacker away from the resources. In our case, it’s a metaphor: the prey in this case is a recruiter or other person looking to hire, and the honeypot in this case is… whatever you have that’s alluring and tempting.

There are lots of things that alluring, tempting thing could be, but for the sake of today’s post, lets say it’s your LinkedIn profile.

I’ve gone to some length to explain what a honeypot is, but why?

Why? The honeypot is your passive job search.

Surprise!

Let’s dig a bit deeper.

If you have a honeypot set up, then you can passively hear about new opportunities as you conduct your normal job search. Potential recruiters or hiring managers can stumble across your profile, portfolio, whatever, and get in touch with you. I imagine that’s a welcome change of pace! You can even have your friends lend a hand; should they hear of something interesting for you, just tell them to point to your honeypot.

Setting up a honeypot is by no means a guarantee of success: you can receieve unsolicited job offers that you just aren’t interested in, as an example, or you can fail to receieve any interest, leaving your honeypot empty. But hey, it’s kind of like a mousetrap; you set it up once, and you decide what to do with it after the trap goes off.

Once you have the honeypot set up, you can start to do fancy things, fancy things that you should already be doing in your search, like tracking your progress. You can make changes to your profile, see your response rate for a month, make changes, and see how they compare for the next month. Of, if you run your own site (you clever reader you) you can even run some A/B tests on your content, layout, etc. to see which performs best. With that information, you can start tuning things to attract more / less results, and of what kind.

Now, I don’t mean to say that you should mislead people, or misrepresent yourself. You definitely shouldn’t do that. But, you can take different aspects of your experience and show it off differently; Highlight different areas of your career.

Honeypots; pretty sweet, eh?

Right, the leaky part. Let’s get to that, briefly.

Imagine that people are contacting you. Fantastic. Better yet, you’ve found a job. Amazing! People are still contacting you even! You are so successful that you have way more results than you need (although, in this case, any is probably more than you need).

Now what?

Normally, you’d just refer the jobs to other folks that could be a good fit. In this case, and I may be mixing my metaphors, none of that delicious honey goes to waste.

In my case, I often don’t have anyone to refer; hence, my leaky (job) honeypot.

It’s too bad really. Referrals are mutually beneficial: you help out a friend, the recruiter, and potentially yourself, as many recruiters offer a referral bonus.