So… gameday, huh?!
Most of the time it’s really fun to work on a team where the others are in general way more fullstack-y than me. It means that my skills are more rare than they’d otherwise be, and that becomes valued. There is also a ridiculously vast amount of stuff I could potentially learn, it will never this decade become boring for me to work on these applications.
But I am techically the odd one out in a group of 30+ developers. It’s mostly fine and I’m very comfortable with knowing different things that the others. I happily ask questions all the time, and this is not an impostor syndrome type situation. But sometimes the team activities can be really alienating for me. Especially if it’s something that is supposed to be fun, while I struggle to follow and just end up feeling like an idiot all day.
We have a day like this coming up now, so now I’m trying to actively take steps upfront:
- to not feel alienated and clueless
- to learn something new (hey, notes!)
- to get something constructive out of participating
Okay. Let’s read Fault Injection in Production – Making the case for resilience testing and make some notes and see if I get any wiser:
how fault tolerance and graceful degradation can be brought to computer systems
To make sure that the resilience built into Etsy systems is sound and that the systems behave as expected, we have to see the failures being tolerated in production.
Hm. Which failures are we actually talking about?! 🤔 Specific kinds of failures? Or just any types of failures? I have no clue and it’s probably contributing to increase my level of feeling clueless.
graceful degradation
I’m familiar with the concept and used to thinking about when it comes to browser support. Not sure how that translates now though. Is it very different? Or quite the same?
- Unit testing of components
- Functional testing of integrations
Yeah, I don’t have any understanding of the difference between those two. But I get the part about how we do this before we put our applications in production. Then we use monitoring and logging to confirm that our apps are behaving.
This also makes sense for me: our systems are complex, it’s impossible to count on updated descriptions of our systems, a QA environment will never be complete — making faults happen in production is useful.
testing outside of production is a very proper approach, it's incomplete because some behaviors can be seen only in production
another option must be added to the confidence-gaining arsenal: fault injection exercises sometimes referred to as GameDay
Oh. A goal of the GameDay is to “gain confidence”… 🙈 So far it’s doing the opposite for me, but the week is not over yet. But okay, I guess this has some UI and UX implications. Everything from 404-pages and error messages — to how long a loading spinner spins before it gives up to make way for some other information to the user.
The chapter contains a case from Etsy about a payment system, and reading it sort of makes it more clear for me what types of failures we’re talking about. Basically all of the stuff I never work on and don’t really know a lot about. 😕
👽
Update after gameday: I learnt something, maybe? These preparations helped a bit, but I hadn’t done enough to be able to contribute with anything useful. So still very much an alien.