Talk is Cheap, show me the code
Hey!
Welcome back to another week of musings.
I hope you had a great weekend, I’m writing this on the Caltrain going back from a comedy show in San Jose.
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
- I think I've shared this podcast in the past, but this interview with 100 Thieves in the Colin and Samir Show was a great view into what goes inside the e-sport industry and running a successful business.
- I’m into stationery and lately I've been getting content around notebooks, and now I want to buy a Traveler’s Notebook Let me know if you’ve had one.
The title quote is often attributed to Linus Torvalds. Sadly, it is frequently used to diminish or minimize the contributions of others to projects.
While code is the way to have a "tangible" product for customers to use, other aspects of projects also help customers and ourselves in the future. When we onboard new developers or new leadership wants to take the project in a new direction, etc.
The other aspect, in part, is that in tech companies, you generally need alignment on requirements to a degree that minimizes reworking a feature or prevents scope creep.
So yes, talk is cheap because it allows us not to spend valuable time coding something that we don't need or will rewrite in a month or so.
We’ll never have “crisp” requirements, as much as we like to complain about it. Companies are constantly making bets on features that might or may not be adopted by customers or bring us new customers.
In my case, the main focus has been making teams effective at releasing code, (actually) iterating, and being comfortable with experimentation and throwing away things that don't work.
Engineers, I think, benefit more from understanding the business need (e.g., Customers need to understand what payments they made last month) over getting detailed requirement stories or tickets (e.g., Make a monthly report of transactions in csv format).
Having the same language as the business benefits you in terms of communication and allows you to build trust in the long term, allowing you to put forward recommendations because they know you understand and have the company's goals as your interest.
And if you're invested in the company and want to see a large change executed, you need social capital with leadership.
Your turn!
Have you ever thought, “why no one has detailed requirements”? Have you ever raised your voice to change that? Or have you asked to listen to leadership meetings to understand the requirements? Let me know your thoughts by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others