Brian Gilham

Engineering leader, husband, and father

medium

As a quick follow-up to yesterday’s note, I’ve now imported all my Instagram videos and stories. I’ve also brought over all of my old Medium articles. The process continues.


How to Unfuck Your To-Do List

You probably have a long list of things you’d like to get done on your projects. The type of tasks that will push things forward. Move the needle. Take things to the next level. Open the kimono. (Sorry, I confused my clichés for a second there.) But I’d be willing to bet you, like _most people, have times where you’re feeling stuck, or distracted. You procrastinate and play video games, rather than tackle the work you know you need to do.

You probably have a long list of things you’d like to get done on your projects. The type of tasks that will push things forward. Move the needle. Take things to the next level. Open the kimono.

(Sorry, I confused my clichés for a second there.)

But I’d be willing to bet you, like _most people, have times where you’re feeling stuck, or distracted. You procrastinate and play video games, rather than tackle the work you know you need to do. You’re feeling the resistance, and the resistance is winning.

Don’t fret. We all have those moments.

In my experience, developers start procrastinating when they haven’t taken the time to think through their tasks deeply enough.

Open up your to-do list. How many items does it have that sound like, “Finish project X” or “Figure out how to do Y”?

Those types of vague, enormous tasks are productivity killers. If your to-do list has more than a couple of them, there’s a good chance you’ve been procrastinating on them for a long time. Or just freaking out inside. That’s usually my approach.

Are you ready to unfuck your to-do list? I am, too.

Here’s a few steps you can take to banish those uber-tasks forever and get back to work.

Break each task down three times

When you’re working on any project, it’s easy to imagine the end product and start feeling overwhelmed.

Let’s say I’m your boss. I’m not sure how I got that particular promotion but stick with me here. If I point at a fancy SUV and say, “Build me one of those,” there’s a good chance you’d start procrastinating pretty damn hard. That’s because “Make an SUV” is a terrible request. Where would you even begin?

But things start to look a lot more manageable when you break it down into smaller tasks. Instead of “Make a car,” you might start with “Learn how a car engine works.” Then you could hit up Google and search for, “How to assemble a car engine.”

After that, you might move on to finding the parts you need, ordering them from Amazon (or wherever you can order car parts from), and — finally — assembling the engine.

Hard tasks, all. But certainly a lot easier to handle than “build a car.”

It’s a silly example, of course. Most of us aren’t building a car from scratch. But you get the idea. Big tasks become easier the longer you spend breaking them down into tiny, tiny chunks.

Next time you’re staring an enormous task in the face, ask yourself what it will take to complete it. Do this three times. Each time you have a new answer, it’s a new task.

If you’re building a chat feature for your product’s website, for example, you’d ask yourself, “What do I need to do to finish the chat functionality for the site?” Maybe the answer would be, “I need to create a new table in the database to store chat messages.”

Awesome. What do you need to do to create a new database table?

“I need to decide on an appropriate schema for the table.”

Okay, cool. I’m obviously skipping some steps here but, by breaking that tasks into tiny pieces, it’s become a series of actionable steps that feel achievable. Working on small tasks is great — once you know the plan, you can quickly gain momentum.

Please don’t assume you’ll be able to keep everything organized in your head. It’s almost never true.

Clear out the bullshit

Often, we add tasks to our to-do list that we have no intention of ever doing. Ever. I’m really guilty of this one.

Take a moment, spin through your list, and ask yourself one question: “Why should I do this?”

If you’re going to do productive work, you need to know what your ultimate goal is and — just as importantly — why you’re striving for it.

When I started working on side projects, it was a way to get out of a job I hated. That was my North Star; improving my career & job prospects.

You need your own North Star. Something to keep you on track. A phrase, idea, or person that speaks to the heart of why you started working on your project in the first place. It could be to land a more fulfilling job, satisfying the creative half of your brain, or improving your skills. Anything.

Without a clear, well-defined idea of why you’re doing the work you’re doing, you’ll just aimlessly wander from task to task. And that’s when procrastination really starts to set in.

Prioritize like a general

Most tasks fall into one of two categories; important or urgent. They’re rarely the same thing.

Take a page from Dwight Eisenhower, who said:

“I have two kinds of problems; the urgent and the important. The urgent are not important, and the important are never urgent.”

In the “Eisenhower Method,” described in First Things First, tasks are broken into one of four quadrants:

  • Important & Urgent: Do it now.
  • Important & Not Urgent: Plan when you’ll do it.
  • Unimportant & Urgent: Delegate it.
  • Unimportant & Not Urgent: Don’t do it all.

When you’re prioritizing your tasks, take a page from Dwight Eisenhower and ask yourself if each task is important, urgent, or neither. Cut appropriately.


Finish Your Damn Side Project: Update #1

Last week I announced Finish Your Damn Side Project, a new book I’m self-publishing this summer. The reaction has been nothing short of amazing. I knew people were struggling with shipping their side projects — it’s part of the reason I write the Monday Mailer — but it’s obvious developers are hungry for a resource that goes deeper than a weekly newsletter. I’ve wrapped up planning and outlining the book, so I thought it would be a good time to pause and share what’s happened so far.

Last week I announced Finish Your Damn Side Project, a new book I’m self-publishing this summer. The reaction has been nothing short of amazing. I knew people were struggling with shipping their side projects — it’s part of the reason I write the Monday Mailer — but it’s obvious developers are hungry for a resource that goes deeper than a weekly newsletter.

I’ve wrapped up planning and outlining the book, so I thought it would be a good time to pause and share what’s happened so far.

Research

I’ve wanted to write a book for a long time. But I don’t want to write one just for the sake of writing it. Over the last eight months, I’ve had the opportunity to chat one-on-one with many of the 1,200+ people subscribed to the Monday Mailer. Like me, they see the potential for side projects to improve a developer’s skills and level up their career. But, when I ask about the challenges they’re facing, I hear the same issues over and over again:

  • “I don’t have time.”
  • “I’m feeling burnt out.”
  • “I don’t know how to get motivated.”
  • “I have trouble coming up with ideas.”
  • “I’m not sure how to get started.”
  • “I have trouble maintaining focus.”
  • “I keep procrastinating.”
  • “I think too much, instead of taking action.”
  • “I don’t know how to build an audience.”
  • “I’m not sure how to promote my work.”

I see the same concerns pop up in my conversations with other developers, and on sites like Reddit, Hacker News, Designer News, and more. I don’t claim to be an expert when it comes to this stuff. But I’ve managed to consistently ship side projects, throughout my career, while working full-time. I’ve learned some useful techniques along the way, and I think I can help.

Brainstorming

Once I decided to pursue writing the book, I sat down and started brainstorming potential topics. I opened a new document in Ulysses and added a new bullet point for every idea that popped into my head. No editing, no critique. Just opening the flood gates and letting ideas pour out.

I initially tried to do this in MindNode, but quickly realized it wasn’t the right tool for the job. Using MindNode, I felt tempted to try and organize my ideas prematurely. I don’t know about you but, for me, nothing puts the brakes on brainstorming faster than trying to generate ideas and organize them simultaneously.

This process produced somewhere in the neighborhood of 80 different ideas for topics.

Outlining

I knew I didn’t want to start writing until I had some idea of the overall structure. So, I wrote every possible topic down on a Post-It Note and stuck them to the wall.

It looks like pure madness, I know. But it was a fantastic way to see the big picture and start organizing my ideas into distinct sections. Patterns began to emerge, and I knew, if I couldn’t find a section to slot a topic into, I needed to consider cutting it. In the end, I managed to lose 10–15 bad ideas this way.

Getting Organized

My next step was to fire up Trello and create a new board. On it, I created 12 new columns:

  1. Topics
  2. Outlining
  3. Outline
  4. Writing First Draft
  5. First Draft
  6. Writing Second Draft
  7. Second Draft
  8. Writing Third Draft
  9. Third Draft
  10. Being Edited
  11. Edited
  12. Done

I filled the “Topics” column with a card for every topic that made the cut during the outlining step. As I work, I move each card along the conveyor belt of columns. It might seem like a lot of steps, but it means I’ll never lose track of my progress or what I need to do next.

Writing

On Friday, I started writing in earnest. My goal is to write at least 500 words per day. I’ve already completed a 2,000-word first draft for one of the essays. I know the importance of maintaining a daily habit when it comes to side projects. So, I’ll be working hard to try and stick to my daily word count.


I’m Writing a Book

For a few years now, I’ve had a secret goal: write a book. I’ve always admired people like Wes Bos, Jarrod Drysdale, and Nathan Barry — folks who teach what they know, write, edit, record, and sell their work. Developers, designers, writers, and countless others are in a unique position; they have the means to both create and share, or sell, the things they create. I’ve successfully sold products in the past — everything from an icon set to iOS & tvOS apps — but the idea of self-publishing a book has never gone away.

For a few years now, I’ve had a secret goal: write a book. I’ve always admired people like Wes Bos, Jarrod Drysdale, and Nathan Barry — folks who teach what they know, write, edit, record, and sell their work. Developers, designers, writers, and countless others are in a unique position; they have the means to both create and share, or sell, the things they create. I’ve successfully sold products in the past — everything from an icon set to iOS & tvOS apps — but the idea of self-publishing a book has never gone away.

I’m tired of just thinking about it. I’ve decided that 2017 is the year I’m finally going to do it. I sat down a few weeks ago and started outlining. Today, I’m ready to commit publicly.

My book, Finish Your Damn Side Project, will be available this summer.

Over the course of my career, I’ve become skilled at brainstorming, developing, and shipping side projects. In the last few years I’ve released more than ten apps, written countless blog posts & articles, and spoken at events & meetups on a variety of topics — all while holding down a full-time job that I love. Through it all, I’ve learned habits, concepts, tips, and techniques that I — and many other developers — have used to ship side projects consistently.

I share a lot of that advice & research with the Monday Mailer, my weekly newsletter. But feedback from subscribers, along with my research, shows many developers are hungry for more. I don’t claim to be an expert; I’m just a developer who has seen the power of side projects to improve your skills and level up your career. I think I can help.

I won’t lie; I’m a bit nervous. The book will be the first time I’ve taken on a writing project of this size. But I learned a long time ago that it’s important to start new, scary things before you feel like you’re ready. Because you’re never going to feel truly ready.

I honestly believe you don’t need someone else’s permission to share your passion, build an audience, and publish your work. The Monday Mailer is one part of that philosophy, for me. Finish Your Damn Side Project will be another.

Even if it doesn’t go as well as I hope, I’ll still learn a lot along the way. And isn’t that one of the biggest benefits of working on a side project?

In the weeks and months to come, I’ll be sharing regular updates — both in the newsletter and here on Medium. In my next update, I’ll share some of the steps I’ve taken to plan & outline the book, along with how I’m approaching the first draft. Want to stay in the loop and get a discount when the book launches? Sign up for the Monday Mailer.


Your First Programming Job

When you’ve been programming for a long time, it’s easy to forget what it’s like to be brand new, fresh out of school, and starting your first job. Heck, I can barely remember what that period of my life was like at this point. The biggest thing I remember? Being afraid. I worried I’d screw up something important. I worried my coworkers would hate me. Most of all, I was scared I wasn’t good enough to hack it as a professional developer.

When you’ve been programming for a long time, it’s easy to forget what it’s like to be brand new, fresh out of school, and starting your first job. Heck, I can barely remember what that period of my life was like at this point. The biggest thing I remember? Being afraid. I worried I’d screw up something important. I worried my coworkers would hate me. Most of all, I was scared I wasn’t good enough to hack it as a professional developer.

Lately, I’ve read a lot of questions from junior developers starting their first “real” programming job. I see a lot of the same worries echoed in their issues and concerns. So, I thought I’d quickly share some advice for those taking the first step in their programming career.

When you start working on your first project, there’s a good chance you’ll spend a lot of time feeling frustrated. You’ll spend hours hunting down a simple bug or struggle to understand concepts that seem like second nature to the rest of your team. It’s normal — every programmer goes through it. After you’ve been programming for a while, you’ll laugh at the mistakes you made in the early days. You’ll spot the same bug in no time flat, looking at someone else’s code. But you need to fight through this phase first, so stick with it.

Don’t get too precious about the code you write — there’s likely room for improvement. When a senior developer offers a suggestion or critique, it isn’t personal. You are not your code. This is so important I’ll say it again.

You are not your code.

At first, every comment on your pull requests will feel like a dagger to the heart. Don’t let it get you down. There isn’t a single developer out there who writes perfect code on the first try. Quality code is a process. When I was starting out, senior developers tore my work to pieces. I won’t lie; it hurt a whole lot. But I slowly learned to focus on the code — instead of my feelings — and started to improve.

Most programmers experience imposter syndrome, at one time or another. Even the developers you look up to and admire. Often, it’s the most talented developers who experience it the most. Everyone looks around a room, at times, and thinks, “This has to be the day they realize I’m a fraud.” It happens, no matter how hard you work or how skilled you become. Acknowledge the feeling and do your best to move on.

There’s always something new to learn; it’s the best part of working as a programmer. Those people in the office everyone turns to with questions? Even they have something new to learn. Graduating from school was just the beginning of your education — it’s a lifelong process.

Finally, don’t be afraid to ask questions. You might feel like you’re bothering your coworkers, pestering them with simple issues. Please ignore that feeling. Don’t forget; you’re there for a reason. You’re a member of the team now. You know what’s worse than asking a stupid question? Not asking the question and grinding your gears all week, with nothing to show for it. Be willing to admit you don’t understand something and have the humility to ask for help.


Monday Mailer Survey 2016

Two weeks ago, I wrote to the Monday Mailer and asked if my readers would do me a favour and fill out a quick survey. People spend so much time and energy trying to figure out what their audience wants — I figured I’d just ask them. 130 people were kind enough to take 6 minutes (on average!) out of their busy schedules and fill it out. Their answers will help me create great content for the newsletter & podcast in the year to come.

Two weeks ago, I wrote to the Monday Mailer and asked if my readers would do me a favour and fill out a quick survey. People spend so much time and energy trying to figure out what their audience wants — I figured I’d just ask them. 130 people were kind enough to take 6 minutes (on average!) out of their busy schedules and fill it out. Their answers will help me create great content for the newsletter & podcast in the year to come.

I thought it would be interesting to share some of the results.

Job Titles

84% of respondents identified as a software developer. Of those who didn’t, the most popular job titles were variations on:

  • Product Manager
  • Student
  • Teacher
  • Writer
  • Soldier

Side Projects

68% are working on a side project of some kind, with 58% planning to monetize it. 8% of those who responded have already monetized a side project.

When I asked the other 32% what was holding them back from working on a side project, they said:

  • A lack of time/too busy
  • Not having any ideas
  • No motivation
  • Feeling burnt out
  • Having trouble deciding what to work on

Challenges

Asked what the biggest challenge they were facing in their work was, most people said:

  • Time management/balancing goals & timelines
  • Maintaining motivation
  • Producing good work consistently
  • Staying focused
  • Suffering from imposter syndrome

Learning

Most respondents want to learn more about:

  • Marketing & building an audience
  • Team management & leadership
  • Monetizing their work
  • Learning design skills
  • Improving their time management skills

Elsewhere

When asked about other sites, authors, and podcasts they liked, the most popular answers were:


How I Write & Publish a Weekly Newsletter

I often receive questions about how I run the Monday Mailer, my weekly newsletter about shipping side projects, productivity, and doing your best work. Readers ask what my writing process is like, and which software tools I use. While I firmly believe tools aren’t all that important — you can make something great, no matter the means— I thought I’d write some of it up for anyone interested. Planning I publish my newsletter every Monday, and the occasional article during the rest of the week.

I often receive questions about how I run the Monday Mailer, my weekly newsletter about shipping side projects, productivity, and doing your best work. Readers ask what my writing process is like, and which software tools I use. While I firmly believe tools aren’t all that important — you can make something great, no matter the means— I thought I’d write some of it up for anyone interested.

Planning

I publish my newsletter every Monday, and the occasional article during the rest of the week. I also contribute guest posts to other sites, from time to time. I manage all of my writing tasks through Trello. My writing board has a lot of lists on it — 17 in total. They cover everything from the latest newsletter drafts, to guest posts I’m writing, to tracking where I’m publishing & promoting my work. Here’s a quick rundown:

  • Ideas: Whenever I think of something that might make for a good article, I throw it in here. I try not to edit these thoughts too early — if it’s rattling around in my brain, it goes on the list. There’s somewhere in the neighborhood of 60 cards, so far.
  • On Deck: Cards from the “Ideas” list I’m hoping to work on next.
  • Process: Lists that cover every step in my writing & editing process: Outline, 1st Draft, 2nd Draft, 3rd Draft, and Edited.
  • Published: Lists for every place I regularly post my articles: Mailing List, Medium, and LinkedIn.
  • Promoted: Lists for every site I usually use for promoting my work: Hacker News, Designer News, Reddit, and more.
  • Pitched: A single list for keeping track of which publications I’ve submitted to, along with the article and current status.

Phew! My Trello board is probably getting a bit out of hand. But I have so much going on every week; I need an external brain to keep everything organized. Okay, let’s dive into my writing process.

Writing

Like many writers, I take an iterative approach. Each round builds on the last. Here’s what it looks like, roughly:

  1. Fire up Ulysses and write a quick and dirty outline. I spew my thoughts onto the page. Every little thought that pops into my head gets written down. I don’t edit or change anything at this stage — it’s all about getting my brain warmed up. If there’s something I need to research, I jot it down as well. Then, I walk away for a while.
  2. Come back, throw the outline on the left side of my screen, and open a new document on the right. I start by expanding on the bullet points in the outline. Again, I’m not too worried about details at this point. I write until I have something mostly resembling sentences and paragraphs. Then, I walk away for a bit.
  3. Put the last draft on the left side of the screen, and a new document on the right. Noticing a pattern, yet? Now it’s time for the real work. On this pass, I work on refining my ideas. I ask myself a few questions: Are things coming across clearly? Am I writing in a way that feels authentic to my personality? Are there any obvious problems? I fix anything I find and then — you guessed it — walk away for a bit.
  4. For this last pass, I run the article through Grammarly. I shell out for the Premium plan every month. It isn’t perfect, but it usually catches a few things I missed in the last draft. Worth every penny, considering the amount of writing I do each month.

I try to dedicate a couple hours to writing every morning. Some articles take a few days — or weeks — to complete; others I can knock off in a few hours. Doing a little bit every day means I always have something I can publish. It also means I’m sometimes a week or two ahead of schedule, which is useful for those moments life throws a curveball my way.

Publishing

The Monday Mailer has 1,168 subscribers as of this writing. I use Mailchimp’s Send Time Optimization tool to send new articles at an ideal time for the majority of my readers. It usually lands somewhere between 9–10am EST.

After I schedule the week’s newsletter, I add the article to my blog. I used to enjoy fiddling around with hosting my website, but I use Squarespace and enjoy the simplicity it offers. Again, worth every penny. I schedule the blog post to publish two weeks after it goes out to the mailing list. I do the same for the Medium version.

Squarespace automatically tweets a link to the post, once it’s live.

A few people have suggested LinkedIn as a good place to share new articles, so I’ve been giving that a try, as well.

Interacting

My favorite social network is my mailing list. I set time aside all week to respond to emails from my readers. I’m lucky — they’re never short on feedback and suggestions.

Since the public version of the article is scheduled ahead of time, I can mostly forget about it until it goes live. Once it does, I spend a good chunk of time monitoring the comments, as well as social media, for comments and reaction. I make sure to thank everyone who shares my work. Everyone I can find, at least.

Fin

That’s it! It’s a relatively simple process. But it’s one I can repeat consistently, week over week. And that’s the most important part.


Side Projects = Investments

There’s a trend I’ve noticed lately — both online and in my inbox — that I find troubling. Someone will share an idea for a side project and immediately follow it up with a comment like, “But there’s no point in doing it — it isn’t monetizable.” What? When did working on a side project become so driven by a desire to make money? Sure, it’s hard to read an article titled, “Tricks to Monetize Your Side Projects” and not want to get a piece of the action.

There’s a trend I’ve noticed lately — both online and in my inbox — that I find troubling. Someone will share an idea for a side project and immediately follow it up with a comment like, “But there’s no point in doing it — it isn’t monetizable.”

What?

When did working on a side project become so driven by a desire to make money? Sure, it’s hard to read an article titled, “Tricks to Monetize Your Side Projects” and not want to get a piece of the action. But a good side project can offer so much more.

A side project is a long-term investment in your skill set, creativity, and career development. I landed my job at TWG based on the strength of my side projects. I found many of my friends and acquaintances through side projects. I picked up a lot of skills through — you guessed it — side projects.

If your project ends up making money, awesome. But if you’re thinking about starting something new, monetization should be the last thing you think about — not the first. If it stops you from getting down to work, it’s just another form of procrastination.

Don’t throw away the opportunity to invest in yourself just because you don’t see a path to profits.


What Happens When Your Post Hits the Top of Hacker News

Friday, on a whim, I submitted Be Kind to Hacker News. Touchy-feely stuff tends to be hit-or-miss with that crowd, but it felt relevant. Much to my surprise, it hit the top of the front page within the hour and stayed there all day. And most of the next day. By the third day, it had only dropped to #22 or so. Insane. I’ve had a lot of people ask about the results, so I thought I’d quickly share some numbers.

Friday, on a whim, I submitted Be Kind to Hacker News. Touchy-feely stuff tends to be hit-or-miss with that crowd, but it felt relevant. Much to my surprise, it hit the top of the front page within the hour and stayed there all day. And most of the next day. By the third day, it had only dropped to #22 or so.

Insane.

I’ve had a lot of people ask about the results, so I thought I’d quickly share some numbers. Each of these is over the course of three days, or so.

  • 2429 points & 429 comments on Hacker News
  • 99,388 unique visitors to my site
  • 742 new subscribers to my newsletter, the Monday Mailer
  • 70 emails from new subscribers, followers, or folks just saying hi
  • 90 new followers on Twitter
  • Around 1600 mentions on Twitter
  • Three new followers on Medium
  • 4 hours before I turned notifications off on my phone 😱

I’ve been blown away — and thankful — for the incredible response.


Snapshot Tests + Blinking Cursors

It was Friday morning and I was already annoyed. One of our snapshot tests was failing. Randomly. Totally fine one minute, failure city the next. The snapshot was for a fairly benign login form. Present the view controller, call becomeFirstResponder on the first text field. What could possibly go wrong? Nothing in the test class seemed amiss. The build server was functioning normally. The test passed on my machine. Ready to give up, hours later, it finally dawned on me.

It was Friday morning and I was already annoyed. One of our snapshot tests was failing. Randomly. Totally fine one minute, failure city the next.

The snapshot was for a fairly benign login form. Present the view controller, call becomeFirstResponder on the first text field. What could possibly go wrong?

Nothing in the test class seemed amiss. The build server was functioning normally. The test passed on my machine. Ready to give up, hours later, it finally dawned on me.

The cursor. The damn blinking cursor.

For those not familiar, calling becomeFirstResponder on a UITextField immediately opens the keyboard and places a blinking cursor inside the text field. As it turns out, our snapshot test had been recorded when the cursor was visible. Well, maybe the build server was running a bit slower than usual, but that day the test ran when the cursor had blinked off. It was sheer luck we hadn’t run into it before.

Head, meet desk.


Disabling Slow Animations in the iOS Simulator

“There’s something weird going on with my simulator. Animations take about 100 times as long as they should. I have to wait 20 seconds to be able to click any buttons on a modal and then, once I do, I have to wait another 20 seconds for it to fade away.” There’s a funny — though extremely annoying — issue I see pop up on Stack Overflow and Reddit every few weeks.

“There’s something weird going on with my simulator. Animations take about 100 times as long as they should. I have to wait 20 seconds to be able to click any buttons on a modal and then, once I do, I have to wait another 20 seconds for it to fade away.”

There’s a funny — though extremely annoying — issue I see pop up on Stack Overflow and Reddit every few weeks. A developer fires up the iOS Simulator, eager to test their app, and discovers everything is moving really slowly. Modals take forever to appear and push animations slide across the screen at a glacial pace. It can be maddening. And unless you know what you’re looking for, it can be easy to miss the cause.

The iOS Simulator offers a debugging option titled — you guessed it — Slow Animations. If you’re working on a custom animation, it lets you see every frame and make sure everything is working as it should. The problem is: it’s incredibly simple to trigger accidentally. It uses a keyboard shortcut you might be familiar with: ⌘T. You think you’re opening a new browser tab but, surprise!

You can turn it off by navigating to Debug → Slow Animations, or simply hitting ⌘T once more.


3 Questions Every iOS Intern Needs to Ask

If you’re a junior developer, two weeks into your first internship, I’d wager you’re probably feeling more than a little frustrated. You spent the first week diving into the codebase — difficult, but at least now you have some sense of what the hell is going on. But now you’ve been tasked with integrating a new feature — or three — and you’re struggling. You’re unsatisfied and disappointed in your meagre output.

If you’re a junior developer, two weeks into your first internship, I’d wager you’re probably feeling more than a little frustrated. You spent the first week diving into the codebase — difficult, but at least now you have some sense of what the hell is going on. But now you’ve been tasked with integrating a new feature — or three — and you’re struggling. You’re unsatisfied and disappointed in your meagre output. Chances are, if you’re at a young startup, there isn’t even a senior developer you can turn to for help. You’ve been dropped in the deep end and left to fend for yourself.

It’s a situation that plays out every year. Eager students jump at what seems like a great opportunity, only to discover they’ve been set up to fail from day one. The good news? It’s avoidable. Here’s three things every student needs to ask their potential employer before signing up for an iOS internship:

1. Who will I be reporting to?

You should be paired with a senior developer who can serve as a mentor, as well as a sounding board when you run into problems. You’re looking for someone who will review your code, improve your skills, and help you navigate your new workplace. They should view helping you become a better iOS developer as one of the core parts of their job — not a chore. Ask if you can meet your potential new boss — even 15 minutes of conversation will give you a good idea of who they are and how they approach mentoring junior developers. Are they friendly? Honest about the company? These are good signs.

If you discover that you would be working alone, or with minimal interaction with the rest of the team, run. Good employers understand that hiring an intern is an investment. Leaving them to fend for themselves, or worse — treating them only as cheap labour — is a surefire way to burn them out, produce crappy code, and drive them to quit.

2. What sort of results would I be expected to deliver?

(Bonus question: How will those expectations change over time?)

Good employers know it will take an intern some time to ramp up and be productive. Actually, that applies to any new developer — regardless of skill level. You shouldn’t be expected to start banging out complex features the moment you walk through the door. That isn’t to say they shouldn’t expect greatness from you, eventually. But they should know it will take a little while to get there.

If their expectations for a junior iOS developer sound wildly unrealistic, it’s time to move on. Many employers mean well. But your first internship should be at a company that has a history of working with junior developers and knows what it takes to make them successful. They already “get it”.

3. What will my hours be like?

Many developers, regardless of skill level, like to be a hero. They work well into the night, cranking out code at a furious pace. When faced with impossible deadlines, they take pride in doing whatever it takes to get the job done. Junior developers can be especially prone to taking this approach, eager to prove themselves. As David Heinemeier Hansson puts it, “When there’s a crisis, it can pay to just carry on no matter what. Get the problem solved and celebrate victory. Winning through shear effort.” Early in your career, however, it can be difficult to distinguish between a true crisis and struggles that are a normal part of learning.

David continues, “But most days are not like that. Most features need not heroes. They need realists.”

Good employers understand that while working crazy hours can pay off in the (very) short term, the returns diminish rapidly. They know that, often, the best thing you can do is close your laptop and go home for the night. An internship shouldn’t feel like a work camp. You can’t learn effectively if you spend all of your time just trying to stay above water. If your potential employer doesn’t encourage their staff to have lives outside of the office, it’s a big red flag. It’s fine if you want to go above and beyond — in fact, I encourage it — but that’s something you can only do if you aren’t already pushed to the limit.

Use this checklist before saying ‘Yes’

You’re considering an offer for your very first iOS internship. Before you accept, run through this checklist:

  1. Will you be paired with a senior developer?
  2. Have you had a chance to meet your new boss/team ahead of time?
  3. Are there realistic expectations of your output? Especially in the first few weeks?
  4. Is there a plan to help you improve your skills over time?
  5. Will you have a life outside the office?

Obviously this checklist isn’t comprehensive — you’ll have your own requirements and red flags. But if you find an employer who checks off each box, you’re in a great spot. Good luck out there!


How to Enable Developer Mode Using the Terminal

“When I used Xcode for the first time, it asked me if I wanted to enable Developer Mode, but I refused. Now I realize that it is really annoying to type my password so many times.” When you run Xcode for the first time on a fresh system, it asks if you’d like to enable Developer Mode. Developer Mode allows Xcode to execute common debugging tasks without constantly asking for your password.

“When I used Xcode for the first time, it asked me if I wanted to enable Developer Mode, but I refused. Now I realize that it is really annoying to type my password so many times.”

When you run Xcode for the first time on a fresh system, it asks if you’d like to enable Developer Mode. Developer Mode allows Xcode to execute common debugging tasks without constantly asking for your password. If you decline the prompt goes away, never to be seen again.

If — like our friend above — you grow tired of those damn password prompts, you might be hard-pressed to figure out how to enable Developer Mode later on. There used to be a button in Devices → My Mac, but recent versions of Xcode seem to have removed it.

Have no fear. The Terminal is here to save the day. Fire it up and enter:

DevToolsSecurity -enable

You’ll be prompted for your password. Enter it, and those pesky password prompts will be banished forever.


Draftly: Now Available!

Good morning, everyone! I’m happy to announce that Draftly, my new Dribbble client for Apple TV, is now available! To download it, head over to the App Store app on your Apple TV and search for “Draftly”. Once you find it, just click that big, beautiful pink icon 😀

Good morning, everyone! I’m happy to announce that Draftly, my new Dribbble client for Apple TV, is now available! To download it, head over to the App Store app on your Apple TV and search for “Draftly”. Once you find it, just click that big, beautiful pink icon 😀


Introducing Draftly

I love Dribbble. I don’t post regularly, but hardly a day goes by where I can’t be found browsing the latest and greatest from designers all over the world. I wouldn’t call myself a designer — more of a “design-minded engineer” — but Dribbble is a source of constant inspiration for me. I also love the latest Apple TV. It supports my extreme Netflix habit while offering a platform for tons of great apps and games.

I love Dribbble. I don’t post regularly, but hardly a day goes by where I can’t be found browsing the latest and greatest from designers all over the world. I wouldn’t call myself a designer — more of a “design-minded engineer” — but Dribbble is a source of constant inspiration for me.

I also love the latest Apple TV. It supports my extreme Netflix habit while offering a platform for tons of great apps and games. I’ll often fire it up when I have a spare 15–30 minutes and watch movie trailers, catch up with CBC News, or browse the latest cinemagraphs from the amazing Flixel community. To me, the Apple TV offers the perfect blend of entertainment, news, and utility.

Some of you might see where I’m going with this.

On February 28th, wanting to up my tvOS game, I started work on a Dribbble client for Apple TV. Today, I’m proud to announce that v1 is done. Say hello to Draftly.

A quick tour through some of the functionality offered in Draftly v1.

Draftly makes it easy to browse work from designers, illustrators, typographers, and artists around the world. Right from your couch. Optimized for the living room, Draftly omits unnecessary features and cluttered interfaces to keep the focus where it should be: browsing the best design work Dribbble has to offer.

My goal was to create a Dribbble client for Apple TV that was perfect for me. That meant stripping out a lot of stuff that, on a different platform, might be considered essential.

I spent _forever tweaking this screen. I think it was worth it._

Want to kick back and browse amazing work? Draftly has you covered. Want to read every comment on a Shot? Organize Shots into Buckets? Scroll through long lists of everyone who liked something? Sorry, Draftly ain’t for you. I know there are probably lots of people who want to replicate Dribbble’s web experience on their television screen. I’m just not one of them.

Instead, I tried to create a Dribbble client that felt at home on Apple TV.

Here’s some of what Draftly does offer:

Large Images + Animated GIF support

Perfect for browsing from the comfort of your couch.

Draftly has ’em all.

Top Shelf Support

Popular Shots, right on your Apple TV’s home screen.

This might be the feature I’m most proud of.

Full-Screen Mode

For when you really want to appreciate the little details.

Detail Views

Views, likes, comments, tags, description, and more.

Profile Views

Easily browse the profile for any user or team.

I’ve really enjoyed using Draftly on my Apple TV — and I hope lots of other people will, too. I’m happy to announce that Draftly will be available on the Apple TV App Store — completely free — on Monday, April 18th, 2016 at 9am EST.

I’d be remiss if I didn’t thank a few people:

  • My wife, Steph, for her support and understanding through some pretty late nights at my laptop.
  • The fine folks at TWG, for tons of encouragement, help, and advice.
  • Everyone who has helped beta test Draftly over the last three weeks. Their feedback helped improve the app immeasureably.

And this is just the beginning. I’m far from done. I already have a long list of improvements I’d like to make, and new features I’d like to add. I expect to be working on Draftly for a long time to come.

If you’d like to follow along, or learn more:

And, of course, you can get in touch with me at me@briangilham.com or on Twitter.

Thanks for reading!

P.S. Want to try Draftly before the public launch? Here’s five promo codes. Redeem one on your laptop or iOS device, then check out the “Purchased” tab on the Apple TV App store to grab a copy.

http://tokn.co/h5fv9d5y
http://tokn.co/ed5kmzag
http://tokn.co/zhe3zepr
http://tokn.co/ty4reafq
http://tokn.co/vu8mhsnm


Burning Out

(I’ve received a fair number of lovely, concerned messages since publishing this piece. While I appreciate all of the love — a ton! — I feel like I need to add a bit of a footnote. I left the job I described in this post almost five years ago. My current gig, at TWG, couldn’t be better. I’m extremely happy and my work-life balance is much better now. In many ways, this post is a warning.

(I’ve received a fair number of lovely, concerned messages since publishing this piece. While I appreciate all of the love — a ton! — I feel like I need to add a bit of a footnote.

I left the job I described in this post almost five years ago. My current gig, at TWG, couldn’t be better. I’m extremely happy and my work-life balance is much better now.

In many ways, this post is a warning. If you are in a job that’s destroying your life, I hope it gives you the push you need to quit. If you’re a junior developer, looking for your first job, I hope it helps you avoid a similar situation.)

In 2009 I accepted a position as a Web Developer at a medium-sized marketing agency in Toronto. The pay sucked, but we had interesting clients and a really fun team. The perks were outrageous. The company-supplied beer flowed freely and we often retired to the local pub and partied well into the night. On the company dime, of course. One year, in lieu of a Christmas party, they sent us on a weeklong ski trip in Quebec.

I was blown away. I had never seen perks like that before.

Two weeks in, my team lead asked me to stay late. Our project was behind schedule and a new one was coming down the pipe. Sure, I said, cracking a beer. No problem.

We shipped.


The timeline for the new project seemed impossible. The biz dev team, eager to sell, had shoved it down the pipe in record time. Four weeks worth of work; due in two. Oh well, I thought, I’ll just have to work harder.

It took 18-hour days, countless energy drinks, and a ton of fast food, but we got it done.

We shipped.


Near the end of my probation I approached the team lead.

“Is it like this all the time?”

No, he said. This is the exception; not the rule. I took him at his word.

They gave me a raise. A year later, drunk at a Christmas party, he would admit they only gave it to me so I wouldn’t quit.


Another late night. It took everything I had, but I managed to clear my plate for the day.

11:30pm.

Fuck. I lived an hour’s drive from the office. At any rate, I was too tired to drive home safely.

The company put me up in a hotel room for the night. Paid for the cab ride and everything.

That was nice of them. I think.

We shipped.


Our project manager was crying. Again. Sobbing into the phone, she apologized to her boyfriend. No, she wouldn’t be home tonight.

Yes, she said. She should quit.

Someone paid for dinner. Again.

We shipped.


I’d been at the office for 48 hours with no sleep. I finally decided to drive home. To shower and change. I didn’t know it then, but I’d end up driving back and working for another 24 hours.

Driving home just to change my clothes started to feel like a real pain in the ass. I started keeping a change of clothes, toothpaste, a toothbrush, and deodorant in my desk drawer.

Perfect. Now I don’t even have to leave.

We shipped.


I’m in bed. Well, a mattress on the floor. I’d spent a few days preparing to move and started feeling ill. My stomach was a mess, my head was pounding. My throat felt like it was being stabbed with a knife. I could barely stand up. My fever was off the charts.

For the next two weeks, I barely stood up.

Lying on your back for two weeks gives you a lot of time to think. To think about your health. Being a team player. Free beer and ski trips.

I wish I could say that I decided then and there to quit. But I didn’t. I stuck it out for another year.

Another year of working all night.

Another year of missing moments with my loved ones.

Another year of eating shit food and brushing my teeth in the office bathroom.

Another year of “taking one for the team”.

Another year of: We shipped.

Those perks I loved in the beginning? By the end I saw them for what they were.

Chains on the door.


No Boots in the Canoe

About nine years ago, a girlfriend and I went camping in Bon Echo Provincial Park. Accompanied by a couple of friends, we spent our time hiking, sitting by the campfire, and swimming at the beach. We were having a lovely time. One morning, she suggested we rent a canoe and take it out on Mazinaw Lake; famous for an escarpment adorned with native pictographs. We had both canoed separately — this would be our first time doing it together.

About nine years ago, a girlfriend and I went camping in Bon Echo Provincial Park. Accompanied by a couple of friends, we spent our time hiking, sitting by the campfire, and swimming at the beach. We were having a lovely time. One morning, she suggested we rent a canoe and take it out on Mazinaw Lake; famous for an escarpment adorned with native pictographs.

We had both canoed separately — this would be our first time doing it together. I didn’t know it then, but canoeing is like taking a vacation or shopping at Ikea. If you aren’t 100% sure your relationship is ready for it, best avoid it altogether.

The trouble started as we approached the water. She had brought her digital camera along for the trip. I pointed out the obvious conflict between water and expensive electronics. It’s okay, she said, “I’ve never tipped a canoe.”

I can’t remember if I mentioned the numerous times I had.

Bringing the camera seemed like a risky move. But in the process of preparing to head out, arguing back and forth, I made a critical mistake of my own. I forgot to remove my boots.

It’s here I should point out these weren’t your average hiking boots. Back then, whenever an occasion called for boots, I wore thick, heavy, steel-toed boots; a relic of my days working in maintenance gigs. Imagine wearing cinder blocks on your feet and you start to get the idea. This becomes important later.

Donning our life jackets, we settled into the canoe and pushed off. Her up front, me in the back. Despite the impressive capabilities of the modern canoe, things felt immediately unstable. When first learning, I was taught to sit with my legs tucked under my seat. This, I was told, would provide maximum stability. Looking ahead I noticed my companion had neglected this crucial step.

Being the helpful (read: annoying) sort, I offered some advice: “If you stick your legs under you we’ll be more stable, ya know.”

With a quick turn of the head she replied, “I’m going to kill you.”

She barely had time to turn back around when — our weight now shifted dangerously to one side — we went into the drink. Splash. I’m fairly certain the timing was coincidental, though I can never be sure.

Upon surfacing, the real troubles began. Worried about her camera, she removed her life vest and began diving for it. A pointless venture — Mazinaw is the second-deepest lake in Ontario. 135 feet, on average. I hurriedly collected what I could and started the swim back to shore.

It’s likely you’ve never been stupid enough to attempt swimming in steel-toed boots. It’s tiring and ineffective, to say the least. After a few feet, and feeling a bit panicked, my brain reached an odd conclusion: clearly, the object most limiting my ability to swim was my life jacket.

Not my boots.

The life jacket.

You know, that thing that keeps you afloat. Designed for exactly this type of scenario. Saves lives each and every year.

Off it went.

“Now I’ll really be able to get moving,” said my stupid, stupid brain.

I had just as much trouble swimming as before, of course. Except now I had the added benefit of, well, starting to drown a little bit. Comically close to shore. I was exhausted, spending what little energy I had simply trying to stay afloat. It wasn’t working very well.

When someone is drowning, it doesn’t look like drowning. The brain considers your respiratory system’s primary function to be breathing. And rightfully so. When you have a lack of oxygen, or even a perceived lack of oxygen, screaming and shouting doesn’t rank highly on the brain’s list of priorities. Speech is secondary.

Thankfully some children were passing by in an inflatable raft, completely oblivious to my situation. Without warning, I grabbed ahold of the raft and sucked back as much air as my lungs would allow.

Once I’d gotten my bearings I apologized profusely, kicked off the boots, and continued to shore.

It’s so easy to get wrapped up in the wrong things in life. We argue with loved ones about meaningless offences. Pressured at work, we rush through our tasks. We think we can do everything, and then some. In our haste, we often make stupid mistakes. We hurt those we love most. We disappoint clients and bosses with sub-par work. We burn out, forced to realize the limits of our time and energy. I’m as guilty of it as anyone.

But when I find myself in those situations, I’m teaching myself to stop, breathe, and take a moment to think.

And to remember that somewhere, deep in Mazinaw Lake, lies a pair of boots and a digital camera.

No boots in the canoe, this time.


Open in Helium

I’ve become a huge fan of Jaden Geller’s Helium. I recently moved to a one-monitor setup, substantially cleaning up my Minority Report-esque workstation. Previously, I played tutorial videos and the like on a second monitor. Now, I use Helium to overlay them on my current work. It’s fantastic. But one thing was bugging me. Every time I came across a video I wanted to watch I had to: open the link in my browser copy the URL from the location bar launch Helium open the “Open Web URL” menu paste the URL hit enter It may not sound like much, but on days when I watched a lot of video content it got a bit tiresome.

I’ve become a huge fan of Jaden Geller’s Helium. I recently moved to a one-monitor setup, substantially cleaning up my Minority Report-esque workstation. Previously, I played tutorial videos and the like on a second monitor. Now, I use Helium to overlay them on my current work. It’s fantastic.

But one thing was bugging me.

Every time I came across a video I wanted to watch I had to:

  • open the link in my browser
  • copy the URL from the location bar
  • launch Helium
  • open the “Open Web URL” menu
  • paste the URL
  • hit enter

It may not sound like much, but on days when I watched a lot of video content it got a bit tiresome.

Poking through Helium’s source code, I noticed it had the ability to be launched via the helium:// URL. Perfect.

Time to create a browser extension.

Since I primarily use Safari for my browsing needs, I started there. If you’re developing a Chrome extension — as I’d done in the past — there are tons of resources and tutorials available online. For Safari? Not so much. But, after a few hours of hacking, I put together something I’d like to share: Open in Helium.

Put simply, it adds a new item to your browser’s context menu. Right-click on any link, click “Open in Helium” and it will launch Helium for you. Done.

I may submit it to Apple’s Extensions Gallery, but for now you can head over to the GitHub repo to grab it and get started.

Admittedly, the number of people using both Helium and Safari is likely fairly small. But this extension has improved my experience of using them together a ton — I hope it does the same for you.


Breathing Room

I’ve spent the last six months quitting things. A successful Apple Watch design & development newsletter? Quit it. My two most profitable apps? Quit ’em both. Blogging about things like Apple Watch & Apple TV development? Quit and quit. Speaking gigs? Hell, I quit one just the other day. Why all this quitting? I realized I was over-extended. I was doing too much. Too much “should”, not enough “must”. It was time to make a change.

I’ve spent the last six months quitting things.

A successful Apple Watch design & development newsletter? Quit it.

My two most profitable apps? Quit ’em both.

Blogging about things like Apple Watch & Apple TV development? Quit and quit.

Speaking gigs? Hell, I quit one just the other day.

Why all this quitting? I realized I was over-extended. I was doing too much. Too much “should”, not enough “must”. It was time to make a change.

None of them were making me say “FUCK YEAH!”, so I decided to start saying no. If something didn’t fill me with excitement or joy, I removed it from my life.

Now I have the margin (both mentally and physically) to figure out what 2016 — and beyond — is going to look like. Without the addiction to constantly doing more, I can finally stop, rest, and figure out what’s important. What brings value to my life — and how I can bring more value to those I care about most.

It feels healthy.


The End of WatchKit Resources

I’ll keep this short. I will no longer be publishing WatchKit Resources, my collection of curated Apple Watch design and development links. The community simply isn’t active enough to warrant a weekly publication. I hope that changes, eventually. Over the course of just over a year, I published 225 blog posts, released 16 newsletter issues, and had the opportunity to check out some of the amazing work being done by developers like Natasha Murashev, David Smith, and Kristina Thai.

I’ll keep this short.

I will no longer be publishing WatchKit Resources, my collection of curated Apple Watch design and development links. The community simply isn’t active enough to warrant a weekly publication. I hope that changes, eventually.

Over the course of just over a year, I published 225 blog posts, released 16 newsletter issues, and had the opportunity to check out some of the amazing work being done by developers like Natasha Murashev, David Smith, and Kristina Thai. To anyone who took the time to follow along: thank you.

I truly appreciate it.