21–30 of 309 posts
Lots of people in the comments exemplifying why I would never want to work with them.
Are you saying you wouldn't want to work with anyone that agrees with the points in the article? If so, it would be interesting to hear your thoughts.
I remember back in the late 90's and early 2000's it was similarly cool to bash anything related to Microsoft.
I spent a good bit of time writing a lengthy comment on slashdot about "Why to code". It was fairly poignant and well-received, except at the end of it I took a low effort pot-shot at Microsoft - because it was cool to do at the time.
Someone replied and (rightly) called me out on it. Why muddle an otherwise interesting talk / piece with a cheap, drive-by swipe?
That was nearly twenty years ago, but let's call this comment me paying it back (if the author reads HN).
Really resonated with this, reminded me of the journey I went on over the course of my dev career. By the end, my advice for every manager was roughly: * Don't add process just for the sake of it. Only add it if seriously needed. * Require ownership all the way to prod and beyond, no matter the role. (Turns out people tend to really like that.) * Stop making reactive decisions. If something bad happened on a total, e…
* Separate bullet points by blank lines on HN. ;)
Really resonated with this, reminded me of the journey I went on over the course of my dev career. By the end, my advice for every manager was roughly: * Don't add process just for the sake of it. Only add it if seriously needed. * Require ownership all the way to prod and beyond, no matter the role. (Turns out people tend to really like that.) * Stop making reactive decisions. If something bad happened on a total, e…
> Stop making reactive decisions. If something bad happened on a total, extremely unlikely lark, don't act like it's going to happen again next week I hate this, like when there's an outage and the outcome is 100 half baked ideas that must be implemented, that just make things worse to work with
I prefer recording over slides.
The productivity of every single team that I've been apart of, that shipped fast, was enabled through permission, by highly experienced domain experts who knew how to build guardrails instead of controls. Canary releases, monitoring and rollbacks, not release managers. Automated testing, not codeowners.
Controls prohibit actors from doing certain things. Outside of regulated environments, they should only exist at the perimeter of your business, interfering in the nefarious activities of malicious external actors.
Guardrails on the other hand, guide actors in the right direction. Well installed guardrails can see your legal team pushing changes to your API schemas.
Those guardrails however take real expertise to install.
How does something like this scale for more than 10 people? 100? 1000?
Every. Damned. Time.
Really resonated with this, reminded me of the journey I went on over the course of my dev career. By the end, my advice for every manager was roughly: * Don't add process just for the sake of it. Only add it if seriously needed. * Require ownership all the way to prod and beyond, no matter the role. (Turns out people tend to really like that.) * Stop making reactive decisions. If something bad happened on a total, e…
an economy of giving in a way
Pizza teams that own the whole stack, and for the roles that don't need a full-time individual, specialists that come in and advise but also make it possible to DIY the things they do.
The best examples of specialists are Designers and Security teams as this talk highlights. They can make the tools and the means for other teams to self-service those needs. For example, security teams implementing CI tools and designers building design frameworks that are easy to apply. Conversely, they can feel free to make changes themselves and are empowered to at the best organizations.
Everyone else in product development is a generalist, including the managers, and everyone is on-call. When everyone is on-call then it results in far fewer alerts going off because when there is an issue, it's taken very seriously and remediated quickly in the following days & weeks.
I think GTM teams could also benefit from this same kind of process, but instead melding Marketing, Sales and Support roles and responsibilities.
My theory on why this wasn't more common in the past was that the work was too complex and specialized and that the tools and knowledge to do the job weren't as easy to acquire as it is today. LLMs have certainly leveled the playing field immensely in this area and I'm truly excited to see the future of work myself.