What Benjamin Franklin Taught Me About Being a Better Software Engineer
Here are the most impactful lessons I took from Franklin’s life that every software engineer can apply today.
I’m rereading The Autobiography of Benjamin Franklin for the second time in a row, and I didn’t expect it to feel so relevant to modern software engineering. Franklin never wrote a line of code, but his approach to work, learning, and self-improvement could have come straight from a senior developer’s blog post.
Franklin was a printer, inventor, scientist, diplomat, and founder. He taught himself nearly everything and improved constantly by experimenting, reflecting, and sharing.
His attention to detail in prose and constant iterations in improving his print business and influence are just a few examples of what we can learn from his life. If you’re building a tech career, there’s much to learn from how he lived and worked.
1. Track What You Want to Improve
Franklin built a personal improvement system with a daily chart to track the virtues he wanted to strengthen. He didn’t just set vague goals. He made them visible and measurable.
Why it matters in engineering: Whether you’re learning a new language, improving test coverage, or working on communication, tracking creates awareness. I’ve started logging my daily learning habits, noting where I struggled during the day, and setting small weekly targets. It’s not about perfection. It’s about progress you can see.
2. Teach What You Learn
Franklin started a Junto club, where members met weekly to debate ideas and share knowledge. He believed that teaching others sharpened your own thinking.
Why it matters in engineering: Writing documentation, mentoring juniors, or blogging about that confusing bug you finally solved (just like we discussed in general in a previous blog) not only helps others. But it also enables you to master the topic. Sharing makes you a better learner and a more valuable teammate.
3. Build Before You’re Ready
Franklin was constantly launching things. A library, a newspaper, a postal service, a scientific experiment. He didn’t wait for full funding, a clear roadmap, or perfect timing.
Why it matters in engineering: I’ve sat on ideas for weeks or months because they didn’t feel ready. Franklin reminds me that execution matters more than polish. Every side project, open-source PR, or idea draft gets you closer to real momentum.
4. Work in Public
He published anonymously, shared drafts widely, and asked for feedback from his peers. Franklin understood that progress accelerates when your work is visible.
Why it matters in engineering: Pushing your work publicly, whether it’s a GitHub repo (like this FHIR data reader tool), a case study, or a demo site, creates feedback loops. It opens doors. It builds your reputation. You're missing half the benefit if you’re hiding everything behind private folders and silent effort.
5. Be Usefully Curious
Franklin’s curiosity was not random. He studied electricity, weather patterns, economics, and public policy, always intending to improve his life or solve a real problem.
Why it matters in engineering: A new framework, AI tool, or language is always popping up. The key is to stay curious but purposeful. Learn what helps you solve real problems more effectively. Build tools people actually need. Curiosity without application becomes a distraction with time.
6. Invest in Writing and Clarity
Franklin believed that writing well was a critical life skill. He practiced by rewriting articles in his own words, comparing them to the originals, and revising until his clarity improved.
Why it matters in engineering: Clear writing is underrated. It makes your design docs readable, your bug reports helpful, and your ideas convincing. Engineers who write clearly get listened to. If you want to lead projects, writing will carry you there more than clever syntax ever will.
7. Use Constraints to Create Freedom
He lived frugally, not just out of virtue, but because it gave him time to work on what mattered. He practiced discipline with money, time, and effort to stay focused.
Why it matters in engineering: I now limit how many side tools I explore each month, how many “nice to have” tasks I pick up, and even which hours I’ll work late. Constraints give structure. They protect your focus and preserve energy for the things that actually matter. Things like building, thinking, and collaborating well.
8. Reflect Weekly
Franklin reviewed his weekly progress and asked himself what went well, what didn’t, and how to improve. He saw mistakes not as failures, but as raw material for growth.
Why it matters in engineering: I’ve started doing small weekly retros, even when not part of a sprint. What frustrated me this week? Where did I waste time? What did I learn? Just 15 minutes of reflection will make me better next week.
Final Reflection
Franklin never claimed to be perfect. He wrote that he failed often and sometimes broke his own rules, but the act of trying made him better. He was systems-focused, experimented, shared, and adapted. That mindset, not any one invention or publication, made him so influential.
As software engineers, we often chase technical excellence. But Franklin reminds us that habits, discipline, and a willingness to reflect and share truly compound over time.
You don’t have to follow every principle. But try one. Track your progress. Share your work. Reflect honestly. Like Franklin, you’ll become far better at your craft and efforts for having tried.
Want More Like This?
Subscribe to my Medium or for tech reflections, engineering lessons, and tools that connect historical wisdom to modern software practice.
And let me know in the comments: what principle from Franklin’s life has influenced you the most?
