|
leper khan posted:always be interviewing
|
#
¿
Apr 16, 2024 15:47
|
|
|
|
| # ¿ May 10, 2024 14:37 |
|
|
The market changes from under you, in ways you'd never pick up if you're not pressure-testing your story. For a lot of years my story was "I've done a lot of tech jobs and I'm good at most of them, so my bosses always point me at their biggest problem. I honestly do not care if that's staff engineering, managing a struggling team, or building something important that's missing, as long as I'm doing it at a good company", and that absolutely does not resonate with hiring managers anymore
|
|
#
¿
Apr 16, 2024 16:56
|
|
|
Rocko Bonaparte posted:...what the hell are they looking for instead? Typing code real fast?
|
|
#
¿
Apr 16, 2024 18:15
|
|
|
thotsky posted:Auto-generated documentation rarely, if ever, document the non-obvious stuff. It's useful only in the "we're required to document stuff and this saves us time" sense.
|
|
#
¿
Apr 20, 2024 19:00
|
|
|
I think y'all got the gist of what I was saying, but I want to add this: sometimes your code can feel poorly-documented if it's really your domain that's poorly-understood (with poor documentation being one common reason that happens). As an example: if you've never worked on SSO and you're suddenly thrown into the middle of trying to diagnose a problem in an OAuth 2.0 flow, you will get very frustrated by a complete lack of comments. If you've written a basic IdP before, you'll probably follow the flow of anyone else's implementation pretty easily, comments or not, because you know what to expect even if you don't find exactly that. It's really crucial for the domain to have great documentation, and then code comments become largely hygienic: the code should map in obvious ways to the parts of the domain you've documented. (Like all outliers, document the poo poo out of the parts that don't.) Incidentally: if you try this and find you don't have a domain complex enough to be worth documenting, don't write the loving microservice. Vulture Culture fucked around with this message at 15:51 on Apr 22, 2024 |
|
#
¿
Apr 22, 2024 15:29
|
|
|
Bojack Srcmain posted:For my team, complexity comes from operating at varying degrees within our IdP. Pre-auth, during-auth, and post-auth are all things we build features around. We have tons of data points that we fetch in a request flow based on network info, a policy configuration, the IP address, user's behavior, tons of things. Thus the complexity comes in a few pieces: how do we feed these points into a system and decision on them, where do we allow varying degrees of configuration based on what clients what, and at what point/in what factors, contexts, etc do we support enforcement? In this case, the leaky domain abstractions are that a) a source of truth doesn't really exist, and b) many capabilities/properties attached to the request context are ambient rather than explicit Vulture Culture fucked around with this message at 01:15 on Apr 23, 2024 |
|
#
¿
Apr 23, 2024 01:13
|
|
|
Bojack Srcmain posted:What's a solid number of engineers to have under you as a TL whose focus is primarily writing tech designs, reviewing product docs, planning rollouts, and doing code reviews? At 5 I'm feeling a little bit spread thin as there's a near constant barrage of incoming support tickets and questions as well.
|
|
#
¿
Apr 27, 2024 19:06
|
|
|
|
| # ¿ May 10, 2024 14:37 |
|
|
Last year, I moved into a role where I was expected not to really build anything, and lead only by influence. Once I took a step back from the work I was doing on my previous team, and I looked at who my stakeholders were, I realized that for all the things I wanted to do, I needed the same people. Collaborative work is a thread synchronization problem, and if you start multitasking, and everyone starts multitasking, sooner or later you're context switching your coworkers off of your own #1 priority and onto your #2 or #3 priority. You will get better results by slowing down.
|
|
#
¿
May 1, 2024 03:57
|
|