Hi, I’m Manu, a biking web developer. I’ve been writing on here since June 2002 about a bunch of different topics. My favorite posts are tagged with ✪.

Why “plothole.net”? As defined on wikipedia,

a plot hole, plothole or plot error is a gap or inconsistency in a storyline that goes against the flow of logic established by the story’s plot. Such inconsistencies include such things as illogical or impossible events, and statements or events that contradict earlier events in the storyline.

This definition suits my life pretty well.

Thanks for reading!

Manu's adventure in Doodleland

I like to think of my time at Doodle as having 4 main themes. I was originally hired as a full-stack engineer for BookMe. Sadly, that product got killed shortly after I joined.

Maintenance and small features

I first helped introduce Sass and tried to clean up the existing CSS code by listing fonts, colours, sprites. It helped raise awareness among the team that it might be a good idea for future evolutions to restrict the number of colours for example and define a style guide.

Two months after I started at Doodle, Angela –our Chinese intern– joined, and I was designated to be her mentor. With no prior experience in front-end development, she chose to work on the migration of FullCalendar version 2 to 3 for the calendar view of Doodle polls.

In parallel, Spyros and I started specifying, implementing and documenting a new JSON-based API for the upcoming iOS app developed by a third party. Again, I could use previous experience in building APIs using the same technology stack and well structured data transfer objects, as opposed to JSON objects defined ad-hoc. One new requirement of the iOS app was the sending of push notifications, so I gained some experience in that domain.

In Fall 2014 I could finally work on the first new user-facing feature: a new participants invitation step on the poll creation wizard, with address book integration.

The next months consisted mostly in code refactoring: introducing the usage of constants, better structuring of the JavaScript data on the client-side, icon sprites everywhere, etc. Another new feature called multi-day events was then introduced. This was the first major feature I worked on with Mirjam as a product manager. Everything before that was led by Malte.

Early 2015, the iOS development was moved in-house, a new office would be opened in Berlin and Malte would give way to Matthias as the web product manager. An Android app was also being worked on.

The new mobile web app

In April 2015, it was decided that we would start working on a new mobile web app, designed by an external agency as we still had no in-house designer. I got to work with Tom –who joined not long ago with Jay– on a React prototype that would be benchmarked against a Backbone prototype built by Spyros and Jay. The latter outperformed the former in server-side rendering and settled the technology stack for the next couple of years. We would use Backbone, with a thin (?) layer of a home-baked framework, a lot of Jasmine/Karma unit tests, as well as Cucumber/Webdriver integration tests.

While building the poll participation page along with super tricky ads behaviours, building the poll creation wizard, I worked on making a subset of existing content pages responsive while assuring that new pages would be responsive as well. Development on the API was still on-going and I got to implement Apple In-App Purchase payments (that got never used). In the Summer of 2015, our small team had also to work on a redesign of MeetMe called doodle.me that got aborted shortly after.

Development of the new mobile web app was halted before it got a new dashboard and home page. The wizard was never released outside of the UK, and the whole app was only accessible with browsers supporting flexbox.

The redesign

The new mobile web app –code-named Stingray– gave way in early 2016 to a complete redesign. Initially it was for desktop only, but the engineers lobbied to re-use what was done the year before –basically adopting a mobile-first mentality.

We not only tried to work mobile-first, but also style guide-first, so we spent time building re-usable components showcased on a style guide. We then replaced existing elements in Stingray with the new ones. Everything went pretty smoothly, especially since it was also finally decided to drop server-side rendering.

While working on the redesign, thanks to an almost complete freeze of the back-end, I finally got to focus entirely on front-end development. Little by little, we worked towards feature parity with the existing doodle.com web app. I worked on:

Miscellaneous

I think it’s very important that code knowledge is shared among the whole team. That’s why I have always read all the commits on the main Doodle code repository. While I know that the same cannot be expected from everyone, I started doing consistent and structured code reviews using GitHub.com and convinced the rest of the team to do so. With Tom we then formalised the usage of pull requests, which I’m sure contributed a lot to the code quality. I also started linking to Basecamp todos, then JIRA issues, in commit messages in order to give more context to code changes. This is something I carried over from my previous job; it needed some getting used to at Doodle but I’m glad we now stick to it.

As Spyros pointed out, I’m guilty of being the behind the scenes scrum master, i.e. doing only the parts I was interested in. I never wanted to write the meeting minutes of our retrospectives, preparing the show-offs, etc. but I did for example start the documentation of the web engineering process.

I failed at attempts to have a nice show-off archive with decent screenshots and videos, because Confluence was nuked and show-offs moved to slides.

In 2017 I got to lead the recruiting effort for the 2 front-end positions, that became 3, that became 4. I think I learned a lot, we did not do that bad, but there’s definitely room for improvement, especially in speed. I’m particularly proud of having brought a woman developer on board.