So you booked some developer time with me?

Thanks for booking some developer time with me! (If you just wandered in from the interwebs, that's ok, too.)

Please read through this, so that we can start on the same page and ready to work together.

Getting the most from your money

You probably want to get your project done in as few hours as possible. That saves you money, and gets your spiffy new features (or bug fixes) available on your site soonest. Although I'm getting paid hourly, I'm usually fully booked, so I want your job done so that the client after you can get their job done on time, too. I also dislike having time wasted, even if I'm getting paid while it's happening. With that in mind, the following will save you money & time:

• Providing all the access I need, before your scheduled time starts.
• Providing clear directions for what you want, ideally organized as tasks.
• Know what you want before we start, so that you can provide those clear directions.
• Choose the right type of communication. More on this below.
• Respond to questions and feedback requests promptly.

Let me know your priorities

Especially if your budget is tight, please be sure to let me know what your highest priority tasks are. I want to make sure I do the work that's most important to you first. I'm also happy to provide a rough guess-timate of how much time a given task will take, so that you can decide which tasks are worth the cost.

What if we run out of time?

If it looks like we aren't on track to do the full project, I'll let you know. I won't go over the hours you scheduled without checking with you. If your project just needs another hour or two and you agree to the additional cost, I can generally squeeze that time in at the end of the scheduled day or within a day or two. However, if you book a day and need five (yikes!), then you'll need to book additional time from my calendar. As a result, I encourage you to book the upper end of what I estimate that we'll need. We can square up at the end.

How I work

Context

If you spend much time around software developers, you'll notice that we talk a lot about context. Context is all the information needed to do the job at hand (programming something cool). [Lately, you might have heard about AI context windows. Same idea. More context = better results.] It's hard to hold all the information needed for a project at once. So developers (including yours truly) use the following approaches:

• We break work into chunks or tasks. More on this below.
• We try to deal with one chunk at a time, so that we can hold the full context for that chunk in our brains.
• We avoid context switching. Switching between chunks of job can require reviewing previous work, checking notes, re-opening a couple tabs of documentation, switching git branches, and more. It's time-expensive. Whenever possible, you should try to avoid making your developer context switch unnecessarily.

Communication

I'm happy to communicate with you however you like, but in general, we need a few types of communication.

• Task tracking: If there's something specific you want me to do, we should have a task for it. I can make it, or you can make it, but one of us should.
  • The best tasks have a descriptive title and exactly one work item in them. If there are four unrelated changes you want, you should generally make four tasks. That way I can check them off as I get them done, and I can see at a glance what the task is. I love checking off tasks, so feel free to make lots of little ones. I don't mind.
  • Grouped tasks are great. In Asana, feel free to make new sections to organize related tasks. That helps me knock out related tasks while I have the needed context already loaded.
  • The best tasks have the information I need attached. If there's a layout bug, a screenshot of the problem is super helpful. If a particular page looks wrong, please include the URL. If you want me to use your brand colors, please attach them.
• The right place for new tasks is task tracking. Not email. Not chat. Not a comment in a Google doc. Not a video call. While we can discuss a new task on a sync call, the task still needs to get into task tracking, or else I will lose it. (The task, I mean.) You can make the task, or I can do it, but one of us must. A better approach might be to add the task first, then have a call only if it isn't clear.
• I primarily pay attention to tasks that are assigned to me and open. If I've closed a task but you want changes to it, please reopen it and leave a comment!
• If a task is assigned to you, it means I think it's something you need to do, or a question I need you to answer.
• Quick async communication: It's helpful for us both to have a way to ask a quick asynchronous question or send an update. I generally prefer async messaging (like Slack, Google Chat, etc) because it allows me to avoid context switching if I'm right in the middle of something tricky. We can use email if you prefer it, but delivery delays make this a little less efficient.
• Synchronous communication: Sometimes, we need to talk. Given the nature of web development work, that almost always means a video call, so that we can look at a screen together. I'll ask you for a call if it seems like async communication isn't getting the clarity I need. However, calls are also the most disruptive to my development workflow. So please, don't make a call the default way to communicate with me. If you can make it a task or a message instead, please do.

What does the day look like?

• A couple days before our scheduled time, you'll get an email from me that I've set up Asana and am starting to load tasks into it. Please make a few minutes to review what's there for errors, omissions, and questions.
• During your scheduled time, I plan to be at my desk, doing your work. You'll see changes in Asana fairly regularly (smaller tasks mean more changes to see), and an occasional asynchronous chirp from me if I need something. If you send me a message, you'll get a response within a couple minutes. We can have a call whenever you want, but time on a call is time not coding.
• If I'm going to be away from my desk for more than a minute or two, I'll drop you a quick chat message that I'm clocking out. I typically take a break every 2-3 hours to get up, eat something, move a bit, etc.

You can make my life easy or hard. Choose easy.

I switched over to billing hourly because I got tired of being the penalized when clients were disorganized. You can be as disorganized as you like, but the meter is running while I'm trying to figure out which of 50 emails contains the information I need, or asking for access or information I should already have. Maybe don't do that, especially if you want your job done on time and under budget, ok?

It's fine to change your mind about what you want, or to come up with some additional changes during our work together. Just be aware that this can increase development time, and may result in us not getting everything you want done within the scheduled time.

Before your first day working with me:

• Make sure I have the access I need:
  • Access to Ghost (almost always needed). Either:
    • An admin-level invite to your Ghost site OR
    • An export of your content (established sites) and a copy of your theme
  • Admin/developer access to any other platforms you've asked me to work on, such as Stripe, Zapier, Google Search Console, Google Analytics, etc etc.
  • If you're going to need DNS changes (you're moving a domain), make sure you have your login information for wherever your nameservers are. (This is probably your domain registrar. Unless it isn't.)
• Let me know about any preferences for organization. My default is Asana, but I'm willing to work on your platform of choice. Please let me know about a week in advance, before I do the work of setting up Asana for your project.
• Let me know about any preferences for communication. My default is Google Meet for sync calls, but you can invite me to your platform of choice instead. I am happy to do messaging over Slack, Zoom, Google Chat, Discord, etc. Just let me know your preference.
• Let me know whether you'd like me to stand up a development site for you to review changes (recommended for busy live sites), or whether I can push changes live to your site for your review. There's some extra work involved in moving content and settings between development and live, so if your site is not live or is low traffic, I recommend reviewing changes on your live site.