One reason I withdrew a bit from the JavaScript Community® and chose to reinvest in Rails was that front-end frameworks and tooling became dominated by megacorps whose DevRel people convinced everyone that EVERY team should adopt solutions designed for Google or Facebook scale. twitter.com/jasoncwarner/s…
So years ago, I made slick carousel (which I’m not even allowed to work on anymore). It was egregiously successful. Tbh, I was embarrassed being the jquery carousel guy. I spent years trying to make more complex things to prove myself as a real engineer. That was a mistake.
When I talk about frontend's lost decade, it's because folks don't grok how long the excesses of 2012-2022 JS "thought leadership" will continue polluting the ecosystem. The UX disaster is radiating from an earthquake of hubris to distant shores like a tsunami of derp. twitter.com/i/web/status/1…
Hiring in 2021: Founder: "We're hiring engineers. Must have 15+ years of machine learning experience. PhD in comp sci and an MBA from a top school is ideal. Level 5 security clearance is also a must-have." Me: "Wow, what's the product?" Founder: "We're making a recipe app."
Wow, they did it. They actually shipped another React major version without proper HTML or DOM support. It truly is legacy software with unfixable bugs: dev.to/bennypowers/wh…
A bit of a catch-22: each time someone explains part of git to me, they have to introduce 3-4 new terms I'm not familiar with in order to explain the term I asked about. Did this all come naturally to the rest of you or is it true that most of us really only understand 5% of it? twitter.com/mattwensing/st…
I’m going to make a new website for my lab. How hard could that be? I’ll use Jekyll. To get Jekyll I need to update Ruby. To update Ruby I need to update homebrew. Homebrew update fails.
I've written a whole book on advanced metaprogramming techniques and I still can't do a git merge without feeling like I'm programming a VCR from the 90s, screwing it up, and somehow setting the TV on fire
Git
Now let's change the subject. Or. Let's *broaden* the subject: What current method *would* I use? None of them. Let's talk about why there are no extant software development methods that reliably lead to optimal software development.
- I love this thread because it advocates two of my strongest beliefs - interpersonal relationships are important, and most of the time, extensive process and structure are a band-aid over a different underlying issue.
- "If your relationships were those things, you wouldn't need much method. And if your relationships aren't, structures, artifacts, rules, procedures, all of these things are usually neutral or even net-negative in impact on those relationships."
- "You will not get optimum software development by emphasizing hierarchical command and control"
- "All happy software engineering teams are alike"
- "They (current systems) focus their attention and their reasoning almost entirely around "process": structure, artifacts, rules, forms, procedures"
What’s it called when your job is fixing something, but if you succeed and permanently fix the thing you’ll have no job, so your job is functionally to make it look like you’re trying hard to fix a pervasive, eternal problem (so you’re eternally employed)?
When you setup Kubernetes to host your personal blog pic.twitter.com/dbjqzbINnB