RTFM - The Single Most Important Bit Of Advice for Engineers

I've been a software engineer for almost 8 years, and I'm sure I haven't always been a great one. But in the last couple of years, I've noticed a significant change in my ability to understand complex systems. It's not that I became a genius or that I learned some obscure advanced concepts. The change was much more subtle: I started to read the manual.

"Read the manual" aka RTFM, this piece of advice accelerated my growth as a software engineer. Very simple advice, with a lot of wisdom behind it. By nature, a lot of engineers like to tinker and rely on their trial and error techniques to get the job done. The uglier term for that is brute-forcing your way through a problem. I'm guilty of still doing this from time to time.

When I worked for Paymentus, I got a lot of chances to work with the SVP of Technology, Eugene Abramov. This man was a walking encyclopedia for us. We would shoot questions at him while he walked by, and he would quote the manual, pinpointing where we had to look as if he had read it just before sleeping that day.

Reading the manual was advice that I got from Eugene. You can save yourself from many hours of debugging and save your brain from having to deal with black boxes all the time. You can also stop relying on your copy/pasta skills. Technology is always changing, there are always new things we have to work with. Only if there was an easy way to learn about this new technology...

We (software engineers) pray to find answers to all of our questions on StackOverflow. Did you ever wonder where the first person could've learned it from? My bet is on the manual. I'm not suggesting that you just start at page one, and go through the entire API documentation before putting it to use, but be sure to at least read about the exact functions you will use and all the options available while comparing the alternatives. Without this knowledge, you might be using a lot of extra time on something that could have been done faster. Most importantly, avoid reinventing the wheel - there are tons of articles out there with examples about how to do things that already exist. Being able to work with things that we don’t fully understand is a strength, but we shouldn’t abuse that power for too long.

If you want to or claim to be an expert in some XYZ technology, then take the time to read the official documentation, cover to cover. Learn about all of the available functions, their arguments, and what they do, so that when you need to use them again in the future, you are already familiar with them. Our brains are usually good at taking this information, and putting it in the archives for the day you will need them.

Software is designed with specific use cases, and the designers want you to use it in a specific way. Go learn from the creators on how their software should be used. You may claim this is not my learning style. That's fine, I only recommended this for people who wanted to be the "expert".

An example, everyone in the web development world wants to learn React. You can find a gazillion tutorials, courses, workshops, etc. Most of them will teach you how to use it, and do a really good job too. Alternatively, or right after, you should go to React Docs, and take the pain to go through it. You will learn everything, from fundamentals, design principles, testing, staying informed, and even how to contribute to the React project itself.

You can apply this advice in the physical world, and you probably already do. When you get that new programmable espresso machine, you will probably read the thick document that came with it. Now you are the expert:

Expert

Follow me to get more obvious tips like this. I may post about unobvious things too.

Thanks for reading.

RTFM - The Single Most Important Bit Of Advice for Engineers

Comments

More from this blog

Convert Existing React App to Server Side Rendered

For my Ukrainian student, learning to code

Introduction to computer science, with problem-solving

Get started with coding, for free

Don't skip use case analysis, learn how to build them

Command Palette

Comments

More from this blog