The engineer you’d want to be
Writing code is just one aspect that will make you a good engineer. In a future where AI will be an integral part of every workflow, standing out in an increasingly crowded field will be important. But what should you really develop about yourself?
Today, while scrolling through my newsletters, I spotted this news:
It turns out that Odysseus landed on the Moon without any altimetry data […]
The moon lander’s range finders were discovered to be inoperable a couple of hours before it was due to attempt to land on the Moon, so the company rewrote its software to take advantage of three telescopes on a NASA payload for altimetry purposes.
- TLDR — Feb 28, 2024
Odysseus is the lander (developed by Intuitive Machines) that reopened the discussion about the Moon as a stable outpost after more than 50 years since the last Apollo mission.
Last Friday, the lander landed on the lunar surface, albeit not without issues. Just a few hours after landing, IM discovered that the lander had inactive range finders (apparently missing a pencil-sized pin and a connector that allowed turning the laser on and off).
Reading this captivating story, I found myself reflecting on the countless occasions when, addressing challenges with my team, I’ve jokingly remarked, ”Well, it’s not like we’re sending rockets to the moon, right?”.
Indeed, it’s true.
Many of the situations we routinely encounter as engineers don’t demand exhaustive problem-solving efforts to unearth solutions, and even fewer require finding efficient ones.
Most of the time, “good enough” suffices.
Many developers often content themselves with slapping on the first patch they find, convinced that the surrounding environment (high-performance hardware, user use cases, etc.) will compensate for deficiencies.
Many of them end up labeling bigger problems with a nice “refactor” tag.
It needs rewriting.
Too hard to understand, poorly written, incomprehensible, no documentation.
It’s better to start over.
I know because I did it myself for a long time.
It’s easier, it’s just more fun.
Let’s rewrite everything!
The world we’re heading towards
However, the world we’re heading towards, on one hand, is creating a large audience of developers capable of producing something “good enough” even with the help of AI, and on the other hand, it demands from developers skills that go beyond the latest shiny framework of the moment.
Companies have never sought ninja developers, just as they won’t seek proficient prompters to indoctrinate AI.
What they’re looking for instead are professionals they can rely on.
If there’s a problem, no manager wants to hear: ”Let’s rewrite everything from scratch in the newest framework x instead of y, so we won’t have that problem anymore” .
Why? Most of the time solves a known problem only to add new ones that are still unknown.
What is expected instead is the responsiveness to request the appropriate time to deeply analyze and propose solutions (and perhaps those solutions will end up being a rewrite, but they’ll be so while explicitly stating real reasons, not assumptions).
Being able to read and analyze others’ code is crucial, even more so than being able to write it.
Unless you are the only programmer on Earth.
Can you picture if, when faced with a complex problem like the one with Odysseyum, Intuitive Machine’s techies had just thrown up their hands and said, “Ah well, let’s start from scratch the next time”?
Instead:
As a result, the company scrambled to rewrite its software to take advantage of three telescopes on a NASA payload, the Navigation Doppler Lidar for Precise Velocity and Range Sensing, for altimetry purposes.
- ArsTechnica
Being adaptable, responsive, and analytical makes a tech person more than just a code writer.
Digging deep into topics and issues is what will really make you stand out in a growing crowd.
