Thanks for sharing Zach! I like the overall arch of teaching in this one. For me, as a coarse takeaway, that was "What is structuralism, and some reason to care."
Criticisms:
The graph containing "We are, perhaps, uniquely qualified" is problematic. I don't know who "We" is. Unless you've pinned it down loudly and explicitly elsewhere, I think it's too loose. (Coders? Architects? Managers? Engineers who love theory? Exactly people with CS degrees? Exactly the people who read your work?) It also comes across as patting ourselves -- whoever that is heheheh -- on the back and therefore is slightly unseemly. Maybe the entire graph could be deleted and it'd be an overall improvement. This is minor overall though -- it doesn't harm understanding other than possible confusion around who is "we", and even that's not a biggie. That said, I wonder if there's an opportunity here to drop this graph and shore up a stronger and clearer PoV for how different groups of folks with different backgrounds may come to experience structuralism.
"If our team is full of frontend developers, our frontend will be full of business logic." This makes me want to stand up for frontend developers who are also good overall designers. I can easily imagine a frontend team who would still do the decoupling because they'd view it as good practice. I can't tell how much of a throwaway statement this was for you, however, it may be limiting the reader's understanding of your point. How should I be analyzing your imagined team of frontend developers who don't decouple? Is that bad, and so what? (Also, are you OK with pissing off readers who have a specialty in FE work!? heh)
The treatment of the surface/depth opposites along with women in our industry being "pushed towards frontend roles" is interesting and controversial to me. I wondered for a moment how coincidental it was to write about the original surface/depth spectrum then later talk about buying makeup. But then it seemed clear there was zero coincidence. The lines of thought here are confusing to me... On the first reading I wasn't sure how much I should be thinking about structuralism as a core concept versus being concerned with analyzing sexism and stereotyping in tech. After a second reading, I realize you did use the phrase for instance in there. So then I found it reasonable to assume the former focus -- structuralism -- is by far primary. Either way I found it interesting writing, but perhaps it could use better directives for me the reader. (I vaguely recall commenting on this a long time ago. Apologies if I'm repeating myself. Also, apologies if I'm contradicting my past self haha.)
Thanks for sharing Zach! I like the overall arch of teaching in this one. For me, as a coarse takeaway, that was "What is structuralism, and some reason to care."
Criticisms:
The graph containing "We are, perhaps, uniquely qualified" is problematic. I don't know who "We" is. Unless you've pinned it down loudly and explicitly elsewhere, I think it's too loose. (Coders? Architects? Managers? Engineers who love theory? Exactly people with CS degrees? Exactly the people who read your work?) It also comes across as patting ourselves -- whoever that is heheheh -- on the back and therefore is slightly unseemly. Maybe the entire graph could be deleted and it'd be an overall improvement. This is minor overall though -- it doesn't harm understanding other than possible confusion around who is "we", and even that's not a biggie. That said, I wonder if there's an opportunity here to drop this graph and shore up a stronger and clearer PoV for how different groups of folks with different backgrounds may come to experience structuralism.
"If our team is full of frontend developers, our frontend will be full of business logic." This makes me want to stand up for frontend developers who are also good overall designers. I can easily imagine a frontend team who would still do the decoupling because they'd view it as good practice. I can't tell how much of a throwaway statement this was for you, however, it may be limiting the reader's understanding of your point. How should I be analyzing your imagined team of frontend developers who don't decouple? Is that bad, and so what? (Also, are you OK with pissing off readers who have a specialty in FE work!? heh)
The treatment of the surface/depth opposites along with women in our industry being "pushed towards frontend roles" is interesting and controversial to me. I wondered for a moment how coincidental it was to write about the original surface/depth spectrum then later talk about buying makeup. But then it seemed clear there was zero coincidence. The lines of thought here are confusing to me... On the first reading I wasn't sure how much I should be thinking about structuralism as a core concept versus being concerned with analyzing sexism and stereotyping in tech. After a second reading, I realize you did use the phrase for instance in there. So then I found it reasonable to assume the former focus -- structuralism -- is by far primary. Either way I found it interesting writing, but perhaps it could use better directives for me the reader. (I vaguely recall commenting on this a long time ago. Apologies if I'm repeating myself. Also, apologies if I'm contradicting my past self haha.)