I can't say ADRs work that great, in my experience, but the flaw was more connecting them to other architectural stuff to make them actually discoverable and drawing the boundaries in a logical way (what goes into an ADR and what goes into a living design doc?).
"Not maintained" seems kinda weird to me, because at least as I see an ADR, it's like a point in time decision right? "In this situation, we looked at these options, and chose this for these reasons". You don't go back and update it. If you're making a big change, you make a new ADR with your new reasons.
One place I worked did have an interesting idea of basically forcing (not quite) the new hires to take notes on all their onboarding questions/answers as they went and then sticking it in the company docs. It at least meant that incorrect onboarding docs got fixed quickly. Sometimes you had good reasons for stuff, sometimes the reason is "dunno, that's just what we do and it seems hard to change".
Willing to relocate: Yes (for US companies, I'm a licensed P.Eng so I should be eligible for a TN visa under USMCA/NAFTA - I understand there's much less overhead with that compared to others)
Hi folks, I'm Matt. About 7 years of experience working at the interface between data science and backend development. My most recent work has been around optimization of grid-scale energy storage systems - I was the technical lead for the team's first go-live in the ERCOT power market. A lot of experience taking something functional but bespoke (think e.g. a Jupyter notebook from a DS researcher) and applying rigorous software engineering principles to make it modular/scalable/maintainable, and dealing with the problems that result from applying machine learning in the real world (e.g. robustness to forecast error).
Primarily experienced in Python but I've learned a lot of languages at this point and don't mind learning new tools that fit that job.
Not afraid to get my hands dirty deep in the guts of algorithms/statistics/mathematics, my background is in electrical engineering with some signal processing experience. I've got years of math skills crying out to be used!
I'm looking for a role that lets me sink my teeth into challenging problems - some kind of math/statistical analysis/optimization/algorithmic bent would be ideal, I get a great kick out of testing out cutting edge new libraries, implementing an algorithm from a new research paper, that kind of thing.
Would love to connect, even if just for networking.
I'm not them but I suspect they mean a kind of "above my paygrade/not my problem" tendency. You can defer almost indefinitely (or make other people do it for you) a lot complicated work with phrases like "we need senior/staff buy-in on the design", "I think we need XYZ team on board/cross-team management approval", "maybe the cloud platform team should be building this, not us?", "I told the architect our requirements and they'll get back to us once they makes a design".
i.e. stop using your own brain and tell the people above you they need to make the hard decisions. Especially because so many decisions technically have impacts beyond your own team, its hard for people to push back on such behaviour.
"Not maintained" seems kinda weird to me, because at least as I see an ADR, it's like a point in time decision right? "In this situation, we looked at these options, and chose this for these reasons". You don't go back and update it. If you're making a big change, you make a new ADR with your new reasons.
One place I worked did have an interesting idea of basically forcing (not quite) the new hires to take notes on all their onboarding questions/answers as they went and then sticking it in the company docs. It at least meant that incorrect onboarding docs got fixed quickly. Sometimes you had good reasons for stuff, sometimes the reason is "dunno, that's just what we do and it seems hard to change".