If I had to pick one thing I learned at Chef, it is this, even if you’re the founder. I had to turn it into a job, that I happened to love, with people I loved, but that ultimately was about the work. Not about my self worth. Just about doing good work, day after day.
Before I did that, everything was multi layered and fraught. I was harder to work with, much more volatile, and sometimes capricious. I’m a little that way by nature - but when my life is all tied up like that, it was so much worse.
Once I realized it could be work - everything got easier. My decisions, my feelings, my friendships. listen to Emily and Jill. Make your work be about your work. Free yourself to find pride in it, but have it be a part of your self worth and life, instead of the opposite.
You’ll be happier and do better work, for a longer period of time. At least I did.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
if you’re a leader, and you aren’t analyzing how you would act, and why, in the situation at basecamp, you’re missing a golden opportunity. Every step offers a gold mine of introspection.
How not to roll out policy changes? Check. Why you never bundle things together? Check. Public airing of dirty laundry? Check.
I like to believe I would’ve killed the names list the moment I saw it. In 2009 it wouldn’t have been because I thought it was racist (tho I see that it is now), but because you cannot have disdain for the people you serve.
The more time I spend in software development, the more I feel like everything hinges on architecture that is flexible in the face of new understanding about the domain. Too much architecture too soon means discovery slows down. Too little later on and the system can’t evolve.
Trying to do TDD without a firm grasp of architecture patterns is like building your own straight jacket. But then later, under testing the architecture means you’ll never be truly stable.
It’s a constant balancing act between over architecting and under architecting. The answers change with the code base, and with the teams, and ultimately ideally with the richness of our understanding of the domain were operating in.
This misses the point wildly. There aren’t different understandings of what open source means. There are people who want what they want. If they still can get it, they’re usually fine with whatever.
When you think you get to define what an important software term means, because you want to retain an advantage - I don’t care what you believe. Just because you say the sky is purple doesn’t make it so. Gross. Do better, @graylog2.
To be clear - like it or not, open source is defined by OSI. As a community we rely on it. We need it, so we can trust what liberties it grants. I’m on the side of there being a more open discussion - but just saying “we think it’s okay” is some bullshit.
You know it’s not. You wanted the non-compete part of the license more than you cared about it being open source. Own that shit. Stand up for your principles.
@webframp Ok! Basics first. F1 is a constructors sport. Each team must build its own car, from scratch. They can use listed parts, outsource some, but the design and build has to be done in house by the team.
@webframp That means the team often can build the car around the driver. They give feedback on how it feels and behaves, and the teams change and adapt over time. It also means each teams car is unique to the team.
@webframp The cars themselves have no driver aides allowed. No power steering. No traction control. If you’ve ever driven a rear wheel drive sports car with no assists, I’ll tell you: it’s difficult. You have to pay maximum attention all the time. They’re absolute monster cars.
There is a market opportunity for an alternative to k8s. You won’t “beat” it, but you don’t have to. You just have to decide to compete. Right now nobody even tries. Nomad is closest, and even their marketing is complimentary at heart.
To be clear - I’m not building one
Also, it’s not because k8s is bad. It’s because it’s such a success, the groundwork for the market is laid. People don’t question its place in the stack. They do question the implementation complexity. Operability.