Trust is a recurring theme in my management style and I try to start building it before I’ve hired people. Trust is formed when one side of a relationship opens themselves up in a way that makes them a little more vulnerable. Since it is uncommon for the hiring side to initiate this, I’ve tried going against that grain. It’s a fine line to walk. Paint the wrong picture in the name of “transparency” and people will flee. But do take a long look and be honest in the reality of your company and team. Nothing is perfect, but nobody is looking for perfection, so don’t paint it that way.

For a few years I kept a running document I called “The Good, The Bad, and The Middle” which detailed the great parts of my employer, the not-so-great parts, and the stuff that was a bit of a mix. I didn’t send it out until we were approaching the end of the hiring process and had established a rapport with the candidate. Trust also can’t be developed if you don’t know a few things about each other first.

The Good

This is easy. What are the best things about the company and my team in particular? Make it more than “the people are great!” The most common question candidates ask is “What’s your favorite part of working here?” And the most common answer, by far, is “oh, it’s the people!” Which is good to say, but you can distinguish yourself and your company by going further than that. This is your opportunity to brag a bit about what kind of culture those “great people” have created and what the candidate will get to do when they’re hired. One line I have is “You have a significant stake in the company’s future and our bottom line. If you do well, we do well. If you stink up the place, we may lose a client (that’s bad).“

This should be the longest list of the three categories, but don’t BS it to make it longer. This is the flip-side to the make-your-weaknesses-your-strength-sometimes-I-care-TOO-much bit. People will detect it in an instant and then put you in the box with all the other hyperbolic managers that aren’t connected to reality. That box is massive. Avoid it.

The Bad

This one’s not so easy. As a manager, you know many sore spots, and sharing them with someone brand new can quickly overwhelm. Presumably, you are working to fix them. State that, and how. If you are not, or have certain things de-prioritized, state that too. For example, this was one of my bullets: “Our on-boarding has gotten loads better, but isn’t great yet. You may feel a little confused your first few weeks.” It paints an accurate picture of what they’ll be getting into. Some of these things are universal — who is truly happy with their on-boarding anyway? — and shouldn’t shock anyone.

This part is also an opportunity to get a candidate to buy in to helping fix the sore spots. “We aren’t great at [thing] yet, and I want to improve it. I will be looking to you to help us figure that out.“ Do note that this needs to be realistic and within the purview of their job. “I need you to fix the institutional sexism in our company” isn’t gonna fly for a senior engineer, but “help us improve how we work with a mix of remote and on-site people” might.

The Middle

Note: this isn’t The Ugly. The Ugly goes in with The Bad. In my list I wrote about benefits, travel, the office plan, and similar topics. These are things that may be listed in the job description, but could stand to be fleshed out a more.

Some may have at one time been in the Bad list, but have improved. Maybe not to the point of being on the Good list, but worth moving. For example, we as a company improved our diversity over the course of a year and while it wasn’t what I’d call “awesome”, it had the right trajectory, and I wanted to highlight that.

Ok, so now you’ve got a mostly complete list. Next step is to tailor it for the candidate and the position. Someone fresh out of college should not receive the same list as a staff engineer. Further, the list should be kept up to date. I like to update it every time I’m going to send it out. It shouldn’t be a novel either. Nobody will read it if it’s too long. My last iteration clocked in at about 900 words — a little less than the size of this post. Lastly, you need to be mindful of any kind of real restrictions that might affect what you can say. Don’t violate SOX or an NDA.

This sounds like work, and it is, so why put forth the effort? It conveys that you will be level with a candidate and begins a relationship from a position of trust. For me, it worked like gangbusters. Every single person I sent it to, even if they ended up being hired or not, said it increased their likelihood of accepting an offer.

Establishing trust that early in the game greatly benefited how I recruited people, and opened up a whole swath of discussion points that could be touched on during the hiring process, or in a one-on-one after hiring. It’s the start of the virtuous cycle of trust.

Here’s another interview question you’ll face: “What is something that you’ve struggled with and what have you done to fix it?” I view this differently from “What have you failed at?” Because to me this is more of a behavior than a single point in history.

I struggle with being organized. In my youth, I had a very good memory and could keep a ton of things in my head. This helped out quite a bit in school, but it also allowed me to develop some pretty bad habits: Namely, I never developed a way to keep my crap together. I still have an excellent memory for certain things that don’t matter at all. If you need a Star Wars or a Star Trek reference? I’m your guy. But God help me if you’re depending on me to remember to take the trash out before bed.

In my 20’s this became a problem and I needed to fix it because I was missing stuff. I started to develop my own system over time. I’ve iterated on it, blown it up, and tried most of the $11.99 Getting Things Done methodologies out there. What I’ve ended up with are some relatively basic tasks that work for me and my broken brain.

I am religious about my calendar. If it is not on my calendar it does not exist. If it’s on my calendar there is a 99% chance I will attend whatever it is, though there’s the odd occasion where the blast of notifications about pending meetings will be completely missed. 1

I’ve become more diligent about writing things down. I don’t have a perfect system for this yet. I’ve oscillated between pen & paper, typing on a laptop, and iPad + Pencil. My goal is to have all of my notes from the day tracked in a searchable format. I’ve used Day One for this in the past, but I haven’t been terribly thrilled with some of their design decisions as of late. I’m reconsidering iPad + Pencil since I’ve seen some colleagues do some great stuff with that and Notability.

I use OmniFocus in a fairly simplistic way. I keep a few running lists called “Today”, “This Week”, and “This Quarter” where I put all of my todos. These could be “Reply to Jake’s email from the 4th” or “Make a feeding chart for the fish”. I try to find a balance between detail and speed when creating task names. I will forget what “Reply to Jake” means. Reply where? Text? Email? Slack? If there’s more than one email from Jake I’ll add that detail too. I know I’m only using the tip of the iceberg that OmniFocus provides, but I don’t need any more right now. I’ve tried to go hog wild with automations and shortcuts and all that and I get overwhelmed and then regress even further. I need my task management system to be nearly brainless, otherwise it will fall by the wayside. If it’s more than “unlock phone → tap a couple buttons → type words” then there’s a good chance it won’t be entered.

I’m also a little wary of the time required to automate task management. Often times I don’t think it balances out to a valuable amount of time saved. And then remembering how to use the automations or shortcuts adds to the cognitive load… leading to a less likelihood of actually getting done.

Lastly, I am still working on the discipline of starting and ending my work day properly. Ideally I’ll get in to work, review my calendar and outstanding tasks for the day and update everything, and start things off well. And then at the end of the day, close things down by reviewing/entering notes, prepping for tomorrow, and setting things up for success. That’s still not a practice I’ve made into a habit yet, but I’m working on it.

  1. This is one of the few things where I want MORE and STRONGER notifications than normal.

Beth had asked for my opinion on a feature she was finalizing. The project was a biggie — year long, 20+ engineers, many different tech stacks that had to integrate with legacy code, etc. I sat down and she showed me her laptop screen and then groaned. “I forgot to turn on the Product Set feature flag. Hang on.” She sighed. She tapped out a few keys and then sat there. We waited. And waited. A minute and a half went by, which is an eternity when you’re waiting for code. Finally it launched. Then she had to click around a few times to get back to the screen that had the thing she was demoing.

The feature was fine, in fact I don’t even remember what it was. What concerned me was how long the feedback loop was between changing code and then seeing the effect of that change. The longer that delay is, the less productive people are. I decided to bring it up.

“Uh, so that build time seems pretty long… what happened to the automatic reloading?”

“Oh, that’s been broken for weeks. The only way to bring up the site is to run it in prod.”

<strange high-pitched sound I make when I’m trying to remain calm but not doing so great at it>

This was bad. Not “we’re screwed” bad, but still, not good. A production build on this app meant that even if a change was small, the build system would need to process all tens of thousands of lines of code to implement the change. A developer will make hundreds of changes to code in a day, and then compound that by the number of people on the team and pretty soon you’re talking a big chunk of time. Further, production mode meant that a lot of debugging tools weren’t available. This was a React app, and there was a rich ecosystem of tooling that couldn’t be used.

After a little more prodding it turned out that this started happening when we had to consolidate both the back-end API and the front-end React code into a single repository1, and the developer who did that was in a time crunch and did it quickly, which broke the automated build. The fix was spending a little bit of time to update the build scripts to allow both the API and front-end to run in debug mode concurrently. It took about four hours to research, implement, and test. That response loop dropped to just a few seconds, debug tools were available again, and there was much rejoicing.

Four hours is not much time in the grand scheme of things. But, that time was never budgeted in any sprint planning, triage, or any other kind of scheduling meeting. A common trap that developers can fall into is tunnel vision. “Just get the task done. Just get the task done. Just get…” and lose sight of the forest because of the trees. To go back up in the story briefly, I should say that Beth is a fantastic developer and consistently built systems quickly and at a high standard of quality, but even someone like that can slip into an anti-pattern.

A management super-power that is worth developing is to identify tunnel vision when it happens and correct it. This can be tricky because another common trap is to spend far more time automating a process than time spent dealing with the “problem” manually. Here’s the criteria I use when making this determination:

  1. How much time is wasted each time the problem occurs? And what’s the frequency?
  2. How many people encounter this?
  3. Will either of those numbers increase or decrease over time?
  4. How much time will the fix take? (This assumes the fix is a known quantity.)

In this case, #1 was a trivial amount of time compounded by its frequency, then compounded by #2. And since code has a tendency to only grow over time, which increases build time, #3 is going in the wrong direction too. Based on that, adding more people to the project will increase the time spent dealing with the issue. Unless the fix was gonna take months this was a no-brained. Fortunately, I was familiar enough with the build system that I could take a reasonable stab at estimating #4 and knew it wouldn’t take long.

If you’ve answered those questions and are still unsure of the direction to go, I recommend following Dave Thomas’s advice about working with agility (little A). I have a lot of criticisms about the state of Agile (capital A) these days, but this is gold:

When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.

In this case, the tradeoff was simple. Speeding up the build and the evaluation loop of software development will absolutely make future changes easier, and it’s almost always worth putting in extra effort to improve those.

I like situations like these. I mean, I don’t seek them out, but when they happen, it feels great to solve them. The solution wasn’t painful, and the result made the team faster and better. That’s a big win.

  1. Sometimes clients like to throw wrenches into things. It’s fun.

I’ve been debating writing this because it requires me to open up in a way that isn’t all that comfortable for me. Specifically, I want to talk about making mistakes and then dealing with the fallout from them. It’s good to talk about this—“Tell me about a time you screwed up and how you overcame it” has been asked in every single management interview ever since the dawn of time. But, while knowing how to answer interview questions well is more theater than reality, it’s good to address the hard questions for personal growth’s sake.

Here’s how it went down. I was juggling many projects, and to borrow a flight metaphor, operating each from about 50,000 feet. That in itself isn’t bad. In fact in my opinion if managers are too low to the ground then they aren’t managing, or are teetering too close to micro-management range. But, and here’s where my mistake was, I didn’t have a timely way to know when I needed to get closer to the ground. The only mechanism was for someone to say, “Hey Scott, how’re your kids? Getting big huh, wow. Oh, you know that year long project that makes up a big chunk of our revenue? Yeah, there’s no way that’ll ever ship. K, byyyye.”

Uh oh. I obviously had a mess on my hands and needed to jump in and coordinate the effort. The specific actions to land that sucker aren’t necessary to list out so I’ll skip ahead to the ending, which was a mixed bag. The thing did ultimately ship, but at a great cost. Many extra, stressful weeks were needed (which meant our bottom line was garbage) but even worse was that there was turnover directly associated with it. People left the company because of this. Ugh.

Failure can be a great teacher, so here’s what I was able to pull from that in the hopes of not doing it again.

Many things went wrong, but here’s where I think my failure was. I needed better tools to know the state of my team and my projects. Word of mouth is a lousy way for critical information to be relayed. It gets changed, filtered, and takes too long to propagate. I want to be clear that the mistake was not that there was a cluster of a project brewing. As long as you have people, you’re gonna get some clusters. The mistake was that it took me too long to see the need to get closer to the ground to coordinate the effort. I needed to be at 10,000 feet months earlier. Had I done that, the actions would have been more course corrections than dire changes. The impact would have been smaller.

The solution to that is hard. Better intel can come from automated reports. Getting reports is easy, but getting the right information out of reports is not. For example, a burn down chart can offer a valuable data point, but if the slope of the graph doesn’t perfectly match the ideal scenario, you can’t immediately parachute in to “fix” things.

Further, any additional processes or tools introduced cannot introduce friction. As a manager you need to reduce that. At one point some years ago I was on one project where every single commit to source control had to have an issue tied to it. There ended up being multiple “Stuff” or “Misc” issues that junked up the system, negating any info that a report could provide.

Fixing a problem like this is gonna take some iteration. It’s like a mini-project all on its own, so don your project management hoodie and get to work. You have stakeholders (your team), and you need to solicit their feedback and understand the problem and what the ultimate solution looks like. And like software, this is never done.

I’m pretty sure this won’t be my last failure. But as I do fail I will continue to seek to understand what my part in it was and push myself to improve. Once I do have it all figured out I’ll be sure to share the results.

It was time for my one-on-one with Ron and I could tell it would be a doozy. He slumped into a chair and before I could even start with a basic “how’s it going?” he launched into a tirade about Sales and how they were screwing us over again and that he had to pick up the extra load. This is a not exactly a unique case—there’s a natural tension between promise and delivery and there’s more than a kernel of truth to it. Ron was really steamed this time though. It could be he needed to vent, but maybe he was just whining.

I don’t like whining. I have two kids who are approaching teenage-dom, and I have enough of it in my life already, thank you very much. Whining from adults is especially grating—they should know better, but it still happens.

I view whining as subtly but distinctly different from venting. And what is that difference you ask? Whining focuses on “woe is me!” and doesn’t lend itself to finding solutions. A whiner wants everything and everyone around them to change to accommodate themselves and their needs. Further, whining tends to beget more whining; whereas when a good old fashion vent is complete, progress can be made. Venting can be healthy.

I actually kinda like hearing a good vent session. If someone is venting to me directly, then it means they have some level of trust with me. They’re opening up and spilling out a little bit of themselves. This means you need to be wearing your listening hat. Vents can get emotional—this is good—it means the venter is invested deeply in something and that they care. So, listen! With empathy!

As you’re listening (with empathy), consider the context. They have their point of view and you have yours. They are much closer to the ground floor of the situation they are experiencing, but as a manager you Know Things that they may not. You can use this knowledge to nudge the conversation and keep it a vent rather than a whine, but don’t try to fix the problem. Something incredible can happen when someone is venting: by talking through it they may discover a solution all on their own. This is good. If it sounds like therapy, it kind of is!

Can you turn a whine into a vent? I think you can, but it may be a struggle. Sometimes it may be asking a pointed question: “Oh wow, that is a mess… what can we do to tweak it a bit?” Dig in and ask constructive questions, though try to steer things towards the realm of productivity. If you have a strong enough relationship consider plainly stating it, “this almost sounds like a whine. Is there a way to frame it so that there is the potential for a solution here?” It may not work, but that’s a whole other ball of wax.

Fortunately, once Ron got it all off his chest he calmed down a bit and evaluated his own communication with the sales team. It wasn’t actually the end of the world (this time), and he picked up a few pointers for how to work a little more effectively with them in the next go around.

Shout out to Jeff Mueller for helping edit this.

Let’s talk about trust. Team members who trust each other feel psychologically safe. This means they’ll be emboldened to act as themselves without fear of blowback or negative repercussions. They’ll focus on the work in front of them without worrying about their boss or co-workers blasting them for it, even if they make mistakes. The opposite is a detriment – they burn too much time double and triple checking every last bit of communication making sure it falls in line with arbitrary office politics.

One of the pillars of psychological safety is trust. Trust that happens between manager and employee, and also trust from team member to team member. That kind of trust takes time to build up, but the good news is that the process can begin at any time.

Tell them the things you probably don’t want to

I like to tell my teams the things I’m nervous about. At one team meeting, I spoke at length of the actions the company can take to “spy” on employees, such as that their inbox is forwarded to me once they leave the company or that all it takes is a few clicks from the IT department and I could read every single email or slack message that they have sent. Most of the team already knew that in theory, but hearing from me just how simple it is was a bit of an eye opener. I also said how many times I had personally taken those measures (very, very rarely, and only for good reasons).

It was a bit of an awkward conversation, but it engendered trust between all of us because they knew what kind of power I could wield, even if I rarely used it. It also gave them an understanding of what they’d need to be cautious of if they needed to have a truly private conversation with me or each other. Understanding what kind of privacy you do or do not have is important for trust.

Ask if they understand their part in the company’s bottom line

It’s good for one to know, whether significant or not, how their work impacts how your company makes money. I like to ask this question in my 1:1s with my direct reports and the answers are occasionally surprising. It might be obvious to you, the manager, how the corporate machine works, but for a worker it may not be.

Here’s an example: I’ve worked in service organizations for most of my career. At a basic level, this means you track the hours you work for a client and that time is billed to them. Relatively straightforward, but there are many more details that go in to the equation. What happens if deadlines are missed? What happens if a client is NET 180 (meaning they don’t pay invoices for 180 days – half a year(!))? And, if that’s the case, how does that affect the company’s revenue and reporting, because brother you better believe it does.

Even if an employee is “just” a tiny cog in a massive machine, it’s beneficial for them to understand how their contribution helps the wheels of the company turn. Knowing that their work is important to someone somewhere allows them to take pride in what they do – their work matters! (If their work doesn’t actually matter… then you should fix that)

Be honest when delivering bad news, but not too honest

If you’re a manager, you’ll probably know about bad news first. Don’t sugar coat it or try to spin it into a positive if there isn’t a silver lining. “We’re gonna miss our target for the quarter. That ain’t great.” Rather than “Team, I’m very excited about a big opportunity for us to demonstrate our grit and perseverance to our customer base and blah blah blah.” Employees are smart and will sniff out the BS… and when that happens, trust plummets.

It’s ok to say what you’re feeling, but be careful if things aren’t looking good. “We missed our numbers and it’s sales’s fault and I think we’re screwed” might seem true in the moment but it can become a self-fulfilling prophecy even when that particular situation might have still had hope. If your own personal cynicism and pessimism is leaking out in your communication, you’re not doing your job as a leader. Your duty to your team is to motivate them and to empower them to do good work. Instead, “Look, we missed our target, and that’s not good. I’m nervous and I’m also a little scared because it means things could get worse for us. BUT, there is a way out and here’s what we’re gonna do…” conveys the seriousness of the situation, as well as your own personal feelings, but also presents a path forward so that people don’t just dwell on the crisis.

[Note: if it is catastrophic, like the whole company is shutting down, treat people like adults and deliver that news promptly so that they don’t have to panic and scramble to find new jobs.]

This list is not exhaustive, but I have found these things to be particularly effective. Trust is built up over time. It takes constant care and attention to grow, must be demonstrated consistently, and can be lost in a heartbeat if you ever stop treating your employees like the fully actualized humans that they are.

Shout out to Sam Davies for helping edit this.

When I’m hiring, I hear this one a lot. A candidate is nervous about something that I just asked, let’s use GraphQL as an example, about and they’ll say “Well, I don’t know much about GraphQL, but I’m a fast learner!!” and their earnestness nearly jumps out of their body and does a little dance.

Here’s the thing. I hear that phrase all the time. I imagine so does every other hiring manager. And this may sound mean, but so what? If everyone is truly a fast learner, what separates you from the rest? Also, I can probably find someone who already knows GraphQL in the stack of resumes I’m procrastinating in sifting through. What’s my motivation to keep going with you?

Yeah, that’s definitely harsh, but it’s reality. Hiring managers are usually stressed and need to find the right person very badly. Here’s a way to play to that need and flip the situation. Start with this:

Wow, it sounds like GraphQL is a bigger deal for this role than I originally thought, and it sounds like I’m a little out of my depth. This still sounds like a dynamite job though, so here’s what I’m going to do: Tonight I’m going to watch the series on GraphQL. Then over the next week I’m going to build a little project that consumes the GitHub GraphQL API. I’ll send it to you if you’re still interested. How does that sound?

That’s a lot better than “I’m a fast learner, please hire me.” It acknowledges the problem (a gap in expectations), and then presents a solid plan for how to overcome it. Further, that candidate shows crazy kinds of initiative, as well as a strong desire for the job, without coming off as begging. And lastly, it’d show me some code, which is very useful when hiring a developer.

It’s not a guarantee that you’ll get the gig, but will at least impress the interviewer.

Other things:

If the job description wasn’t clear about the requirements for GraphQL in the first place… that’s a miss on the hiring manager’s part.

Also, that response presumes that the candidate has the free-time to do all that, which is not the case for everybody.

I have a weird fascination with high altitude/cold weather disasters and mysteries. I’ve watched every documentary on Netflix about Everest disasters, K2 disasters, read Krakauer’s books, and I still can’t get enough of the stuff. I’ve watched so many that they’ve started to all blur together, and I have trouble remembering which is which… I’m not sure why I find it all so fascinating; I have no interest in actually going and having those adventures, but something about confronting those extremes are just interesting to me.

I also dig unexplained phenomenons. I watched a lot of Unsolved Mysteries as a kid, and they always stuck with me. So, the story of the Dyatlov Pass Incident is right in my wheelhouse. The gist is: in 1959 a group of Russian college students went on a long hike/camping trip through the Ural Mountains. One night they all abandoned their tent and ran out in the middle of the night in -40 degree weather without shoes or proper cold-weather gear on. They were discovered a month later buried in the snow, and nobody could figure out the cause. They were all experienced campers in a very remote region. Theories included avalanche, a lovers quarrel, wild animals, indigenous people turned murders, the KGB, rogue science experiments gone wrong, and, of course, aliens.

So, it was only natural that I’d be interested in Dead Mountain – The Untold True Story of the Dyatlov Pass Incident. The author goes through meticulous detail to find out everything he possibly could about the expedition, the rescue (and then recovery) party, and his own experiences traveling to Russia to try to retrace some of their steps 50 years later.

I enjoyed reading this. The author provided enough context of the group, their motivations, and the climate of the Soviet Union at the time without going too far off the rails. He also breaks down each theory, even some of the outlandish ones, and points out the strengths and flaws in each of them.

My favorite chapter came towards the end when he switches into speculation mode, and weighs all of the facts and evidence and then comes up with a plausible explanation. I don’t want to spoil anything, but it seems convincing.

If you’re into this kind of thing, it’s worth checking out.

Oh yeah, Hollywood also made a movie “about” the story a few years ago. I didn’t see that one, but it included time-travel and teleporting mutants apparently. I think we can rule that one out.

[One of my goals for 2018 is to read 12 books in the year. Some of you may scoff at that number but while I love to read, I haven’t had time as of late to indulge in that. This year I am making the time.]

I see a lot of resumés. We’re a growing company, and are hiring often, so the rate of resumés that cross my desk has only gone up. I care quite a bit about my team and hire with great care, so I say ‘no’ most of the time. If you wanted to know how to get a leg up on my hiring process, and perhaps others’, here’s how I scan and determine pass/reject on resumés.

[Note: this is my process. I am not stating it is the best or that it will work in any other situation. This is just how I do it.]

Step 1. Reject the grossly unqualified. These are the people who may very well have applied for the wrong job by accident, or just don’t care and apply to every single job they can find. The most memorable of these was someone who’s closest relevant experience to a senior developer position was that they were a college mascot…

Also, double check to make sure you find and replace the right strings in your cover letter. “I really want to work at [Some Other Company]!” looks bad on you. Speaking of cover letters:

Step 2. Reject those who don’t read the job description. I include a blurb like this on every job description I post:

Do not just send in a resume. Tell us your story. What have you built that makes you proud? How have you demonstrated leadership? What are your aspirations? What are you passionate about? What are you dying to learn next? Share with us the stuff that makes you stand out. This could be something as simple as a well-crafted cover letter, or something public that you had a hand in creating.

You’d be surprised how many people don’t do any of that (or actually, if you’ve ever hired anyone before, you are completely not surprised in the least). If there is nothing but a resume attached, it goes in the reject pile.

“How can you automatically disqualify people without even reading their names?” you say? Well, in this job, the details matter. If you are the type of person that does not read that, you are not going to do well by our clients, and that is just not gonna fly.

Those two steps will whittle down a pool of 200 applicants to 20 or so. I want to get that number down to below 10. The next steps are a little more involved. But before that, there are a couple of smaller things to consider.

How much school stuff should I put include?. School kinda matters for an entry-level job. The school, your GPA, and if what you studied is related to the job are data points, but not deciding factors. Graduating summa cum laude from MIT is a nice feather in your cap, but it does not guarantee that you are a good software developer.

Nobody cares about your high school. Seriously. Don’t put it on your resumé.

Bits and bobs. Have up to date contact information on there. That includes easy URLs to any social media you feel like sharing. If I’m interested, I’ll try to look you up on LinkedIn. Sometimes it’s easier to glean information there than a resumé.

Ok, more important stuff now.

Step 3. More Hemingway, less Faulkner. I will not be spending more than a few minutes at this stage on your resume. I do not have the time to read your 5000 word treatise on how awesome you are. It is possible to convey your passion for the craft in a couple of paragraphs, I’ve seen it.

Also, take 5 minutes and do a Google search on the company and position you’re applying for. “I saw that you recently did [some thing] and I love [key component of it]. I’d like to talk about that!” Flattery will get you everywhere, and this is the easiest way to get in the good graces of the person screening resumés.

Step 4. Evaluate skills and job history. If I’m hiring a web developer, can you, y’know, develop software for the web? When I’m doing this I’m looking for something that makes you stand out to me. Do your best to make this easy for me. “I designed and built a load balanced RESTful API that scaled to 200,000 sessions” is good. “I took a junior dev under my wing and helped her get a promotion” is great.

For a senior type position, I’m only going to look about 5 years back on job history or so. The industry changes so quickly, it doesn’t really matter that you were a Backbone.js expert if we’re jumping into Vue. You should still include it for history’s sake, but it should be short.

For the juniors and entry-level folks, don’t include non-relevant part-time jobs. It’s cool that you worked at Chili’s for 9 months, but putting noise like that on a resumé makes me grumpy. Note: If you worked crap jobs to put yourself through school and are proud of that, and you should be, put it in the cover letter.

If you are changing careers, definitely include that, and make it apparent. Last year I hired someone who got her PhD in physics and after 20 years of that decided to become a developer. She was clearly smart and has been a great addition to the team.

So, if you do all of that, you’ll very likely make it to a phone screen interview. That’s a whole other post though. But, what about bigger companies? The ones with giant HR departments that have other people phone screen?

In that scenario, your resumé will very likely be screened by a non-technical person. Someone who may not know that if you can build APIs with Express, you can do it with Hapi, and is looking for that magic buzzword and will reject you if it is not there. If you feel like you’re applying to a company like that (and if they have more than a few hundred employees, you probably are), take special care that your resumé has all of the right bullet points and that they are obvious.

My kids and I like to play with Nerf guns. My younger daughter in particular likes to sneak up behind people and shoot them in the back. She’s devious like that. While running around and shooting each other can be fun, it does start to get a little boring after a while.

So, we started to implement rules and make more of a contest out of it. We started with a little capture-the-flag, but that was still a little dicey, certain members of the family would either really want a particular stuffed animal to be the flag, while others definitely didn’t want that one to be the flag ever ever ever ever.

I was familiar with a simple game mechanic of capture points. Each team flips over a card-type thing to their color and they get points for that. The more capture points the better — it keeps everyone moving. If you get shot, you have to go back to your re-spawn point and start over. The catch was that keeping score was too tricky without some kind of impartial observer.

Being the coder that I am I whipped up something quickly for iOS and called it Red/Blue, for the two teams it had. It’s a basic premise:

  • When the app launches, choose how many minutes to play and tap Start.
  • The game starts and displays a split screen with two different colors.
  • When someone taps a color, ex. Red, a clock associated with Red starts to increment.
  • When Blue is tapped, Red is paused, and Blue increments. I added some sound effects to denote when this happens. (it’s just my voice saying “Red” and “Blue”. My kids think this is hilarious.)
  • When the main clock counts down to 0, the game is over and whichever color got incremented the most wins.


Start Screen
Start Screen
Game Screen
Game Screen
End Screen
End Screen

This worked pretty well. We ended up pulling out old iPhones and iPads and laying them on flat surfaces and threatening all kinds of trouble if one of the kids moved or picked up a device. Ultimately we had four control points which led to all kinds of mayhem.

One thing we noticed was that it was annoying to start a round with the four control points we usually played with. Everyone would have to be by a device to manually start off each timer. A quick googling revealed that Multipeer Connectivity is pretty easy to pull off. Another hour of coding and now all of the devices will start off when the first device hits start.

I do not plan to submit this to the app store. I just don’t want to have to deal with it. The code is under an MIT license, so that you can do whatever you’d like with it.

To install

  • You’ll need Xcode and an iOS device running iOS 10 or higher.
  • Clone or download the code from GitHub.
  • Open the RedBlue.xcodeproj file in Xcode.
  • You may need to adjust the Signing stuff to get it to run on your own devices.
  • Connect your device to your Mac.
  • From the Product menu, select Run.
  • Xcode will build the app and then install it on your device.


  • There are no tests. I should probably fix that. We’ll see.
  • Once a round starts there’s no way to end it prematurely other than force-quitting the app. I don’t think that’s a big deal.
  • The code could stand to be refactored a bit. I only spent a few hours on it so it’s a little haphazard. Patches are welcome ;).

In the future!

I may add other gameplay modes. Some sort of King of the Hill mode may be interesting, or chained control points (point 2 isn’t enabled until point 1 is captured), or any number of other things, but I don’t know if I’ll ever get to that.

Copyright © 2018 - Scott Williams - Powered by Octopress