HTML+CSS dev vs JS-first dev Discourse MUST take into account how gender & seniority intersect or they WILL be harmful.

The divide between how senior women engs frame it and how newer women frame this is NOT a coincidence, and is ESSENTIAL to understanding the debate.

Thread. If someone is a front-end specialist or a full-stack engineer with non-BS front-end skills, and they've been in the field 7 or more years, they probably learned front-end a) informally, and b) HTML- and CSS-first.

Today's #RealWorldCode livestream, where we worked to remediate outage-inducing IO overload on a production database, left me surprisingly emotional.

So I'm gonna thread about inclusion, formal & informal dev education, and performance work. Performance work is, hands-down, the single most impostor-syndrome-inducing area of development work I do. I'm pretty good at remediating perf issues within normal business applications, but it's hard to remember that.

Because of how perf work has traditionally been taught.

Lately a few cishet women have asked me, "what's the problem with wanting a women-only space, given that nonbinary folks aren't women?"

This framing ignores two things:

- identities != access needs
- strict gender binaries are structurally queerphobic

Gonna thread! Three things actually: the third is that unless an organization is actively trying to handle resource constraints anti-oppressively, these resource constraints will lead to inequitable distribution of resources.

Wanna expand on this a bit. When I worked in my first ever inclusive, non-microaggressive tech job, my professional growth TOOK OFF. I'd been a pretty solid senior engineer before that place, but it turned me into a Technical Leader.

Gonna thread on why/how.

https://twitter.com/betsythemuffin/status/1075531795804971009

1. Trustworthy feedback. In non-inclusive workplaces, receiving feedback means sorting through reality vs stereotype. Even well-intentioned feedback is filtered through iffy language ("abrasive," "under-confident," etc) - figuring out where you need to grow becomes a lot of work!

There's a thin line between telling folks that programming skill often matters less than team skills, product sense, & grit -- which is usually true --

and telling them programming skill *doesn't matter*, which is such a transparent lie that no one believes it. We've created a world in which we try to tear down the false idol of "CS fundamentals" by asserting that team skills, product sense, and grit all matter more -- but that doesn't actually change people's minds about whether "CS fundamentals" == "programming skill."

I've been thinking a lot about domain-oriented OO vs pattern-oriented OO because domain-oriented OO is usually thought of as "unteachable," and that fact showcases the way developer education is broken.

External Tweet loading...
If nothing shows, it may have been deleted
by @betsythemuffin view original on Twitter

Domain-oriented OO is hard for current dev education paradigms for two reasons:

1. It is a subjective craft. Subjective crafts require art-school techniques, not "here's how pointers work."
2. It is not about building a static artifact. It is about building team understanding.

There are two styles of object-oriented programming: domain-oriented and pattern-oriented. Both have their place. Practical OO is about resolving the tension between them.

Domain-oriented OO leads us to code beautiful unique snowflakes. Sometimes this is great! Sometimes... no. Pattern-oriented OO: Models, Views, Controllers. Presenters. Workflows. Delegators. Facades. Query Objects. All code has a box; find the right one.

Domain-oriented OO: What are the nouns in this business problem space? What are the verbs?

Underrated programming techniques: name something (a step definitions file, a class, a directory, whatever....) "junk drawer."

Not "util" or something else that kind-of means "junk drawer" but pretends to dignity.

Be bold. Admit what you're doing. Do it with joy. Calling it a "junk drawer" tells us the following:

1. If you can find stuff, there's not too much stuff in it.
2. If you have a sudden insight as to where something in it ought to go, move it there!
3. If you can't find stuff, do the bare minimum to organize & move on.

unpopular Ruby/Rails opinions: "better object decomposition" is not necessarily related to test speed. In fact, many test-speed-optimizing design patterns have damaged our ability to write good OO Ruby as a community. We optimize for test speed because slow tests are measurable, annoying, disruptive to our ability to socialize TDD as a practice, and much easier to fix than engaging with the subjective complexities of object-oriented design.

We conflate test speed and OO to rationalize this.

I want "simple mfing websites" back too, but the way to get them back is web standards evangelism, not javascript-bashing. best way to kill webpack is to promote HTTP/2 + <script type="module"> ... & seeing that comes from knowing the problem webpack solves