Developing as a Developer Evangelist: My Strategies

Blog Posts ,Random Musings
August 15, 2016

This isn’t an entirely VR-related post, so bear with me here. I’ve been spending a lot of time developing (which has been absolutely amazing) so I figured that it was time to update with some things that I’ve been noticing about my workflow and productivity. A lot of this is probably more scientifically documented elsewhere, but this is an N=1 kind of deal so you get to hear what works for exactly one person: me!

A few things about my development style:

  • I primarily program in C#. Vanilla JS is in second place, which I use to write WebVR applications. When I write C# code, it is almost always for Unity applications or Windows Universal applications.
  • I work in an interrupted development environment. My job title is “developer evangelist”, which roughly translates to “make like Kim Kardashian and update all the social medias whenever you finish a function”. That’s a bit of an overstatement, of course, but a significant part of what do also involves quite a bit of documentation, step-by-step recounts of what I did, and taking video clips of different processes. It’s rare that I have a day when I can sit down and spend a solid 2-5 hours coding without interruption, which is ideal for me, so it’s important to have a space and workflow that takes all of these things into consideration.

Ultimately, something I’ve realized recently is that setting makes a huge difference for my ability to get work done – and depending on the type of coding that I’m doing, it may or may not be the same type of setting that optimizes my productivity. There are some pretty small factors that play into it, and subtleties between types of development that impact overall workflow.

When I’m coding in Unity, I have a few things going for me: the modular nature of scripting in a 3D experience helps me scope my dev time, and I can work in short bursts contained in short(ish) script files. When I’m coding in JavaScript, I tend to need a longer chunk of time to split out how things are working and architect files.


My office space – even organized, there’s a lot going on in the desk that could be moved around. That lamp is essentially the only lighting, not good!

Generally speaking, there are a few factors that make it easier for me to focus – things that I haven’t noticed until recently, but that I plan to spend more time tweaking to continue to optimize:

  • Lighting: This is something that I have sorely underestimated until now, but there’s something about blaring overhead lights that makes writing code go from a fun puzzle to a nasty monster of “please don’t make me look at this!”. Last week, I had an exceptional coding session that was entirely in dim, colored light and it made a huge difference in how comfortable I felt looking at the screen for six (yes, SIX!) whole hours of pure functional() delight. I am now going to go hang rainbow lights up in my home office, which is lacking in soft ambient lighting.
  • (Lack of) Clutter: It is hard to cable-manage multiple headsets, a monitor, mouse, keyboard, three tracking devices, and a plethora of additional power cords for 360 cameras. Working at a clean, tidy work station helps keep myself focused on the task at hand – and it’s hard with so many random devices sitting around. The solution? I’m off to buy some additional shelves for my office space, because I’ve realized that just about any amount of clutter is just too much for me.
  • Silence: A lot of people like to listen to music, but I find that it tends to get me feeling like I should be up, moving around, and playing Tiltbrush or AudioShield – not the best solution for times when I need to be heads down. I tend to work with a window open, so I get a little bit of background ambient noise while not having anything too specific. If that ambient noise contains a low level of music, that’s a good level, but anything that is coming directly out of my speakers tends to have me distracted. Playing something from my Alexa speakers tends to be a lot better ambiance-wise than my desktop speakers, with an added bonus of not having to adjust when I need to watch a video tutorial for how to do something.

Aside from the general room setup, there are a couple of other things that I keep in mind while planning out the work I need to do:

  • Days where I’m working in the office, I have to plan on bright lights, laptop work, and other people/noise. This is a fairly regular experience, so I try to plan to focus on meetings, blogging, email, or presentation preparation on days when my coding situation is less than optimal. I have a great degree of flexibility in my current role, which helps me break out my tasks.
  • Maintaining coding best practices: As a computer science student, my mentality for assignments was generally “One Script to Rule Them All”. As a developer evangelist, a lot of what I write is open sourced and shared broadly. As I’m working, making sure that I’m sticking to good coding practices and writing specialized scripts helps me break down components of what I’m working on into more actionable items that can easily be paused and resumed. When I first started learning Unity, I had a habit of making one master controller script that handled too many behaviors – while it worked technically, it wasn’t great for clean code or coming back to when I had to leave off. Breaking out my scripts into more specific components has helped significantly with being able to keep track of things in bursts, and for keeping individual tasks pared down to smaller time chunks.
  • Document as you go along, not at the end. This doesn’t apply to every single scenario, but I find it much easier to keep a running list of notes as I go about what I’m building, and include relevant screen shots along the way. Sometimes, what I end up documenting is garbage, but more often than not, I’m able to turn that note-taking document into a blog post relatively quickly, filling in the gaps with code snippets and a little more detail on my thought process.

A final tip that I’ve found helpful is to limit social media to phone-only, but I haven’t yet implemented this in practice even though I probably should. It is way too easy to quickly tab over to check Twitter or Facebook, which results in dead time that doesn’t end up being useful. One option that I’m considering is using a different browser for development purposes, so that I can stay logged out of my social media accounts when I want to look up documentation. Alternatively, if you have a good browser plugin recommendation for setting a time to not show me Facebook, Twitter, or reddit, that would also be great!

What tips do you use to stay focused when you have a coding-heavy role that’s broken up with a lot of non-coding tasks? Share on Twitter or the comments (and then get back to the code! 😀 )

Related Posts

1 thought on “Developing as a Developer Evangelist: My Strategies”

  1. Hi, I always enjoy your Monday musings… One thing I found works great for me is to limit all my social media and marketing related checking to my iPad, that way I only pick it up when I have time for it, or need a break. I removed the apps from my phone entirely. The phone doesn’t work (IMO) as we tend to pick up our phones a million more x a day then digging out a tablet to check twitter for instance.

    Keep up the good work!

Leave a Reply