Adopt

https://www.thoughtworks.com/radar/techniques/platform-engineering-product-teams are what I have been encouraging IT to do for years. Push management of runtime environment of applications onto teams and encourage them to develop their own on-team expertise for this (devops). IT can split a team away from typical "Help Desk"-related tasks and have a team dedicated to taking care of things like networking, cloud enablement, providing VMs or a self-signup environment to devs, provide "consulting" to teams to help them solve challenging problems and provide security guidelines. Work with teams to understand their current and future needs and try to get in front of some of those needs for a just-in-time delivery of important IT-related functions.
https://www.thoughtworks.com/radar/techniques/design-systems are fantastic and would hugely help engineering-heavy teams make their applications look better, have reasonable UX, and just generally shine compared to what they would do on their own. This is a great way to "scale" a smaller UI/UX team to have larger, organizational impact. In order for them to be successful though, building the design system is not enough. They need to socialize it, make it easily accessible, and advocate for its use and growth. Over time teams will see the value in consuming it and contribute their experiences and needs back to the main UI/UX team building it.
https://www.thoughtworks.com/radar/techniques/api-expand-contract I've never been a fan of any versioning scheme in REST APIs. Prepending versions onto an API is ugly and frequently only ends up being /v1/ for its entire life, even with deprecated routes underneath it. Other versioning schemes like accepts headers and the like I have never seen used in practice. This sounds much better and aligns more with my experience.
https://www.thoughtworks.com/radar/tools/sentry The lone tool in the "adopt" column this year, Sentry is what I recommended in my Node best practice document and is my go-to as well for bug tracking.

Trial

https://www.thoughtworks.com/radar/techniques/distroless-docker-images This really piques my interest.
https://www.thoughtworks.com/radar/techniques/ethical-explorer is also intriguing. Would make for interesting discussion in a team retrospective or other team-building exercise.
https://www.thoughtworks.com/radar/tools/esbuild has come up on my own personal radar a few times over the past month. Will have to keep this in mind. For my website I'm using postcss which doesn't do javascript building/bundling so if I ever need to do that I'll likely try this out.
https://www.thoughtworks.com/radar/languages-and-frameworks/swr is a client-side http fetching library with a "Stale While Revalidate" caching strategy baked in. I had never seen this library before but it looks interesting! I have been away from React for a while and haven't built anything with hooks yet, but I'll have to keep this one in mind when the time comes.
https://www.thoughtworks.com/radar/techniques/lightweight-approach-to-rfcs It is unclear to me what they are comparing lightweight RFCs to. One would assume "Heavyweight" RFCs, but they don't provide any description or elaboration on what this is like and what to avoid. At work, we have begun to try out "Architecture Decision Records" in an attempt to capture some of this tribal knowledge they are alluding to in this blip. I would relish the opportunity to expand that further into an RFCs model for cross-team collaboration on best-practices and technology adoption, but it's still early days for this sort of collaboration for us. I'm going to continue to encourage the use of ADRs in greenfield applications, and for the meantime will be advocating for simply documenting designs on our internal wiki and sharing them out to folks on other teams that may have some expertise on a given subject. That, along with making those wiki pages public within the company, I'm hoping will usher in more of a documentation culture and collaboration that, I hope, will lead to the sort of RFC process being described here.
https://www.thoughtworks.com/radar/techniques/hypothesis-driven-legacy-renovation On my team at work, we do this a lot. I will elaborate some on an example. We had a legacy API that had recently been adapted to accept events from Salesforce's Outbound Message Queue and save them to a database. This API performs many other tasks, but has largely been stable for years. At times, our Sales team would run mass updates to Salesforce, creating a torrent of events that barraged the API and bog it down for hours. Each time we would sit down afterwards for a Postmortem to discuss what went wrong and how we might improve the system to avoid this, but most of our early improvements didn't yield the results we needed. We ended up turning this into a project, for someone to really dig in, do some deeper performance analysis, and provide some hypotheses as to the root cause of the problem. We then regrouped as a team, reviewed the hypotheses, and decided on which actions we wanted to take to test them. It was a great team-building experience, and gave that individual a chance to own something important to the team, drive the discussion, and perform the experiments. Overall I recommend this approach!

Assess

https://www.thoughtworks.com/radar/techniques/privacy-focused-web-analytics This was something I looked into when I built out my blog. Netlify actually offers server-side analytics, which requires no tracking on the frontend. I don't know how robust this is compared to client-side (for example I doubt you can track something like a sales funnel this way), for my purposes I was happy with it and glad that it didn't require client-side shenanigans.
https://www.thoughtworks.com/radar/tools/buildah-and-podman is something I've been thinking about too. While Docker has been serving our needs well over the past several years, I want to better understand why people are adopting alternative tooling for this. Am I missing out?
https://www.thoughtworks.com/radar/tools/github-actions The other day it occurred to me that github actions has completely supplanted my need for Travis CI. I love the ease of use of Github Actions and will definitely be using it on all of my open source projects moving forward.
https://www.thoughtworks.com/radar/platforms/kafka-api-without-kafka I've got an article in my backlog to read about this subject. I have never personally used Kafka, but I read up on it here and there and work to develop a mental model of where Kafka would be a good fit architecturally. This concept of using Kafka without Zookeeper is relieving to hear about, though, because it's my understanding that Zookeeper is a bear to operate.
https://www.thoughtworks.com/radar/languages-and-frameworks/react-hook-form I had never heard of. It is a form library that is built with react-hooks in mind. Want to keep an eye on this for the next time I'm working with React forms!

Hold

https://www.thoughtworks.com/radar/techniques/ticket-driven-platform-operating-models nods furiously
https://www.thoughtworks.com/radar/tools/aws-codepipeline surprised to see an AWS service in the hold category. Will have to keep this in mind.
https://www.thoughtworks.com/radar/techniques/gitops I was surprised to see this on the hold list, but their explanation made sense. At work we use git to store our infrastructure as Ansible playbooks, and the different environments are represented as separate inventories you can apply a single deployment playbook to. This helps us avoid the drift problem and makes us think very carefully about when and where we have our environments differ from one another. It is also the "painful path" to diverge using this model, which is a good thing!
https://www.thoughtworks.com/radar/techniques/peer-review-equals-pull-request hits particularly close to home for me. I have been advocating for a long time the need to adapt code review to the work being done. In some cases, a Pull Request is fine, sure. But often what is needed is a pairing session, a Q&A session, a show and share, or a cross-team feedback gathering session. It's important for engineers to develop a level of confidence in their work to be able to accept criticism, be willing to go back to the drawing board when their design or solution has clear issues. They should seek out these experiences, and not settle for rubber stamp PRs when they are working on something that is particularly complicated or has lingering questions. It's also so critical for junior engineers to have mentorship. Everyone learns differently, and teams need to take into consideration that the way they normally provide each other feedback may not work for an engineer that is just getting started out in their career.
https://www.thoughtworks.com/radar/techniques/separate-code-and-pipeline-ownership please please please don't build out a siloed devops team that is managing builds and deployments. This is awful and a bastardization of what devops is meant to stand for.

chadxz / personal-website

highlights from the ThoughtWorks Technology Radar Volume 24 #18

Adopt

Trial

Assess

Hold