Who Is Toni Morrison?
Toni Morrison was an American Nobel Prize-winning author, famous for novels such as Beloved and Song of Solomon. She was a literary giant whose works inspired generations of Black writers. Her unapologetic exploration of Black identity, history, and culture, combined with her poetic yet disciplined storytelling, resonates with millions of people.
Although this article does not focus on Morrison's life and work directly, that context matters. It helps frame the ideas in the interview and why they remain useful beyond literature.
In an interview with Mavis Nicholson, Toni Morrison talked about her writing journey and the influences that shaped her style. She also explained how her writing evolved and why. In this blog, we will look at a few of those ideas and how they relate to modern software development.
I. Create the Things You Wish Existed in the World
When asked why she started writing, her response was straightforward.
I wanted to read about people like me. People who were black, young and had lived in the mid-west, and nobody wrote about them.
I find this perspective interesting not because of her particular interests, but because most of us default to giving up when we fail to find relatable content. She did not. Instead, her idea was simple: if something I want is not out there, I will bring that thing into existence.
That same idea appears in one of her most famous lines.
“If there's a book that you want to read, but it hasn't been written yet, then you must write it.”
II. Do Not Make It Too Personal
Despite her interest in creating work that resonated with her, Morrison also emphasized the importance of emotional distance. In her speeches and teachings, she advised creators to “think of somebody you don’t know” and avoid writing only about “your true love and your mama and your papa and your friends.” Her point was to aim for broader truths instead of self-indulgent emotion.
This idea is especially fascinating because she admitted that she fell into the trap herself early in her career. “It was my editor’s advice that made me realize that I was writing about my own pain, in my own language,” she said. That fixation on the self, she argued, damages the authenticity of the work.
If you start to use your own emotions to in order to inhabit the character, you are doing them a terrible injustice. Your emotions may not be large enough, they may be too small or they are inaccurate, they are not authentic necessarily. The character needs your intelligence, not your emotions.
What Does This Have to Do with Software Development?
It is reasonable to question the connection between literature and software development, but the parallel is real. Morrison's ideas map surprisingly well to how we build software.
1. Build Personal Projects
The modern era of software development is defined by abundance: tools, languages, frameworks, and learning resources. That abundance is useful, but it is also overwhelming. It leads to questions such as: What should I learn? and What is the best way to learn it?
One common answer to the second question is this: build something that solves your problem.
You are never going to learn programming by reading a book called ‘Learn Programming’. Every one I have met who can program learned it the same way. They had something they wanted to do and they tried to do it.
Even in George's usual high-energy style, the point is sound. Working on a real project that matters to you is one of the best ways to become familiar with programming and software engineering. Personal projects expose you to the software development process while helping you solve real problems.
This concept is often called “scratch your own itch” in the developer community, a phrase popularized by Rework by Jason Fried and David Heinemeier Hansson. It aligns closely with Morrison's call to create what you wish existed.
2. Prioritize Users
Few professions demand more attention to the user than software engineering. The true success of a project depends on a user-centric approach. UI, speed, and software quality all matter because failure in any of them can easily overshadow the strengths of the product.
That is where Morrison's lesson applies again. Creativity and originality are valuable, but they should not come at the expense of clarity or usability. A sleek interface or a backend optimized for speed may begin with the developer's own needs, but it has to move beyond personal preference and serve a broader audience.