10 years in the industry

Today marks my 10th year working full-time in “the industry”, in my case, a full-time job at a tech company. This is the story of an employee, not a founder – while I did have a company, it didn’t survive, and I ended up in a “software engineer” career with a few twists (like, I’m not actually doing that much software, but I’m getting ahead of myself here.) Also, this is a long blog post – it’s a summary of 10 years, after all, but to structure it, I’ll start with the early days, discuss some career learnings (as in, things that work(ed) well), and wrap up with a reflection on how I changed over time.

From academia to industry

On this day, 2015, I started as a developer technology engineer at AMD, straight out of university. I’ve been doing research on large mesh rendering using voxels, had a reasonably good grasp on what a GPU is, and I figured I knew some folks at AMD, so I might as well apply there. To my surprise, the interview process actually went fairly smoothly, and I managed to get a 0-day break between my last working day at university (Friday, 13th, 2015) and my first working day at AMD (Monday, 16th, 2015) – a lot of this was due to GDC (which is always in March) and joining early enough to book a trip. In hindsight, finishing university earlier would have been a smarter choice, as I would end up not having a more than two week break from 2015 to 2024 (more on this later.) Sure, I could have booked half or more of my vacation in a single chunk, so this was also by choice, but somehow when you do start working, taking 3-4 weeks off in a row rarely seems to work out as planned.

At AMD, I went through different levels and jobs, all while AMD went from near bankruptcy to a solid business; starting as a developer technology engineer, doing a few hardware things, becoming an architect over time, and finally leading the work graph effort as an AMD fellow. It was great to work in all those roles without having to actually change jobs, and I also got to work with some amazing folks. While big companies have all their problems with scale, the fact that you can get in touch with world-class talent fairly easily is a big upside for working in a big company. I’m sure there are also bright minds in smaller companies, but the sheer scale of a big company means there’s likely some expert for every area of your interest who you can get in touch with. If you get really lucky, that person may even have some spare time to mentor you! In retrospective, this was actually the best part of my job at AMD – learning from some of the best people in the industry how things are done.

Eventually, I ended up switching jobs. It’s hard to tell what exactly made me do it, but as a wise person at AMD told me at the time – getting ready to switch jobs means usually you changed. In the end, it was much less dramatic than it seemed at first – your company forgets you in a few days anyways, and you’ll find new interesting problems to solve and new people you enjoy working with at the new company. In the end, if you really made friends, they’ll still be around after you switched companies.

Lessons learned

Show me the money

One thing I want to get out here while thinking about LinkedIn and other portals is economic success vs. career success vs. fulfillment (or call it personal success, growth, happiness - anything you can’t measure in money). I’ve seen plenty of people in my career who optimize for economic success first, and one learning I’ve had both from hiring and managing people, and from my own career, is that your economic success is only loosely coupled to your career success or your personal success. The sad reality of the economy we’re in is that stock options are the key driver for economic rewards, and being at the right company at the right time will trump anything else: Hard work and the right skill are a secondary concern if your company stock goes up by 10× or more. It’s important to realize this early on and not mix this up and believe you did a smart choice when your company suddenly started printing money. You just happened to get lucky. At the same time, someone else, working just as hard as you elsewhere didn’t get that lucky. Coping with that reality is not easy and I’ve seen plenty of people – especially new in the industry – hoping for huge bonuses and feeling like they’re missing out if they don’t get lucky. It’s a game, and the company is buying you lottery tickets. Over the years, you’ll get a lot of lottery tickets.

Fulfillment and success

For personal success, it’s much more important to realize that you’re in for the long run and pace yourself such that you can be productive and increase your value long term. Someone working fantastic hours but burning out quickly is not going to get far; people who plateau and switch into cruise control will also get stuck eventually. Same applies for folks who strongly believe in LinkedIn and Youtube and think that switching companies is going to make you successful and rich, independent of skill – it works for a while, but by the 3rd or 4th job change most companies will have figured you out. The safest way to success is unfortunately the most boring, too – solve hard problems from beginning to end, stick around with the team when they need you, and stay outside your comfort zone. It’s also important to remember that there’s more than work: Your personal life and health matters, too, and you’re the CEO of your personal life. Not every day at work will be great, and finding ways to relax and recover is the key to make sure that a bad day doesn’t turn into a bad week which can turn into a bad month or year. It’s your responsibility to make sure you can continue living a life if your company decides to lay you off, which, similar to your economic success, is largely outside your control.

What did I learn?

For me, the most interesting part of this journey were the people I ended up working with, and the various topics I got to work on. I did software, worked on games and demos, but also APIs like Vulkan and D3D. I ended up doing hardware, too – ray-tracing and work graphs, designing new hardware blocks, making tweaks to existing hardware, and I saw my work actually ship in silicon to millions of people. I also got the chance to work on everything in-between: Talking to developers, writing university papers, writing library code, shader analysis, the actual shader ISA, but also build tools, assembling big-iron servers, running a CI cluster, becoming a professional Rust developer, and many more things. If someone had told me that my career as a developer technology engineer would end up with contributing to all those things, I would have considered them crazy. Looking back, I’m glad I had and continue to have all those opportunities.

Playing to your strengths …

Reading this you may wonder what my top skills are. I’ll start here with the strengths I brought into the job on day one, or rather, things I felt reasonably comfortable with: Defining APIs, as in, building things others will use, seems to be a pet peeve of mine and I’m glad I could monetize this skill (if you look at my spare time projects, you’ll see that it’s often times also the substrate for others, but rarely the top of the stack.) The other skill I brought in was ray-tracing – I knew quite a bit about the applications, which helped me when I was digging into the hardware side of things as well.

… and learning new skills

The reality is however that I also acquired many new skills over the years – both in terms of domain knowledge (work graphs! Neural rendering!) but also in personal development like running & managing a team. That was probably my biggest learning as well over the years – impactful projects are too big for any single person to handle, and you need to find a way how to provide a vision to a team but also give people work and allow them to contribute in their unique ways. Fortunately, I always had mentors and role models I could ask for help along the way, something which definitely made it much easier to succeed than trying to figure it all out on your own.

To this day, I try to keep this mix of learning new things, but also applying my experience to problems at hand. It’s still a balance because the “I’ve always did it this way” card becomes increasingly easy to play with seniority. It takes quite some time to figure out which way to go, and as you become more senior, I’d strongly advice everyone to spend more time thinking – as in, sitting down, identifying the reasons why something happened, weighting the options, and considering the consequences. It’s easy to come up with new solutions to problems (it really is, when you’re getting told about problems all day long), the hard part is finding solutions that fit into the current system and set everyone up for success. This equally applies outside of work, too – be it your personal finances or some other decision you need to make.

The other defining trait that helped me a lot over the years is a “whatever it takes” attitude to work. There’s nothing I can do that I won’t do – if I need to fix some CMake build script to help the project, I will, if I need to write specification language, then so be it, etc. That may be a leftover from my startup days where I did the tech, but also everything else that had to be done, but it’s also in my view a better approach to work than sitting idle and waiting for things to happen elsewhere that you can actually influence yourself. Fun fact, during my time at NVIDIA, I recall Jensen saying exactly this: Stress the things you can control, don’t stress the things you can’t control. This somehow stuck with me, and so far, it seems to generally apply. Stress is caused when you know that you could do something, but you’re not acting. If you start doing something about it (learning more about the problem, start writing code or helping the person who is working on this), you’ll often realize it’s not that much work to begin with, and also that now that you control your destiny, the stress goes away.

One more thing on the “whatever it takes” approach to round this out a bit. I got asked if it’s curiosity driving me to figure out what to do whenever a problem arises or if I’m more focused on just solving the problem. The reality is that it’s a mix, and there’s a balance to strike here. I can get nerd-sniped and dig into a topic if it interests me. It’s a super interesting industry and many problems are fascinating to explore. At the same time, you need to learn how deep you can get and make meaningful contribution before handing over to a domain expert. There’s always this story of a 10× engineer and the reality is that for a certain problem, someone can be a 10× or even 1000× engineer compared to you. I’ll give a trivial example: You realize that some issue happens due to a process problem in the foundry (let’s say, some wires leak more than anticipated, or it’s some capacitance issue.) Now you can start learning everything about silicon manufacturing and in two to three years you’ll be able to make a meaningful contribution. Or you can hand it over to Jane who spent her last 20 years working with EDA tools and let her fix the PDK and ask for an extra rinsing step in the foundry to solve the issue. Realizing when this is the case and moving on is as important as not skimming over every detail.

And now what?

That’s an interesting question. I’m now more than 10 years in the industry and I certainly carved my name into some hard rocks (or rather, some specifications like Vulkan, or various patents.) Today, I’d consider myself a “full-stack” development lead & architect. It’s a bit of a weird combination of skills, but it brings me joy to work with a team that develops the “full stack”:

• Application: What problem is the customer trying to solve, and how do they want to solve it? Often times, the how is strongly biased by the tools given so far (I want to cut this tree and I need a bigger chainsaw) and you need to map this onto upcoming technology opportunities in a way that’s easy to adapt (we have light sabers coming up but they’ll have the same grip as your chainsaw today and require little extra training!)
• The API: If I made mistakes that I’ll regret when I retire one day, it’s always in this area. APIs are forever and it’s important to do a good job designing them or you’ll hurt not just you, but the industry at large. Convenience will always win in the end.
• … and the path down to the hardware: Now this is a funny one. The path down to the hardware is roughly runtime, driver, firmware (sometimes), shader compiler/ISA or other fixed-function blocks, and finally the individual blocks you need to touch, ending with the actual RTL (that’s the language you use to describe the hardware, i.e. Verilog). Being somewhat effective here means you need to learn a lot of different things. Being able to read all sorts of assembly for example, as you won’t see the high level code the application wrote in many cases and have to deal with the final assembly only. Understand how blocks are connected, as in the end it’s just wires and somehow the data needs to flow physically across the chip. You also need to understand how hardware wants to consume data, what’s expensive to build (yay, let’s do a 64×64 crossbar!) and not (we need to extra those bits here and then shift them around.) This is also the part where I feel like collaboration is the most essential – building good hardware requires the hardware folks to understand the software, and the software folks to understand why the hardware wants things in a certain way. On top of this often times I’m the guy who wants to wire up three blocks in novel ways to solve a bigger problem, and now you need to coordinate people who may not be talking with each other that much.

If this sounds like a lot of work, it is, but it is incredibly rewarding once all the pieces come together. Here’s a problem someone couldn’t solve efficiently before, and now we’ve provided a whole stack from software to silicon. On top of this, you know this will be in place for years to come. Being able to shape the industry in this way and having actual impact is what makes me get up and get to work – and I hope I’ll get to continue on this path for years to come, and maybe, who knows, one day get to design a whole GPU :) One can dream, after all, and if anything, this post was meant to inspire you on your path in the industry, no matter if you’re just started, or if you’re about to retire and look back just the same way I did today.