Jayant Godse

Working with 'real' engineers

16-05-2026

I’ve just finished up a year long internship working at Visa Cashapp Racing Bulls. A Formula 1 team. Suffice it to say, being around some of the smartest engineers on the planet gives you a lot of things that to learn and internalize. This year of work has given me my initial perspective on a lot of core software engineering skills and processes that I’d like to recount and consider. Along with that some other takeaways that I’ll take forward into not just my professional career, but life too.

Don’t Try and Change the World

This team is old. Older than I am. A lot of my colleagues have been working longer than I’ve been alive. This is a harrowing thought, (For them perhaps) and it leads to a lot of our codebase looking archaic. There are things written in languages no one really ever uses. Versions of C# that were dropped about a 5 years ago. Design patterns I was explicitly told not to use, or none at all sometimes. In short, the code that I’d have to read and tinker with each day was not the prettiest thing.

Despite it all. It worked1. And this is something that didn’t really sit well with me. I wanted everything to be shiny, beautiful, cutting edge. I came in with opinions on how things should be done, and I tried my best to attempt to shoehorn those opinions into the things I was assigned to do. Suffice it to say, this didn’t really work.

Each time that I would look at a codebase in disgust, I would attempt to make some grand sweeping change that would try and fix all the “issues” that I thought I saw in the code. I’d try to force these super technical projects that had years of cumulative engineering wisdom and problem’s solving in them to look brand new. In doing so, I’d neglect all the quirks that you’d see in the code itself. As a piece of functionality evolves, it seems to “grow hairs”, little snippets of things that look odd at first glance, but solve some problem that you may not have ever considered. It makes little sense to thing that I would know more than years of bug fixes and better engineers.

I read an article about the mistakes that developers make when contributing to large projects. And this really opened my eyes to all the things that I was doing wrong. I was being inconsistent in an effort to make the code better. I was trying to change this already established world. And for what? Hubris.

So whilst it’s hard, the next time I see a codebase, I won’t rewrite the whole thing.

C# Works >:(

I hate this, I hate that it does this. I hate that it works. I hate that it works well. There’s no implicit null checking. There’s no enumerate method for collections. There’s at least a gazillion different keywords that you need to know. 8 different ways of instantiating a variable.2 No explicit null conversion3 and worst of all. It’s written by Microsoft.

Despite all of this, it’s the backbone of entire technical stacks, and there are engineers who swear by it. It manages to do so many other things right that you can overlook the quirks of the language and the runtime.

I see the appeal, you have bundled with your language some amazing tooling. Visual Studio is perhaps the best debugging experience that you could ask for. It’s has features that, to this day, I haven’t used, and probably never will. The .NET runtime lets you quickly write cross-platform code whilst giving you all the niceties of having hot reloads. And WPF is the de-facto way to build Windows desktop applications.

So throughout this year of work, I’ve complained. I’ve said it’s too easy, it has no character, the documentation is all over the place, There’s too many ways that you can do things, the package management is horrendous and MVVM makes no sense to me. However, despite it all. I’ve come to respect this tool for what it is capable of.

At the end of the day, you don’t get to write the things you want in the latest tool, with all the coolest bells and whistles. Sometimes you gotta take the kinda ugly thing that gets the job done.

Complex Is Easy

There is an inherent tendency towards making all things be extremely complex. Terry Davis did put it best when he said that true genius admires simplicity. I suppose the reason he said this is because of how difficult it is to keep something simple and stupid. Especially in software where there is a perpetual shiny object, standing there just out of your line of site. It gets only harder to say “no” to all these distractions and stick to the simplest problem.

For me, this problem was magnified since I don’t have the experience to judge the scale that my projects would have to scale to. I could make some simple judgments, but the foresight to see where a project might evolve in the coming months is something that I am yet to cultivate. This would lead me to attempting to design things for the largest possible scale that I was aware of. Designing things to handle gigabytes of data per second when something much simpler could have sufficed.

Funnily enough, I don’t think experience alone is the path to an appreciation of simplicity. I had a senior engineer comment that he would have added top level app wide state management to my react app that was written to be used by three people in the company. There seems to be an element of taste and reservation that makes an engineer halt their urge to complicate and really commit to making the simplest thing that solves the problem. Even more so, commit to keeping it simple.

The Human Element

I walked into my job thinking that, since I’d be working with some of the smartest people on the planet all the decisions that they would take would be rooted in a level of rationality. That each decision would be ruthlessly informed by numbers. I was surprised to find that this is not the case. Even at the highest standards of engineering.

It seems that the human element is inescapable. There will always be decisions that are spurred by nothing but like and/or contempt for another human being.

It struck me as a funny thought. There really are no substitutes to being an amicable colleague. Regardless of the heights of engineering that you are working with. It seems that a friendly smile and compliment will always get you places that raw skill and output never will. Liberating in a sense, for I’ve never had an issue getting along with people and have a generally likable constitution

Footnotes

  1. For the most part

  2. Okay there’s really only like 4. Unless there’s another way that I don’t know of.

  3. For example if foo is null you still can’t do if (!foo){} as a statement.