Author: Brad

Featured Post

Matt Nohr

Almost two years ago I took on a new role as an engineering manager. In an attempt to get a better understanding of how to properly perform in this role, I’ve been interviewing several managers for the site. Here is the second in the series of those interviews. In this one, I speak with a former coworker, Matt Nohr. He is currently a Backend Engineering Manager at Gitlab. You can find more information about him on LinkedIn.

  1. What was your career path to becoming an Engineering Manager?  Was it an intentional decision or were you unexpectedly offered the opportunity to transition away from being an engineer?

    I started my career as a backend software engineer, starting with large internal applications for 3M and eventually helping build the IoT platform for SmartThings. For most of that time, I did not want to go down the management track. However, during my time at SmartThings I was “strongly encouraged” to take on some people management responsibilities in addition to my engineering role. At the time we were quickly growing the engineering organization and needed help on the people-management side. It turned out to be something I enjoyed doing. For the first few years I had to balance being both an engineer and a manager but then was able to switch to being a full-time manager.
  1. What is your definition of an Engineering Manager and what do you see as the purpose of an Engineering Manager inside your organization?

    I work for GitLab, where we’re lucky enough to have pretty well-defined definitions of the  Engineering Manager and other leadership roles. In short, I feel like my main job is to make my team be successful. That includes meeting with them regularly in one-on-one meetings, removing anything that is blocking them, and helping them grow in skills and experience. I also spend time recruiting/hiring to build out teams, high-level project planning for the team, and helping to improve processes across teams.

  2. Did you receive any formal training once making the move to management?  If so what kind?  If no, what self-learning have you done to close the knowledge gap?

    Unlike learning a new programming language or concept, there is not a simple path or defined set of skills for being a manager. I did take some classes on my own which had varying amounts of value. A lot of my training was more of the “learn by doing” style. That said, there were some good books that helped. When first starting out as a manager, or moving into any new position, I’d recommend reading The First 90 Days. I also learned quite a bit from Drive: The Surprising Truth About What Motivates Us and Turn the Ship Around!: A True Story of Turning Followers into Leaders. There are also plenty of blogs and articles out there.

  3. How does a normal workday as a manager differ from your normal workday as an engineer?

    The “product” I am developing is no longer just the software or hardware, it is the team of people I manage. This means my days are spent checking in with the people I work with. I also am coordinating projects for my team and working across teams to identify dependencies, improve the process, and remove blockers. Depending on the day, I also spend time recruiting and hiring to help make the team better.

  4. Gitlab is a fully remote company.  How has being part of a fully remote company changed the way you manage?

    Managing a fully-remote team changed things a little, but not as much as I expected. I have always valued open and transparent communication, which is probably the most important thing with a remote team. You also must have a high level of trust in your team. Like many things, GitLab has a public-facing entry in the handbook all about managing within a remote company.
  1. Has the pandemic changed the way you operate/manage your team and if so how?

    GitLab was a fully remote team before the pandemic, so when other companies were shutting down offices and figuring out how to be a temporarily remote company, we just kept on working. The big difference is what is happening in people’s lives outside of work. For me it has been very interesting to hear how people on my team around the world have been dealing with stay-at-home orders, quarentines, and travel restrictions. 

    For the whole company, we’ve had to adapt to more flexible schedules as people are balancing not just work, but potentially additional child care responsibilities, caring for family members, and dealing with the stress of the pandemic. We have regular “family and friends” days where the whole company is expected to to take the day off to recharge and spend time on the important things outside of work
  1. What is the single most unexpected part of the job?

    Every day is different, so there are many small unexpected things that happen. As a manager, I feel like I have to be able to juggle all these unexpected things. This means that there are many times when I need to learn about a problem, try to quickly understand the different aspects of it, and then make a decision. This happens to me multiple times each day.

  2. What is the highlight of the job?

    For me, the highlight is when the team starts working really well together and you notice they are moving faster than you realized. When the team or a single person is exceeding your expectations and they can continuously improve without you having to be directly involved, it is very rewarding.

  3. What is the best piece of advice you can offer a new Engineering Manager?

    One hard part about moving away from being an engineer to an engineering manager is that you need to learn a whole new set of skills. You often do not want to give up on the engineering skills you have mastered, so you will be tempted to keep writing code while also trying to be a manager. The sooner you can move away from this, and stop trying to do both jobs, the better it is for you and your team. Your job is now letting the people on your team write the code and helping them improve, and if you keep doing their job,  they will not be able to learn and grow.

    If you do feel the need to keep writing code, be careful with what you do. Try to avoid anything on the “critical path” and only pick up a small task that won’t get in the way with what your team is doing. You shouldn’t be a blocker and have someone on your team waiting for you to finish a task since you are not a full-time engineer anymore.

    That said, I still enjoy writing code. However, I focus my energy on things not directly tied to our team priorities or deliverables, like automating repetitive tasks, building analytics and reporting, or updating documentation.

  4. Would you say that being in Minnesota has helped or hindered your career?

    I have been fortunate to work for some great companies that were headquartered in Minnesota, like 3M and SmartThings. Getting the experience at these companies helped me grow and transition to a fully-remote position. Now I am lucky to be able to work from home or escape to a cabin and work from the lake. The hardest part of working in Minnesota for me was the concentration of tech jobs in downtown Minneapolis or other places that are a far commute from my house in the northeast suburbs. This always felt like it hindered my job opportunities since long commutes impact my work-life balance.

11. Anything else you’d like to add for new or potential Engineering Managers?

The power of an Engineering Manager is in the “multiplier effect.” You trade your own single set of skills for a team of people all working together, hopefully at a high level. To make this happen, you need to delegate responsibilities to the people on your team because the more responsibilities your team can take on, the less you will be a bottleneck. Trust your team!

Kristina Durivage

Below is an email interview I conducted with Kristina Durivage. Kristina is a well known engineer, hardware hacker and speaker both in Minnesota and across the country. You can find more information about her on Twitter and LinkedIn.

  1. Can you tell us a little bit of your background as a developer?  
    1. When did you start? 
      My dad bought me a domain name in high school. I had a pretty bad (by today’s standards) digital camera, and wanted somewhere to put pictures of me and my friends, so I built a website for that. I also would edit blog templates and try to get commenting systems to work so I could be an Online Teen before it was cool. 
    2. What was your first language? 
      Standard HTML when Microsoft frontpage wouldn’t let me click and drag. Old school stuff!

  2. What is your primary area of focus in software development?
    I was a full stack dev for the first few years of my career, but ended up doing more and more front end work with different job changes.

    1. What is your language/framework of choice?
      Javascript, and focusing on React as the framework.

  3. What are the tools you use most during your day?
    VS Code, Sublime Text, Tower

  4. What made you decide to focus on frontend development as a career?
    I really liked thinking through problems as a user, and trying to translate a task to something that would be as simple for a user to do as possible. I loved the position where I knew the technical problem from a developer’s standpoint, but could think about it from a UX/end user standpoint, and solve for the middle part. It also lets me think creatively about problems outside of the ones I’ve given – if I know what data a company has, what would it take to make that useful to ourselves and others? Focusing on the front-end lets me think creatively from a technical background, and I really enjoy that.

  5. As a frontend developer, what is the highlight of the job?
    I love the satisfaction seeing the end user directly interfacing with your work. At Target I work on an internal tool, so we have meetings where the Product Owner goes over features with a subset of our users, and seeing excited reactions over something I built is amazing.

  6. What is the single most unexpected part of your job?
    There are, without fail, a million ways to express the same thing. Even coming into a conversation thinking you’re being super clear, it’s always a lot of work getting everyone on the same page. Every time, I find a new way to realize communication is hard. 

  7. What is the part of your job you enjoy the least?
    Responding to unexpected stress. It generally means decisions will be rushed and less informed, which leads to a worse solution, which in turn can lead to other issues down the road. 

  8. Outside of work, you’ve done a number of hardware related projects, can you tell us about those?
    It started with my dad asking me if I had ever considered putting lights in clothing, and led to a few projects where I had lights in clothing that would receive messages from the internet. I’ve put lights in quite a few objects since then that can communicate with the internet, and it’s been a really fun area to learn new skills.

  9. Would you say that being in Minnesota has helped or hindered your career?
    It goes both ways – Minnesota is a bit slower to adopt new technology, which can slow your career if you want to specialize in something considered untested by the industry. However, overall the tech scene here is incredible and there are always plenty of opportunities to do anything you want, even if it doesn’t translate into a usable job skill immediately.

  10. What is the best piece of advice you can offer a new software engineer, or anyone interested in getting into software development?
    Accept frustration as part of the universal learning experience. As a beginner, it’s really easy to not understand something and take that as a block on moving forward. It’s also really easy to look at everything that’s out there for software and feel overwhelmed. Compounding all of that, it’s also-also really easy to look at experienced developers and feel like they have all the answers. Experienced developers aren’t experienced in the breadth and depth of what’s out there for software. They found something to focus on, and were frustrated every day as they learned.. And most likely still deal with frustration every day. New devs: Keep in mind you aren’t just frustrated learning a new skill, you’re navigating what skills are important, which is extremely hard to do without experience. Give yourself a break, reach out for help, and know it gets better.

  11. Any Minnesota tech organizations you’d like to call out that people may be interested in learning more about?
    Javascript MN (https://www.meetup.com/JavaScriptMN/) is still doing virtual events, and is a great organization!

Robert Tomb

Almost two years ago I took on a new role as an engineering manager. In an attempt to get a better understanding of how to properly perform in this role, I’ve been interviewing several managers for the site. Here is the first in the series of those interviews. In it I speak with one of my old managers Robert Tomb, who is currently a Senior Engineering Manager at Target. You can find more information about him on Twitter and LinkedIn.

  1.  What was your career path to becoming an Engineering Manager?  Was it intentional decision or were you unexpectedly offered the opportunity to transition away from being an engineer?

    The first time I recognized I was being offered a chance to lead, the job did not include the title of manager. I was a Sr. Software Engineer building testing tools, and I was told that I could hire engineers to work on my team to support our new tooling initiative. The only catch was the team would be in our Philippines office. In that position, I did not have HR reporting responsibilities, but I helped to interview, select the onsite leaders for the team, and, with another local Sr. Software Engineer, drove the team’s technical direction.

    I did not choose to pursue this because it included the opportunity to manage. I’m grateful for it, though. It helped me recognize how interesting it can be to share my knowledge and scale my ideas beyond my own keyboard. It taught me to have confidence in my designs, learn to break down work so it could be shared with others,  and to include the input of the people on my team.

    This was not a transition away from being an engineer, this was a transition away from being an individual contributor. This chance came in 2006. I’ve gone back and forth between various IC, team leadership, and leader-of-leader roles.

  2. What is your definition of an Engineering Manager and what do you see as the purpose of an Engineering Manager inside you organization?

    An Engineering Manager is a leader in a technical organization who, formally, has the job to grow engineers and lead projects.

  3. Did you receive any formal training once making the move to management?  If so what kind? If no, what self learning have you done to close the knowledge gap?

    I have been a leader at a few different organizations over the last 15 years. I did not receive formal training from any of my employers over that time. At my current job, however, I am scheduled for multiple leadership growth training sessions over the next few months.

  4. How does a normal work day as a manager differ from your normal work day as an engineer?

    The biggest thing I dialed in on was the fact that I could no longer measure my productivity on quantity of my PRs, commits, or deploys. It’s now your job to help make other people productive.

  5. What is the single most unexpected part of the job?

    A good bit of what you’ve been doing on your engineering career growth trajectory has been leadership, and it has been leading up to where you are. If you’re surprised you’re a leader now, you’re not very observant. Being observant is a big part of your new job, are you sure you’re ready for it?

  6. What is the highlight of the job?

    Working with smart people and knowing you don’t need to be the smartest person in the room for the project to be successful. 

  7. What is the best piece of advice you can offer a new Engineering Manager?

    Here’s a response I gave to a similar question on twitter:

    https://twitter.com/bikeonastick/status/1217993737000947712

  8. Anything else you’d like to add for new or potential Engineering Managers?

    See # 5

    Seriously, though, you can be a leader without being a manager.

Erik Onarheim

Below is an email interview I conducted with Erik Onarheim. Erik and others are working on an open source game engine named Excalibur.js.

1. Can you tell us a little bit of your background as a developer?  When did you start? What was your first language? What is your current language of a choice?

 I wrote my first programs in middle school in a BASIC dialect on the TI-81 graphing calculator. The one I remember most was drawing the Sierpiński triangle using a random plot method. I also taught myself some basic JavaScript with “view source”, copying scripts, and experimenting. 

TypeScript (and JavaScript by extension 😉) has been my current language of choice for a few years. I find the type system to be wonderful and perfectly suited to wrangle the web. Today, almost anything can be done using JavaScript! The web is ubiquitous.

2. Where do you currently work and what is your position? 

I’m a senior software developer at Renaissance Learning in Minneapolis; we build educational software that helps kids learn to read. I do a little bit of everything from front-end to server-side, databases, and DevOps. I spend a good amount of time mentoring and reviewing code.

3. Can you tell us about your current open source project, Excalibur.js?

Excalibur is an open source 2D game engine for the web. Our goal is to make it easy for people to make games. We want to make building a game approachable to both the new hobbyist and the professional developer. 

Excalibur uses a film/theater metaphor: Actors, move around the screen and perform actions. Scenes are the stages (or levels) for actors to do things within. Last but not least, Cameras are used to view the action. 

4. What made you want to begin developing your own game engine?  Was the engine the result of building a game or the end objective from the beginning?

I’ve been interested in making video games since I started playing the original Nintendo, which was definitely a contributing factor to my software career and game dev hobby. 

Excalibur started as a work presentation advocating for TypeScript. The presentation was meant to showcase the possibilities of TypeScript, so I built a small platformer to demonstrate. I figured that other folks could probably use what I had made, and Excalibur was born! That said, building a game engine is one of those classic developer traps; it’s easy to get stuck working on the engine and never actually make a game. I try to build small games on a regular basis with the team. Ludum Dare (http://ldjam.com/) has been a great way to do that!

5. What were the factors that led you to selecting Typescript for the project?

With HTML5 and the new canvas API around 2012, the web felt like the best platform to build games for the future, before that I was experimenting with a Java prototype of a game engine with a work friend. After working on some complex JavaScript apps for my job, TypeScript felt like a natural fit to get the best of the web and static types (like Java).

In that time, I was in the middle of a large mobile project written in JavaScript using Cordova and we were feeling the pain of a large JavaScript app. At the same time TypeScript 0.8.0 had just been released and I was very excited about the prospect of strongly-typed JavaScript for Excalibur. 

6. What led you to the decision of open sourcing your project?

At the time most available game engines were commercial closed-source products. I wanted to build something that others could use to build games for free. The story has certainly changed in the last few years. Many game engines are now open source (or at least source open), and it’s a lot easier for hobbyists to gain access for free or low-cost. 

7. Compared to your position as a Senior Software Engineer, how does being the lead contributor of an open source project differ from being the lead of a work project?

In many ways it’s similar: mentoring, designing, testing, and the imposter syndrome. I feel like being a maintainer has helped me in my career. Being part of a team, designing, planning, testing, working through conflict, shipping and supporting code. I think the best thing being a maintainer has taught me is patience and kindness are paramount when leading a team or a project.

Sometimes I catch myself thinking “what do I know about making video games or running a project or programming?” but then I look back at what I’ve accomplished with the team, the things I’ve built with them, and the things that I’ve learned. That realization helps. I recommend this post if anyone ever feels like a phony.

8. Do you have any clear idea of how many people have used Excalibur as the engine for their game?

If we base our estimate on GitHub stars, we’ve had hundreds of people try out the engine or at least take a serious look at it. We’ve had several people reach out to us directly over the years, mostly hobbyists like us. We had someone recently port one of their old Flash games to Excalibur, which was awesome!

9. How many people have contributed to the project?  What is your process for accepting other’s code? 

Around 45+ people have contributed with code and more than that have contributed by opening issues or fixing documentation. We are always looking for folks to help and contribute however they can, and we welcome any feedback on things that could be different or better!

Generally we encourage people to open an issue, get consensus on a course of action, write code, and finally open a PR for review and possible merge. We try to be the most inviting and friendly project out there, all are welcome. We have all of the specifics in our contributing document https://github.com/excaliburjs/Excalibur/blob/master/.github/CONTRIBUTING.md

10. How does Exaclibur.js compare to other HTML5 game engines?  What are the pros and cons of it compared to Pixi, Phaser or any of the others?

Excalibur shares a lot of the same basic features as Phaser, melonjs, impactjs, playcanvas, easeljs, and others. Excalibur is written directly in TypeScript, but many others include TypeScript support including Phaser. The biggest pro for Excalibur in my mind is our focus on keeping things simple and TypeScript focused. The biggest area that we can improve is the developer onboarding and documentation experience. Excalibur has some okay docs, but Phaser definitely has a wealth of docs and community out there. Others, like Pixi and Three.js, are focused on visual rendering and are more low-level APIs for interacting with 2D or 3D canvases.

Excalibur focuses on 2D game development and building games in TypeScript that are easy to read, understand, and program. Excalibur has been a labor of love by a small team and it caters to the way that we want to build games. Most of us aren’t full-time game devs and so we’re learning as we go, which is why we tend to focus on trying to keep the API intuitive and not make assumptions about what our users may or may not know.

If you want to pick a game engine for the web, please try Excalibur, but don’t take my word for it, try other engines and libraries and see which of them makes you happy!

11. Throughout the project what were the hardest technical problems that you ended up solving?  Were there any that you didn’t solve and in what way was the design of the engine impacted by that?

The most challenging thing we built was the physics system for collision. We spent a lot of time tweaking to make it useful and helpful. We built in a tree based spatial partitioning system, which is a fancy way of only checking for collisions if objects are close to each other making it very efficient.

We spend a lot of time thinking about and iterating on the APIs as we build games ourselves, which is why we haven’t reacted 1.0 yet. We’re trying to find the pain points. It might sound odd but the fact that much of the core team only has time to commit to one or two game jams a year means that we come across APIs we developed that we’ve forgotten how to use. API design is hard, and we often don’t get it right on the first try. It’s useful to see the engine with fresh eyes, and to get feedback from others on the team and the community to make Excalibur the best it can possibly be.

The next technical hurdle this year is to be happy with the APIs and the performance of the engine and have a release candidate for 1.0. Some of the hardest decisions will be identifying APIs to change significantly or drop all together.

12. As an engineer what are you most proud of in your Excalibur.js?

I’m very proud that we’ve continued the project for so long (8+ years) and built several games with it. I’m also especially proud of what we have been working on this year, a brand new graphics API, WebGL based rendering that will increase draw performance significantly, and the Entity-Component-System (https://en.wikipedia.org/wiki/Entity_component_system) support for more maintainable (and extensible) game code. 

13. Would you say that being in Minnesota has helped or hindered your career in technology?  How so?

I wouldn’t have the career I have without being in Minnesota. With the cold outside and my homebody tendencies, it meant I spent a lot of time indoors with the computer tinkering and programming. This is really when I really became passionate about computers and set me off down this path. 

I was lucky and privileged enough to go to the University of Minnesota for computer science. Which by some lists, it is in the top 100 schools in the states for computer science (take that statement with a grain of salt). I got a great start, learned a ton, and met some great life-long friends. After university, I joined General Mills as a full-time developer after an internship, which was a great first job. It seems getting that first job/internship is the hardest part, and there are so many great places to start working in tech in Minnesota.

Additionally, there are so many good opportunities here to grow, it’s not just a fly-over state! We have so many local meet-ups and conferences, like Twin Cities Code Camp was where I gave my first talk about making HTML5 games. There is also MDC, NDC, MidwestJS, Open Source North, IGDA Twin Cities, and more. Folks should definitely check some of these out. Also, I recommend giving a conference talk a try at least once!

14. Where can everyone find more information about you and your project?

Thanks for interviewing me! You can find me on Twitter (@ErikOnarheim) and at https://erikonarheim.com, and on github. And more about Excalibur on Twitter (@excaliburjs) for news and releases. If you are new to development or experienced we do our best to be as friendly and inviting as possible. 

Check out our website https://excaliburjs.com, it comes complete with samples (https://excaliburjs.com/samples) and a gallery (https://excaliburjs.com/gallery/) of some of the jam games we’ve made. We also have a Google Group for any questions https://groups.google.com/forum/#!forum/excaliburjs 

Todd Gardner

Below is an email interview I conducted with Todd Gardner. Please follow him and his company at the information below and if you are a frontend developer, take the time to explore what TrackJS offers.

  1. Can you tell us a little bit of your background as a developer?  When did you start? What was your first language? What is your current language of a choice? 

I started my career in IT operations, I was a system administrator at Toro in bloomington. I spent a lot of time automating actions and hooking up monitoring systems, which sparked my interest. 

After a few years, Toro gave me the opportunity to switch into their software development group where I wrote a distributed IoT system that pulled data from ground sensors. We used C# and SQL Server, and a lot of gymnastics to make the whole thing work.

Lately, I write a lot more JavaScript than anything else. I tend to build web applications mostly, and it’s really the only option for applications in the browser. I typically write vanilla JS because it doesn’t change much, and I can pick up an old codebase and use it again. But I also dabble in React and Angular if it’s something that doesn’t need a long shelf-life.

  1. For those who don’t know what TrackJs is, can you provide a description of the application and its unique qualities?

TrackJS is an error monitoring service for web applications. It gives developers visibility into how well their applications behave in the hands of the users and reports errors in their code, third-party libs, or network failures. The web ecosystem is complex and asynchronous, it captures non-error events as part of error reports so that developers can understand the story of how the user got to the error.

  1. Where did the idea for TrackJS come from?

TrackJS is sort of the culmination of my development experience. I wrote a lot of web applications, and we always had to deal with weird errors. I would find myself creating these subsystems in my code to get better observability into behavior. In fact, I met my co-founders while building one of these systems at a local company.

After building simplistic versions of TrackJS several times for different consulting clients, we finally had the bright idea to build it on its own. I pitched my co-founders at Minnebar 2013. At the time, Eric Brandes was working on his own project, but was so excited about the idea that he dropped it and partnered with me. We hacked a demo together over a few weeks and brought it to a JavaScriptMN meetup in the old DevJam basement where we did our first pitch, and landed our first customers.

  1. When you set out to build the app, did you imagine the finished product to be something just for you to use, or did you always know that you wanted to release a fully realized and sellable product?

We were so naive. When we first started, the idea was that this wasn’t really a product, more of a bonus to our consulting work. If you hire us, you get all this error monitoring goodness for free! Of course, that didn’t work. That’s not really how the consulting world operates.

But as the system came together, and we talked to more people, we understood how painful this problem was, and how broadly interesting it could be.

  1. How many people work on it now?

Our team has taken several iterations. The initial team that I pitched was 4 people, and we didn’t even have a company yet. We just had a “shared copyright agreement” on what we wrote together, and hacked on nights and weekends. The team wasn’t quite right and we’ve said goodbye to a couple folks. The initial system was written mainly by Eric Brandes and myself, pairing together on the work.

A few months in, we welcomed Jordan Griffin to the team, and we began to specialize more into our current roles. Eric leads up the backend of the system with Jordan’s help. Jordan handles operations and making sure our systems are stable and resilient. I build the agents.

Our core team is still just 3, and we want to keep it that way. We enjoy working together and keeping our overhead low. With a smaller team, we can still move fast and focus on priorities better than other startups.

  1. How long did it take to get to a version of the application that you attempted to sell?

The idea was in March of 2013, we had a demo in July. Beta was in October. First sales in January.

  1. How many people are using your product?

Thousands, I am shocked and amazed by how many teams around the world use and love our product. 

  1. What tools did you use to manage your tasks and stay up to date with what everyone was working on?

Haha, we get most of that for free with a 3 person team. It’s easy to talk and keep everyone up to date. We do track our work in Trello, but it’s mainly for keeping conversation together on a topic. We also have a Slack channel for less formal things.

  1. What percentage of development at this point is new features vs maintenance?

75% feature work I’d say. We optimize our work to keep maintenance minimal, which supports our small-team strategy.

  1. From an infrastructure perspective, is there anything you wish you had done differently early on?  If so, what is it and why?

We started TrackJS in the cloud, relying on Platform-as-a-Service utilities to keep our code simpler. This helped us get started faster in the beginning, but it bit us in the ass. We got locked into a particular provider, and when our requirements outgrew the performance that the platform could provide, we were stuck. 

2 years into our product, when we should have been refining features and investing heavily in marketing, we had to embark on a major rebuild that took us 6 months to make our code portable enough to switch providers.

I have a sour experience with PaaS to this day, I’m skeptical it’s worth the tradeoff for anything non-trivial. Especially when you consider the infrastructure isolation and automation options that we have today.

  1. As one of the primary engineers on small team, do you feel any amount of stress associated with wide and growing adoption of your product?  
    1. If so how do you deal with that stress?

Oh hell yes. Building your our thing is a manifestation of all our decisions about software that people can look at and criticize. When someone doesn’t like it, it’s hard not to take it personally. I stress about performance and customers and growth all the time. You have to have thick skin to do this. To be able to take criticism, and distill it down to something meaningful, or realize that our product isn’t for everyone. 

People want different things and prioritize different aspects of their tools. At TrackJS, we’ve prioritized simplicity and intuition to the detriment of integration and configurability. That means that any web developers can use TrackJS with no training and understand the impact and context of errors. But you can’t build custom dashboards or run complex queries. Life is about choices.

Handling the stress gets easier. We’ve got a pretty successful product today, so losing a customer or getting bad feedback doesn’t crush me like it once did. There is more to life than software, and it’s important to remember that things outside our computers are a lot more important.

  1. Where can everyone find more information about you, your product and your company?

Everything you need to know about TrackJS you can find at TrackJS.com. I occasionally have witty things to say on twitter, I’m @toddhgardner.

Zachary Johnson

Below is an email interview I conducted with Zachary Johnson. Please follow him and his company at the information below, and be sure to check out his game Joggernauts. Available now!

  1. Can you tell us a little bit of your background as a developer?  When did you start? What was your first language? What is your current language of a choice? 

I’ve been a developer since I was a teenager. I used to make games in QBasic, and then I taught myself web development. Uncompiled, plain text scripts in languages like Batch Shell, QBasic, and JavaScript meant I could learn a lot from other people’s code.

Today I’m generally either doing application and UI dev in JavaScript or game dev in C#.

  1. For those who don’t know what Joggernauts is, can you provide a description of the game and its unique qualities?

Joggernauts is a side scrolling game (like Mario) where one to four players – alien athletes that can’t stop running – must use a shared teleportation ability to solve color coded puzzles. It’s available for PC/Mac and Nintendo Switch. I’ve been told it ruins friendships. Just kidding. Maybe.

  1. Where did the idea for Joggernauts come from?

Joggernauts has a very specific origin! I was playing the game BIT.Trip Runner with my friend Jesse. It’s a single player rhythm game, and we were taking turns trying to beat the levels. Joggernauts was the answer to the question of, “How could we both play this game together, multiplayer?” The idea for Joggernauts was that a team of players could run together in a line. The teleportation, switch-to-front, ability that players must use in Joggernauts was a way to make sure that nobody got bored running in the back.

From there, the idea for Joggernauts became about making a game that anybody could play with friends. It can be hard to have fun playing some multiplayer games with friends because of different player ability or experience levels. If you always lose, and your friend always wins, that can get old. We wanted to solve some of those problems with Joggernauts and make a truly cooperative party game. 

  1. When you set out to build the game, did you imagine the finished product to be a fun side project, or did you always know that you wanted to release a fully realized and highly polished game?

I did think it was an idea that could turn into a commercial product, but I think every new game idea needs to be proven out. There’s plenty of game ideas I’ve abandoned. Joggernauts started as a very rough demo with free placeholder art. I play tested it with folks from the Twin Cities game development community. I had never, ever had a response to any of my previous games like I did from demoing Joggernauts. Ultimately, it was the overwhelming positively response from people who actually try Joggernauts that kept me going through the finish line.

  1. How many people worked on the game?  What parts did each person work on?

Joggernauts was developed by the three owners of Space Mace. I was the programmer. Tommy Sunders (@supertommy64) was the artist. Robert Frost III (@heyfrostiiie) did sound and music. Tommy and I co-designed the game. In the last months of the project, we had help from some local contractors. Krista McCullough (@knm_xyz) helped with code and art production. Martin Grider (@livingtech) helped with code. Jason Pfitzer (@JasonPfitzer) helped with animation and art production. We also partnered with publisher Graffiti Games, their producer at the time Dave Proctor (@blankdave), and the QA team at Plastic Fern Studios.

  1. What technologies were used to build the game? IE, IDE’s, languages, design tools, etc.

The game was prototyped, designed, tested, and pitched largely in the JavaScript game engine called Impact. Once we set a release date and platforms, we switched to Unity and C#. I use Visual Studio Code. Tommy uses Adobe Illustrator, PhotoShop, and After Effects. Robert used the FMOD middleware for game audio, but you’d have to ask him about his sound design and music composition tools. We used Git for version control.

  1. How long from start to finish, did it take to complete the game?  Was everyone working on it part time or full time?

We were a team of three very part-time people for the first three-ish years of design and development. At the end of that period we had secured our platforms and a publishing partner, and the three of us went full-time for the last 9 months of development. It was over four years from start to finish.

  1. What tools did you use to manage your tasks and stay up to date with what everyone was working on?

We primarily used Slack for communication and Google Drive Docs and Sheets for documentation, design, and task management. We used DropBox for asset sharing. We tried Trello but bounced off of it. We used Monday.com to greatly help us with our first full production schedule.

  1. One thing I’ve always found true for video games is prototyping is often the most important design tool, because it’s very hard to determine if something will be fun until you play it.  Do you agree? How often do you prototype out game mechanics?

I always prototype and playtest my game ideas! I really like to see how other people engage with a prototype. I even started a regular public playtesting event during the development of Joggernauts so we could do it more often. Tommy actually joined the project because he liked the demo so much. We hadn’t worked together before Joggernauts. We asked Robert to join us because of the great work he had done on a different game prototype that Tommy had worked on. So prototyping and play testing isn’t just a way to design a better game, but it is also a way to build a team.

  1. How much development time did it take to get to the simplest, playable version of your original concept? When you played that version for the first time, was the fun level what you were hoping for?

It took about a month to build a prototype I was willing to show to somebody else. I was very pleased with the response, as you have probably already read!

  1. Throughout the project what were the hardest technical problems that you ended up solving?  Were there any that you didn’t solve and in what way was the game impacted by that?

Joggernauts is not a technically complex game, however it’s design is very complex. There’s a tremendous amount of small tweaks and big evolutions that the game underwent from years of intensive public playtesting and solicitation of feedback from peers. Even then, I don’t think we totally cracked the difficulty curve.

  1. How was the development process different when preparing to launch on Steam vs Switch?

We’d been building for console from the beginning, so the Unity port to Switch was painless. Steam was maybe more difficult because we had to support graphics settings and keyboards. It’s way easier to patch and release updates on Steam. Also, Nintendo did their own QA process on our game, so we had to allow enough time before our release date to pass that.

  1. Do you feel there is a higher level of prestige within the developer/gamer community from releasing on the Switch because it is a Nintendo console?

I think any console release comes with a degree of prestige. It was also certainly a dream of all of us to make a game for Nintendo. I got a Nintendo Seal of Quality tattoo after our launch!

  1. How much time as a developer do you need to devote to maintaining the game now that it is live and published?  Do distributor changes require that you update things periodically?

Our game was still a full-time job for at least a few months after launch. There are bug fixes, patches from player feedback, and ports to other languages and platforms. After that though, it’s totally up to you whether more content updates make sense for your game. There aren’t any update requirements from game platforms, with the exception of maybe Apple OS X where code signing recently became a bigger issue.

  1. Where can everyone find more information about you, your game and your company?

Thanks for interviewing me! Find me on Twitter (@zacharyjohnson) and find Space Mace on Twitter (@SpaceMaceGames), or visit our website: https://spacemacegames.com

Welcome

Welcome to MNDevs.com. A website dedicated to the engineers, managers and designers who make up the Minnesota tech scene. Here I hope to discuss many of the aspects of a tech worker’s life. From favorite programming languages, to management techniques to dealing with stress.

The plan is to interview anyone and everyone doing anything interesting here in the state. So if you’re working on something that you want to discuss, please let me know and let’s talk. We all have something useful to share with the community.