[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:
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!
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:
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
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.
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.
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.
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.
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.