[Robin]: I think the biggest difference between senior and junior front-end engineers isn’t whether they know the latest CSS trick or whether they know how to do one specific thing with a cool and upcoming framework. Those things can certainly help and save folks a bunch of time – but in my experience I see more senior engineers being strong in one particular aspect of the work.
The more senior folks are really good at making reduced test cases.
Wait, what the heck is that? Well, a while back Chris wrote an outstanding piece all about them:
A reduced test case is a demo/example page you create which reproduces the problem you are having with the least amount of code possible. Only the HTML needed to show the problem content. Only CSS that is related to that reduced HTML. Only the JavaScript related to the problem functionality at hand.
Reduced test cases are the absolute, no doubt about it, number one way to troubleshoot bugs.
Here’s an example of that: recently my team has been restyling the form elements of a giant and rather complex web app. We have a lot of legacy code with multiple form elements, some of which were different sizes and it was unclear exactly why one of them was breaking – our components are certainly very complex and there’s a ton of markup that adds bootstrap grid classes to each input.
With all the logic that adds class names depending on different states, I couldn’t easily pair two components together to see what the differences were between them. “Aha!” I said. Opening up CodePen, I copy and pasted the markup of the broken input into a pen and did likewise with the one that we wanted to imitate. By making this reduced test case, I could see the markup that didn’t match up right away.
I copy and pasted the classes, fixed the markup, and hurried back to the component into our codebase and fixed it right away. Boom!
Instead of doing this reduced test case, I might’ve spent hours trying to figure out which combination of classes work, and which JavaScript functions needed to be modified. I could’ve gotten lost in the other components as I tried to figure things out. But by being able to see the rendered markup side-by-side, it took me a whole minute to find the issue.
That’s the power of a reduced test case: tearing out all the things that you don’t need to think about so you can focus on the trouble at hand. Another example of this I’ve seen is when engineers quickly add background: red to an element to see how it renders on the page. This is handy as it can tell you a bunch of things; is this pseudo-element rendering on the page at all? Is this element the full width of the page, etc. etc.
In that piece, Chris continues:
Reduce, reduce, reduce! Now start stripping stuff away, periodically testing to make sure your problem is still present. Start by removing HTML so what is visible on the page is reduced down to as little as needed. Then remove any CSS that is now un-needed. Then remove any JavaScript that isn’t related to the problem. If it’s not a JavaScript problem, remove all of it (unless you think it may be JavaScript interfering with whatever the problem really is).
Deleting all of this code to find the problem helps us focus – and that’s really the difference between a senior and junior engineer: focus.
From the Blog
Three Predictions from the State of CSS 2019 Survey
Sacha Grief runs the State of CSS survey and has some thoughts about the most recent one and argues that:
- CSS still has a lot of unexplored territory (for example, a lot of folks still haven’t experimented with CSS Grid just yet).
- Functional CSS will keep gaining popularity in the near future as more folks start to play with it.
- The battle for CSS has just begun, as there isn’t a single framework, library, or methodology for writing CSS that happens to be overwhelmingly popular.
Here’s my little prediction: I don’t think there ever will be a clear-cut decision as to what the best way is to write CSS – and I hope to see more libraries, frameworks, and technologies start to compete with the ones we’re used to using.
Buddy
Automate website delivery with the fastest deployment tool ever made. Compile CSS, run Gulp tasks, bundle assets with webpack, build Docker images, and deploy to server – all on a single push to Git. We like to think of it as 15 Minutes to automation nirvana.
Different Approaches for Creating a Staggered Animation
There are lots of tiny tricks to figure out when learning about animation and staggering animations is a pretty good place to start. In this post, Daniel Benmore writes about how to do just that:
Animating elements, at its most basic, is fairly straightforward. Define the keyframes. Name the animation. Call it on an element.
But sometimes we need something a little more complex to get the right “feel” for the way things move. For example, a sound equalizer might use the same animation on each bar, but they are staggered to give the illusion of being animated independently.
Using Percy to add visual testing to a Jekyll site
Over the past couple of months, the team at Gusto has been using Percy to do visual diffing – testing if the code in a pull request has made any visual regressions on the app we’re working on and it’s superb. It makes us feel so much safer and confident that the changes we’re making will affect this one thing and this one thing only.
That’s why it’s great to see how to use Percy to a Jekyll site so that you can view changes like so:
I cannot say enough good things about Percy.
Bugherd
Spend less time discussing bugs and changes. BugHerd pins feedback and bugs directly to the page you’re working on. It’s like using sticky notes on a website. Try free today.
In this week’s Weekly Platform News: Wikipedia helps identify three slow click handlers, Google Earth comes to the web, SVG properties in CSS get more support, and what to do in the event of zombie cookies.