For those of us who don’t like exceptions I think the concern is more that the exception might not be caught right there, so an exception may potentially transfer control to an arbitrary point above the current function in the stack.
As long as we are throwing out anecdotes, I've been doing this for 3 years and have seen successfully done it on several teams, though they were all at the same company. It absolutely can be done with the right culture.
> If you're legitimately a people manager (not a low grade 'team lead'), there is no way, no how, you could have 80% free time.
Just because you've never seen this dynamic work successfully doesn't mean that it doesn't. The best manager I've ever had operated like this. She spent most of her time coding and made sure to know what everyone on the team was up to. We were all competent professionals, so we did a perfectly fine job of prioritizing our work and working with others within the team and across teams to get things done. It helped that much of our work could easily be undertaken in parallel with strong ownership of different parts of the code by a single person, but when there were projects that required strong and frequent collaboration she just carved out a sub-team and designated a lead then trusted the lead in the same way she trusted us as individuals. Not only did this mean that we got the benefit of her very impressive technical contributions, but it also meant that we were all able to be more productive because we spent vastly less time in BS meetings.
Afterwards, I moved to a company with a more traditional structure. Ostensibly there were three people in charge of me: my engineering manager, my product manager, and my designer (since we are "design lead"). It was a pretty big culture shock. One difference is that there are a lot more junior people in my new company (the average age was around 50 in the first one), and I think younger engineers may need a firmer hand, but I'm not sure that that explains it all. I joined the first place right out of college and thrived in that environment.
I think most people don't understand just how effective a minimal management strategy can be because they've never experienced one that works well.
I meant specifically things only a manager does. For instance, the presentations he does are for director/vp level, hefty slide deck stuff.
Of course the more senior ICs do more than simply code AFA talk across teams and divisions to scope and define work, present workshops and presentations to the team and cross-departments, contribute to architecture decisions, present as SMEs across various parts of the stack, and mentor juniors. None of the ICs year on my team spend more than 80% of their time simply coding, the more senior staff spend probably more like 60-70%, and I spend about 50%.
I’ve worked at 14 companies over 23 years, from 3 Fortune 500s, to a couple mid-sized, to a bunch of smaller companies, to a handful of early stage startups. Have had probably close to 20 supervisors over this time and interfaced with dozens of other managers on related teams, and been a team lead about 5 or so times and a manager once.
I’ve never seen this dynamic play out. IME you're talking about a team lead not an actual people manager. Even in the most streamlined/simplest environments, I don’t think I’ve ever seen a people manager spend the majority of their time coding, not unless they were pushing 60+ hours doing so. Something as simple as 1-on-1s should be done at least once every week or two, and that can take up to an hour (or more counting prep) for every report.
Your mention of having multiple sups and junior heavy ICs at one place sounds dysfunctional and has little relation to any place I’ve worked at.
Those presentations to the higher levels didn’t really happen because the corporate structure was very flat. Also, I would not expect those to take up all that much time.
You may have worked at a lot of places, but your experience is still only a tiny slice of the different shops out there. My experience is likewise limited, and I acknowledge that such light touch management is probably very rare, but it can and does work.
You said she was a team lead not a real manager, which does have some truth to it, but it’s not like there was someone doing the “real” management work to pick up the slack for her. In the right environment that stuff simply isn’t needed.
> such light touch management is probably very rare
Don't be too certain about that :-) I recognize the things you mention from my first job, I had a manager / CTO who were like her. (This was a 20-30 ppl startup, high trust, not many meetings)
They need more than a simple majority to convict in the senate trial, so it seems unlikely to be successful. The best they can hope for is to force republicans to vote in favor of the insurrection and hope that is still an unpopular choice in 2022.
As a diagnosed dyslexic, this website feels nothing like what reading is like for me. It might be representative of some dyslexic experience, but certainly not mine.
> Go's standard library provides a regex library that provides certain O() guarantees, but has a significantly larger constant factor than PCRE-like regexs.
While that is true, Rust's regex library makes the same guarantees.
I'd also like to push back on the idea that perf comparisons are meaningless if one implementation has degenerate cases. Pathological behavior in a backtracking engine happens very rarely, and backtrackers typically come with features that are not supplied by O(n) engines. Someone in the PCRE camp might complain that the benchmark isn't fair because go's engine can't handle backreferences. The different approaches come with different features (backreferences vs garenteed O(n) running time), but they do have a place where their problem domains overlap. It is not useless to examine how they perform in that area.
"I'd also like to push back on the idea that perf comparisons are meaningless if one implementation has degenerate cases."
That's not what I said. I said, you can't use "X times faster" comparisons if the O() of the two algorithms in question are not more-or-less the same. That does not prevent you from still characterizing performance differences. You just can't do it via "X times faster" statements, because those are only well-defined for things separated by linear factors, and practically defined for things separated by practically linear factors. f(x) = x^2 is not "2 times bigger" than g(x) = x, or any number of "times bigger", whereas h(x) = 3x + 5 can be reasonably said to be "3 times bigger" than i(x) = x + 50, even though it is not the case that h(x) = 3i(x).
If that was your first foray into Rust land, I hope you give it another shot. I definitly struggled with fitting into the Rust programming model at first, but a few adjustments to how I code have really helped me. Some particular points which helped me are:
1. It really helped me to stop trying to force my code to be as pretty as possible the first time around.
2. If you are getting errors about a lifetime not living long enough in a complex expression, it can help to pull some part of it out into a helper let binding.
3. Adding an artificial scope (a curly block in the middle of another block) can be a great way to control the lifetime of a borrow.
4. clone() all the things! This is a major advantage that Rust has over other ball-and-chain languages like Haskell. When you get into a type-tetris situation in Haskell, you just have to find a way out. In Rust you can often just clone() something that you would rather not have to clone() and move on. I love being able to tell the borrow checker to go away while I concentrate on my program logic. Later I can always go back and fix it.
Sadly this is my third or fourth Rust foray. Only one was really successful - writing a tool to basically do 'git describe' using libgit2. That was a decent experience. I also tried to write a wrapper around libsoundio - got quite far but eventually gave up because of limitations in the Rust lifetime system, and because of how hard it is to do callbacks.
