LIFE AT NORDEUS

THREE LESSONS I LEARNED AS A SOFTWARE ENGINEER

Thunder rumbles through the storm.

Blacksmiths clear sweat from their faces as they gaze into molten steel hardening in the smelter. Sparks fly from anvils as hammers pound upon them. The steel piece is pushed into its hardwood grip and lifted to the heavens in awe.

“The gods have bestowed upon us… a masterpiece. “, a senior game developer exclaims, “This tool will save us hours per sprint! We’ll be able to ship this thing at least 3 months sooner.”

“Not the gods…”, a young apprentice retorts, “… I made it.”

The new game beats its competition by only 5 weeks and is a resounding success. Quarterly financial reports sparkle in green, and the tool’s craftsman buys a sports car with a V12 engine which he continues to turbocharge, riding off into the Montenegrin sunset.

– The End –

Okay, that might be slightly dramatic, but you get the picture: tools are super important in game development! They make jobs easier, save time, and open up new possibilities. The Nordeus forge calls out for new blacksmiths and apprentices every so often, so be sure to check out our Careers page for any openings.

Making internal tools is a unique role in a gaming company.. My clients are my colleagues, so I can directly see how my work  impacts their workflow , gather feedback easily, and iterate quickly. It’s also great if one has broader interests in software development, because you will almost never stay in one language or technology during your efforts to support other engineers, artists, designers or any other roles in your company.

Without further ado, here are 3 lessons that I learned while working as a Software Engineer in Nordeus.

1. FIND THE ACTUAL PROBLEM

I would argue that listening to your client and finding the real requirements are your most important skills. People will often come to you with an itch: something they want automated, some part of their workflow they need to supercharge, some job that they need to finish. In a natural attempt to scratch that itch themselves, they’ll come up with a solution and will come to you with something along the lines of: “I need a button that will take X, process it through all of my Y’s and display it to me in Z.”

You start making the tool exactly as the client described. You spend a few days building a usable version and take it to them. The client seems confused and borderline disappointed, but tries to hide it.

“Uh… Yeah, seems alright, but not QUITE what I meant,let me show ya”. 

So you go over their proposed solution again, this time slightly modified, in a joint effort to make something useful. You both want it to succeed, and you try again and again, trying to approach the pain point at the right angle, but something seems off every time. 

Finally, it hits you – you’ve been working on the solution to a problem without considering the problem at all.

It’s crucial to dig under the surface until you’re sure that you’ve found, outlined, and specified the actual problem you are trying to solve. The shallow approach of building a proposed solution without understanding the problem might work sometimes, but the long-term net value of it is negative. You will almost certainly end up wasting time.

So, when someone comes to me wishing for a new button, I ask them questions and do my best to understand why they want this. 

• What do they know or have? (the inputs)
• What do they expect to receive? (the outputs)
• Why do they want this? (the motivation, goal)

The resulting solution (path from inputs to outputs) may or may not coincide with the client’s proposed solution, but it appears that digging under the surface to find the problem always leads to a productive outcome. 

One upside to this is that you sometimes discover other problems or new ways to do things more easily, efficiently, cheaply, etc. Another bonus is that often, once you two discuss the issue, you realize that the solution already exists, but the client just didn’t look at it that way or wasn’t aware it was an existing feature.

So, to recap – listening closely and putting myself in the client’s shoes has helped me to be more productive and proactive in my work.

2. BE A JACK OF ALL TRADES, MASTER OF SOME

Source: Lynn Fisher, Dribble.com

You’ve probably heard the saying “Jack of all trades, master of NONE”. 

I prefer the original version “… master of SOME”, especially as a Software Engineer. 

Once I’ve discussed the requirements with the client, it’s time to map out a practical path that will take us from the inputs to the outputs. Spoken more concretely, I need to decide on a tech stack to implement the solution in. Of course, most frequently it is within already active frameworks and technologies in the company such as the Unity Editor, python for Maya or MotionBuilder, but tackling some larger problems requires standalone applications. As an example, we used the Blazor full-stack web framework to implement an automated testing and metrics dashboard that we use to track Football Engine’s development. This is where knowing multiple languages and technologies, being aware of libraries and frameworks really comes in handy.

Naturally, one will know only a handful of technologies very well and they will be the weapon of choice for most challenges, but I’ve found it very beneficial to be ready to venture outside your comfort zone whenever it seems promising.

3. JUST MAKE IT WORK

Source: Henrik Kniberg, Minimum Viable Product Design

Last but not least, a classic piece of advice you’ve probably heard a million times is still worth mentioning: “Just make it work”.

Like many of us, I like writing neat code, using clever optimization techniques and geeking it out on whatever I’m working on so I can get it as close to perfection as possible. There’s nothing wrong with improving your solutions and pushing your limits, but I admit that I’ve found myself going deeper into the rabbit hole a few times more than I should have in the past. 

In retrospect, I could have spent that time much more efficiently if I had just made the solution sufficiently good at the time and moved on. It’s a delicate balance, of course – we don’t want to go into the other extreme of doing a sloppy job of everything – but there’s a real productivity boost in knowing when to stop and move on to the next iteration of the current problem or move on to the next one. 

The point is to provide value to your team. I believe it’s useful to have that word in your mind when making decisions on what to work on and how long. If optimizing or extending something won’t make a job easier, faster, cheaper or won’t open up new possibilities for our games, then it’s probably not worth doing at this time. Also, In my experience the dilemma often wasn’t whether an effort was worth pursuing at all, but when we should pursue it. There are always good ideas and potential improvements to work on, but the tricky bit is to figure out which effort will provide the best value in the current timeframe. It’s also worth noting that a tool’s development is almost never finished, only paused in order to invest in higher-value opportunities.

So yeah, the old man waving his stick and going “Premature optimization is the root of all evil!” or “Don’t fix it till it’s broken!” is right this time, I’m afraid.