A Day in the Life of a Windscribe Employee

You’ve seen the memes. You’ve used the services. You may have even joined the Discord. You’ve heard about the hot job market in tech, and the wild perks that some companies offer to obtain, and retain, staff. But have you ever wondered what it’s like to work at Windscribe?

I’m a Windscribe employee; my job title is ‘Frontend Engineer’ (if you have no idea what that means, the explanation I give to my mum is that I move buttons around on the internet) and I primarily look after Control D, our DNS management application. I also write blog articles like this one, and these other ones, and you might even have spotted me hanging out in the Windscribe Discord server, telling users how Soon™ features are going to be released. I sit on Control D’s Product Council, which is where we take our fearless leader Yegor’s ideas and work out how to turn them into reality and how Soon™ we can do it.

I work from home almost all the time (did you hear that Windscribe is a remote-first company thanks to a lil nudge from our friend, the ‘vid?) but as I live about an hour’s drive from our main office in Toronto, I go in sometimes to enjoy snacks, ping pong, and working without the interruptions of my dog Maple.

I decided to write this article completely on a whim, and picked a random day to chronicle. Of course, you have no idea whether I’m telling the truth or not, but if it means anything, I promise: this is a typical Wednesday in my life as a Windscribe employee.

8am: Wake up. Working from home gives me the luxury of waking up an hour later than I would need to otherwise, and having an awesome fiancé means there’s always coffee ready. Take our dog out, feed him, feed our cat, and finally, find out if it’s a Bones day (it was!).

8:45am: Announce that I’m ‘off to work’ and walk five meters to my adorable office setup. Laugh at my supreme wit. Ignore the pity laugh from behind.

8:48am: Check-in on Slack. My team at Windscribe has a very casual ‘check-in when you start, check-out when you finish’ policy. Within reason (‘reason’ being working the total amount of hours stipulated in our employment agreement), we work the hours that work for us. For me, that happens to be roughly 9 to 5 most days.

I took the two days prior to this off, so I dedicate the next hour or so to catching up on everything that I missed. This involves reading all the relevant Slack threads, where we do most of our casual communication, and catching up on the more formal ticketing system we have going on, which is on GitLab. I have the pleasure of being the Grand Organizer (I made this title up just now) of our issue boards - this is how we know what to work on next, what’s ready to be looked over by other developers, and what’s being QA’d - so I also spend some time ensuring that the state of the board makes sense, reflects reality, and has plenty of small, well-documented work items for members of the team to pick up.

10am: It's time for Standup, which is a 5-minute update (usually) on each of the team member’s current work items. Our team has a standup every morning at 10am, with some ‘special’ meetings throughout the week. This is a ‘special’-ish meeting, as we’ve decided to no longer start our weeks on Mondays and end them on Fridays - instead our team will start new work on Thursdays so that we can aim to release new stuff on Wednesdays. There are many reasons for this that I’ll go into elsewhere (probably), but the main one is that this avoids releasing on Fridays, which risks leaving you all hanging all weekend if something is not quite working exactly how it’s supposed to.

10:15am: Documentation of processes is a very important part of what I do at Windscribe, so I spend some time documenting the above (new) workflow policy, updating our internal documents, and making sure that our leaders are on board with the change - which they are! Hooray!

10:55am: A team member is working on some UI tweaks and comes across a bug for which a solution isn’t immediately obvious. In this case, entering a promo code for a specific product on the Control D website and then immediately clicking the link that navigated the user to this page in the first place leaves the user in a strange state, where the promo code is applied, but they can’t see the product that the code was applied to anymore. If you know where to click, this is not an issue, but we of course don’t expect our users to be able to read our minds. There’s a short debate: should clicking the link again reset everything, or should it do nothing? A link that does nothing feels like it’s broken, and clicking the link that took me to the page is what I would do if I wanted to reset the state of the site, so we go with that. This conversation takes 7 minutes.

11:02am: I chat to some of our Discord users, attempting to help someone solve a problem they’re having with Control D, and discussing the benefits of scrollbars. Some of the overlays in the Control D app are scrollable, but the lack of a visible scrollbar means that some users don’t realize they can scroll down. I chat with Yegor about this, and he confirms that people like to really see their scrollbars, so I make a ticket - a work item - to make sure that all scrollable content includes a visible scrollbar.

12pm: It’s lunchtime! I warm up butter chicken that I made a few nights ago and that I’m absolutely obsessed with. My partner makes rice, and instead of adding butter, he uses ghee, which is exactly why I agreed to marry him. We watch New Girl while we eat, because we’re both software developers whose brains don’t want to watch anything at lunchtime that requires thinking.

12:30pm: Something else I lead for Control D is our user testing, which is brand new, and pretty important - because we (obviously) aren’t tracking your activity on our app, we need other ways to find out whether what we’re doing is working. This week, I’m particularly focused on how much prior knowledge of the Internet affects the usability of the app, so I write two almost identical tests for random people to take while we record their screen, so we can see where they get stuck. The only difference is that one test calls for people with ‘high’ existing technical aptitude, and one for ‘medium’.

1:30pm: Code reviews. You may have noticed that despite having ‘Engineer’ in my job title, I haven’t actually written or read any code yet today. Only about 50% of my job is writing/reviewing code, because there are things I love equally, like project and product management, content creation, running our user testing initiatives, and talking to the good people of the Discord server. There are people on my team with an identical job title who spend more like 95% of their time writing code. Windscribe is a place where you can pick what you do, as long as you commit to learning to do it well, and it brings some kind of value to our people or our products (this is my favourite part of working at Windscribe, because I have enormous ‘I want to do whatever I want to do’ energy). For what it’s worth, I spent the entirety of the following day coding, but that might have to be a different article.

3pm: Product Council meeting. The Product Council for Control D is made up of representatives from management, design, project management, and product ownership (hey! That’s me!). This is where we talk about new ideas, new designs for the ideas we talked about last week, and memes. I can’t go into too much detail on this, but we talked about Cool Stuff and looked at Cool Designs for things that are coming Soon™. Most importantly, I’m able to determine from these meetings what my team’s priorities should be, while making sure that we’re able to keep the longer-term plan in mind for our product.

4:13pm: I start looking over some of the designs that were finalized and approved during the meeting, making sure that I have a good sense of what exactly the implementation will entail, and how we can split this up amongst our team members so that it’s done efficiently and robustly. Our Thursday morning planning meetings have a tendency to go long, so I try to prepare on the prior afternoon; that way we can keep things moving along swiftly, and I always have suggestions ready for what we can work on and in what order.

Also 4:13pm (true multi-tasking as I tab rapidly between Slack, Figma, GitLab and VS Code for the next 45 minutes): Our excellent dedicated QA tester comes across something that he’s going to find quite difficult to test, since the problem that he’s checking our solution for only happens in an extremely specific set of circumstances. I’m able to recreate the circumstances locally and he’s not, so I step in to help test this aspect of the work. I do find a small problem with it, but I’d rather we find it first, than have a user stumble across it! I quickly check in with our wonderful designer, who confirms that it does indeed look wonky, and I send a screenshot to the QA tester I’m helping, who’s much more capable than I at bug documentation and duly makes a note of the bug for the developer who implemented the feature.

5pm: I’m done! I write a quick check-out message on Slack and start preparing for the hockey game tonight, which involves making an ungodly amount of food, and praying. Lots of praying.

9pm (bonus): We have eaten all the food I made, and now I order Dairy Queen.