Who The Hell Wrote This Code? – Dev Leader Weekly 61
TL; DR:
Exclusive Article: Who The Hell Wrote This Code?
Seriously, What Were They Thinking?
Does this sound familiar:
This is potentially followed by them asking who could have ever committed such a monstrosity.
If you’ve worked in a particular area for long enough, odds are you’ve heard something like this. You might have even been a person who’s said this in the past!
The scenario I want to discuss is not the one where you stumble upon your own code that you wrote last year (or maybe last week) and you can’t believe you wrote something so grotesque. Instead, I want to focus on people joining teams and asking about the code, the architecture, the tooling, the processes, etc…
But they don’t have the full context.
Once Upon A Time…
Before working at Microsoft, I worked at a startup called Magnet Forensics which eventually grew into a very large and successful digital forensics company. I was fortunate enough to be there in the early days and help build out a lot of the product offerings from the ground up.
The side effect of that: I wrote a lot of the code that would eventually need to be refactored, rewritten, or otherwise extended by future team members.
Something I observed as the company grew was that periodically people would join, and during their ramp-up period they would have this moment of harshly criticizing the code. I quite literally have heard people say it exactly as the article is titled — and more than once.
As someone who had been around for a while, I often found myself in situations where I was explaining the code. More specifically, I mean having to defend why the code was the way that it was.
After spending enough time doing this, I realized there were generally two sides to this:
I eventually took it upon myself to give a recurring talk to new employees to explain this type of thing — and I would walk them through different points in time where we’d evolve code, patterns, processes, and tooling.
The key point? Context is everything.
You Wouldn’t Believe What We Had Before
The framing of my talk was of the pattern: “You see X, you don’t like X, but you never had to live through using the thing before that”. This seemed to really convey to people that as a rapidly growing company, we were continuously improving. The side effect of continuously improving is that if you come in at any point in time, you will live through improvements that will later become obsolete.
I wanted to give you some generalized examples of these so you can see how it worked! Let’s check ’em out.
The Tests Take Too Long
We had to run suites of automation that would cover different parts of our application from unit tests to functional tests to user interface tests to end-to-end tests comparing search results. This can of course be a frustrating experience. But did you know before we had the automated UI tests that we’d have multiple people for several days clicking through the app to test it out by hand? So the tests aren’t lightning-fast currently, but they’re (mostly) consistent and much faster. And did you know before that we didn’t have any regression tests on our searching capabilities? We’d periodically frequently ship a regression that we’d have to hotfix right away or even our founder would find an issue right before launching. But before that, we didn’t even have coded tests. We’d be breaking functionality in the app almost as quickly as we were adding new features! And before that? We didn’t even have a build system. We used to have an intern that would build the product on his desktop and we’d copy the files to a release location. Our founder would run through a few things and we’d rock and roll. If you see remnants of any of that, it’s because it’s taken YEARS to even get where we are. Things are MUCH better than they were. Things can STILL be much better.
This Engine Is SO Slow!
When our search engine was being optimized, there was criticism about the existing performance and architecture. Without getting into the details about how it worked specifically, how work was scheduled and done in parallel was under scrutiny. It was determined to be our biggest bottleneck in performance. How could someone have ever done this?! Things evolve over time and our search engine, much like a data pipeline, was no different. As other optimizations were put in place, how our scheduling was done was now holding us back. But what had gone unnoticed was that architecture and design was at one point the biggest performance boost we had seen. We had gone from a single-threaded application to having a search engine that could split up work across cores for more effective processing — a HUGE performance boost.
That single change was at one point our biggest performance gain, and without touching that code specifically and just optimizing around it, it had eventually been left as the biggest bottleneck to future improvements.
Funny how that works.
Be Curious, Get Context, Don’t Criticize
I wanted to write about this topic in this issue because it came up at work in my current team — at least not negatively, but my manager has this pre-emptive realization that he wants to make sure people are comfortable in the team. People shouldn’t feel like it’s “someone else’s code” and therefore they are always intruding when they need to spend time developing in the codebase.
It reminded me that it’s important to be curious. People need to be asking questions to understand what’s going on. People need to ask questions.
But HOW you ask makes a huge difference:
The former is something I highly encourage, and in my opinion, there is no space for the latter. People are more than happy to help you and provide you with as much context as they possibly can when you’re genuinely curious and aiming to improve things. When you’re mocking code and not attempting to understand any of the history, you’re failing to acknowledge that your peers were operating with the best intentions with the information and circumstances they had.
Remember: context is everything.
Weekly Recap
Internships, Learning Paths, & Getting Your First Job – Interview With Erik Andersen
Look, we know it’s challenging. Many people are going through tough times with it.
领英推荐
Landing your first job as a software developer is no simple task.
I sat down to chat with Erik Andersen about his advice for helping folks navigate getting into the industry.
Erik had lots of actionable tips for aspiring and junior software developers, and I think you’re going to love this one.
Thanks for the chat, Erik!
Common Behavioral Interview Questions For Big Tech – Principal Software Engineering Manager AMA
Did you hear the news?
Coming to Dometrain in the very near future is the course you’ve been waiting for!
Nailing the Behavioral Interview in Big Tech — and we’re bringing our engineering management experience to help guide you through it.
Join me in this live stream where I’ll be going through some common Big Tech behavioral interview questions.
As with all livestreams, I’m looking forward to answering YOUR questions! So join me live and ask in the chat, or you can comment now and I can try to get it answered while I stream.
Today we focus on:
THIS Is Even More Unsafe Than Reflection In DotNet!
Everyone will warn you about using reflection in DotNet.
And, generally, this is for a handful of good reasons:
In this video, I’ll explain Unsafe Accessors in CSharp and how they can do some powerful reflection-like behavior.
VP Expectations of Engineers – Interview With ex-Amazon VP Ethan Evans
What does it look like to go from managing engineers at startups to a rocketship ride to VP level at Amazon?
Let Ethan Evans tell you all about it!
Ethan has led global teams of over 800 engineers at Amazon and helped invent Prime Video, Amazon Video, Amazon Appstore, Merch by Amazon.
Let’s hear what Ethan had to say about what VPs and senior leadership are looking for when it comes to leveling up as a software engineer!
Thanks for the insightful conversation, Ethan!
Like Reflection BUT… You Won’t Believe How FAST This Is!
Unsafe Accessors are fast. Like… Stupid fast.
When we look at unsafe accessors, we generally compare them to reflection in DotNet. This is because they allow us to do some pretty crazy things like accessing private members on classes.
Heck, we can even mutate private fields!
But just how fast are unsafe accessors? Wait until you check out these numbers!
Caffeine And Narcolepsy – My Journey As A Software Engineer
Caffeine is awesome — but even as someone who loves consuming caffeine, it’s completely changed my life. Sometimes not for the best, unfortunately.
As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.
Nick “Dev Leader” Cosentino
Socials:
– Blog
Looking for work
2 个月I remember a teammate in a university course packing UI code and a whole bunch of stuff... In a Java constructor. The guy didn't see the point of using methods for some reason.
Technical Support | Help Desk Specialist looking for remote roles
2 个月Spoiler: I did !!!!! ??
Making code & cloud less confusing | Software Engineer @ Cisco | Dad | DEI advocate
2 个月In my experience no dev wants to write garbage code, but they’re often forced to by pressure from above, e.g. management and deadlines. It’s often a temporary solution that ends up hanging around for years