Interviewed at Tencent Frontend Conference
Last month, I was interviewed after delivering a presentation on ECMAScript to an audience in Shenzhen, China. I think it was an entertaining interview, so here’s a transcript.
Interviewer: How did you get started in programming?
When I was around 11, I had some lessons at school where we learned Flash. We also learned some Frontpage and made websites at school. I made a few websites on my own, just for fun, too. Around this time I started playing StarCraft, which I’d play for almost 10 years straight. I found that their map editing tool was quite complex. You could create Triggers (when 10 units move into Zone X…) and Actions to execute in response to those triggers (…kill those units in a big explosion). It wasn’t entirely scriptable, but it was always fun figuring out how far you could take this simple rule-based system. It turned out you could render in-game scenes with dialogue and whatnot entirely by using these rules, so I spent quite some time doing that.
In high school, I got into more interesting projects. I implemented my own version of the classic Snake game and my very own Paint. I noticed my computer was too slow for my Paint app to smoothly draw a point over each coordinate the mouse moved over when using the pencil tool. I ended up compromising with an algorithm that’d draw lines between the last point you moused over and the next one. This looked much more smooth and it was good enough if you weren’t intentionally trying to break it. Once I implemented this, I was thrilled to discover the original Paint did exactly the same, with sharp lines being drawn if you moved the mouse around very rapidly in a circular fashion.
Then I started playing a different game, Ultima Online. This one didn’t come with a map editor, but there was an open-source server called RunUO, and I used to run my own server and implement features for the game. That’s how I learned C#. I implemented things like an unsupervised system where people could sign up for a tournament for a period of time, they’d then fight each other in turns using a randomized double-elimination bracket system, and eventually there’d be only the winners left, and fireworks. Then I made another system that’d look for peak hours with lots of online players and automatically open these tournaments, which were previously scheduled by hand. Even before I implemented the tournament system they were run entirely by hand, with the Game Master moving players into the dueling zone, like an animal!
After doing that for a couple years, a friend told me, “You know, people would actually pay you to do this” but I was skeptical, C# was too fun and beautiful to be something you could make a living off of. But it was true, and I got a job writing C#.
Interviewer: Have you ever thought that turning love of role-playing games into a career will spoil your fun?
I think it’s the other way around. It never felt it like work to me. I didn’t fall out of love with my hobbies because I was doing it for work as well, but I did grow out of gaming after I started working and transitioning into an adult. It’s extremely important to work on something you like. Then it won’t feel like torture when you’re doing it for days. I feel blessed to be able to make a living off of something that I enjoy so much doing.
Interviewer: What does Argentina’s tech community look like?
It’s in a much better shape than it was, say, 5 years ago. Nowadays, we have JSConf, CSSConf, NodeConf, and the smaller meetups people are also used to like BeerJS, NodeSchool, and NodeBots. It’s definitely growing. NodeConf started last year and this year it’s shaping up to be fantastic. With conferences and meetups on a regular schedule, people can engage more as a community, and not just attend some event once and then completely forget about it.
There’s probably a framework coming out right as we speak. The important thing is to avoid the temptation of jumping onto the latest and shiniest bandwagon, whatever that may be. It’s more about figuring out the trends, what’s useful and helpful for me and my projects.
If you started a project 2 years ago and it’s “still” using Angular, there might very well be no need to migrate to React. The fact Angular is a little bit lower than React is often negligible especially when considering the amount of time you’d put into a migration like this for any moderately large application. It always depends on your requirements. The consistency of using the same tool for a while is valuable.
It’s really important to figure out how you learn things best. Some people love to watch screencasts or other videos. Some people enjoy a good audiobook. Some people like to read digital books. Some prefer to read physical books. I’m really bad at learning through vision. I need to read. If I watched a video and I need to understand it well, I’ll spend a lot longer than if I just read equivalent content on the same topic. What I’m trying to say is that you should figure out whether you are a visual learner or if you prefer written content. Maybe you prefer to learn as you go and by trying things out and breaking them apart, or perhaps you prefer something more structured like a course with a series of screencasts or long-form articles — or formal education, if that’s your cup of tea.
I implemented my own frameworks to learn how similar frameworks work under the hood. I did this with many libraries as well. I think it’s an effective way to experiment and come up with your own understanding of how things work. I would recommend 12factor.net. It lays out 12 different principles for robust application design in terms of security, configuration, scalability, etc. I found it invaluable when I was first getting into open-source. I’m also a huge fan of The Pragmatic Programmer, far and away the best book I read on our craft.
In my book series, I’m teaching how to write concise and single-purpose modules. The reason is that we need modules to be specialized so that they can reused, tested, and document in isolation. Scalability is an important aspect of this, in terms of architecture. When you have 200 different modules with 5,000 lines of code each, it can be mind-boggling to work with them and it’s surprising if you get anything done. In contrast, if you have 5,000 modules comprised of 200 lines of code, it’s a lot simpler to understand how pieces of code are related to each other, and what they do.
The series discusses language features in and after ES6, how to design and maintain highly modular applications, how to test our modules, and effectively deploy these applications.