# DimwittedSorcerer: Interview

## Can you give a brief introduction to your role so everyone understands what software engineering is?

Sure, so I work as a software engineer on the systems team at Roblox. A very brief overview of what I do is:

- Write code for our engine in C++ (sometimes I use Lua too)
- Design and implement new features to empower developers
- Review code written by other engineers
- Fix bugs and make improvements to existing parts of our engine

I think a good way to summarize it is _helping to build a world-class engine that anyone can use_.

## What lead to your role at Roblox?

Chance. Or at least that's how it often feels.

Before I worked here I used to create games on the platform. Back in 2017 I wanted a better way to manage dependencies in my projects so, I built my own package manager and later published it on GitHub.

What I wasn't expecting when I did this was an email from Adam Miller [rbadam?] (the VP of Engineering) a couple of days later to discuss it in more detail. After talking for a little bit I was invited to intern with them over the summer.

At the time, Roblox was much smaller than it is today. I think there were roughly 200 employees in the office. While I was there I got to meet so many great people, and learned a lot of cool things. The weather wasn't bad either which was a bonus ;)

I decided to go back in 2018, for me it felt like a really good fit and, again I had a great experience. In 2019 I returned full time and I've been working here ever since.

## Was software engineering something you always wanted to do?

Actually, no, it wasn't. For a very long time I wanted to study medicine. Writing code had never been much more than a hobby for me.

It was a teacher of mine in high-school that changed this. Somewhat ironically, he held a doctorate in Chemistry yet taught me information technology and is responsible for turning me away from medicine and towards computing.

But he really was a great computing teacher. No teacher had ever really pushed me or believed in me the way he did. When my school didn't offer computing at A-level he offered to teach me it on his own time.

I went on to study computer science at university and haven't looked back since.

## What Programming Languages are you most proficient in?

Over the years I've used quite a few languages. The most interesting one is probably Haskell while my least favorite was PHP. Most proficient though, it probably has to be Lua or C# (not C++ though, there's always something new to learn there).

## What lead to you joining Roblox instead of working at a different organisation?

There were a few different places I considered when looking for work after university but having interned at Roblox before I think I already knew that's where I really wanted to go. The people are great, and I get to work on things I really care about.

## What was the process in you designing the GUI Border Mode for Developers?

Haha, it's not actually that interesting. I think somebody made a comment about borders being cut-off by frames when ClipsDescendants was enabled so I said hey - let's do something about that... and that's how we got BorderMode!

## Now we know you’ve worked on a lot of things, I think the most known one that you’ve released for the moment is attributes, could you explain your role in the release of them, and why people would use them?

We started out with a few questions:

- How can we expose properties to developers from Lua that they can easily configure?
- How can a developer expose a property on their own asset that others can easily configure?

My role was to come up with an answer to those questions and then implement the solution. There were 3 main parts to this:

First, there's the API. That's the bit that you, the developer, sees and uses. We considered a few different approaches for this but in the end we settled on a set of methods that let you set and get different values, similar to the DataStore APIs.

Second, there's file serialization. Attributes were a completely new system and since they could be created and removed at any time (unlike properties) we needed to come up with a new way to save them to files. For that I wrote a brand new serializer capable of taking many of the types we support in our engine and converting them into a binary blob of data.

Third, there's network replication. Again, since attributes were a new system we needed to come up with a way to handle their replication efficiently. We could have replicated the entire set of attributes each time they changed fairly easily, but we wanted to do something a little better than that.

There were a few other things that I didn't mention, such as CHS but they were all fairly minor in comparison.

Of course, there were others who worked on the feature too and it would be wrong for me not to credit them. The studio team did an excellent job integrating attributes inside of the properties widget. There were also members of the product and engineering team who played a vital role in realizing this feature.

-- Why would people use them?

To your second question -- Why would people use them? There's really a number of reasons:

- They let you expose values to other users through the properties widget
- You can associate additional data with an instance (an awesome use-case is replicating player data)
- They can be used to create your own properties
- One awesome use-case I've heard is someone adding them to UserInputService ...
- You can view them in realtime.
- Useful for debugging a value which is constantly changing
- Can make changes on the fly and see how it affects your game

## One of the more unknown things about you is that you own the Roblox Climbing Club, could you tell us a little bit about your involvement with this and the Climbing Event.

The Roblox headquarters has a climbing gym not too far from it. When I was an intern I used to go there a lot and try to persuade people to come with me. I even created a channel on our internal messaging service (can I mention slack?) so we could organize going to the gym together.

Fast-forward a few years and rock-climbing now features in our 'Inside Roblox' video. It's only for about 5 seconds, but it is in there so that always felt like a small (but huge) win to me.

Anyway, that's sort of where the Roblox climbing club came from. I thought it would be cool to have an actual group on Roblox about climbing. At some point I'm hoping to make a climbing game for it, but for now it's just a group that climbers can join.

## One of the last questions I have for you, is about something that you are working on right now, can you talk to us about the Deferred Event Handling.

Deferred event handling, or deferred Lua is really about isolating when Lua runs in our engine.

For me this has involved creating a new way to schedule Lua code for resumption in our engine. In many places where we would previously have resumed a thread instantly, when deferred Lua is enabled they are now added to a queue which is executed at certain points of the 'engine step'.

While working on this there were a number of challenges to solve:

- How can we make sure values we pass to events aren't stale (out of date)?
- When do we need to process the queue of deferred threads?
- Do events need to remain ordered? (yes)
- Developers are used to the existing flow, how can we make the new flow easy to use/adapt to?

Over time, we'll have more to share for sure. Right now my focus is on making improvements based on feedback we've received from developers since initial release.

If you want to know more about deferred handling there's a great post on the developer forum by zeuxcg which goes into more detail about some of the motivations for doing it and our long-term roadmap for the feature.

## Final Question, I know we’ve had a lot of the publicly released features, would you mind telling us about anything you’ve got coming up in the pipeline?

Sure, I can tell you a little bit about some of the public features I'm working on at the moment though there's a chance that by the time people hear this everything I share will have already shipped :joy:

Deferred Lua has been my main focus recently, and will continue to be as we iterate upon it. As part of this, I'm looking at how we can make improvements to thread management in our engine more generally. Developers will be able to use four new APIs which we're planning to release soon. They'll let you:

- Schedule a callback function to resume after a specific amount of time has elapsed.
- Queue the current thread to resume after a specific time.
- Defer a thread to the next invocation point (as part of deferred Lua)
- Run a thread instantly with engine-level error handling

Some of those may sound familiar already. That's because they're based on existing APIs but meant to fill gaps which the current versions do not.

Beyond that though, there's not much to share. I'm always checking the devforum for new feature-requests though so if you have a cool idea be sure to post it or send me a message on the forum!