A Cover Letter is an Argument

A few days ago I wrote that your resumé should make no sense, where I explained that you should customize your resumé so that it is tailored to the receiver to such a degree that sending it to anyone else would make no sense.

A cover letter is similarly customized, but I think that’s more obvious. Never use a generic cover letter. If the application is cold, you need all the help you can get. If it’s not, for example, if you are being referred, then you really need to mention that.

The cover letter is a response to the job description. It is a point-by-point argument for why you are best person for the job as it was described. It is a guide for navigating the resumé. It is a writing sample. Every job description asks us to have excellent communication skills. Your cover letter is the way you prove this.

Before you even start to write it, you need to dissect the job description and pull out the most important asks where you have an excellent response. If you don’t have an excellent response, this might not be the job to apply for.

You will also have one or two things about you that are so great, that you need to get them in the letter. This could be a side-project or open-source contribution, a talk you gave at a conference, some technical achievement at work.

Finally, you should research the company enough to try to find other things that would make you a good fit. Read the company blog or twitter. Get a sense of who they are. If the company is small, you might be able to find team members or the hiring manager of the job they are looking to fill.

With all of this raw material, write a letter that makes it clear that

  1. You are specifically trying to get this job, not any job
  2. You are willing to put in work to get it
  3. You have the required skills of the job
  4. You have excellent communication skills

From experience I can tell you that getting one like this is rare. When I am the one filtering the pile, I will always call anyone that does this and give them a chance.

I got my last two jobs with cold applications and extremely custom letters. Of course, the letter just gets you the interview, but you are going to do a similar amount of preparation for those as well.

February 2021 Blog Review

This month I talked about how The Practice helped me understand what I am trying to do by blogging and motivated me to blog every day. I shared some tips to how I am doing that.

  1. Start the day by writing morning pages, then write a shitty first draft.
  2. Keep a long list of topics.
  3. Bank blog posts.
  4. Edit by using the editing sweep method.
  5. Write a lot of posts to become a better writer.
  6. Generate topics with these tips. For example: Mining your tweets or writing while reading.
  7. Use media depravation to make space in your brain for your own ideas.

I offered some tips for technical job seekers.

  1. Write a job statement
  2. Build your network by being useful to people
  3. Don’t be afraid of rejection.
  4. Make your resumé specific to the job.
  5. Prepare for interviews like they were a performance.

Your Resumé Should Make no Sense

If you sending out resumés and getting auto-rejected or never even contacted, let me help you understand why.

Yesterday, I wrote about writing a Job Statement, which is a very specific description of the job you want. You can think of it as the employee equivalent of an employer’s job description.

You are now looking for something very specific. And when you find one to apply to, you are also a very specific person.

So, why is your resumé generic? If you could send this same resumé to lots of different software developer jobs, then it’s going to get filtered out for a lot of them.

Consider the receiver. If this is a well-known company who will get a lot of applicants, they may get a hundred applicants to every position. I worked for small companies in small job markets and could get that sometimes (especially when we targeted new grads at the local colleges).

With such a pile, the reader has no choice but to skim each quickly. Imagine that they will read the very first lines and then skim for a few pieces of key information. If you pass that, they might give it a more careful read. It is also possible that they are using crappy software to score the resumé ahead of time.

Why will your application get chosen?

Here’s one way. Your resumé should be so specifically meant for that job that it would make no sense to send it to anyone else.

Doing this takes a little longer than just spamming job sites with your generic resumé, but the hit rate is worth it. And it’s really not that bad. You are going to start from a long generic resumé and edit it to be more focussed. I personally maintain a few styles because I have more than one domain I am willing to work in (and they are different enough to warrant this).

Read the job description very carefully and figure out the one or two most important things they are looking for. Take note of the words they use, especially jargon or technical terms, because you will use them as well.

The very first real sentence of the resumé, below your contact info, should be a concise argument for why you should be hired for this specific job hitting those two most important points.

Next, should be a concise summary of your technical qualifications, edited to be specific to this job. Maybe label this section “Relevant Skills” if you are afraid you are editing it down too much.

In every job you list, make sure the reader can skim and see the tech stack you used there (bold it). Use the job description as a guide to what you write about the job.

The description of your current job should be very specifically tailored for this receiver, and you can do this to a lesser extent as you go through the resumé (but it won’t hurt to do it completely).

If you need help, please get in touch.

Your cover letter is going to be even more customized. I’ll cover that soon.

Note: If you think your resumé will be auto-scored, the standard recommendation is to make sure your resumé has the keywords they are looking for. Since you are tailoring the it to the job description, you should be fine.

Job Seeking Tip: Build a Job Statement

If you are looking for a job, write a very specific description of what you are looking for. Do this even if you think you’d take any job. Looking for any job doesn’t help you focus your actions, but when you get specific, it’s easier to think of things to do that would help find it.

Why?

There are a lot of different jobs and good ones get lots of applicants. The goal is to make you into the perfect applicant for the job you want. This way, you’ll spend less time applying and preparing, and when you apply, you’ll be sure to stand out.

If you don’t do this, you may find yourself spending a lot of time spinning wheels and getting nowhere. You won’t have any good way to evaluate job listings, or even start searching for them.

You will probably apply to way more jobs than you should, and then, you won’t be giving the proper amount of attention to any of them. In frustration, you might just take the first job that comes along.

So, write a job statement

Break down all the aspects of a job and try to figure out what’s important to you.

Answer these questions:

  1. Where is the job located? Is it near home? If so, what is the maximum distance? Any particular neighborhood or town? If you are willing to move, what kind of place? In your state or country? To a city, a small town? Does the place need to be near anything (downtown, a highway exit, a train line, etc). Or does it not matter because you want to work remotely.
  2. How big is company? Is it just a few people? A big public company with international offices? Or do you just care about the team size? If so, how big is it?
  3. What domain? Is the software for internal of external users? Is it horizontal or for a specific vertical (like healthcare or finance)? If vertical, which one? Who are the customers?
  4. What technologies? Any particular language? Web? Mobile? Do you care about whether you use OO or functional style?
  5. What is your role at the company or on the team? Team member, lead architect, team lead?
  6. How much do you want to make? Can a part of the pay be equity? If so, how much? What kind of benefits and vacation?
  7. What kind of company culture? Casual? Business casual? Formal? Flexible hours?
  8. How much travel do you want to do? None, weekly, occasional? For what reasons? Customer visits? Conferences? Working in different offices?
  9. Contractor or employee? Part-time or full-time?
  10. Do you care about the office space?
  11. How about the team’s abilities?
  12. What about their contributions to open-source?

The next step is to prioritize your answers. Once you do that, you can use this statement in so many ways.

  1. To form search queries on job sites
  2. To find Linked-in connections to reach out to
  3. To customize your resume
  4. To drive your self-learning for gaps you might have in qualifying for the job you are looking for
  5. To make a list of companies that match your criteria.

Another effect that isn’t so obvious is that it helps you recognize serendipitous leads. When you are tuning into something specific you start to notice it everywhere. If you mention your search to other people, they will think of you when they see it. The randomness of the world starts to work in your favor.

Please reach out to me if you need help with this (message me on LinkedIn). I can help a lot better if you are specific.

Writing vs. Thinking About Writing

In my review of The Practice, I said that I was posting every day to focus myself on writing something worth posting every day. Shipping makes me think about a reader more than journaling would.

But, I am definitely not worrying too much about quality because I believe that that will come with time.

This story from Art & Fear is often cited to illustrate the power of quantity. I heard it first from Coding Horror in 2008, but here’s the earliest reference I could find:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

[…] Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

When I think back to how I learned programming, I remember that I did it nearly every day and produced a lot of code. Most of it was unshippable, but I learned from making it and eventually learned to ship it too.

I believe in combining identities to build a new skill from a developed one, so applying my code writing attitude to writing text will help me keep going. I have seen the power of quantity work before.

I have also seen the effect of “theorizing about writing”. I have been trying to write more for years. I started this blog in 2003, and right now, just two months into 2021, I have more posts than any other single year.

Thinking about writing produced very little. Please, don’t wait eighteen years to learn this lesson.

Randomness is the Great Creator

I am reading Julia Cameron’s The Artist’s Way, a book that goes against so many of my instincts. It espouses a spiritual force, a Great Creator, that helps us create. I am trying so hard not to resist because I am getting a lot of reading it.

I want this creative force to inhabit me too. I am looking for a way to incorporate it into my belief structure. Cameron knows that many readers will resist this idea and she tells us to find our own name for it—something we believe in. It need not be spiritual or religious.

I believe that the universe is a random, unknowable thing that offers infinite variety. We have an opportunity to tap into it with contributions to the randomness.

Cameron says to put up a sign that says:

Great Creator, I will take care of the quantity. You take care of the quality.

I said in my review of The Practice that I am writing to get better at writing. The quantity is the point. The quantity is how I will add to and tap into the universe’s randomness.

Raising The Bar is a One Dimensional Concept

In the context of hiring, I often hear people saying that they want to “raise the bar” or not “lower the bar”. My problem with this is that I don’t believe that they (or anyone) has any idea where the bar is or who is above or below it.

But, the bigger issue is that a bar that is raised or lowered and that people are under or over is a one-dimensional concept. Using this metaphor for hiring will result in one-dimensional hires. It’s clear from the past few decades of the tech industry what this has led to. We over-index on 20-30 minutes of code performances as the only predictor of success at software engineering.

Even if our interviews include other attributes, they aren’t treated as equal to the coding interview. You can’t even get to a more nuanced interview if you bomb the technical-screen.

So, to change this, I would first say to ban the idea of a bar from your vocabulary and thought-process. Instead, imagine something more multi-dimensional. Start with something like this:

Use the nodes to pick the attributes you think are important to your team’s success. Coding is probably one of them, but so is writing, team-focus, customer-focus, etc. The key is those things are peers, not successive gates.

Along each dimension, you might have a minimum, but don’t just set it high and make it a gate again. Wait to see the whole person.

And, use it to honestly assess your current team. Where are your gaps? Is the right new hire one that fills them?

Remember that whatever shortcoming the new hire might have may be offset by their strengths, and some things (like coding skill) can be improved by training and mentoring.

Mine Your Tweets for Posts, Mine Your Posts for Tweets

I don’t tweet much, but I think I’ve found a way to integrate it into my daily practice of blogging.

Tweeting is a good way to get some feedback on ideas. I’ve been looking at my posts and topic list and seeing if I can boil them down to something tweet-sized.

I also have been looking back at my old tweets and seeing if there’s anything there worth expanding upon. A couple of days ago I wrote about having dinner with a 50’s era UNIVAC programmer. I was reminded about that from seeing my tweet about it.

I am not doing this to market this blog. So, I am letting these tweets stand alone right now—not linking here. I don’t want the tweets to seem promotional. Also, I am doing them way before the publish date of the blog post. I’m hoping that feedback will help shape the post while I am editing it. I’m testing the post with pre-tweets of the content.

But, if already have a lot of tweets, go get a download of them and see if you can populate a topic list—you might already have some idea of how useful the post would be based on your engagement.

And even though I’m not promoting my blog this way, I absolutely think that this would be a good thing to do if I could figure out the right way for me.

Programming Tutorials Need to Pick a Type of Learner

I’m working on an app to help me stay on an intermittent fasting routine. I wrote about it a little in Icon-first Development.

Fast-o-Mat is an iPhone app, but I want an Apple Watch complication to give me quick access to when my fast begins or ends. To do that, I need to get data from the phone to the watch.

I had never done this before, and I didn’t have the first idea of how it is done in modern iOS/watchOS development.

Here was my process

  1. Do a few google searches to find out the basics. I learn that this is called Watch Connectivity.
  2. Try to make sure that this is the modern way of doing things, since Apple changes things a lot and watch development generally change a lot in 2019. It is.
  3. Look for a tutorial. I pick this Hacking With Swift one because they are usually pretty good. (Here is Part II, the Watch app, if you need it)

Then, at this point, all I do is look for the import and the basic classes I need and see how far I get from just basic iOS knowledge.

This tutorial is good at facilitating that.

  1. The code samples are easy to skim for
  2. There isn’t much pre-amble before we start getting into it
  3. It’s focussed on just the code we need for Watch Connectivity

So, this is very unlike my idea for vague tutorials, but I am not really a new learner.

There isn’t a new concept here for me to learn on my own—I understand the concept of asynchronous message sending. I just need to know what framework and classes to use for this specific task.

The issue is that this same tutorial is what a new learner would find as well.

I believe a they would get this all working by following the instructions step-by-step, but would they have learned it beyond that? Could they troubleshoot?

One thing that is not clear from the API or this tutorial is that Any doesn’t really mean Any in the message parameter to sendMessage

func sendMessage(_ message: [String : Any], replyHandler: (([String : Any]) -> Void)?, errorHandler: ((Error) -> Void)? = nil)

I decided to just use one of my types there. It’s a struct with two TimeInterval parameters.

The documentation says

A dictionary of property list values that you want to send. You define the contents of the dictionary that your counterpart supports. This parameter must not be nil.

And running it says:

errorHandler: NO with WCErrorCodePayloadUnsupportedTypes

And now I see that “property list” values are things that you can store in a plist (so, not my struct, just simple types or NSArray or NSDictionary). And yada yada yada, it’s a little more complicated when you want to do this for real.

This is all to say, sometimes you just want the code (like me) and sometimes you are trying to learn a new concept from first principles, and the same tutorial can’t deliver both (or should even try).

In Your Personal Network, Be the Server

If you want to “network”, don’t think of it as trying to meet people, or trying to find customers. Think mostly of servicing the network you already have

Consider everyone already in your network to be your clients. This doesn’t mean “customers that pay”, it means “clients that you serve”. It means you care about their well-being. You would help them if asked. You are interested in them and their problems.

There are times when they make requests, and you would do it freely—do it and follow-up. There are times when servicing the request should cost money—make that clear.

But, the important thing here is actually care about them and their problems, not yourself and your problems.

Make deposits. Do this constantly. Do it right now. Just build up as much good-will as you can. Also, to be clear here: likes, shares, and engagement on social posts are not deposits.

What if you actually need something from someone?

Ok, at some point, you might a withdrawal. Paid work, a recommendation, an introduction. Some of those are small enough, just ask. Let them know what happened—follow-up.

For bigger asks, to the extent that it is possible, figure out how your withdrawal might also be a deposit. For example, can you ask your paid clients how you can deliver more value to them? How you can help their contacts?

If your mindset is to serve, you will constantly come up with ideas.