Writing will always be the hot sauce

Have you seen those commercials for Fank's Red Hot Sauce?  In case you haven't the gist is that this old woman makes awesome food.  Her secret?  She puts Frank's Red Hot Sauce on everything.  Or as she would say "I put that sh*t on everything".  In engineering we often use the hammer and nail analogy.  When you have a hammer, everything looks like a nail.  This is meant as an anti-pattern.  You shouldn't use the same solution to all problems.  Maybe she shouldn't put Frank's Red Hot Sauce on everything?  I don't know.  I'm not sure that analogy applies here cause Frank's is pretty damn good.  Is there an equivalent in engineering?  Is there a hot sauce we should be putting on everything?  

Writing software can be incredibly complex and difficult.  Wrapping your head around a business problem and translating it into usable, testable, readable code is an absolute achievement.

Increasingly - being technically competent - being able to execute a product vision technically - is no longer enough.  The best engineers I've worked with do more than that.  They communicate.  

Communication is key to any team environment.  These days engineers are expected to engage via Slack, JIRA, GitHub, Basecamp, Trello, Asana, Google Docs, StackOverflow, and more.  Oh, and also email and Twitter and LinkedIn and...and...and.  What's the common algorithm to solving problems on these platforms?  What's the common API?  Writing.    

Writing is harder.  In code there is x==y.  In writing there is nuance.  There is opinion.  It's a non-deterministic, fungible medium.  It's exactly the kind of thing engineers historically avoid.  But ultimately, writing is just a more verbose, round about way, of coding.  You're translating ideas into language to solve a problem.

In an ideal world you might have a product manager who will write a user story.  "As a user when I Click X, I expect Y to happen".  That product manager will then take that story and create tasks for engineering, qa, product marketing, customer support and sales to make sure the task is (a) completed as intended and (b) all relevant stake holders are notified and documentation is updated.  In my experience this can happen but this is the exception, not the rule.  More often the product manager doesn't have enough context to interface with all of those groups.  They don't understand all the implications of the changes being made.

In the truest sense, the engineer's role is to solve problems not just write code.  The best engineers I encounter are the ones who can take that user story and of course solve it in code.  But then they work with qa, product, support, marketing, sales.  The way they do this is writing.  It's writing a readme, a wiki article, updating a JIRA or GitHub issue or even something as simple as an email to the stake holders.  They can communicate the intent and the output in plain, non-technical language.  

When I see an engineer start with a user story and close the loop with stake holders - that, to me, is product-engineering nirvana.  That engineer knows the business case so clearly they can communicate it directly to the relevant people across the organization.  The product managers trusts engineering so implicitly they don't need to micromanage the process.

If you're an engineer looking to move up in your career, my advice is to write.  It can be as simple as writing well rounded documentation to the work you're doing.  The best tip - do it in advance.  Write the doc, then write the code.  If the code doesn't match or vice-versa then maybe you didn't understand the problem correctly.

Here's the thing.  Today it feels like JavaScript is the hot sauce.  Years ago it was SQL.  Tomorrow it might be Rust or Elm or AI powered blockchain drones.  Being able to communicate clearly, being able to write, will always be the hot sauce.  Being able to communicate your ideas and your actions will always have value, no matter your role.  

Writing is the easiest, most powerful way to make yourself more visible and more valuable in your role as a technical contributor.  You can put that sh*t on everything.