Putting Down the Tools

by Marcus Blankenship on May 30, 2015.

Putting Down the Tools, Avoiding the #1 Mistake All New Software Company Owners Make in a Crisis

Yes, we’ve all done it.

I’ve done it. My previous managers have done it. And most likely, it’s the default setting for many battle-worn team leads.

In those crisis moments when expectations are high, everything is going off the rails, and the deadline was yesterday, all new tech agency owners will utter one fateful sentence.

It would be so much faster if I just did this myself.

Then they pick up the IDE, close the office door, and retreat into the code.

What they don’t realize is that they’ve just kicked off a chain reaction of negative work practices that will plague their team for months.

Save Yourself

As you probably understand all too well, the programming world is full of fires to extinguish. No matter what your company’s size or specialty, you are going to hit many, many pressure cooker days.

It’s up to you to anticipate the inevitable before it happens and make a firm, conscious choice not to try to code your way out of a crisis.

Why We Make This Classic Mistake

Making the switch from programmer to owner-manager can be flat-out awkward at times. You’ve gone from playing in the orchestra from leading it, which really shakes up your identity.

The most significant shift comes with the realization that you’re no longer a production unit, but you’re still working in an industry that values production. If you’ve always taken pride in the tidy transaction of being paid for your output, management is a strange new world.

Mixed Messages

First off, while having your name on the door is a much-coveted status symbol, deciding to run your own shop carries a built-in mixed message. It’s as if you’re telling yourself, ” I’m such a great programmer that I can go out on my own… and spend less time coding! Now doing less coding often feels like you’re doing less altogether or that you’re not contributing to the bottom line, especially when you’re just starting out.

Dependent on Others

Then there’s the new reality of how production happens. As a programmer, your brainpower and clever workarounds could conjure magnificent code from your fingers.

The programs you created could keep manufacturing production humming or bring it to a standstill. Entire businesses hung on your creations.

Now you’re dependent on other people to create the code that works this magic. And making the switch from creating your own technological incantations to supporting other people’s efforts really feels awkward for a while.

It Gets Worse

That clumsy beginner’s feeling gets cranked up when you face the new aspects of team dynamics and the reality of being without your most powerful weapon: your ability to code.

But you really get triggered by array of new expectations staring at you, like:

-Figuring out your clients’ agendas
-Assigning work to peers or former co-workers
-Dealing with morale speed bumps
-Steering through software quality problems–as the person who’s supposed to have all the answers

Adding a management role to the rest of your responsibilities can feel like stepping into a plane’s cockpit without any flight training. There are all these complicated, unfamiliar dials and gauges you don’t understand, and you don’t know if that blinking light means an engine has failed or the coffee’s ready.

In order to escape this anxiety loop, many business owners new to management fall into one of two patterns:

1. Code less, but indulge their coding desires by putting out fires and debugging whenever possible.
2. Code even more intently, blocking out team members and undermining their credibility as a leader.

Each of these positions is a pattern that will cause you to fail.

Let me say it again. Retreating to the position of “I’ll do it myself” isn’t going to save you any time or frustration. It’s only going to crank up the problems.

‘I’ll Do It Myself’: Say Hello to a Cascade of Problems

Once you’ve uttered those fateful words, you are no longer doing the job you were paid to do: leading. And if you’re not doing your job, especially when your employees need your leadership most, then no one is.

If you follow through on your natural desire to just do it yourself, you’ve chosen to avoid doing the following critical items:


Checking in with your team members and other principals is the heart of your work. But chaining yourself to your computer stops that cold. Suddenly, you’ve cut off any discussions about quality, progress, or individual development. Everyone loses.


Jumping in to correct someone else’s work not only short-circuits their learning process, it teaches them to do substandard work. Pretty soon they only turn in partially completed work because they figure you’ll just redo it anyway.

“Why bother?”, they think. They lose their drive, you lose their trust, and projects start to suffer.

It’s like a conductor wrestling the tuba away from the tuba player


When you move back into production mode, there’s no one available to keep team moving forward. Essential work like status updates, work review, and new project preparation is completely out the window until you pick your head up.

You’ve just traded away hours of non-replaceable time and energy that should have been devoted to doing the job you’re hired to do. And when you get back to the work that’s been piling up on your desk, you’ve got to dig out all over again.


Let’s be honest. It feels great to be a hero, swooping in to save the day with a brilliant solution. But the cost is just too high.

A “quick fix” always takes much longer, turning your one-hour job into six hours (or more!) of panicked coding. While you code up a fix, your resentment and exhaustion build, and you’re teaching your team to depend on your last-minute efforts to bail them out instead of their own skills.

Management Skills

Running to your comfort zone feels safe, but it’s a very limited strategy that keeps you from making the changes necessary for you to be a good manager.

Trust me. Take a chance, drop the IDE security blanket and interact with your team instead.

Best Practices for Crises

While you’re waiting for your team to complete their work, you don’t need to sit passively or beat them with the boss stick. Here are a few tips that will keep you sane and your team on track.

Don’t Do it Yourself

If there’s a problem that you desperately need to rework, don’t do it yourself. Grab a programmer and say, “Let’s review this code together to fix it.”

Sure, you just scratched your itch by getting involved, but you’ve also established much-needed rapport and created up a teaching moment—for both of you.


Panicked about a deadline? Get a status update from the programmers, adjust the workload if needed, and contact the client to give them an update.

Once again, you’ve opened lines of communication and placed your focus on the overall project, not just your team’s to-do list or your stress.

OK, Go Ahead And Code…

Can’t keep yourself away from temptation? Fine. Then code. But don’t code anything that will be used in production.

I cannot emphasize this enough. If you absolutely, positively can’t resist, then choose a project that is on the back burner. You don’t want to muck up a project in process.

This Is About the Long Game

Great management practices depend on a solid, thoughtful foundation created outside the heat of crisis. But it’s worth remembering that reputations are earned and character is uncovered during crucial, adrenaline-filled moments.

Remember that your purpose as an owner-manager is to create a team that is capable of producing excellent code.

In those instinct-driven moments, especially in beginner’s panic, please take a step back. Avoid this classic management blunder.

How to hire an iOS Developer

by David Tate on May 28, 2015.
You sat down to work today and see *Find an iOS Developer* staring back at you from the top of your todo list. This isn’t a straightforward task like “complete expense report”, “buy new coffee filters” or “fire Ralph” - this will take time, technique, and steady effort to complete.

First, the bad news: iOS developers are in high demand and have gone into hiding only coming out for interesting projects and to attend the WWDC. When you find a good one they can be very pricey.

But then the good news: Because of the obvious demand there are also thousands of people trying to join these group of talented recluses. But the challenge for you is to find members of the first group: experienced, talented, motivated and not the second group: inexperienced, looking to work on their first real project.

But first let’s talk about you.

Do you need an iOS Developer (yet)?

An iOS developer should be hired when you have a clear understanding of what you want and have decided that it should be for the Apple mobile market first (or in total / only). Do you know much about your target market - do any of them use Android? If so then hiring for iOS will not easily allow you to later support them; you might want to instead look into PhoneGap or equivalents.

Do you know exactly what you want?

Do you have an idea or a plan? You are competing for developers and one of the signals you send to people who listen to your offer is how well thought-out your project idea is. Did you just dream up something that you think would be cool or have you proven that there is a market for the product and know exactly how it will work? Do you have mockups yet of what it should look like? With tools like Proto.io and Invision you need no development experience yourself to create something that looks (and acts like an app on your phone!) to validate the user interface.

A solid iOS developer will entertain multiple project offers and you want to stand out as professional, hard-working, and with a fleshed-out plan. Your project should feel that it already has momentum and its success is an inevitability.

Let’s talk about candidates again.

Vetting Candidates

Let’s assume that you post to one of the millions of free-for-all job posting boards that serve as the new age classified ads. Your inbox is then full of developers awkward cover letters and details of their experience with technologies you have never heard of.

How can you tell if you are:
- Talking to someone with experience?
- Talking to someone that can actually complete your project?
- Someone that can communicate clearly with you in regards to the details of the user interface, project status, and any problems faced during the build?
- Talking to a real person and not a dog trained by a talented prankster?

Research online presence

Developers have a number of tools with which they can show general competence in technical and non-technical areas. Look into each candidate's online activity:
- Blog
- Github or other shared code
- Twitter profile

You don’t need to do any private investigation-style research here - you are looking to see if their blog or code contributions match the general tone of a professional, match with their declared level of experience, and don’t contain any odd red flags.

Look in more detail at code contributions

Open source is a great way to vet candidates - you can look at actual projects that they have built and use them to ask questions about challenges faced and areas for improvements. Open source contributions are a clear way to tell see who is active and hustling in the developer community. Watching popular projects is a good sign, committing to projects is a better one, and being the creator of projects that are used by others is the best tell that you are dealing with a good candidate.

Components Built and Used

Not all code can be shared though - working for big companies means that some developers are quite good but simply aren’t allowed to show it publicly.

This doesn’t mean you shouldn’t ask what they would pull off the shelf for a new iOS project. After giving them a few details about your project ask them where they would start at a technical level. What components would they use for authentication, logging, UI components, caching, network handling, testing, etc.?

Feel free to also ask about specific commonly-used libraries like AFNetworking, JSONModel, DateTools, etc. as well.

Complete Lifecycle Experience

An experienced iOS developer will have some pet apps that they have developed in the app store - either to make money or simply built when they were learning the platform. Ask them to showcase some of these and talk over the challenges they faced. Compared to all other development ecosystems the app one has the lowest barrier to entry: developers can directly make money from their work by only trading their time. What challenges did they face once the app was live?

Tool Opinions

A new developer loves everything about a tool, platform, or language while an experienced developer complains about its limitations. This is part of the experience lifecycle:
- You love it but feel like you don't fully "get it"
- You learn a good deal and start to realize the limitations of the new thing
- You master all the strengths of the tool, and start to feel the weaknesses
- You are challenged by the weaknesses and they frustrate you.
In that way very experienced people sometimes come across as hating the thing they use everyday while also quietly respecting it.

A good way to detect this phenomenon is to simply ask:
- What do you not like about Objective-C itself? How about Swift or Cocoa Touch?
- If given the chance how would you change the XCode interface?
- You are king for a day - how do you change the app review and feedback process?

Are They Constantly Learning?

Ask them about their first iOS project and things that they would do differently now versus in the past. Ask them what the last technical blog post, book, or talk they consumed that changed their knowledge was. What resources do they use to stay up to date with new tools, components, and techniques? How much do they know about WatchKit or HealthKit?

A Better Path

You could do all these things, roll the dice, and hope that your developer gets the project done or you could use Gun.io where your job posting will be seen by a multitude of iOS developers pre-screened and ready to work.

Building a consultancy while living in Japan with Keith Perhac

by Jake Jorgovan on May 18, 2015.

Today I am honored to have an incredible guest on the show Keith Perhac.

Keith runs a digital marketing agency called Delfi-Net, and best of all, he runs the agency while living in Japan!

For the past 12 years Keith has been living in Japan while building up a business primarily with US based clients.

In this episode, we dive into Keith’s journey, how he got started and built the agency to the point where it is today.

There are a lot of great insights in here on building up a successful business and living a non-traditional lifestyle.

Mentioned in this episode:

APIs and Higher Level Abstraction of AWS SES

by Marcian Diamond on May 18, 2015.

Hello Fellow Developers! As we trek along deeper into the computing wilderness and climb to the higher rungs of development, we become keenly aware of the unfullfilled needs of the development community. These needs tend to be sated by brave souls who endeavor to author APIs. Some quintessential examples of this courage are jQuery, D3, and OpenLayers, just to name few.

Whats an API?

Well, we all know that it stands for Application Programming Interface. Thats easy. But...

What does it do?

APIs are a contract between the user and the API provider. Developers typically use the method signatures defined by APIs to handle program functionality without concern for the how the functionality is implemented. In Computer Science jargon, this is known as abstraction, hiding implementation details from users of the API. By authoring APIs we are creating tools for developers while taking our skills to the next level.

Why use an API?

For one, they are easy to use. Just invoke a function or method with the appropriate arguments and watch the magic unfold. Another important consideration is application configuration. APIs can save us much of our most precious resource, time, by providing well-understood and commonly-used functionality as well as encapsulating lower-level application details.

In this article, I will provide an actual scenario through which an API may arise to fulfill the needs of an application. We will examine how a simple API may be created to provide a higher level of abstraction for sending emails through AWS SES service. The purpose of this article is to demonstrate processes involved in creating developer tools.

The Problem

For over a year now, I've been developing a Flood Forecast and Warning System web application with the Santa Clara Valley Water District, located in San Jose. This application is still beta, but is to eventually allow site registrants to receive email alerts in the case of a forecasted flood event.

To implement this email alert functionality, I decided to leverage the Simple Email Service(SES) infrastructure provided by Amazon Web Services(AWS). SES offers developers several powerful solutions for sending emails.

My application simply needs to send an email that has been dynamically templated. For my purposes and from a developer standpoint, a simple sendEmail() function with arguments for recipients, sender, subject, and body is desirable, yet I couldn't find such a thing! All the available options provided by AWS require SES credentials, lower level SMTP configurations, and/or long query string formations to dispatch to the AWS SMTP endpoint. The closest thing to this ideal scenario that I could find was the Sending an Email Through Amazon SES Using an AWS SDK. The SDK does a swell job of encapsulating the lower-level details of email sending through the AmazonSimpleEmailServiceClient and SendEmailRequest objects, BUT all I want is a method with the signature:

boolean sendEmail(String[] toAddresses, String fromAddress, String subject, String body);

As you guessed, this method would send an email to the addresses in the toAddresses array and return true if successful an false if not so.

The Solution

This is an ample opportunity to create an API that is a higher level abstraction of the services already available through AWS SES. By doing so, It will allow users of the API to send emails using a sendEmail() function and they need not be concerned with the other low-level (but never dull) facets of SMTP and AWS SES. However, as the author of the API, these details must be known and understood!

Now, Amazon SES provides a simple, cost-effective way to deliver outbound-only email. There are two primary options available to developers for dispatching email messages through SES. The SES SMPT interface and the SES API. The SES SMTP interface is used with an SMTP-enabled software package, application, or programming language or to integrate SES with an existing mail server. The SES API is used to send email using raw HTTP(S) requests. The AWS SDK provides a higher level of abstraction for these raw HTTP requests, but the level of abstraction is not as high as we please.

Before we dive into hacking an API, its useful to follow some software engineering best practices. First, we should clearly understand the problem at hand. The problem is AWS SES doesn't provide us with a high enough level of abstraction for dispatching email messages. Next, we chew our pencil tips and stare blankly into space for some time to determine the best way to solve the problem. BOOM! All of a sudden, the solution is clear: we will author an API that leverages the already existing infrastructure of SES. Since we are only concerned with one thing, the API will provide just that: a single function for sending emails. Now if this API is realized, my dev team can be provided with the API and begin sending emails to their hearts content with minimal effort (most of the effort is undertaken by the API author/s)! In this context, the API author must have a working knowledge of the solutions provided by SES. Only with this knowledge (and coding experience) would an author be able to deliver an API providing a higher level of abstraction of SES.


Though I mentioned only a single sendEmail function for consumption by API users, there is plenty of room to develop more functionality over SES. How about this: client-side javascript that allows browser users to send email through a dashboard app? One solution is to have a javascript function that forms HTTPS query requests, using paramters from the user's input, and uses AJAX to dispatch the requests to the SMTP endpoint.

Sorry, I will not implement the API in this article (maybe a future article! Or even better: you can do it as an exercise!), I simply wish to demonstrate how the birth of an API may occur and how APIs make the lives of developers even more pleasant. By taking the next step from API consumer to API producer, developers further their skills in the field and provide assistance for fellow developers. As an author of a popular API, various opportunities to capitalize on your skills will present themselves! Happy Coding!

Charging $20k+ per week with Brennan Dunn

by Jake Jorgovan on May 12, 2015.

In this episode I am honored to have Brennan Dunn as a guest.

Brennan has built up an absolutely incredible consulting career charging rates of $20k+ for a single week of work!

In this episode, Brennan shares how he built up a consulting career to justify charging those rates.

Brennan also shares best practices for raising your rates and getting more clients.

Brennan is an absolute authority and leader in the freelancing and consulting space and his advice in this episode is absolutely invaluable.

I would highly recommend picking up one of Brennan’s books Double Your Freelance Rate. I bought a copy over a year ago and since then my rate has tripled! Brennan also offers an incredible free email course where he shares absolutely incredible insights. Sign up for it and I know you will get a love of value out of the lessons!

Learn and Earn!

Sign up for great tutorials, guides, rants, raves and opportunities to earn more money!