A series of posts on sensible software engineering practices @ Meta. In this post we discuss the practice of doing your research first to unblock yourself and asking questions.
Photo by Scott Graham
on Unsplash
I recently worked at the Meta London office as a Senior software engineer for a year and a half. I was fortunate to get the opportunity to work deep within the trenches of the WhatsApp Test Automation group.
My group was primarily responsible for automated testing frameworks and tools for WhatsApp mobile clients (Android, iOS, and web). We supported 100+ mobile engineering org and enabled them to write solid automated tests using automated frameworks like Espresso, XCUITest, Unit tests, Screenshot tests, and JS-based Internal E2E testing frameworks across Android and iOS.
During this time, I made my contributions towards improving the culture of Automated Testing and increasing the reliability of our frameworks, tests, and infra for one of the most popular apps in the world with 2 billion+ users.
I have been keenly observing how engineering happens at Meta and have a few personal observations on some engineering practices that I’ve seen engineers follow and which I think are something we can all learn from.
I think these probably would make a lot of sense for other teams in the wider industry as well and even if not directly applicable in your specific context may at least serve as an inspiration.
I intend to write a series of small posts covering these, so keep following this series of posts on my newsletter and blog. Let’s dive in.
Practice 1: Unblock yourself first before asking others for help 🙏
Sift through docs, wikis, and threads 📃
Within Meta, Software Engineers use a lot of internal tools.
One of the unique challenges this presents is that often you’ll not be able to find answers to your questions in stack overflow or Google. If you are lucky and it’s an open-source technology you are working on then sure googling it is useful, however for every other bespoke tool and stack, you mostly rely on internal search tools and engineers.
Information about any tech, framework, tool, Infra, etc is usually scattered either in internal wikis, notes (kind of like an internal blog platform), or workplace posts (think, like Facebook, but for work).
While most core technologies have decent documentation, often the real hints or clues about solving a particular problem are to be found either in the Internal Q&A site or sifting through comments by other engineers on historical workplace posts, and most times by just reading the code.
You need to get good at finding where to look.
Do your research first 🔍
One of the core skills you pick up early as a Software engineer to succeed in this kind of environment is to be able to research your problem well first and have a good explanation of what steps you have tried so far and also what specific area you need help in.
Being able to write them down clearly and concisely is also an essential skill.
I feel this is a pretty good practice/framework in general to follow.
It makes the job of other engineers way easier in a couple of ways:
- Reduces the amount of context switch they have to do and the time it takes for them to understand your problem and its associated problem space.
- They can give you well targeted pointers on where to look next since they can follow your trail of thought easily.
- It also conveys to them that you’ve done a lot of the upfront hard work and in turn, makes you look really good in front of them
Art of asking good questions ❓
if you’ve ever written a well-crafted stack overflow question then you’d be able to relate to how useful and effective this approach of formulating good questions is in getting answers.
The act of trying to explain your problem, how you are approaching it, and what is unclear is a good mental exercise and often times results in you being able to find answers yourself. I would anecdotally advocate that doing this enough not of times, makes you a better engineer in the end.
Sometimes you really don’t even know where to even start looking. This is more common when you are a new engineer ramping up on meta-technology stacks and tools
In such cases if you are lucky you’ll be able to reach out to someone on the team/company who has experience with that piece of technology and they would be able to give you some code pointers to get started with or fill in the gaps
You have to understand that the real onus to keep prodding the problem is really on you.
Knowing when to ask 😖
If you are working on something, it’s easy to dive into a long rabbit hole toward its solution and end up wasting a couple of days.
With time you develop strong judgment on if this is happening to you presently and you know when to seek help and save time.
There is no shame in it really, I make it a point to seek help when I know I’m in one of these rabbit holes and it would be more effective to get some answers upfront.
As long as you’ve done the initial upfront research, other engineers are usually quite happy to jump in and help you out and also validate if you are on the right track. I’ve been fortunate enough to receive this and also offer this to other engineers many times.
So next time, try and follow this approach and let me know how it worked out for you. I’m also curious to understand if there are variations of this that you follow in your own workplaces. Looking forward to a discussion on the comments. Let me know will ya? I would love to hear your thoughts in comments
| Thanks for the time you spent reading this 🙌. If you found this post helpful, please share it with your friends and follow me ( @automationhacks ) for more such insights in Software Testing and Automation. Until next time, Happy Testing 🕵🏻 and Learning! 🌱 | Newsletter | YouTube | Blog | LinkedIn | Twitter. |
Top comments (0)