You may be a software engineer, but you can also think of yourself as a nuclear engineer. You start something from nothing, and when you step away that process needs to keep running without much human intervention. Your work may even have requirements, safeguards, and fail-safes to do everything possible to prevent catastrophic failure. And when it fails, you have systems to contain the fallout.
But too often software engineers think of themselves as architects. Debating software "architecture" is every engineer's favorite part of the job. Writing about software "architecture" does pretty well on HackerNews. Becoming a software "architect" might be a career aspiration.
The association of software with architecture is strongest in the balancing both fields make between form v. function.
But most elsewhere the comparison falls flat. Architects move on from their projects. The building is built; the architect's work ends. Reactors startup and run, and the job of the engineer continues. Buildings house and shelter. Reactors power and sustain. You are constructing reactors, not the Guggenheim. You're more Rickover than you are Rem Koolhaas.
From neutrons to users
Neutrons have lifecycles, just as your customers do. What if software engineers studied and obsessed over their customer's lifecycle just as a nuclear engineer does with neutrons? The neutron is central to the nuclear engineer's trade. The customer is central to the software engineer's trade.
The "neutron lifecycle" is a central part of nuclear canon, and is a framework which explains how a reactor generates power. An atom decays and ejects neutrons at high speed, which slow down, strike another atom and cause that atom to decay, which ejects neutrons at high speed...The cycle repeats.
To clarify, a nuclear engineer's job might be far abstracted from dealing with actual reactor physics--they might work on valve design. But they still have to know and recite this piece of canon. In my submarine's ~50 person engineering department, I'd guess that less than 10 people had jobs that were "hands-on" with reactor physics. Everyone had to draw and explain the above diagram when quizzed.
I don't know of any companies that expect their software engineers to detail their customer's lifecycle. Unlike engineers on a submarine, you're actually designing and building your company's reactor! Isn't that more of a reason to become experts in your reactor's neutrons/customers?
Summarizing your reactor
A reactor isn't magic. Its ability to generate power is the inevitable outcome of probabilistic, physical processes. The same thing goes for your software, product, or business's ability to generate revenue.
The neutron lifecycle can be summarized in one equation:\[κ=ηρεƒP_{NFL}P_{TNL}\]
The above formula is a model of what happens to neutrons in a reactor. We're not going to walkthrough it, but it allows nuclear engineers to diagnose and explain what happens to a reactor. Swap the fuel type from U-235 to thorium? Change characteristics of the fuel cladding? Add some poison to the core? A nuclear engineer can demonstrate what will happen using the above equation.
If we can summarize all of reactor physics, you can summarize the core of your company's revenue reactor. For instance, suppose you work at an e-commerce marketplace. You make money through charging fees to both the buyer and the sellers. You might first summarize your revenue reactor as:
\[Revenue = Revenue_{Sellers}+ Revenue_{Buyers}\]
That's easy, but as an engineer, it doesn't give you any understanding on how your work contributes to the reactor's health nor does it train your intuition on what's happening to your customers.
Understanding your reactor
The nuclear engineer's neutron lifecycle is well-studied and fully characterized. It would be very bad if we built nuclear reactors without fully understanding how they might operate. Your customer's lifecycle is almost certainly not as well-understood as the neutron lifecycle.
One really fun thing about working on a product is that you're discovering how the customer interacts with it. Referring to the above e-commerce marketplace example, everyone may understand that revenue comes from both sellers and buyers. But, depending on your company's stage, no one may understand how that actually happens.
For the sake of simplicity, let's focus in on the revenue contribution from new sellers. Sales have a fixed transaction rate that your platform takes for revenue: \(Revenue_{NewSellers} = Sales_{NewSellers}*AvgTransactionRate\)
Then, you, the engineer, can decompose each of these variables on and on into their atomic units. It's painful to demonstrate this in paragraph, but you can follow my thinking here, and see what the beginning of quantified model looks like here.
Unlike reactor physics, there's no right answer! The above isn't the solution, it's one possible solution. The fun is figuring out what is the best model for how your revenue reactor runs.
You are building reactors to go critical
When each fission releases a sufficient number of neutrons to sustain chain reactions, engineers describe the reactor as achieving "criticality." When your product's reactor throws off enough revenue to sustain operations, accountants describe your business as "profitable."
While casting yourself as an architect might seem glamorous, you're more like an engineer working on valves, wiring instrumentation, and checking gauges. You're working on a reactor. Find inspiration from Homer Simpson, not Howard Roark.
Build reactors that go critical.
Caveats
- I'm using nuclear engineer to stand in for engineers, technicians, and operators.
- I learned naval nuclear propulsion's style of nuclear engineering. Things like the neutron lifecycle are simplifications and is not how the bleeding edge of reactor physics describes the reactor.
- Software engineering is software engineering. Nuclear engineering is nuclear engineering.
[1] Heinze, David. (2010). Burn-up Simulation of Novel BWR Fuels Using SCALE -- Sensitivity Analysis and Benchmark Comparison. 10.13140/2.1.2540.5443