Being a mobile developer for Toggl is all about constant improvement. Our team is constantly looking for opportunities to make the apps, and the team itself, better.
In case you don’t follow our blog, both the iOS and the Android have recently gone through a complete rewrite. And as these things go, complete rewrite has its pros and cons. The most obvious con is that you need to spend copious amounts of time writing features that existing clients have already implemented. The pros, on the other hand, is that once you’ve caught up you have a solid foundation where you can start developing new and exciting features. That’s where my adventure begins.
The Fellowship of the
During the development of the new apps, we brainstormed a myriad of ideas. Selecting the best one among these was no easy task, so our thought process was to pick a feature that was very mobile-centric.
And as you know, mobile apps are sometimes overlooked. They tend to be subpar versions of a web-client, and that’s not what we wanted. We wanted the apps to feel unique and use the phone to do things your desktop browser couldn’t do.
That said, smartphones are very personal gadgets. We always have them in our pockets and they usually contain details about our schedule for the day. Leveraging the power of tools like Google Calendar and iCal and making it available to our users anywhere is something that transforms a good mobile app in a great mobile app. That’s why, for our very first mobile-specific feature, we opted for creating some kind of calendar integration.
With the apps in a stable state and given that our team had grown a lot in the last two years, we had the possibility and enough personnel to create sub-teams to tackle these new features. These teams are called task forces.
I was given the task to lead the first task force. This meant a big change for myself and the team, both in our daily schedules and in our mindset as a whole. But, hey, everyone in the mobile team is always up for a challenge, so we, the fellowship of the calendar, set out on this new and exciting adventure!
Towers Sides of Managing
Change is usually not easy. It takes an effort to get out of your comfort zone and learn something new. Changing from developer to a manager was no different.
My initial approach to championing the feature was to be more involved with the code architecture instead of writing code per se. Since our apps have a shared layer of code, we needed to draft the calendar feature with both Android and iOS in mind, even if the initial release was going to be iOS only.
Another thing that I decided on day one was to be 100% open to the feedback of the developers working with me. Despite me being the one who designed the architecture, they are the ones coding the biggest part of it. So I told myself that I would not micro-manage them and listen to their inputs, for they probably knew many things better than myself.
This meant that my time was to be split between creating GitHub issues for developers to work on, updating specs (and other documentation) and drafting the architectural outline, so the others knew why and when to write which portion of code.
For the first week and a half I was pretty sure I was doing everything wrong and that the calendar project would fail, I would be fired and the polar caps would melt. Yes, I’m a bit dramatic, why you ask?
Of course, it was just my mind trying to sabotage me. The team praised me, my direct managers were mostly happy with my work and no one is fired for not being instantly good at something. The polar caps might still be melting, but I swear I have nothing to do with that.
Despite not being a complete failure, I still had things to improve. As usual, my team never lets me down and I got tons of excellent feedback from everyone (my superiors and my peers) that allowed me to constantly improve.
From all the things that I needed to improve, the one that was by far the hardest was communication. We have this fake impression that communication took place when it hasn’t and we are very afraid to be overcommunicating and annoying people. Let me stress it one more time: There’s no such thing as overcommunication. Write things multiple times, make sure to write notes on every meeting and avoid private discussions when the topic concerns everyone.
The whole project took more or less two months and I felt an immense growth. From the initial angst of not being good enough to meet expectations (both my own and external) to the final feeling of having delivered something great and having improved as a professional, I must say that I strongly recommend this kind of context shift for every developer!
The Return of the
One of the most crucial skills I learned during my time as a manager is delegation. So I’ll use that right now and delegate the parts where I talk about nerd iOS stuff to Juan Laube, one of the great developers that worked with me in the calendar project. To be more specific, he worked on the `UICollectionView` wizardry that enables the calendar to work beautifully!
~~~~~ Take it away Juan! ~~~~~
quest to destroy the ring calendar feature came with some technical challenges, but the most interesting for me was how to render that beautiful view.
Enter the Collection View
The most obvious solution was using a collection view with a custom layout, and as a mobile developer, I was super excited to work on this because it is not something you do every day.
I began prototyping the idea in a new project, to validate some concepts and get an estimate of how much time this would take before writing a single line of code in the actual project.
The calendar view is one of the most complex views we have in our app. We took advantage of different visual elements the collection view provides us out of the box, like reusable items and supplementary views to display all the different elements you can see (for example, the timeline indicator), the current time indicator that moves as the time passes, the start and end time of the item that is being edited and, of course, the events from the selected calendars and time entries.
The Custom Layout
The layout is the most powerful part of the collection view since it is responsible for calculating the position, size and other attributes like the z index of every visual element on it.
We had to remove the dust from our old calculators and do some calculations to position every calendar item where we wanted, considering that some of the may overlap at the same hour.
At this point, the collection view alone was great visually, but we were able to do more (and we did!). Since we wanted to make sure that our users have the best experience on their mobile devices, we added a set of interactions to create new time entries by dragging in an empty space in the timeline, or editing existing entries by dragging the knobs (or the entire entry, why not?) that appears when you do a long press.
That’s not all though! The interactions we mentioned are accompanied by some beautiful haptic feedback (if the device supports it, of course) you can feel when creating your time entries from the Calendar View.
~~~~~ Back to Will ~~~~~
This concludes the journey of mobile team’s very first task force. If I had to summarize my experiences as a manager to someone that’s developer transitioning to management, I’d say the following:
- Don’t panic about doing things wrong. We usually are too harsh with ourselves to judge this properly.
- Ask for feedback. Your peers will know what needs improvement much better than you.
- Trust the people that are doing the coding. They probably know better.
- Write everything down. Every. Single. Thing.
- Communicate clearly and often. I can’t stress this part enough.
- I don’t know half of UICollectionViews half as well as I should like; and I like less than half of them half as well as they deserve.