5 things I learned in journalism school that made me a better software engineer and tech lead
Have you ever tried to solve a problem using only one tool? It's like trying to hammer a nail with a screwdriver - sure, it might work in a pinch, but it's a lot easier (and more effective) to use the right tool for the job.
In the summer of 2014, while trying to find my place in the software engineering industry, I moved to the US to pursue a master's in journalism and computer science. I quickly discovered that software engineers and journalists are more similar than not; instead of trying to make sense of lines of code, you're trying to make sense of the world. Studying journalism gave me a toolbox full of insights and skills that proved immensely useful in my engineering career.
In this article, I want to share 5 essential skills I picked in journalism school that helped me improve in solving complex problems and showed me how to be an effective team leader.
♟️ Ask the right questions
Engineers learn ways to provide solutions but only sometimes think critically about the problem. For instance, how often do we build a machine learning model without understanding its business need? How about the resources required to run the model in production? We could work in a part of a more extensive system and not wonder how the rest of it operates.
Knowing what questions to ask is like identifying the missing piece of the information puzzle. You'll never find it if you don't know what you don't know.
As a software engineer, this can be helpful in several situations.
First, when debugging code or service. When I ask the right questions on how the code works with specific data or which part of the system has the potential to eat up resources, I can strategically rule out other possibilities. I follow the path to where the bug or the issue lies, saving myself and my team significant time. It can also manifest into a practical method of observing opportunities for building new and optimal products.
Second, when preparing for a meeting. If you are now questioning why you should prepare for meetings, I hope you remember this moment the next time you sit in another mind-numbingly dull meeting. I like comparing meetings to interviews; it's imperative to have questions ready in advance to ensure you get the information you need. Otherwise, you miss the story. Regardless of a team sync, a cross-functional meeting with VPs, or a simple 1:1 with your manager, knowing what you should ask can make a difference.
Lastly, when leading a project. Clear and effective communication is crucial for the success of a project. Asking the right questions ensures that everyone stays on track and progresses. It can help a team member figure out why they are stuck or allow them to express concerns about the implementation. I always aim to clarify the problem and resolve any ambiguities with colleagues early on. This will lead to designing better engineering solutions and saving time and money.
If you want to learn more about critical thinking, I highly recommend "Asking the Right Questions" by M. Neil Browne and Stuart M. Keeley.
👂 Listen carefully
The other half of the equation of thinking critically is to listen. You can only ask good questions if you listen. And although we all pretend to listen, few of us indeed do.
Listening skills are crucial for understanding your team's or stakeholders' needs and goals. Like a game of telephone, the message gets distorted at the end of the line if you don't listen closely to the person next to you.
As someone who's spent a lot of time talking, I've learned that sometimes the most important thing you can do is shut up and give someone else a chance to speak their mind. A way to do this is by practicing active listening by focusing on what the other person is saying rather than just waiting for your turn to talk. You can show that you're listening by nodding, making eye contact, and paraphrasing what they've said to show that you understand.
It's also crucial to be aware of nonverbal cues, like body language and facial expressions. Sometimes, people might not feel comfortable speaking up, but their faces can give you an idea of their disposition. By paying attention to these cues, you can create an environment where people feel safe to share their thoughts and feelings.
This becomes even more vital when you are in a leadership position. As a leader, it works counter-productively if you are the one who speaks first. It could discourage others from sharing their opinions if the team lead has influenced the discussion. And even if you do have the answer and feel that you can move the conversation faster, it will likely be much more efficient and scalable to sit back, listen to others, and let the best idea come from someone else, maybe subtly even guiding them to it by asking questions, than offering it yourself.
🔍 Find the story
When journalists look at the world, they don't see problems. They see stories. Everyday life is a source of information; their role is to interpret and present that information to the public clearly and accurately.
The ability to "see the story" is probably the most challenging concept for a software engineer. Or at least it was for me. We are trained to act on a given problem, not spot the problem or the opportunity. Once my mindset shifted, I started challenging my assumptions and looked at things from alternative angles. I became more inquisitive and curious. I started "seeing the story" behind the product or the feature I was building.
For instance, when I worked in the New York Times personalization team, it wasn't just about introducing a new recommender model to improve what the user would see on the page; it was about making sure the recommendations were not keeping the user in a news bubble. That was the story, and it had to be factored into the logic of the solution I would provide.
For several reasons, finding the story can be an essential skill for software engineers.
First, you understand the user better. This can lead to more effective and user-centered product design. Second, you come up with new and innovative solutions. If you train your mind to challenge the status quo and think outside the box, you can spot opportunities where others see obstacles. Third, you are one step ahead when communicating with stakeholders. Knowing why your product or system is being developed helps convey your value to others. And lastly, you build empathy for your users. This is often overlooked, but I want to underline its importance for shipping compassionate and inclusive products.
🪦 Don’t bury the lede
For those of you wondering what the lede is and why did you bury it, let me tell you about it. In journalistic lingo, the lede is the juicy tidbit, the shocking revelation that makes you go "whoa" and "huh?" It's the most critical part of the story, which grabs the reader's attention and makes the story unforgettable.
And what has all this to do with being a software engineer? Glad you asked. The answer is: presenting the information.
If asking questions and listening to others shape critical thinking, presenting information is the last piece of the puzzle of effective communication.
As a software engineer, presentation skills may seem like something other than the most important thing on your plate. After all, your code speaks for itself, right? Wrong! Learning how to communicate your ideas and work is crucial for software engineers and technical leaders. And that involves identifying the juiciest part that brings the most value and showcases it to the world.
Whether it means creating a presentation for your team and your stakeholders or speaking at conferences and meetups, being good at presenting information in a concise, transparent, easy-to-understand, and engaging way can raise your professional profile and get others excited about your work. Not to mention that public speaking offers an excellent opportunity to create and grow your network.
Being good at presenting your work can make a good project great and a significant project unforgettable.
🐥 Kill your darlings
Finally, dare to "kill your darlings."
"Kill your darlings" is a phrase that refers to how writers have to cut or edit out some of their favorite parts of their work if they don't serve the overall story.
In software engineering, "killing your darlings" can be difficult. Most of us spend much time developing a system, building a new feature, or training an ML model. Frequently, it requires a lot of iteration and experimentation. It can take weeks, months, and sometimes even a year to ship something to real users. When done right, software development is a creative process, so the attachment is real.
Often, however, it is necessary to clear the clutter to make room for new things. That could be features that contribute very little to the business, outdated code, or systems that could be more cost-effective. If an item can't justify its maintenance cost by the value it's providing, it needs to be deprecated. In a world where your company's business model is the story, the systems that support it should be in service of its overall objective.
And thus, as a software engineer, I had to be as disciplined and humble as when writing stories: evaluate the code, recognize if something is redundant, and make the tough decision to cut out the parts not serving the overall project, team, or organization.
After all, maintaining less allows you to free yourself from constraints and push the boundaries of what's possible, maximizing impact. All that while considering that your work today may be old news tomorrow.
Conclusion
Combining skills from different disciplines, even as contrasting as computer science and journalism, helped me become a better engineer. It pushed me to cultivate a more open-minded approach to looking at problems and grow more curious and adaptable to new ideas.
Learning tools from multiple fields could help you develop more exciting solutions and shape you into a better leader in the workplace. It's like having a toolbox of various perspectives. And let me tell you, the world is full of nails that need hammering - complex problems that can't be solved by looking at them from just one angle.
