Investing time into developer tools

As I open source another framework this week, I wanted to share few thoughts about building developer tools.

Developers are lazy creatures, we like to automate stuff, we write scripts, use File Automation to get rid of repetitive work.

One would think that we’d use the same principles in our jobs, yet I’m constantly surprised how few developers actually invest their time into building tools and setting up processes inside their app to ease their day to day work.

Looking beyond the current state of union

I believe we should always try to find more efficient ways to do things, come up with processes and tools that can help us become more efficient.

This often requires us to think outside the box and what’s currently available on the platform.

You don’t need to wait for Apple to come up with new solutions, build them yourself.

My favorite quote applies here well:

You can have excuses or results. Not both.

Couple of things that were doable long before Apple added it to the platform, they might have been far from ideal but they allowed us to save tens of hours of development time:

If Apple decides to sherlock (implement) something you created for the community, you should not be sad, instead you should be happy.

If they did good job, you now have a tool that someone is paid to maintain and improve over the years, and this is something we should all be glad about as this gives us more time to work on another great idea we might have.

Small things

But even beyond that, there are often simple things I see developers do over and over again instead of making it easier.

Some common examples:

If your app requires login credentials:

Add a user breakpoint that fills them out and automatically progresses

Long-running features

If you are working on a feature that will take you a long time, configure the project so that when you run it, it will automatically jump straight to the screen you can test your feature on.

Again either via user breakpoint or by adding build phase script that will allow you to write code like:

#if merowing
    runMyFreakingFeature()
#endif

Reproducible environment

If you are working on an app that requires specific kind of data e.g. Images, make sure to build up a stubbed data source for it.

Especially since often times building those tools allows you to work:

using Simulator
without Network connectivity
with code injection

That way you can not only save time by not requiring to do manual steps, but you can easily test regressions in performance and functionality.

Feeds

Most apps consume external feed, instead of having to wait for your backend developers to deliver new features, write a stub data providers, or better yet use a framework I open sourced this week to be able to see how feed changes affect your app in real time.

If you architect your app in a functional manner, you should just need to replace your feed provider to leverage the file watcher:

let fileWatcher = FileWatcher.Remote(url: myDropboxURL)
try fileWatcher.start { result in
    switch result {
        case .noChanges:
            break

        case let .updated(data):
            myUpdateClosure(data)
    }
}

Is it worth it?

When we start considering whether to invest time up front to build something we might be tempted to postpone it until further if it’s low pain point, but be aware of boiling a frog?

If you plunge a frog into boiling water, it will immediately jump out. But if you place the frog into cool water and slowly heat it to boiling, the frog won’t notice and will slowly cook to death

Instead, ask some questions:

How often will I need to do it?
How long does it take?
How much time will it take to automate this?
How long before the invested time pays off?
Is doing this manually is annoying the crap out of me?

I often say YES, especially to the last point there, so I build a lot of dev tools and frameworks over the years.

Conclusion

Writing developer tools and setting up right processes requires time, but more often than not, that time pays off for itself with a big return on investment.

Especially if you work on a bigger team, the payoff can be huge.

If you are looking for inspiration, take a look what Orta, Olivier, Felix and Kyle build.