The bugalore

I was listening to a podcast today which featured L. David Marquet who has recently published a book called Leadership is Language in which he talks about how asking better questions can help so much in our day to day communication. He narrated the engaging story about observing the conversation recorded on the black box of a sunken ship. He realized how much more effective the conversations and decision-making on board could have been, had someone asked better questions.

One of the perks of working at an open source organization like mine is that I get to talk about my work projects with the world. Everything I do as part of my work is public and accessible to anyone who wishes to see it. TemplateWizard is one of the first projects I undertook as a Product Manager that has major user-facing functionality. The project was requested during the 2017 Community Wishlist Survey and made it to #5 in the results.

Note: This post was originally published on https://wikimediafoundation.org/2018/09/06/global-preferences-wikimedia-wikis/ There are a lot of Wikimedia wikis. Wikipedia is the best-known of them all, but there’s also Commons, Wikiquote, Wikisource, Wiktionary, and more. Also, each of these sites is available in multiple languages. Wikipedia, for example, has nearly 300 language editions. The newest launched just this week. Until this month, each wiki and language version had individual preference settings. This caused some serious frustration for people who contribute to multiple wikis.

After three years and five months of being a software engineer at Wikimedia, I decided to step into the role of a product manager at Wikimedia in April 2018. It wasn’t an abrupt change. I’d been toying with managing products since early 2017 and I was lucky to have a manager who was willing to give me a chance. There’s a lot of good advice out there about how to transition into product manager which you will undoubtedly find helpful if you’re looking to make the switch.

This was my first time backing up and setting up a new MediaWiki (-vagrant) instance from scratch so I decided to document it in the hope that future me might find it useful. We (teams at Wikimedia) often use MediaWiki-Vagrant instances on Labs, err, Cloud VPS to test and demonstrate our projects. It’s also pretty handy to be able to use it when one’s local dev environment is out of order (way more common than you’d think).

Something at work today prompted me to get thinking about what people generally mean when they say they are/someone is a senior developer. There are some things which are a given - long-term technical experience, fairly good knowledge of complex languages and codebases, past experience working on products and so on. But in my opinion, there are a fair number of things which we don’t really talk about but are important skills a “senior” developer must possess to actually deserve that title.

What the heck is eventlogging? Eventlogging is a MediaWiki extension which lets us log events such as how users interact with a certain feature (client-side logging) or capturing the state of a system (user, permissions etc.) when a certain event happens (server-side logging). There are 3 different parts to eventlogging an event. The schema, the code and the log data. I won’t be going into the details of that because there’s a detailed guide for it.

The what, the why, the when, the who, the how: I’ve been coding for a while now, mostly on Wikimedia projects. Every time I get stuck with a bug or come across something I didn’t know of, I’d learn something new, fix it and move on. While this works great for me, it’s a wealth of knowledge that I’m keeping all to myself. I wanted to be able to pass on the intriguing lessons I learnt to other people who might want to hear the stories I brought back from the pits I fell into (no, not like Bruce Wayne).