I've been lucky to be part of several powerful organisations and startups, and even more so luckier now that I get to run my own firm.
Like many, ...
For further actions, you may consider blocking this person and/or reporting abuse
This article is honestly great.
Mate thanks so much! I'm super keen to see the new stuff you post out soon!
They're all great! I mean it! Super keen to see your growth online!!!🙏🙏🙏
No need for thanks, your article was great.
Glad you’ve been enjoying my content, I’ll keep it coming.
This is a good article, and I absolutely agree with the concepts you are driving at, I'm just not sure "failure tolerant" is quite the right term for this.
Failure is bad as far as I'm concerned, and I try to avoid it, easier said than done of course... I am though failure intolerant in my approach to software development.
What I think you're really looking for in developers, and what your post alludes to, is:
When I've hired developers I look for people who are almost relentless in their approach to learning and who can understand the wider context within which they are working. These developers have perspective and they know it's not just a code problem. And the really great developers are the ones who can communicate well and have soft skills.
None of this is to say the "f**k up fast" approach as I like to call it is a bad thing. It's just it often comes from a bad place. I often advise developers and companies to fail fast and iterate because they have no interest in doing any domain discovery work. So I see fail fast as a way to quickly understand a domain without causing too much damage. Of course to do this you have to be failure tolerant, but I don't see failure tolerance and fail fast as things to aspire to. I see learning, perspective and communication as traits to aspire to and I think this is what your post is really getting at.
Hey Rob!
"Failure is bad as far as I'm concerned" you are absolutely right on this part. And while I agree the article reads to encourage this, I think what I was getting to was, the mindset shouldn't be to actively look to ways to fail haha but incase it happens, dust yourself - which is exactly what you said so you're definitely on the money!
" I look for people who are almost relentless in their approach to learning and who can understand the wider context within which they are working"
Yes this is so critical!
"It's just it often comes from a bad place." Agreed - the Valley mindset isn't the most effective, true!
" I see learning, perspective and communication as traits to aspire to and I think this is what your post is really getting at."
Nailed it!
What do you say to those who say "Boring is Good"? i.e. choose the less exciting, older database over the new one except when it's intensely unsuited for the task at hand.
In terms of innovation, it's the product or real pain points/provable big wins in the development process that should drive this.
Example: I wrote the backend for a user chat feature quite quickly with postgres. With default config it's not the optimal database for the job. Chat has append only semantics and low locking requirements so the right kind of database can get many multiples better latency. But crucially, taking this step would have no appreciable effect for the user with the low traffic we had. The risk and learning time cost of introducing unfamiliar new tech would have been considerable and required much more complex code to get to the fully optimised async version.
In practice, that part of the backend has worked away faithfully for nearly 2 years, not exposing bugs and with lower latency than any other user interaction.
I see part of my job as resisting the urge to learn new fun stuff on someone else's dime without great justification.
I say, choose a tool that is correct for the job, if its old, but it is the tool needed to do the job due to backwards compatibility issues.
I was watching a youtube video from the cofounder of wufoo yesterday who gave an example of another incredible company where they would keep tech support phones in the middle of the dev floor, because if the devs are directly involved in supporting solutions for customers they will best find a great solution to fix the issue.
Perhaps I should mention/overcommunicate that this mindset should be when your firm is in growth mode and is specifically looking to improve their current practice because it needs to improve. I personally would never wander into new waters when building a new product, I wander into new waters when my current approach isn't enough for the outcome i want to deliver to my customers.
So in short, you are absolutely right to do what you have done in your example sir! In the end elegancy doesn't mean "new" shit, it means building things that work better than before, BECAUSE it's necessary.
"People respect new solutions that are better ways to solve problems, not because they're just better for the sake of being better." 💪
Absolutely agree, very well said.