Do I need to know how to code to write better requirements?

4 min readNov 16, 2020

After spending thousands of dollars on a programming bootcamp and staying up late to code after my full-time job, I can tell you the ROI is low.

The truth is with so many new technologies coming out every year, even engineers themselves have a hard time keeping up with the latest.

This post will teach you how to learn the minimum amount you need to know with the least effort.

1. Immerse yourself with engineers

To prioritize what to learn, you need to know what is most relevant to your engineers and your particular application. At the end of the day, your goal is to write clearer requirements for your team.

To start, take notes of terms that come up frequently and under what context. If they are going too fast in meetings, record them and re-watch them later.

How can you find these opportunities?

Join the engineers’ slack channels, their demos or the company’s tech talks.
Sit near the engineers and eavesdrop on their conversations.
Ask them to invite you the next time they plan to go over a specific part of the application that you want to learn more about.

The key here is to avoid asking questions during these talks to not interrupt their conversations — so they won’t mind including you in the future.

Much like learning a new language, you want to get used to hearing those terms. So your brain doesn’t naturally tune out or freak out when the jargons appear in conversations.

2. Find resources with the right level of depth

If a topic is completely new, start with a high-level overview by watching a few YouTube videos. Pick those that are shorter than 15mins. Why is this important?

It is a sign that it is too in-depth.
It is easier to follow and sustain your focus when it is short

I’ve bolded some keywords to search for in the sample videos.

If reading is your preferred learning style, use the same keywords to search for an article.

You want to study a few of these beginner resources. If the same concepts keep coming up, they are likely very important. Make sure you review and understand them. The good videos will include analogies and examples from common applications, like FaceBook, that you can relate to.

After you nail the basics, all you are doing is building on top of what you already know. More on this later.

3. Focus on the purpose of a technology

Ask yourself what problem is this technology solving? How is it better than an existing solution? How does your engineer use them? Answers to these questions can be understood by any non-technical people.

Using cloud servers as an example:

Because cloud servers are virtual, users can quickly adjust the size of their server based on traffic received.
It is better than physical servers because you don’t need to rely on the IT department to set up the infrastructure that is time and cost-intensive.
Our engineers use databases on AWS.

It is easy to get sidetracked to know the differences between different providers of the same technology. For example, you don’t need to know what makes AWS (cloud services provided by Amazon) different from Azure (cloud services provided by Microsoft).

If you are not sure if they are all of the same thing, ask a few engineers.

4. Understand how the data flows and how systems interact

Applications consist of sets of building blocks that work together. Data is received, manipulated and saved from one component to another. That’s why engineers use flowcharts to illustrate the sequence of events.

Bugs happen if one of the blocks or connections between the blocks breaks. Those are great opportunities to tie the abstract ideas to real-world examples. Knowing what happens when it malfunctions, you will understand the purpose of the block.

For example, the user is getting an error after clicking `Save`. Your developers can’t’ find the newly saved data, suggesting a failed connection between sending the data from the front end to receiving in the database.

5. Apply your learnings

“Learning-on-the job” is the most effective way to grow your skills — because you are forced to retrieve what you learn every day. Repetition reinforces learnings.

Be a keener and take initiative to create more of those opportunities.

Teach your non-technical teammates. They likely want to learn them to do their job better. It also earns you the reputation of the “go-to-person”. Win-win situation.
When is the next meeting where your teammate will talk about this technology? Test yourself if you can gradually follow the conversation better?

Parting thoughts

Learning how to learn is more important than acquiring the knowledge itself. Emerging technologies come up so often. Follow the process above and you can learn any concept quickly and communicate with your engineers effectively.