Datapoint: as someone who lives in a small apartment without room for two machines, the combined washer/dryers are wonderful for me. I'm on board with the initial article, but it made me realize that enshittification is relative - to some people, the "unnecessary features" are actually useful. Maybe enshittification is actually a lesson on how to slice a product into different product lines?
You're welcome! I stumbled across it by coincidence today and had an epiphany, "Whoa, forget DeFi - it never occurred to me how important decentralized archiving is. What if archive.org goes down? How would we rebuild?" Thanks for making this!
The idea is to write your environment in Starlark (a minimal Python subset) and we'll handle running it on Docker or Kubernetes for you.
We started with "reduce Kubernetes complexity" so we don't yet have the full Kubernetes ejection seat, but we're slowly marching towards it - feedback welcome!
How would you feel if you could use Starlark (if you're familiar with it) to parameterize a la Helm, and then can add more Starlark commande later to update previously-defined infra a la Kustomize?
Full disclosure: our startup is trying to build a tool where you don't have to pick, so trying to test the hypothesis
Big +1. We switched to Starlark for our DSL last year and have been very pleased. Users who've never used Starlark before come in with some 'what, another language?' trepidation, and end up pleasantly surprised.
I do think there's a power to the readability that makes it more approachable (but which eventually burns you). We were rewriting our AST at Kurtosis last year, and the default choice we were going to go with was of course YAML. But we came across a Github issue from DroneCI (who also started with YAML) that said something like, "we started with YAML, and we learned that you always eventually want to add more complex lotic on top. Go with a Turing-complete language to begin with, else you'll be in the CircleCI trap inventing a language via YAML DSL."
We decided to go with Starlark as the base language for our DSL, and we've had a consistently great experience. Users report that it's very approachable, and the starlark-go library is very pleaeant to deal with.
For me, one of the true advancements of JSON/YAML over XML is how its features are orthogonal to each other
I don't have to ask "should this be a tag property, or a subtag"?
Which, to your point, isn't to say that YAML is "good", but I think there was at least an advancement through minimalism.
Right tool for the job. I think XML is too much tool for most jobs, but there's a huge gap between JSON/YAML and XML, so in 99% of cases I'd rather err on the "too much" side.
Viewpoint as someone whose primary job right now is recruiting: my observation on what differentiates Fine software engineers from Great ones is how they understand the problem, engage with it, and go get what they need to solve it. Fine software engineers need to have the problem pre-digested; Great ones can take ambiguous problems, figure out what's missing, and hunt it down.
I don't see the author's withholding of all problem parameters as tricky at all, but an attempt to accurately mimic the ambiguities of the real world to see what the candidate does with it.
I do interviews for my team, and I'm very aware that framing questions the wrong way quickly leads people into the trappings of their own obsessions. Be that a need for optimising the wrong things (e.g. optimising minute but easy to optimise logic next to large, network-heavy calls), or assuming the wrong perspective on a task (e.g. getting tasked with an accidentally math-heavy problem, and assuming it's about solving the math instead of their overall approach to new requirements) or simply lacking the confidence to question obvious problems in the task they were given. Interviewing is a stressful to downright dehumanising process that is hard to get right, even with years of experience.
Big +1 to "there are no off-hand requests"; this was a failure that I realized I was making as a leader a month ago. I was (ostensibly) trying to give my team ownership, blasting them with the multiple things that needed doing, but in practice I was pushing the stress of "what should they be working on in any given moment" to them.
It's a sneaky trap, because you think "I'm making them so empowered!" but you're actually stressing them out and reducing their focus.
> It's a sneaky trap, because you think "I'm making them so empowered!" but you're actually stressing them out and reducing their focus.
As a head's up, the even sneakier trap is that different team members thrive best with different approaches. Some people flail and fret without explicit, procedural direction and others are completely discouraged by it and do feel disempowered.
Rather than taking your lesson as the New Universal Rule, make sure to just add it to your toolbox while trying to learn how to discern who needs what. It's good that you're learning to work better with the people who need more explicit direction, but you're going to burn out managing a team where all of them need that all the time (and if you only practice one approach, you'll eventually get there: filtering down to only have those team members who do thrive by it)
Yup. As a team lead, I fretted that I wasn't giving me one of my new team members enough hands-on time / direction. I'd sort of give him stuff with as much context as I had, meaning to follow up in a few days to see how things were going, but never got around to it.
I later got feedback from my manager that my teammate really appreciated that I was giving him space to figure things out on his own rather than micro-managing him!
I think I do my best work when it's something no one asked for in the first place. I also do great work when I have a good back-and-forth to clarify requirements until I know exactly what we're going for. Where I get discouraged is when I get half-baked requirements, carefully consider the problem and provide a best effort solution, then get clarification that would have been great to know up front, now requiring a re-think.
Two different points. He's saying not to be one of those but as a leader, you will have to lead those. Some people are just not great at interpreting context and your job will be to spoon feed it.
When you give someone the power to decide what to do, they also have to be empowered to know the deadlines and costs of not doing each. They have to be trusted to make the right decisions - which often includes deciding not to do something - if you are not willing to back their decision when things are not done then you shouldn't have given them the authority in the first place.
Good that you realized it. Far too many managers have the impulse control of a puppy that just had a double espresso. Every hour a new task that "has priority".
