As an experienced engineer, I read the book hoping it would allow me to read F# code better. What I got from it instead was a better intuition on how to write a better and cleaner code. The book teaches how to refactor imperative code into functional code that uses filter/map/reduce.

If you’re new to functional programming and callbacks, this book will give you the tools and ideas to evaluate your code better.

If you’re an experienced developer – it will give you vocabulary and names to concepts learned through experience. You’ll be able to better mentor your peers and write better feedback in code reviews.

The writing style is very casual – building on relatable real-world examples. It avoids computer science terminology – making it approachable no matter the experience.

Good things

JetBrains Rider is great IDE and since I already have it as part of license I decided to go with it.

GitHub CoPilot and CoPilot chat sometime give useful suggestions. They also to tend to hallucinate a lot. Since I’m mostly in learning phase I’m turning off auto-suggestions to force myself to think.

F# Discord community is amazing. The amount of discussions and how quickly I could get answers is amazing. It’s also full of people asking very detailed and expert question which makes it poor choice for passive learning at my beginner stage.

Friction points and mixed successes

Online teaching of F# isn’t really beginner friendly. I watched through the F# Community promoted tutorial “F# for Beginners” and it mostly a tech demo and not so much a ramp up to be successful with the language.

One of the side-quests I made is that to read Domain Modeling Made Functional as a way to learn more F#. I did learn more about architecture but I still struggle with writing code. I don’t mind as it will help me create better Python and TypeScript apps.

Overall I’m having quite a bit of problems with fully understanding difference between collection types and how to deal with strings and characters. I’m looking for a better resource about it to grok it better.

I’m enjoying Exercism platform to practice writing smaller apps. While lacks good intro to language itself it makes it up with nice problems that come with tests. I really enjoy seeing different community solutions.

Standard library is highly confusing. There are concat functions – System.String.Concat and String.concat . I’m still looking for a good tutorial on how to navigate things like this.

Unexpected successes

Reading Grokking Simplicity as part of learning process helped me gain new vocabulary for concepts and terms that I learning through teamwork before.

Learning much more about Microsoft’s .NET ecosystem and different UI toolkits that exist. I’m now more aware disconnected different technology bubbles are.

Next steps

At the moment I’m working through Grokking Functional Programming. I think it won’t help me with writing more F# but should provide useful knowledge for later.

Do more Exercism exercises.

Read Essential F#.

The book does a great job of teaching Domain-Driven Design and uses F# as a language for the example code. Author starts slow with world building and how it’s about business needs before diving into any technical code. It keeps circling back to business needs with almost every line of code written and with this approach it nicely presents how developer’s job is not to write code but to solve business problems.

F# makes the whole book more interesting as it forces you stop thinking about your everyday language and makes you also consider some new ideas. At the same time, all the ideas are easily implementable in modern languages like Python or TypeScript.

Nitpick about the book I have is that it glosses a bit too much over the code implementation while going into details of specific revisions of F# language.

Who should read this book? Developers that want to increase their value to their employer. It would also be great group read for teams that are trying to refactor legacy code. This books goes on my list of must-read recommendations.

Jose Antonio Pio Gil is Engineering Manager and Cloud Architect and Marley Spoon. We discuss the role of Engineering Manager and Cloud Architect and his approach to leading high-performing teams.

How do you see your role?

I’m responsible for my team of engineers and the cloud architecture of our system.

In terms of architecture, I try to create systems that are beneficial to engineers in the long run. Most engineers try to solve their tickets and forget that they have to maintain the system the following year. I think about maintenance, security, and the reliability of that system in the long run. Not only because it’s expensive for the company, but also because it burns the engineers down.

A large part of my job is helping engineers avoid shooting themselves in the foot. They shouldn’t create a maintenance burden because they have to finish something today. Business often overlooks this technical debt. It will cost real money to the company when engineers get tired of maintaining tech debt and switch companies. I’m trying to prevent this from happening in the first place.

What does an Engineering Manager do compared to Senior or Staff Engineers?

You get responsibility for a team. You need to build it, take care of it, and account for ups and downs. There’s also a more bureaucratic aspect of taking care of their contracts and hiring. 

You’re responsible for delivering results, taking into account their education and training, and ensuring that your team lives the company’s culture. Sometimes you also need to mediate and help with conflict resolution between members. You have to see the human side of the work rather than the technological. During many individual conversations, you figure out what each engineer needs for their job. You try to unblock their work.

Our Staff Engineers handle the technical side of what we do. As an Engineering Manager, I don’t implement engineering solutions.

How does the role of Architect compare to what Senior or Staff Engineers do in your company?

As an Architect, I take care of the overall architecture and coordinate the work between several teams on our Tribe. There are about 60 engineers across all of our departments. A large part of what I do is negotiate contracts between different microservices that different teams maintain. Once agreements are in place, Senior and Staff Engineers implement software systems.

We need so much coordination because we’re moving from a monolith to a microservice infrastructure. We keep redefining ownership of different parts of systems and how we will transition it going forward.

How do you organize your team?

I assume principles, and I don’t control what they do. I set clear expectations about what I want them to deliver this quarter and where we’re going this year.

The way I see it is that it’s a contract between you and me and that terms have to be clearly defined. If not, you won’t know what to do. One of the things that I need to account for is how I tell my team if they’re doing a great job or failing. There needs to be clarity.

The other thing is that I set clear boundaries on what I don’t do. I don’t track time, care how they organize their day, or build a sprint. I care that they finish each sprint. Whatever is in this sprint, they decided how to put it together with the product manager and me. Then during a daily meeting, I want to know the status and how to unblock everyone for the next day.

When I do a retrospective, I follow the principle of self-organized teamwork. I keep drilling down to the core reason if tasks are not done. If the excuse is that another person didn’t finish the work, I want to understand why team members didn’t support them in completing the work.

Self-organization means that I don’t have to tell them what to do. I focus on specifying the expectations. They have to provide the process. Why? Because all my team members are seniors. If you’re a senior, I’m not expecting to tell you how to do your job.

If you’re a junior or a professional in the middle, I will help you do your job and find strategies, build software, etc. But if you’re a senior, we talk about the output, not the process. I’m assuming you have enough experience in your career to know how to do it. As an experienced professional, I trust you can deliver on these things.

Why focus on results?

If I care about the process, I need to care about coordination. So I give up control and coordination and care about the result. I’m so focused on results with such a highly skilled team because I work on core infrastructure for our business. I can’t afford to mix juniors with more experienced developers.

Since our downtime means a serious loss of revenue, we have a higher bar for the quality of our solutions. We need to make sure that every incremental change, each deployment is also a final solution. We need to make sure that If we stop working on this subsystem today and leave it as it is, it will continue for two years.

How do you ensure the quality of your team’s changes to the system?

I’m very clear about my expectations, and I talk with them a lot. For every change, we discuss how it needs to be tested and make sure that it’s clear what will be the impact on the business. How will our changes impact customer care, accounting, or marketing? We need to be sure that we understand all the aspects of our interventions. 

If we make a mistake, this might mean that we need to send out 100,000 emails to our customers apologizing for the error. We need to understand the impact of our work and coordinate with other teams to prevent such events. We often work with customer care to ensure they’re on board with the number of potential support issues they’ll need to handle.

To minimize the issues, I make sure that my engineers have clear boundaries of responsibility. Clear boundaries allow us to discuss the potential impact on other systems when making changes. We’re not conservative with our changes. We need to make a comprehensive plan of testing the changes as part of the implementation plan.

What’s your big picture goal?

Our software is there to support business. It needs to make more money than it costs to write and maintain it. There’s no academic beauty to real-world engineering.

The only thing that executives care about is if our software makes their lives easier and how much money it makes. My engineer manager role is to explain this to new team members. You are only as valuable if you can produce value for the company. As an engineer, it means that you already are beyond dogmas and own your craftmanship. You are already a senior, and you already had training. Now you need to generate value.

What are some resources that you recommend to people?

The Culture Code: The Secrets of Highly Successful Groups

Dare to Lead: Brave Work. Tough Conversations. Whole Hearts.

I suggest that people enroll in Nonviolent Communication training to improve their communication skills.

I expected it would be about specific writing and the shape of words. It turns out that words are highly contextual and that before you write, you need to consider your audience. The Copy Workshop is an empathy and marketing seminar that helps you internalize this. There’s almost no talk about specific language rules.

Three powerful things that I learned

Consider for who you write and ignore silent judges. If I know my audience likes a certain text style, I shouldn’t try to write it for my high school English teacher. I should also ignore other experts in the room if they’re not my audience.

With every text – ask who it is for? While this can be applied to my writing, it also helps me evaluate texts from other people. It provides an often needed perspective.

Copy isn’t good or bad; it’s effective or ineffective. Achieve goals. Move on. Create more, and don’t worry about the artistic value of your text.

Naomi Spirit is a founder of a small digital agency From This Day. They focus on creating websites with a low environmental impact. We discussed how to develop a low carbon website in terms of technology choices and user experience (UX).

How did you get started with the idea of creating an environment-focused digital agency?

We were looking to orientate towards meaningful work, to help people doing charity or ethical projects. When we’re doing work for people doing good things themselves, it’s almost like you’re doing the good work yourself. With our support, they’re making even more impact with their work.

Around 2017 when the IPCC Climate Report came out, I just felt so motivated that I had to do something to help the environment. I decided to start a blog to promote ways we could all be greener. So I used my development skills to create  Little Green Ways. It has achieved a good reach throughout the years. We even started doing a bit of activism from it, including a petition about microplastics which gained quite a bit of traction and got discussed in a parliament.

I reached a point where I was deciding between moving to environmental work full time and not being a web developer anymore. Around that time, I became aware of the impact of our digital lives on the environment and the amount of co2 that we produce. I realised I could try and use my technical skills for good. 

The Internet alone produces more carbon than the UK and I realised that maybe my specialist niche could help with that. While websites are a small part of the whole Internet, it’s still an area where I think I can do my bit. I can help educate other people to understand it better, create better websites that pollute less, and develop this as a specialist skill.

That’s how we shifted toward building super low carbon websites. Our new websites create about half a gram of carbon per page load. In contrast, we were looking at anywhere between four and 10 grams of carbon potential before. We’ve reduced the effect of any new site that we’re building. We have used our skills to ensure that you can still have a beautiful site even if it is low carbon, that’s where artistry comes in for example –  www.arranecosavvy.org.uk – which still looks great even though it’s creating much less carbon. Restriction can actually improve design as you have to think outside the box.

What’s a low-carb website, and how do you think about the whole process?

Websites are usually served from servers that are not particularly environmentally friendly. There’s also a lot of infrastructure for information to get through to the device requesting that information from the server. Your end device also uses power to display the information. So you need to break this whole process down into many different areas to see where you can improve things.

The first thing to do is to make sure you have green hosting. We use Kualo and find them fantastic. They consider themselves a carbon-positive company. That is based on carbon offsetting. We realize that’s not the answer for everything, and we still need to reduce what we’re using too.

In terms of the website, it comes down to optimizing it to be as slick as possible. Use as few images as possible, reuse them, and use SVGs where possible. Compress the assets and build the theme light. Try not to use fancy fonts, keeping it plain where possible.

Another thing to consider is also your content structure. If you have a good User Experience, there’s less need to click around the site, which downloads extra assets, and increases server usage. It’s also worth considering a good archive policy and only keeping content if it will add value in the future to your actual website or SEO.

If you design a website with a dark design, it draws less power on the user’s device. So really, it’s just about being considerate about everything you’re doing. Doing things of value and just keeping everything as light as possible.

How can I think about my carbon footprint in the Cloud?

As an example, sharing your video on a Zoom call is carbon-heavy. If you’ve got a zoom call with 100 people sitting there all with video on it is creating a lot of carbon. There has to be a bit of awareness around how we work digitally with each other. I think the same with basically any green stuff – we can try and do things more sustainably. But the real green thing is to reduce what we’re doing, switch off a little bit, use less of everything.

There’s a great book by Gerry McGovern – World Wide Waste and a video talk that details lots of detail about how much carbon our digital lives uses. For example, a Kindle becomes more environmentally friendly than a paper books only after reading around 150 books.

What are some valuable resources and practices that you can recommend?

Website Carbon calculates how much carbon your website is using.

We are planting trees to offset the carbon usage of our projects and lifestyles. I can recommend Trees for Life and Ecologi.

Join 1% for the Planet Impact Pledge to support environmental initiatives.

Jernej Virag (LinkedIn) is a Technical Lead / Manager at Google. We discussed how mid-level developers can become Senior developers and how to ensure that you can deliver what you promised as a technical lead.

How do others introduce you?

They usually introduce me by explaining how my name is pronounced My current role is what they call a TLM – Technical Lead / Manager. It’s an informal role that was created because Google tends to have a lack of engineering managers on the engineering track and engineers tend to now also take up a mantle of managing smaller teams.

I’m currently one of the technical leads on the Android Google Assistant project. I’m responsible for the core architecture of the Androids, Phone Assistant, together with about ten other senior engineers and architects. We form a kind of council, do design reviews, work on basic architecture, support our teams and ensure that our product works on your Android phone.

What kind of seniority levels would you see in a team?

The usual team size at Google right now is around 10 to 15 people. About three or four are Senior Engineers, one or two Staff or higher. The rest are about half mid-level Engineers and half Junior engineers. The distribution between teams varies, but it is rare to see a team composed of mostly senior engineers.

How would you define a Senior Engineer?

At Google, we think about seniority in terms of responsibility. You are an individual contributor when you get a task that you work on yourself. It could be a big task like owning a whole piece of User Interface or a library.

The requirement for the Senior Engineer role is to be a go-to person for something. You need to be a person that other engineers ask for advice and to make technical decisions. To be successful at this, you need to think in terms of “Why are we doing this?” and also be able to clearly communicate the reasoning behind decisions to others in your team. You also need the authority and technical knowledge for people to trust you. And that trust is critical – most senior engineers aren’t managers of the teams they lead, so people won’t listen to them if they don’t have enough trust in the team.

You need to prove three things to get to the Senior engineering level. What I just talked about is Leadership – gaining trust and being able to influence other people to follow your designs.

Another aspect is Impact. To demonstrate impact, you need to show that your work is useful and helps the overall company bottom line. It’s a measure of how useful your work is to the company and others. The company needs to understand why it’s paying you. And a senior engineer needs to demonstrate that their work impacts more than just their team in a measurable way. This has unfortunate side effects of the infamous launch-centric promotion progress process. It’s easier to measure the impact of newly launched features than justify and explain future usefulness of cleaning technical debt or improving infrastructure.

The third one is Technical Complexity, where you need to show that your work is sufficiently complex to be worth the senior engineer title. This means that your work is more than just putting some buttons on the screen or running simple CRON batch jobs.

From a practical perspective, to get promoted, your manager needs to give you a chance to work on a project where you’ll be able to clearly demonstrate those three aspects. After that, it’s all on you.

What’s at the core of being a Senior Engineer?

It’s about always asking one question – why? Why are we doing what we’re doing? Does this product, technology, approach, business strategy, architecture, library choice, language choice or any other decision make sense?

If you keep asking yourself why and writing down the pros and cons, you will usually end up with good decisions, especially if you give it to other people to scrutinize and to contribute their ideas. Then you iterate on feedback with fresh eyes until you’re able to make an informed decision.
The main development I see with junior and mid-level engineers is that they’re cargo culting and not thinking their solution through to understand what they’re trying to accomplish. They’ll decide on a technology and architecture based on an emotional hunch, “easiness” of implementation and their limited skillset.

Growing to senior engineer is where you go from I’m taking Docker because everyone is using it to I’m taking Docker because of these upsides which outweigh these downsides. When you can adapt to this mindset, everything else follows. 

They say “a good engineer has to be lazy”. But a good engineer needs to be lazy in the right way. There’s workplace laziness where you’re always trying to find ways to minimize the amount of work to reach your goals. If you’ve saved three months of work, your team will get better results than if you’d worked for three months. That’s the good kind of laziness.

But what’s not acceptable at a Senior level (or any other level really) is to be intellectually lazy – where you decided because it emotionally felt like the right thing, not because you’ve spent time thinking it through.

My favorite example of this is when you’re building a new product, and you know that you will need to internationalize (i18n) at some point. What I see junior engineers do is just ignore the requirement “because we don’t need to think about it yet”. Then one year later, you find out that your libraries don’t support i18n. Now their team is losing to their competitors because they need to rewrite large parts of your technology stack instead of adding user value. 

Instead, they should think about how to be prepared for i18n in the planning phase. Ensure that when they pick libraries, they support i18n and architect the backend with this in mind. Add i18n as an item to the checklist when evaluating different solutions. It doesn’t mean they should actually add the i18n support, but they should think about it. Don’t do “manual” work but still do “thinking” work.  And this is a tough mindset to have, and I even see our teams struggling with it. Think first and then build.

How do you build this culture of asking why?

Trust, I think, is the only answer here, and that’s why it’s so hard. When it comes to trust, business needs to trust engineers, and engineers need to trust business, UX, and everyone else.

It’s really, really hard to assemble good teams. This is where big corporations have the most significant problems. When you get a direction from high-level leadership it propagates down the hierarchy. At every level, people are trusted to drive the initiative forward and document their thinking. The issue is if they have the trust of their peers.

One of the significant improvements we made in our teams was to have regular design review sessions with senior engineers across our organizations. Engineers come to show their design and then we talk about it. Depending on the tone of the conversation, you either gain or lose trust. If you’re a senior person and start your feedback with “Hey, why are you building your feature like this? This is stupid; how could you do something like that?” – it will result in people not coming to you and asking for yout opinion. You lose trust and those engineers aren’t going to learn from you. We both know developers that behave like this. Behave like programming is some kind of ego competition where you need to win; behave like they always know better and they need to constantly prove it. There’s also a different way of discussing: “Hey, you kind of forgot this, this and this. We used your proposed design already in product X and there we hit this issue, there’s the post mortem document for a production outage.” 

Just by changing the tone and getting your ego out of the way, people are more likely to listen to you and more likely to come to you and say,” I don’t know this. This doesn’t look great to me, but it’s the best way I know how to implement this. Can you help?”.

The above mindset continues into a culture of blameless post mortem. If you actually reach that point, you have people who can openly discuss everything they did wrong. The end result isn’t people inflating their egos by tearing down all the things you did wrong. It’s a conversation in a different tone: “These six things we did are the cause of a 16 million user outage. We need to work together on this to fix it across four teams.”

It’s tough because as soon as teams grow, it’s so easy to lose the personal connection with the people on the other side. Especially when working remotely, where the other person is just a face (or even worse, an avatar) on the other side of a video call. You stop seeing them as your allies but as people slowing down your path to project launch product launch, causing you to do extra work during weekends.

Can you introduce the practice of asking why from the bottom-up, or does it need to originate in management?

I think a good engineer can start this practice as long as they’re the communication firewall between their team and the outside. A single team manager can trash trust, basically, within weeks, if they do it wrong.

I think you can do it in a small team where you can cultivate trust. There needs to be a clear communication firewall where the lead needs to step in and protect the team from outside influences. 

At this point, it becomes a question of larger organizations’ style. Google is not a top-down organization, so it’s up to teams to decide how they want to work. In a more top-down organization, your team practices can help propagate these ideas to management.

How can a junior developer become better at the practice of asking why and related skills?

Just… ask yourself “Why?” in the context of the tools you are using. Think about why you chose Python? Why did you choose your library? More importantly, read other peoples code and think about what decisions they made. In my field, level up by having Android engineers go and look at Android source. For some reason, that’s a very scary proposition for most people, although it’s all there – a single click away.

When you find something broken, you can ask yourself – “why is this built like this?” or you can go to the original code author and ask them, “why was this built this way?” Most of the time, you’ll learn something new. If you’re lucky, it’s not going to be just the technical part but also the organizational part. The latter is important as well. You’ll hear stories of how the organization approaches different risks, past failures, and how they try to mitigate that. You’ve now learned important things about the culture, and you can prepare your projects better. 

Sooner or later, you’re also going to be the person that knows how to build things as well. The more knowledge you have, the more you need to learn how to communicate it. The reality is that most of this needs to be written, so you need to practice and develop this skill. It also tends to be in a format of answering different whys – why did we choose these things and the other options we considered. Practice writing and explaining your whys. As you get better at it, you start using this skill automatically in your emails. You explain things better, and that leads to increased trust. 

What should someone who is currently working in a small company and can see themselves not growing as an engineer anymore, do? 

The easiest way is to go work in a team where you’re not the smartest person in the room. It’s tough to grow if you’re not challenged. It gets even harder if you’re on a team that doesn’t need to change because you’re wholly dependent on outside sources. The Internet is full of blog posts written by people with two years of experience who never lived with their decisions. The sad part is, to become an excellent senior engineer, you need to live with your decisions for the next few years. It also helps to join a team where you need to live with someone else’s decisions from five years ago and see all the ways that they can break.

You can always write code and deploy it, and it will work for the first year. And then the second year, probably as well. And the third year, your startup will fail because it can’t change your codebase to follow the market. You need to have these kinds of experiences to grow as an engineer.

If your team doesn’t challenge you to grow, read books, watch lectures, follow blogs. Conferences are starting to be a thing again and they’re full of talks where people explain what they learned. Find people on the web that are smarter than you and can tell you what you’re doing wrong. Read other peoples code and look at the massive open source library of software as an inspiration.

How do you know that the engineering team you’re planning to join will challenge you to grow?

My tactic is to go and talk with the prospective future team members. Longer lunch works well, or even a virtual meet the team. You can quickly see, within an hour, if new team members are actually interested in growing, if you can have a good technical debate with them, and how they approach working on their project. I’m also checking if they can answer the “whys.” My favorite questions are usually around the things that went wrong and what they learned from that.

It’s also not the end of the world if you join a more junior team. You can use this opportunity to level yourself up in leadership skills and create a framework that will level up the other people on the team. It will be challenging because you don’t know what you don’t know and what you’re doing wrong. You will need to get into a feedback loop of improving yourself and the team. You will spend a lot of time practicing your explanation skills to explain things to other people to make them better. You’re not going to grow fast as an engineer, but you’ll still grow.

As a team lead – what kind of things are you saying no to?

One of the significant mindset shifts that I had to do when I came to the team lead position was protecting my team’s time. At this level, you start saying no to everything that doesn’t fit your team’s direction or vision. You don’t want to take unplanned maintenance of a project you are not responsible for. Your team will not get rewarded, grow, and you’ll look bad because you won’t deliver on your core responsibilities.

In a startup or a small company, that means not doing projects and features that are not valuable—not doing rewrites into a new library stack or adding features that only a handful of users want. These kinds of things won’t bring in more money, and they’ll eat away your time.

When I get a request from my team, I ask for a meeting, and we start talking about how it makes sense for my team. What’s the core part of it that will make sense in terms of metrics, goals, and promotions for my team and a good product.

I first need to understand the scope of what the other team wants us to do. This makes it easier for me to go to Leadership and request additional resources and changes to OKRs. I want to make sure we don’t work on unrelated things.

What are some books or resources that you recommend to people on your team?

Well, I need to start with our own books which explain lessons learned on how to approach good software engineering:

Software Engineering at Google – Lessons Learned – Describes lessons learned from the software engineering process at Google.

Google SRE Books – Books describing the processes Googles SRE use to make sure that services run stabily and meet the quality bar.

The Architecture of Open Source Applications – A series of books talking about how popular open source software actually works under the hood. Useful for bite-sized reading.

The Manager’s Path – Essential pre-reading for anytone thinking about switching to the Engineering Manager career and what that entails.

Spring Into Technical Writing for Engineers and Scientists – A great beginners book for technical writing.

Working Effectively with Legacy Code – Sorry engineers, legacy code is the default state of things in software and you’ll need to handle it well.

Great Conference Talks:

Architecture: The Stuff That’s Hard to Change – Dylan Beattie – How to approach and architect good systems.

Expecting Professionalism – Robert C. Martin – A good summary on how a professional team should approach solving problems. No, it’s not Clean Code related, put away pitchforks please.

Simple Made Easy – Creating simple things is impossibly hard and this talk makes it a bit… easier.

Rok Breulj is the founder of Proxy Studios, a small indie game studio that makes PC games. Their biggest title to date is Warhammer 40,000: Gladius – Relics of War. He shared how to get into game development, what it takes to get a big IP license such as Warhammer 40k, and the skills required to complete a video game.

How do you describe what you do?

Our writer once described me as a quirky coder. That description is not without merit. Besides coding, I manage team, marketing, and PR communications. I talk to players and make both low-level and high-level decisions. I’ve implemented a lot of our UI and UX, our platform-support systems, production pipelines and the multiplayer backend, but lately I’ve been focusing on project management and marketing.

What’s the size of your team?

We are four core team members from Slovenia, Germany, Sweden, and the UK. We work with several external contractors that help us with different aspects of our projects. We’ve been working remotely from the very beginning of our company.

How do you organize your workday? How do you balance between meetings and work time?

It depends on what phase the project is. In the beginning, we’ll have more meetings around game design and project structure. That can be pretty stressful–getting everyone on the same page and agreeing on things. But once you get a budget and momentum going, it gets easier. We only have one standing weekly meeting, and the rest we schedule as needed. A review of contractors’ illustrations would prompt such a meeting.

I start my day with sports and transition to working at 9-10 am and continue until about 2 pm. These are my most productive hours, and it’s when I code and do similar focused work. Sometimes we do pair programming as it’s very beneficial in the early stages of the project when you’re creating the foundational systems and architecture of the system. Later in the day, I do less intense things like email, checking player feedback, or research.

How did you get started on this path of having a game studio?

In high school, I played thousands of hours of Guild Wars, an MMORPG. There I met my current business partner. We ran our guild, and we were in first place for a year.

My cofounder was already studying Computer Science and wanted to make computer games. I got interested in making games too, and I started learning C++ in the summer before my first year of Computer Science studies. He helped me review my code and gave me pointers where I could do better. I was also looking at his code, and we continued our collaboration from there.

Eventually, we made an independent student game that ultimately failed. We did learn a lot from it and got an honorable mention at IGF (Independent Games Festival).

This recognition got us in touch with a UK publisher, and my partner got a job working for them. Later on, the publisher asked us if we wanted to do our own project and if we had any ideas. We got a bit of funding to make Pandora: First Contact. It was successful for that time and the fact that we were still finishing our studies. Eventually, the same publisher asked us if we wanted to do anything with the Warhammer license, and we pitched a project, got accepted, and created Warhammer 40,000: Gladius – Relics of War. This time we were very successful.

What’s your advice for people that want to get into the business of making games?

Make as many projects and little games as you can. Just make anything. Don’t focus too much on networking. It’s mostly a waste of time. The publishers are looking for a portfolio and understanding of what you’ve done. You’re going to impress them with that and not by talking and being nice to them.

These can be little projects with a specific focus, such as trying a unique game design or diligently working on a mod for an existing game. You need to have something playable. Learn a bit of everything in the beginning, especially if you want to start a studio. You’re going to need to know how the whole game comes together and everything that’s involved. It takes the skills of coordinating with other people, managing the art and code, and the process of game design. You’ll get opportunities to impress some of your peers at first. Afterward, you’ll be able to impress some people with money, which will open up new opportunities for you.

We hear of these big teams of people making games. How does a single person even begin to approach something so complex?

There are two possible directions. You can make a fancy version with a small scope. You could take Unreal Engine, which is free, and complete a small fleshed-out project. For example, if you make a combat simulation of some sort, it can just be one level, or it can just be two characters fighting. If you do that well and pay attention to detail, you can impress a lot of people.

The other direction could be a more straightforward game, and the graphics could be elementary 3D shapes. Create a whole game and show that you understand everything that’s involved.

If either direction turns out to be a success, you can expand and iterate on it.

How long does it take you to release a new project?

Warhammer 40,000: Gladius took three years to make. But then we’ve also been releasing additional content for it, which has been another three years.

How do you keep focus for three years?

It’s a challenge. I think you have to keep it interesting for yourself. Wearing multiple hats works very well for me. One day I’m doing game design, deciding which functions or units will be in the game. On another day, I’m implementing the integration with Steam. I might also be thinking or working on PR and marketing. There’s always something to do.

It’s also not as bad as it sounds because as there are natural phases to the project. In the beginning, it’s design and more deep thought oriented. You’re trying to make good decisions and working on prototypes. Later on, you’re deep in the production cycle. You’re integrating assets, managing people, and dealing with all the challenges that crop up.

It might be more challenging if you’re doing it alone. If you have good teammates that are into different aspects of it, you’ll motivate each other. 

Anything else that you’d like for people to understand about making games for a living?

If you’re starting your own company, you need to have business and marketing skills. You need to build things that people will want to play. You need to understand what’s financially viable and is at the same time interesting enough so that you’ll be able to finish it.

Understanding games is also a skill you need to develop. Just like filmmakers watch films and think about them, you should do the same with games. Think about what makes a particular game stand out, what its competitors are, and what else you can learn from it.

Our first project only had a multiplayer mode, plus it was a hardcore strategy game. It didn’t have enough players, so it never took off.

What did you learn about marketing indie games?

You should be smart with how you allocate your resources. As an indie you usually can’t just spend $100,000s on advertising,  elaborate promotional videos or gold sponsorships.

One thing that you can do is to leverage Steam’s algorithms so that they’ll promote your game for you. There’s a concept called “wishlist velocity” that affects how much visibility you get on Steam. So you can take part in events that integrate into Steam, and you can buy placement on their events list. It will make more people aware of your game, and they’ll wishlist it. Great marketing also has an effect — awesome screenshots and understanding how people navigate the Steam store.

The best resource on this topic is The GameDiscoverCo newsletter.

Do you have any resources or general recommendations?

Books on Effective C++ by Scott Meyers help with essential guidelines for how to write good C++. It’s such a big language, and it’s easy to get it wrong. In general, be a perfectionist when you start to code and fade out the overthinking later.

Naval Ravikant is full of endless wisdoms on life–especially the topics of wealth and happiness. He vocalizes some of the lessons I’ve learned through experience. Have a look at the Almanack of Naval Ravikant. My favorite lesson is to relentlessly value my time. Make sure that what I do is in the direction of what I want.

How do others introduce you?

I think the last description of me was that I am the resident mad scientist. While I was still at Metabase, my time was split between data science and supporting engineering work. Trying to apply various machine learning approaches or heuristics to the products and experimenting on blue skies projects. My work revolves around using and making sense of data.

What are some misconceptions that people have around data?

One of my pet peeves is Big Data and the idea that the sheer quantity of data will ensure that you can get something relevant out of it. This might be the case when you really have a lot of data. To get there, you need a different approach. 

I often see people starting out and trying to apply some sort of machine learning or similar statistical approaches where they are hoping that throwing enough data at the problem will solve it. Still, they don’t actually have the quantity of data required. 

What I try to do is be smarter with both heuristics. Sometimes it’s better to have less data if that means you can understand it more clearly.

When analyzing large sets of data in a growing company, the thing to watch out for is that you don’t capture the different balances between the segments. As your company grows, the composition of your segments is going to change. This might mislead you to see trends while it’s just your early adopters being replaced by the early majority. If you instead focus on just one well-defined group, you can better see what’s going on.

Consider where the data comes from and the causes that generate the effects you are observing? Try to tailor the hypothesis about the processes you are observing through the data. This will make it easier to trace the problems through the system instead of focusing on the data layer.

This is also a way for people who try to break into data science or analytics to have the edge over their competition. It’s an advantage to have a good sense of the broader business context, the fundamental business metrics, marketing funnels, basics of UX, product development cycle, and understand the basic needs of users. This allows you to translate your analytics or data science problems into these business contexts. That makes you a better analyst than just being slightly more sophisticated with your statistical approaches.

What are some resources for people that want to learn more about this way of thinking about data?

This is my basic analytics knowledge stack:

• How to measure anything by Douglas W. Hubbard as a foundational work
• A.Croll & B. Yoskovitz: Lean Analytics
• Practical advice for analysis of large, complex data sets
• SaaS Metrics 2.0 – A Guide to Measuring and Improving what Matters
• How To (Actually) Calculate CAC
• 5 Things You’re Measuring Incorrectly With Digital Analytics
• 5 things I’ve learned from building analytics stacks at J.P. Morgan and Fivetran
• Building a data team at a mid-stage startup: a short story

What’s the story behind your offering of mock engineering job interviews to the local developer community?

I got the idea from being part of the SharpestMinds community – a startup that pairs people who want to break into data science with mentors from the industry. They practice doing mock interviews, and I’ve seen the value of this exercise to gain more experience.

I’ve also noticed that I’m one of the few people who don’t see hiring interviews as an absolute burden. I generally try to think about problems through processes, and the hiring process naturally allows for improvements. I’ve also had a lot of experience being on the other side – interviewing for different jobs. This allowed me to reflect on my interviewer style and start noticing patterns where candidates are weak.

Offering this to the local community seemed like a relatively high leverage way to give back to the community. So far, I’ve done 22 mock interviews: 18 developers (8 juniors, 7 mid, 3 senior) and 4 for marketing positions.

What patterns did you notice in your mock interviews?

The first significant pattern is that people don’t explain enough the intermediate steps or show how they think. Sometimes it’s okay, or I assume that you’re thinking the right thing. But you’re also not helping me understand how you think and how you solve problems. And this is one of the most important things that I need to understand. 

The goal of the interviewer

When I’m interviewing, I’m trying to answer three questions:

1. How’s it going to be to work with this person? I want to understand if I will enjoy working with you. If I don’t get that sense, I’m going to reject you as a candidate.

2. I’m trying to understand how high is your ceiling? What’s their potential? Most of the time, I don’t really care much about where you’re currently at as long as you fulfill the basic needs of the business. The process of finding someone, especially if we talk about developer jobs, is so long and so costly that it makes sense that you will invest in those people anyway. I’m trying to understand how far we can take these candidates with the mentoring.

3. What was their most significant project or task so far? What is the biggest responsibility I could entrust them with on my team? I find this a much better question to discuss instead of talking about seniority.

I notice that seniority tends to be subjective, and you also have these horrible proxies like 7 years of experience. It’s complete rubbish for what we’re trying to figure out. For me, it fundamentally boils down to this question – what would I be comfortable to entrust them with? This also tells me where they would slide into the organization, and it would also allow me to have a rough sketch of their career path. This will enable you to clearly communicate all of this to the candidate.

The second bad pattern is that candidates respond to the questions as one-way communication. We want you to engage with us in a discussion. We’ll sometimes give you intentionally underspecified tasks because we want to see how you act in a situation where you don’t have all the information at hand. If you try to directly solve it, you’ve already failed. When I give design tasks, I make sure they lack detail and concreteness, and I want to see where the candidate takes them.

There are more structural reasons why you should be asking your interviewer questions. By asking questions, you essentially take charge of the process and demonstrate how you would autonomously solve problems. If you just answer the questions, I don’t get a sense of organizing your thinking around different sections of the problem. The other reason is that interactive sessions are way more memorable and more fun for the interviewer. It also allows you to shift the interview into a shared problem-solving session and forces the interviewer to commit to trade-offs. Engaging the interviewer in the process will force them to pay attention to what you are doing. You can also show that you understand the connection to business and real-world needs when designing the IT system. We can also then talk about the needs of stakeholders and what kind of outputs you would provide for them. All of this will leave your interviewer with a better feeling of you as a candidate compared to a session where you would directly answer questions.

Where do whiteboard coding challenges fit into all of this?

I think whiteboard coding challenges are a poor use of time and inefficient. They suck both for the candidate and the interviewer. When I do the interviewing, I try to sidestep that. What I will do is I will have one or two questions, which are designed questions, but I want the candidate to walk me through their process of thinking and how they approach something.

This question allows you to ask for further definition of the web scale. How often does it need to crawl, and what kind of data is it crawling? What’s the business case for this web crawler? It also allows us to discuss what kind of resources we have available and the trade-offs.

The same is often true even with algorithmic questions. These tasks are always embedded into a larger business context, and they often don’t have clean solutions. So you’ll need to be making trade-offs and thinking about how it’s going to be plugged into a broader architecture.

A similar example is to ask a candidate to design a data processing pipeline: we have real-time data coming in, and we want to do something with it. At this point, you can start by designing some sort of streaming pipeline, or you can start by asking business questions. By asking business questions, you might learn that we don’t need to access the data often enough, and you might be better off with an hourly batch process. This won’t demonstrate your knowledge of data processing. Still, it will show an extensive understanding of your role in the company. Also, the interviewer can always ask additional technical questions if they really want to know if you understand how to build a stream processing pipeline.

The more senior you become, the more it will be about solving business processes and less about the specific technical implementation.

How would your interview differ between a junior and a more experienced candidate?

I would still expect that junior candidates would have at least a rough handle on the trade-offs. Obviously in less detail than someone with more experience. I would raise the bar much more for more senior candidates and expect more detailed reasoning around inflection points. I’m also trying to see if you understand a broader context of what we’re doing. So if you’re interviewing at a product-focused web company, I would expect things beyond your role. What are some fundamental elements of UX, how product management works, what metrics this type of company would look at and why? This allows me to talk to you about things beyond just basic web frameworks and databases.

I’ve noticed in candidates at all seniority levels that people don’t really apply their knowledge. An example of that would be HTTP protocol which we all think that we know. Still, when candidates start talking about using it in practice, they tend to forget things like the payload limitations of the GET request. They must show that they have a deeper understanding of such details.

Is there anything else that candidates should understand about interviewers’ questions?

Fundamentally a big problem when interviewing is how to disentangle skill and knowledge. An interview is inherently conducted in the medium of knowledge and not on a skill level. But as an interviewer, I want to know more about your skill than your knowledge. So when I ask a question, it is really a proxy to understand your skill.

If you answer my question in a school-like form of a definition, it doesn’t help me understand how you think and solve problems. Instead, try to talk about trade-offs and weave in your previous work experience. It shows how you structure your answers and how you prioritize the issues. Think of an inverted pyramid from journalism where the first sentence is the most important and tells most of the story. Then the rest follows with the least important information at the end.

Once you get a complex question, you can also take a few minutes and sketch out roughly the outline of the answer. It will help you keep a better structure, and it’s less likely that you’ll forget essential insights. If the interviewer refuses to allow you this, seriously consider if you want to work there. It shows a complete lack of humanness and introspection on how to conduct an interview.

Overall I find that job ads are very bad at describing the needs of the company. It’s better to just apply even if you don’t match the description. This is especially a problem for women who tend to see all requirements as hard requirements. What’s more likely is that once you get an interview, the company will try to figure out if you can learn to do the role and be trained fast enough to do the job required.

How can we improve our thinking patterns?

When you are a junior, one of the most critical skills almost nobody teaches us is how to ask good questions. What’s important is to learn how to make this transition between unknown unknowns to known unknowns, where you can start asking questions.

There is value in going in multiple directions in your learning and getting to know different concepts. For instance, you can always decide to read on the Annual Recurring Revenue Funnel framework basics. It’s a straightforward concept. You can read about it in two hours and then mentally file it for later. Later, when you approach a new problem, you have all these frameworks stored, and you can start thinking about how I would translate this problem to one of the stored frameworks. This allows you to ask better-defined questions, and there’s probably a community around those frameworks that can help you. There’s an extra benefit that if you’re stuck in a job without mentorship, these avenues can provide you with a community that helps you level up. Still, you do need to ask good questions. Otherwise, you’re not going to get good-quality answers.

One thing I’m exploring at the moment is how to better approach problem decomposition. It’s turning out to be an immensely high leverage skill because that gives you a framework to ask questions, even when you don’t have a concrete framework to map the question to. Also if you can write about it well, or if you can teach someone then you probably understand the problem. 

This is tied closely to thinking in meta terms about how I work, the friction points of my tools, and how I even approach solving a specific problem. If I’m mentoring on the job, one of the main things we will be talking about in our 1-to-1 is this priceless kind of meta-work aspect. It’s also a helpful topic if you’re leading a team and talking to them about meta work. There will be friction points pop-up and things where everyone thinks that they’re losing time and resources. Thinking about these issues on a meta-level helps the team improve their work.

How would you onboard a new junior engineer into a company?

No matter the seniority, I think we just need to make onboarding more efficient. Each new employee should have two mentors. One is your long-term mentor, and you report to them throughout your career in their department. They should care about your skill development and how to become a better developer and human. And then, I would also advise having a second mentor who helps with onboarding in the first few months. They’ll help transfer the institutional knowledge, and you can be more relaxed with them as you don’t have to worry about looking dumb in front of them.

Have important parts written down. Create a Tao of Engineering, the principles and beliefs we have as an engineering organization, and how we do things. This document is also going to address how to approach trade-offs and what we value. Examples of values could be UX, reducing friction, or having a very stable application. Things will fail at some point, and it’s easier to look at them from a systems point of view and fix the process instead of assigning blame. When you have clashes with the team, you can blame the Tao for not providing sound guidance and focus on improving the document.

What’s your advice for companies going remote?

My very strongly held belief is that if you think that remote doesn’t work for you, it indicates a bigger problem. Same if you’ve seen a massive drop in productivity after moving to remote work. It’s not an issue of being remote, but rather that some other processes are broken. In-person communication managed to smooth over them enough that they weren’t as acute as they were when moving fully remote.

What’s your advice on mentorship?

Seek out mentors if you don’t have one assigned to you. If you are in an organization where you can enact that, make sure you have a practice of mentoring. This should be deliberate practice, also from the mentor’s perspective, not just something that you do. It must be something that you care about, invest the effort, and make yourself a better mentor. 

In general, everyone in the organization should have someone they see as their mentor and kind of helps them with the guidance of their work. Mentorship for me means meeting at least once every two weeks, and it’s not like a quarterly performance review. It has to be a regular activity, almost kind of like a ritual.

If your organization is not offering that – seek out mentors. If you ask 10 people you look up to, one of those will probably say yes. It’s also a perk that companies can offer if they don’t have a mentorship program yet. Use some of the funds to bring in external mentors and spread the knowledge around.

Something like coffee or free food is worth basically nothing to a developer. Having an established mentorship practice will make a massive difference. As a developer, you’re going to use this job as a stepping stone to the next one, and you want it to provide you with this kind of value. It’s going to make you better at your job and also increase your future earnings.

What are some resources that you recommend for leveling up?

• Bret Victor
• Gödel, Escher, Bach: an Eternal Golden Braid by Douglas Hofstadter
• Alan Kay
• S. Fish: How to Write a Sentence: And How to Read One 
• How To Ask Questions The Smart WayHow To Ask Questions The Smart Way
• Coda Hale

Developer oriented

• Elements of Clojure – Despite the title it goes way beyond Clojure, even way beyond programming
• Grokking Simplicity
• Companion site to the influential computer-science text Structure and Interpretation of Computer Programs

Explore things outside of your direct domain of work and think about how you could integrate this knowledge with the rest of what you know.

There’s an external library icecream that you can also use and it will have an even better output.

I presented this library at Ljubljana’s Python Meetup in September 2021.