It's been exactly one month since I started my placement year at Autodesk. I got this internship after about six months of off and on applying. I did about 80 applications, focusing on quality rather than just blind firing applications everywhere. I tailored my strategies, finding improvements as I went along, learning from interview after interview, and rejection after rejection, so I could give myself the best chance. In the end I ended up with two offers, Autodesk and Johnson&Johnson. I chose Autodesk despite the higher monetary compensation at Johnson&Johnson because I believed that writing software in a software company is bound to be better than writing software in a healthcare company. Both companies are large American multinational corporations, and I'm incredibly humbled and proud that my work paid off in the end.

Now for my time at Autodesk. It's been one month. One month of learning more than I've learnt in any one month span of time, by far.

The Scale is Immense

Codebase

The first thing I saw was the scale of the app. The main project I've worked on in this month has nearly 7000 commits over nearly a decade of work put in by hundreds of talented devs (don't worry, we'll get there). The codebase has an almost unfathomable amount of code in it, and it's a mix of all sorts of old and new code (we'll also discuss this, in due time).

Autodesk and ACC

Our product, the Autodesk Construction Cloud is a massive product. It's a suite of apps, where we only work on a (very large) subset of it. Our bit of the app connects with other bits of the app to create a massive product that is seen by the end users. The deployment and management of a codebase(s) of this scale is still an absolute wonder to me.

Novel Solutions

With such a scale, novel solutions need to emerge. Using an implementation of (i think) module-federation to make an Exoskeleton, our dev machines only compile the code we need to be testing. The other bits of the app I mentioned come from a completely different online hosting of the app. It's an online server that stitches your code and the production code in one dev ready build, where only some parts are being loaded from your machine. The idea works surprisingly well in execution, and it makes sense, as there isn't a portable machine on earth with enough horsepower to push a Webpack bundle of this size in a reasonable time.

Team & People

Day one, I met at least 2 dozen people when I first came into the office. That's a whole lot of people to keep track of, and I quickly lost track of the names of people and things. I still have to ask for names of things I know exist, but don't remember the company jargon for. As an example, as the frontend team, our internal name is Voltron. Similarly, there's a whole bunch of teams for a whole bunch of things like testing, backend, 3d model viewer etc.

The people in the team are absolutely sensational. I have never been in a room with fellow likeminded nerds geeking out over a niche web technology that no one's heard of except us weirdos. It's so rewarding and so satisfying being able to use any term that comes into my head, and know beyond a doubt that the person in front of me has not only heard of this thing, but also used it for 4 years prior or something. This level of interest and knowledge is beyond my wildest expectations, and I'm all for it.

Now, all of this talk about the team being incredibly knowledgable means nothing if they're cold, distant code monkeys, preferring to keep to themselves. To my delight, the entire team is immensely helpful. From the bottom of my heart, I think I can ask any of them for advice on anything, work or not, and they'll genuinely try to help me. Of course, they’re also incredible with the work. The specialised domain knowledge required to work in a decade old codebase is immense, and because the retention rate of our team is quite high, most of the team has intimate knowledge about how the app works, likely because they've written a lot of the code in the first place!

With the Gitlens extension in VS Code, you can see the commit history of when a line was last changed. It's still unnerving to me seeing a line I hover on was last edited 5 years ago, but the line below was changed a month ago by a different person. Every line of every file can have a different person working on it at a different point in time. To me, it's quite unreal to witness collaboration on this scale.

Facilities & Support

The company provided facilities really do help us perform our best work. I know a lot of companies use a lot of marketing speak for this, but I believe this outside of any corporate speak as well. It's actually excellent. The office space itself is extremely well maintained, the desks numerous, high quality, and oh so good. It's the crème de la crème of the support things that are usually nice to haves, but never really the main focus of a PC build. Stuff like the desk, the monitor, chairs etc.

The laptop itself is also perfectly suited for the job. It feels like I'm giving it a run for it's money, but never enough that it feels like it's slowing me down. It's just enough laptop for the job. Having autonomy over the device to install any software to make my experience perfect for me is also an added benefit, like Better Touch Tool (read more about that here).

The flexibility to WFH entirely is also excellent. You can be anywhere you want and still work. I knew in theory how it works, but it was still a surprise to find out that one member of the core team lives in Switzerland. Every meeting is remote first, so even people in the office have to join from their laptops. This means you're missing nothing when working from home. The implementation is a lot better than I was expecting, for sure.

Challenges

Big scale means big challenges.

Running the app is not a simple yarn start in a directory. Oh no. You need to request access to have projects available to view in your local build of the app. The app is in a monorepo, so you need to be careful about where you're running the start command from. Also, depending on which bit of the app you're running, there may be a different command, that you're definitely gonna have to look up when it's your third day on the job. Also, there's test suites that can bring your laptop to it's knees, so best run them in serial. Also, this is just one repo out of the many you will be working on.

It's a lot of things, things that you get used to after a while, but still things. This ties into my next point really well too.

Because the scale is so large, and the codebase so gargantuan, there's been times I look at a part of the app and can easily be fooled that it's not even the same project. What, with the differences in the era that the Javascript code was written, who it was written by, what language it was written in (TS or JS) etc, every single part of the app feels like a completely new mountain for Sisyphus to climb. Except in this case, he's managed to get up every single time.

The Unexpected

There's a lot more "find out how this component works" than I was expecting. Because a large part of my work so far has been bug fixes instead of writing new code, I'm always reading code more than I'm writing code. This was, well, unexpected, because I was expecting the day-to-day to be a lot more about writing code.

The meetings. Oh boy the meetings. There's far more meetings in my week than I expected. And the funny part is, I can understand the need for each and every single one of those meetings. They're functional, they're insightful, and I always end them feeling like my time was spent productively. I never thought that I, of all people, would be saying these words.

There's a lot of tech debt. When there's a codebase as tenured as this, there's bound to be some tech debt, but holy crap there's a lot of tech debt. There's partial JS to TS conversions, there's partial conversion from our deeply intertwined implementation of an internal system, to a shiny new Facade layer which encapsulates all this logic, there's class components(!), there's functional components, and everything in between. There's a lot of duplication in the code as well, as we have two sister projects that we're supporting at the same time. Oh, and they're partially moved to one centralised location too 🙂

The codebase is in need of a large push to reduce code smell. Thankfully, Autodesk being a software company embraces this with open arms. The next quarter has a dedicated slot where some of the team will work on fixing the existing code instead of writing new features. This kind of DX is exactly what I was hoping for when I joined a software company, for the software, and I haven't been disappointed yet.

Realisations

Seeing an actual company writing actual software for the masses brings me great hope for the future. There's no AI I can see that's doing the work of a company any time soon. The scale, the old, the new, the intermingling of the two, no LLM based chatbot's doing this. If you're making single page cookie cutter websites, you already know you're in trouble. But this isn't being replaced. I had an inkling that this would be the case, but actually seeing this in action has solidified the idea in my head. If you're good enough, ain't no AI doing what you can do with Natural Intelligence. Focus on getting good enough. Play to your strengths as a human being, as rare as they may be.

Here's an interesting realisation I had on one of my first tickets. I was expecting this arcane way of making a web app that only the pros know and what I've done in the past will only be tangentially related to the stuff I'll do at big mega corporation X. Until my first ticket, this was true. The sign up process was involved, the local server setup even more so.

But the description of the first ticket said something like "add react-query-devtools to the app when a certain condition is met". It's the same Typescript, the same react-query, the same React people are forced to learn by writing it on a piece of paper, and it's the same React I've been writing for the past two years.

And then I thought, maybe this won't be too bad.