[Robin]: I’ve been in my fair share of meetings over the years; those that were unfocused and a bit rambling, those that were unclear about why they even needed to be meetings in the first place, or heck meetings that ended up being just plain weird. I would often leave those meetings and wonder why they felt so peculiar. Did I eff up by not writing an agenda? Was I a little unclear at the end about what everyone’s expectations were?
Meetings are important for us front-end developers and there are so many ways a meeting can go sideways that it’s worth sitting down and asking ourselves how we can improve them. So! Thankfully Sarah Drasner wrote about how to have good meetings and gosh darn is it a very good post:
It may at times feel like meetings are a drag on a software engineering process, but it doesn’t always have to feel this way. There’s something special about collaborating with a group of people who are respectful and working towards a common purpose. Good meetings can provide clarity and save people hours and days of work when they’re headed in the wrong direction. Having clear ownership, documentation, and only the right people in the room can keep many teams in lockstep, even when problems are complex.
The whole post is great because it digs into what a bad and good meeting is, but Sarah also explains how adding process to your meetings might actually make them worse in the long run:
Sometimes people use an agenda to write thoughts down before the meeting, and I would strongly suggest you steer clear of this—there’s nothing wrong with a person keeping notes for themselves for the meeting but if you come to a meeting where an agenda is locked top to bottom with material, it can sometimes shut down the collaborative aspect of the meeting—which means it shouldn’t be a meeting at all, it should just be a shared doc, to be consumed async. Part of the purpose of the meeting is the discussion itself.
Gah! That’s such an important note: meetings shouldn’t be the place where you give information to someone, but space where you can discuss the ideas and brainstorm solutions.
The best part of all this is that these notes are just a tiny bit from Sarah’s latest book called Engineering Management for the Rest of Us. And although I’m not an engineering manager (and let us all hope I never will be), I think there’s going to be so much to learn here about communication skills that I’ve found lacking in my own career.
So I couldn’t be more excited about this beautiful thing. Make sure to sign up on the website and get notified when it’s out.
GitHub Copilot
There’s been a lot of hubbub on the old vine this week when it comes to GitHub Copilot, a tool that suggests whole lines or even entire functions right inside your editor as you type. The idea is pretty simple—you make a comment at the top of the document and this fancy AI will write code based on your comment.
To see it in action is pretty bonkers:
I’ve heard a lot of positive and negative takes on Copilot, and I’ve yet to really form many of my own. To me, this seems sort of like writing another kind of abstraction: just like how writing JavaScript today is really under the hood getting compiled into a bunch of machine-legible jibberish, writing comments like this is still functionally writing code, just without the unnecessary hurdle of having to know precisely how.
Maybe that’s awful and an insult to engineers! Or maybe that’s life-changing to so many people who are interested in engineering but need better tools to get started. I have no idea! But it’s certainly very interesting.
How do you make a layout with pictures down one side of a page matched up with paragraphs on the other side?
Okay, let’s get back to CSS. Chris answers the question above from a reader where they’d like to make a layout look something like this:
See how the picture is on the left, text on the right? We can do that with just a few lines of CSS:
body {
display: grid;
grid-template-columns: 300px 1fr;
gap: 1rem
}Then with some padding, some nicer fonts, and some margin between things, we can get something working super quickly. From there we can start to work on even more complex layouts with CSS Grid.
Fixing a bug in low-resolution mode
Sometimes bugs can pop up on low-res screens and yet our dev environments might be using the fanciest HD 8K 3D Retina technology. So you need to fix that bug even though you might not be able to even see it. Well, Firefox has a setting I didn’t know about until five minutes ago called “low-resolution mode.”
Chris walks through how to use it and how low-res mode helped him fix a particularly weird bug.
Chromium spelling and grammar features
::spelling-error and ::grammar-error are two future CSS pseudo-elements that I’m pretty excited about and Delan Azabani wrote this wonderfully in-depth post about them:
The squiggly lines that indicate possible spelling or grammar errors have been a staple of word processing on computers for decades. But on the web, these indicators are powered by the browser, which doesn’t always have the information needed to place and render them most appropriately. For example, authors might want to provide their own grammar checker (placement), or tweak colors to improve contrast (rendering).
To address this, the CSS pseudo and text decoration specs have defined new pseudo-elements ::spelling-error and ::grammar-error, allowing authors to style those indicators, and new text-decoration-line values spelling-error and grammar-error, allowing authors to mark up their text with the same kind of decorations as native indicators.
What I love about this post is how something as seemingly innocuous and simple as text underlining for grammar and spelling errors is actually brilliantly complicated with problems that require a ton of expertise to think through.
System *Things
Chris writes all about one of the weirdest revelations I’ve had lately, too: the discovery of system colors. Think of these as variables that you can use but browsers and operating systems will likely render them completely differently:
body {
background: Canvas;
}
h3 {
background: ButtonFace;
color: ButtonText;
}Weird, right? Those variables will change in macOS when you switch between light and dark mode:
Chris goes on to note a ton of different system-specific ways we can style things with CSS: from colors to fonts and then emoji. I wonder how this sort of system-specific styling will expand and change over the years…
If we’re gonna criticize utility-class frameworks, let’s be fair about it
There’s a lot of criticism out there when it comes to using something like Tailwind to help you write CSS. Utility-class frameworks will often lead you to writing markup that looks something like this:
<button class="hover:bg-light-blue-200 hover:text-light-blue-800 group flex items-center rounded-md bg-light-blue-100 text-light-blue-600 text-sm font-medium px-4 py-2">Those classes sure can stack up quickly and make things pretty hard to read after a short period of time. But I guess if you and your team can learn to write code like this, then good on you. I won’t fight you to the death about approaches to CSS.
Personally, I think a combination of utility class and component design is the way forward. (This is also because I like fighting with everyone, at all times, about every little thing.) Let’s say you make a component and now want to change it just a bit, perhaps align the text to the right. That’s where tiny utility-class framework stuff shines in my opinion.
But as the only approach to building sites? Mmmmmm… I’m not so sure.
However, Chris argues that some of that criticism in the community is kinda unfair:
Another unfair criticism I hear in conversation about utility frameworks is that you ship way more CSS with them. If you are, then you’re definitely screwing up. In my mind, the main point of this approach is shipping less CSS (only the classes you use). I’m the first to tell you that a build process that accurately and perfectly does this is tricky and could lead to an unhealthy amount of technical debt, but I’ll cede that if you do it right, shipping less CSS is good for performance. Tailwind in particular highly encourages and helps you do this.
Sponsor
How to Monitor and Optimize Core Web Vitals
This on-demand webinar runs through the fundamentals of monitoring Core Web Vitals and provides actionable techniques to manage and improve them across your own website.
Watch it on-demand, and take control of your CWVs today!
Sponsor
I’ve got one question about Jetpack for you.
And it’s for those of you who don’t use it on your WordPress site. I’m running a one-question survey to find out why you’re not using it. We’re big fans of it at CSS-Tricks, and Automattic (maker of Jetpack) sponsors the site. But I know some folks are hesitant or just plain resistant to using it. We want to find out why and your answer will help us out!
[Chris]: I love seeing a new technological magic drop as much as the next person. The huge one everyone was talking about last week was GitHub Copilot.
We’re already used to some degree of “typeahead” or “IntelliSense” features in code editors, that help us make smart choices on what the next word or two in code is likely to be. I type <d in HTML and a smart editor will help me pick from a list of HTML tags that start with d. I type color: in CSS and a smart code editor will give me a list of known or useful colors to pick from. TypeScript users are used to calling a function and having it help you choose correct parameters for it.
I’ve seen this taken a bit further by companies like Tabnine who do more robust completions based on “AI.” I’ve had Tabnine installed for months and I like it just enough to keep it there (one big annoyance is that it’s always at the top of the autocomplete list when sometimes I prefer the built-in autocompletion, like when you start typing a new component usage and the built-in auto-complete automatically imports it for you—that’s better than autocomplete alone).
GitHub Copilot takes it much further than any of this, offering to prefill sometimes a dozen lines of code or more based on what it thinks you’re trying to do. At its best, it’s incredible time-saving genius. You’re still responsible for your code, of course, and it’s proven that the code you’re given can be sloppy and, for example, give you a SQL/HTML injection security hole. At its worst, I’m sure it’s capable of really gnarly insidious bugs that make it through pull requests that were written by a developer who was phoning it in extra hard that day and letting AI do their job.
I mentioned magic at the top here because I’m not actually that mesmerized by the GitHub Copilot magic. I’ve seen enough of this machine-learning-trained stuff now that, while it still feels both impressive and scary, it doesn’t feel quite magical. You give a computer a billion samples and tell it to learn from them, and well, I guess I expect computers to be able to do that.
That might be a little jaded. Maybe just because the training set for GitHub Copilot was basically every line of open source code on GitHub and text feels like training data I can wrap my brain around. When machine learning/AI is applied to other things it does start to feel more magical to me (and even scarier).
Have you seen Brickit?
You literally dump out your box of totally random LEGOs and it figures out what you have and suggests brand new models for things you can build with them. WHAATTTT. Check a user video. Jason also called the process “magical” to describe it:
My kids have approximately a billion Legos at my house, so I downloaded Brickit to try it out. The process is a little slow and you need to do a little bit of pre-sorting (by taking out the big pieces and spreading your pile out evenly), but watching the app do its thing is kinda magical.
I’m sure there is all sorts of ML going on there, but it feels like multiple layers of ML applied to data that I don’t quite understand that makes it feel magical.
Even without a lick of ML/AI, there is plenty of magic in web tech to be found. This Fluid Paint canvas absolutely blows my mind.
It’s so fast! It looks like real paint! How? Oh, I can just look at the source code. JavaScript, naturally.
