{28} Pseudo Selectors, TI-86 & Scrum
Featuring Kait Tremblay, Ali, Colin, Swapstack, HTML All The Things, and Mr. Steal Your Code
Dane Lyons is a startup vet with hot takes and eclectic knowledge writing for the aspiring generalist.
Design: Collaborative World Building
Kait Tremblay
Collaborative design is a fascinating topic. One of my favorite games of all time is still Minecraft. I remember playing with a group of friends and coming up with wild physics-defying ideas.
We’d collectively mine resources and contribute to the idea. But our visions were always at least slightly different. This required compromise, adaptation, and a lot of communication to arrive at something we were collectively happy with.
It’s nice to see modern design frameworks embrace a collaborative workflow. Figma and Miro are great examples that allow multiple designers to work simultaneously. I imagine game design is also moving more in the direction of collaboration. I’m just not as familiar with the tools.
Frontend: The :is Pseudo Selector
Ali
Using the :is pseudo selector nicely bundles a verbose list of selectors. I do think the more verbose format is probably easier to read/understand for contributors who aren’t CSS wizards. But I wouldn’t call the :is syntax unreadable. It’s just a new concept for a lot of people.
There are 2 alternatives:
The :not pseudo selector. If you have a particularly large list of selectors to match, it can be easier to list the selectors you don’t want to match.
.container :not(.bio){
font-size: 24px;
}
Nested CSS. While nesting is not yet widely supported by browsers, I wouldn’t be surprised to see broad support in the near future.
.container {
& h1,
& a,
& .btn {
font-size: 24px;
}
}
I don’t particularly like the “&” syntax of nesting. Hopefully, the spec changes to omit the extra “&” characters. If so, that’ll be my preferred method for bundling selectors.
Backend: TI-86
Colin
I’m surprised there is still a community of game developers hacking away on the TI-86! This was my intro to programming. I have a lot of fond memories of figuring things out without the internet to provide libraries or copy-and-paste snippets.
Kids writing code these days seem to have less resilience in problem-solving. They Google a solution as soon as they hit a wall.
Don’t get me wrong. I don’t believe there should be a right of passage requiring learning through a painful process of trial and error. Writing code should be highly accessible. A kid should be able to solve a real-world problem the first day they start writing code.
I’m frustrated because we are training the next generation to avoid hard problems. When we hit a wall, we should have the instinct to spend time thinking about it. Sometimes that process will inspire us to invent a new solution. Other times that process will help us arrive at the best available solution. Both outcomes are better than the instinct to use the first available solution.
Marketing: Swapstack
Swapstack
It’s nice to see change logs published for tools that aren’t dev-centric. I’d love to see that trend continue.
I’ll test Swapstack over the next few weeks to promote The Daily Subset. It’s nice to have access to small to mid-sized newsletters with approachable price points.
Team: Scrum Alternative
HTML All The Things & Mr. Steal Your Code
I’m not a Scrum fan. I know developers who love it, and others who hate it. I’m happy for teams that find their Scrum sprint groove. For me, it’s too formal.
I strongly prefer a simple Kanban workflow. Instead of everyone trying to break down work into 2-week chunks, members can operate at their own pace. People working on design and rapid prototypes might be working in 1-2 day cycles. People working on bigger infrastructure projects, might have 1+ month cycles.
Kanban also avoids story estimation which is one of my least favorite parts of Scrum. Investing time randomly guessing how long an ambiguous task might take…and being held accountable when you are wrong is potentially toxic. Some teams have a healthy story estimation workflow, but it seems kind of pointless to me. Instead of imagining how long something might take, just dive in and make progress.
Kanban isn’t perfect though. The todo items are often detached from an organizations North Star. If you just have a pile of things to work on without a notion of what’s important, it’s hard to make good time investments. A good Kanban process needs some notion of priority.