The Soft Fundamentals — Reading Documentation, Reading a Stack Trace, Asking a Good Question, and the Skills Nobody Examines

The engineer everyone wanted on their team

Towards the end of her first year, Sneha — the frontend engineer from the fintech week in Bangalore, the one who reviewed Karthik's pull request and caught the concurrency bug — was quietly becoming the person other engineers wanted on their projects. Not because she was the strongest coder on the team. She was not. Moin was stronger. Riya was stronger. If you had ranked the team purely on raw technical depth, Sneha would have been somewhere in the middle.

But when a ticket needed someone, her name came up more than anyone else's. When a junior was stuck, they walked to her desk before they walked to Moin's, even though Moin knew more, because Moin made them feel small without meaning to and Sneha did not. When she opened a pull request, it got reviewed fast, because her descriptions made the reviewer's job easy. When she got stuck, she got unstuck quickly, because she had become very good at asking. When she disagreed with a design, the disagreement made the design better instead of making the meeting longer.

None of that was on her degree. None of it was in any syllabus. None of it would show up in a technical interview's coding round. And all of it, every single piece, was learnable, and most of it she had learned on purpose in twelve months by paying attention to the things nobody told her were skills.

This is the last chapter of Part A, and it is, deliberately, not about systems. It is about those things. They are called soft skills, which is a bad name, because there is nothing soft about them and they are not optional. They are the fundamentals that decide whether everything else you learned in this book gets used, and the engineers who are trusted all have them, and almost nobody is ever taught them. This chapter teaches them.