I believe that Richard Feynman can teach ServiceNow developers (and any software developers) a great deal - about physics, sure; but also about our own discipline.

I'm something of a physics nut myself (insert Spider-Man meme here), which has led me to something of an obsession with Richard Feynman. His work, of course (I've even got a Feynman diagram tattooed on the back of my neck), but also his life and upbringing. I'm interested in how someone like Richard Feynman was raised, and what lessons can be taken about how to raise children to become people with his best qualities. Qualities like intellectual curiosity and earnest, unabashed, confident-yet-humble exploration.

I once talked about the importance of confident-yet-humble exploration of new topics on a podcast with Robert Fedoruk and Cory Wesley. You can jump straight to the relevant time-code in that episode if you're interested in hearing it, here. (https://perspectives.snc.guru). This is a topic about which I am deeply passionate. I strongly believe that if we had more people with the sort of confident and humble intellectual curiosity of Richard Feynman, the world would be a much better and better-off place.

So, to that end, here are a couple of lessons I've taken about software development, from the late great physicist, Richard Feynman.

1. Don't Worry so Much About the Names of Things

Richard Feynman's father, Melville Feynman, used to take him on nature walks. During one such walk in the woods, a young Richard asked his father the name of a bird they saw. Melville responded not just with the bird's name in English but also in several other languages. However, he then pointed out that knowing the names of the bird in various different languages didn't actually teach Richard anything about the bird itself - the bird's habits, its role in the ecosystem, or its behaviors. Melville emphasized that the name is just a convention, a way for people to communicate about the bird, but it doesn't convey the essence or the true nature of the bird.

Relating this story to writing code - I'm not talking about variable names here; I'm talking about arcane terms like "monad", "higher-order function", "contravariance", and "Idempotence". If you use these terms without explaining them when talking to someone who you aren't certain is on the same page as you, then you aren't helping.
You aren’t teaching.
You're flexing.

Knowing the name of a thing is not the same as understanding it.
Using the name of a thing is not the same as explaining it.

Or, as Feynman’s father put it:
"Knowing the name of something, is not the same as knowing something."

2. Focus on Simplification Before Solution

Feynman was a master at simplifying complex concepts to their essence. I (vaguely, possibly apocryphally) recall hearing a story about Feynman working with another scientist on the same problem in an adjacent office. Feynman would sit in his office and play the bongos all day, apparently not working on the problem at all. The other scientist became very annoyed but was too polite to say anything.
After a good several days of the other scientist being deep in turgid thought, and Feynman just fiddling on the bongos, Feynman announced that he had solved the problem!
The other scientist thought he must be out of his mind, but no - Feynman had spent almost that entire time indeed not trying to solve the problem, but instead trying to come up with a way to make the problem simpler.

Once the problem could finally be simplified, the solution was almost obvious!

In programming, the ability to distill a problem to its simplest form before attempting to solve it is invaluable. This must often happen even before metaphorical pen is ever put to metaphorical paper; including in the requirements-gathering, design, and technical architecture stages.

This doesn't just apply to writing code; it also means simplifying your understanding of the problem itself.
Often, by focusing on simplification, you may find more elegant and efficient solutions, or even discover that the problem you're trying to solve is not the real problem. Developers (and especially architects!) can learn from Richard Feynman, to spend time upfront, understanding and simplifying their challenges, leading to more effective, efficient, and cleaner solutions.

3. Break Problems Down into Manageable Components

Feynman's problem-solving approach involved breaking down complex problems into smaller, manageable parts that could be more easily understood and solved. This technique is directly applicable to software development, where complex features or bugs can seem overwhelming at first glance.

By decomposing a problem into its fundamental components, developers can tackle each piece individually, making the overall problem more tractable. This method also aids in identifying reusable code components and simplifies debugging.

4. Find Joy in the Process

Feynman's enthusiasm for physics was driven by a love for the process of discovery, not just the outcomes. Similarly, the best software developers often are those who find joy in the process of coding itself—the act of creating, solving problems, and continuous learning.

This mindset helps to maintain motivation and resilience in the face of challenging or mundane tasks and fosters a culture of innovation and curiosity.

5. Teach to Learn

Feynman believed in the power of teaching as a tool for learning. He often said that explaining concepts to others in simple terms was the best way to solidify your own understanding. This principle can be applied to programming through giving talks at conferences, holding open office-hours calls, doing code reviews, pair programming, and writing documentation.

By teaching others about your code or explaining your approach to solving a problem, you not only help spread knowledge but also deepen your own understanding and uncover potential improvements or errors in your work.

Conclusion

By incorporating these lessons from Richard Feynman into their practice, software developers (including ServiceNow developers) can enhance their problem-solving skills, improve their work's clarity and effectiveness, and foster a lifelong passion for learning and innovation in the field of software development.