Yesterday I’ve announced that I’m gathering a team to build the mobile version of Pitch. The feedback was awesome, so thank you for all of the retweets, and especially if you’ve applied! I’m going through the list of applicants now.
This whole process is quite new to me, and I don’t really know if it’s going to work as I planned. I have some intuition to follow a certain direction. I need some smart experienced people who are willing to share the risk. I thought it would be helpful to explain more in detail how we’ll be working on this new thing. So here’s a long open letter to a fellow mobile engineer.
If you think this writeup is worth sharing, please go ahead and use your favorite social media means to do so!
My name is Misha, and I’ve been developing iOS applications for the last couple of years. I’ve been lucky to work with some brilliant people that built Wunderlist. Few other people consider it as one of the best todo apps on the AppStore. I think that’s very cool because todo apps are ubiquitous and there’s lots of competition. Last year with some of my former teammates we’ve started a new company called Pitch. At some point, we’ve raised the question who will build the mobile apps, and the choice naturally fell on me. So now I’m starting to gather a team that will bring Pitch to the plethora of smartphones and tablets available out there.
Building Wunderlist was a great ride. However, after working on the same product in the same way for five years straight, some of the ways we used to work grew weary on me. With the new team, I want to improve the process. You know how some people naively hope that their new ventures will be the most successful ones and that they won’t repeat the mistakes of the past? Well, I think I’m one of these people. I sincerely hope my team will find better ways to develop mobile applications.
In the previous years, I was opposed to the mobile apps built using web or hybrid technologies. PhoneGap, Apache Cordova, responsive web apps, React Native — all of these, I thought, are evil. My main point was always that they wouldn’t let me build a delightful user experience and become a burden in maintenance.
My understanding of what makes a great user experience has changed over time. These days I still believe that UI has to look stylish and be responsive. And I also believe that feature consistency across all of the platforms that our company claims to support, familiarity of the UI, being able to respond to user feedback quickly (not just with a “we hear you” email, but with a “we just did it” email) and time to market are as important.
Against my own will (well, almost), I got introduced to the modern web development cycle. There’s more — I even had to learn Clojure/Script! It was a bet that our CTO Adam had taken when we started tinkering with the very first versions of Pitch. Boy was I opposed to these choices! I always thought that web development ecosystem has a number of layered abstractions that are one too many, and here we have a whole different niche programming language on top of it. What can possibly go wrong? Ignorant me was eagerly waiting for the time we’ll have our first sleepless night because of this niche language’s teething problems, so then I can be right at least once in my lifetime.
Now I’m glad I was wrong. In retrospect, I think that choosing Clojure/Script was one of the best decisions for our young team. Becoming an exclusively Clojure/Script company allowed us to hire an incredible team of brilliant and experienced people in no time. Moreover, Clojure/Script gave us a property that I adore and haven’t seen anywhere else: we focus on the problem and not on the technical intricacies of a particular language.
I’ve experienced how we work while building a product with a cross-platform codebase. As an engineering team, we see the need of a user, and we come up with ideas to solve it. Talk about these ideas, draw and test them. Then we write data structures and functions. Clojure/Script is very well suited for these — there’s little to no syntax. Code is data, by the way. The language is also highly interactive, so we see the results as we type the letters into the editor. Additionally there’s a REPL sitting next to the editor where one can sketch a solution and interact with a running app. It’s like being able to change tires while riding 25km/h (I’m an urban cyclist) and having infinite lives. Not dangerous and very impressive!
The feedback loop of getting something in the app, making it work and polishing it takes way less time than in my usual way of doing things with native iOS. We don’t wait for the compiler to finish churning through the bits, and we don’t have to click or tap through the app, again and again, to bring it to the right state. It may sound superficial, but think of this: the feedback cycle drops from a 15-30sec interval to 100ms. How much faster can one iterate? How long will it take one to polish a UI element? Just this simple fact frees us from a burden of wasting time waiting while the code compiles, so we don’t spend time over-engineering a button class in a (mathematically) proven way using all of the particularities of a language so that it’s robust and doesn’t break when something changes. When the feedback cycle is significant, every bug leads to a painful cycle of changing few lines of code at a time, recompiling, restoring the state of the app, and checking the result. But when the cost of an error is just a few hundreds of milliseconds, one stops worrying about it. It’s not a problem. It’s so much not a problem that we can break it many more times, completely guilt-free, and stop after we find the best solution for the user and the business.
As the app is cross-platform, after every change to the codebase, we get fully featured apps running on macOS, Windows, Linux and in the web browser. Thank you, CI/CD computers from the cloud.
That’s the qualities of our current day-to-day work that I want to take to the yet to be formed the mobile team. That’s why I’m taking a bet and would like to start building a hybrid mobile application. It has an insignificant probability of failure, and all of these ambitions might evaporate in a year or two while we’ll be rewriting the app using native means because the outcome doesn’t meet our standards. We’ll be a team of smart people with an adequate level of humility, so we’ll go through the bitter feeling and correct the course. Or perhaps not, and everything turns out well, and we’ll reap the good fruit of taking the risk.
As a mobile team, we won’t be a platform-expert silo that simply implements technical requirements and mockups given from somewhere else. I see us being a part of the engineering team which builds the product altogether.
We won’t be a team which is invited to a product meeting simply as platform experts, where we can help to figure out how to adapt the product to the platform limitations (small screen, touch input, SDK intricacies) or benefits (voice assistants, on-the-go scenarios, security features). I see us taking part in the discussions and processes that shape the product and its direction.
I see us talking about more about the problem and less about the implementation. I see us coming up ideas on how to save users’ time, not arguing whether to hop on the next fad train of the new variation of MVC. I see us iterating on the problem with close to instant feedback, not fencing swords while “it’s compiling.”
I believe that we can prove to the development community that a team of curious minds can ship a hybrid mobile app with an excellent user experience.
So, enough me with this ambitious visionary mumble-jumble. Now about you. I’m looking for a few new awesome teammates, no matter of the race, gender, religion or any of it. Someone who would like to take risks with the technology of choice. Who likes experimenting and solving problems of users and the business we’re in.
I’m looking for open-minded iOS and Android engineers who love their respective platforms, and who would like to build a bridge to the world of the web apps and come up with productive ways to solve problems.
I’m looking for frontend engineers who are experienced with ClojureScript and want to dive into the land of native mobile apps, where 16ms response times and proper rubber-banding animations are flowing.
If it sounds exciting, then I’d like to hear from you. You can find the job description and the “Apply” button here!