The Dev-X Project is a series of features with industry leaders sharing their developer experience insights. In each “episode”, we ask an industry leader 10 interesting questions about DX, collect their responses and insights and share them with you.
Today we are featuring insights from Viktor Farcic - Developer Advocate at Upbound, a member of the Google Developer Experts, CDF Ambassadors, and Docker Captains groups, and a published author. His big passions are DevOps, GitOps, Microservices, Continuous Integration, Delivery and Deployment (CI/CD), and Test-Driven Development (TDD). He is a host of the YouTube channel DevOps Toolkit and a co-host of DevOps Paradox. He published The DevOps Toolkit Series and Test-Driven Java Development.
In addition to his content channels, you can find Victor on Twitter and on LinkedIn.
When did you decide to become a developer?
[Viktor]: I started hacking and pirating games when I was about 12 years old. So the story goes that I got Amstrad computer (464 or something like that) when I was very, very young. It came with the instructions in German, which I couldn’t understand. The only thing I could figure out is that if I type something from that book, which I did not understand at all, then eventually something would happen. So basically, I learned how to write code by reading code without really reading any explanation about that code. Over time, I obviously learned more and it became easier.
What are the key ingredients to a really good engineering culture?
[Viktor]: The most important thing to me is the freedom to make decisions.
Many companies, I believe, are treating engineers as if they are children - holding their hands, telling them what to do. Now you can cross the street, now you need to stop. Now you move left now you go right. To me, this can be really crushing to any creativity and any ability to learn among developers. This is devastating because I believe that most of our job as developers is thinking and figuring things out.
Writing code is easy. Once you know what to write and assuming that you have at least a basic understanding of syntax and stuff like that, writing code is the easiest part of the process. Figuring out what to write and how to write it - that’s the complex part. And if we do not provide sufficient freedom to people to figure this stuff out, then we end up with the results we didn’t want - stuff doesn’t work becau
se the developers were just robots who did exactly what you told them to without any thought or creativity of their own.
Let’s say you’re building something from scratch. What does your ideal stack look like?
[Viktor]: The language would be Go. I really love it. I would be using GitHub actions to run all my imperative steps like building, running tests and so on and so forth. I would probably also use Google Cloud Run and forget about what’s below it.
But in real life, it’s never as simple as the way you asked the question. These decisions are almost always much more complex and the actual list would have like five hundred items.
Tell us about an epic engineering fail you’ve experienced in your career. What did you learn from it?
[Viktor]: In one of my previous companies, a long, long time ago, I was very much focused on trying to automate everything, because I was always bored with what we were doing. I figured that by automating processes, I could just fake it as if I was doing what they told me to do and then I could spend my time doing something interesting.
Over time my approach actually gained traction and people started coming in and joining me. I thought I was actually on to something productive. But for some reason, what I thought was actually a good technical contribution wasn’t being adopted or received well outside our department. About a half year into this experiment, I spoke with a person high up on the business side of things and asked him why my great idea wasn’t being adopted. And he he taught me a very valuable lesson. He asked me: “What’s our business model? We’re a consulting company, right? We sell hours, right? So what are you trying to do? You’re trying to get us to the point where we sell less hours. So what’s in it for me??”.
It’s a ridiculous example that should never have happened. And eventually, I’m pretty sure that company lost a lot of their work simply because they could not keep up. But the lesson, I think, was there that there is often a disconnect and an isolation between the engineers and the business side of the company. We very often do not understand what the business really needs, and the business does not understand what they can get from its developers. And I think that there is a huge gap between technical people speaking in abbreviations and business people speaking about money.
The solution to this is to remove the silos. That’s the only way forward. And also by having more and more self-sufficient teams. What I mean by self-sufficient is that eventually they should include the business side of things as well. A long time ago, with Agile, we started creating self-sufficient units. They could do everything themselves by having developers and testers and managers (which we started calling ‘product owners’) on the team. Over time, other units evolved like DevOps. And we started putting operations into that group? And maybe the next step is actually including some kind of business elements here too. These tiny teams can actually have business goals. Maybe they actually set some of their own business goals and implement the best possible technical solutions to achieve them. These are some ways that we can avoid this current disconnect between the business and development units.
In fact, I remember a long time ago the process in many tech companies was that the business unit figures out some goal or objective, and sends it to somebody who translates it into “requirements” for the development team (there’s actually something called “confidence of requirements” which wasn’t really applicable in these cases). The developers were told they must develop exactly what’s in the requirements. They were robots. Fulfilling “requirements” with no idea what it’s for. This is what we need to try and avoid.
How important is “Developer Experience”? Do you see this as a trend that will evolve into dedicated teams/functions for mainstream tech companies?
[Viktor]: It’s very important. Developers are customers of those providing services they consume. Just as with any other type of service, if users are not happy with the experience, they stop using the services. If that rule applies to, let’s say, people shopping on Amazon.com, I see no reason why it would not apply to users of the tools created by platform teams. The major problem is that in many companies, it is not clear that developers are customers of ops, SRE, platform, and other teams that are not working on end-user applications. As a result, we can observe significant lean times, shadow ops, complaints, and other problems associated with silos.
As far as how it might evolve - Bigger companies had platform teams for quite a few years now, so that’s not anything new. What is new is the realization that those platforms need to provide a certain level of freedom to the consumers to choose what to do, how to do it, and when to do it. Another issue is that “platform teams” often provided to devs access to their (ops) tools. That never worked. We cannot say “here’s AWS/Kubernetes/etc., go, do something”. We need to work on providing services that are tailor-made for the needs of developers and that provide full freedom up to the level of their knowledge and experience. That is the change that we are experiencing now. That is the evolution of the platform teams.
Let’s take the mono-repo question once and for all - should you ‘go mono’?
[Viktor]: The value in mono-repos is that it enables you to fake that you’re using micro-services. That’s the biggest value.
Personally, I am not fond of mono-repos. I think that we do not have enough tooling for mono-repos. I think that there they simplify certain things, like for a developer, it’s great because, hey, I have my application, which happens to be this directory, and it depends on some other things in other directories, and everything is in the same repo. But simply put, I believe that pipelines are not ready for that. Clusters are not ready for that. Processes are not ready for that. So it is indeed working very well for companies like Google, but what many companies are forgetting is that companies like Google have enough capacity to figure out how to solve any related problems themselves. While the majority of the rest of the world is not going to write a new repository type from scratch and use it to replace something else.
So I think that if everything is working great, I would be in favor of a mono-repo setup. But in reality, a mono-repo often introduces issues and reduces performance. I think it’s actually great if you make it work. I’m just afraid that too many companies jump to this just because Google is doing it (and I’m using Google figuratively. It could be Spotify, Netflix, whatever). The main questions are - does it make sense and does it solve a problem for your company.
What will be the hottest dev trend/adopted technology in 2022?
[Viktor]: Two things popped to my mind immediately.
First is that we will see the disappearance of Kubernetes. I don’t mean that we will not use Kubernetes, but this disappearance of Kubernetes will be similar to the way we saw hypervisors disappear once the interfaces and layers on top of hypervisors became mature enough. Everybody started creating virtual machines without even knowing that there is actually a hypervisor that creates those little machines. So I think that the next stage will be really building those layers, building solutions on top of Kubernetes that will make Kubernetes as a set of building blocks disappear.
The second thing is actually already happening, but it will drastically increase. And that’s going back towards platform teams. Going back towards the idea that if you’re not a developer working on an end user application, you should be providing services to everybody else. And those services would be like: how to create a cluster, how to deploy your application. Not in the way we were doing before, with a single button, creating a cluster without choices. But rather creating new interfaces. Basically, providing everybody in your company the same type of service that AWS is providing to you as an operator. You have freedom within certain boundaries. You cannot choose random amount of CPU and memory for VM nodes, but you do have a choice to how big within certain parameters the VMs are. The reason I’m saying this is that more and more and more companies are moving towards Kubernetes and cloud or they are already there, and they’re realizing or already realized that neither Kubernetes nor cloud are end user services. They are a set of building blocks.
Some claim that front-end developers will become irrelevant in the future of no-code tools. Do you see this happening? If so, how soon?
[Viktor]: I don’t know whether specifically front developers will become irrelevant or obsolete, but I do know that we are continuously moving towards doing more complex things and letting less complex things become either provided services or be done through some tools in a way that it’s very easy for anybody to do it.
Right now, we have no-code, low-code. We have services. In the past, we had stuff like Dreamweaver. My first HTML site was based on drag and drop from Dreamweaver, which I assume most people did not even know existed. There is simply a constant push towards other areas or more complex operations, while what we were doing for a while now becomes commoditized. So I’m not sure if this will be specific to front-end developers, but yes, if something becomes easy for a machine to do, then you as a developer need to figure out how to do something else.
The real trouble is, I believe, that there are quite a few places where people are incentivized to do the same thing over a period of many years and they even get promotions for doing that same thing so that they become so highly paid that they cannot accomplish the same anywhere else. So if that company ever goes under or they ever choose to find a new job, there is suddenly nobody who needs them anymore. Putting it simply - whatever you were doing five years ago has no value today or is unlikely to have value today.
Share some tips to help remote teams collaborate better.
[Viktor]: The most crucial part, is finding way to create team building, and a regular gathering of sorts. Even when people work “in the office” they tend to speak through Slack anyways, right? So it’s not the communication itself that differentiates office from remote. What you miss with remote work is getting to know your teammates and establishing a bond. When you work in an office you can see people (unless your company is huge). You might go hang out at night after work. The next day you’ll continue speaking through Slack, Zoom or whatever, but you get to know the person on the other side of the conversation a bit better. But when we work remotely, we need to find ways to get to know each other. We need to kind of have fun with each other, and find excuses to do so.
So the main tip is to find ways to establish social interaction. Something that will foster establishing emotional bonds with other people. Perhaps even invest in getting everyone to the same place. Maybe take everybody to Mexico. Those things look like huge expenses, especially if people are coming from everywhere. But the level of productivity that you get and the amount of time you stop losing as a result is far more valuable. Very often when you work remotely, you find that you end up speaking only with the same two people in the company over and over again. These kind of initiatives to create bonds helps avoid that and it really pays off.
Do you want to share anything else? Please share anything you think would be of value to the broader developer community
[Viktor]: That’s hard because whenever I share tools I sound biased and subjective because they are usually tools that are either from a company I am working for or that I work with. But I would reer people to Crossplane and everything from Argo. And if you can choose where to host your applications, go to Google Cloud.
Enjoying The Dev-X Project? Any feedback? Requests or suggestions for upcoming featured guests? Let us know!
