Around here, the month of January can only mean one thing: CodeMash. CodeMash is an annual developer conference hosted at the Kalahari Resort in Sandusky, Ohio. CQL sends a group of developers every year, and since this was my first time attending, I couldn’t wait to share some highlights from the sessions that stood out to me.
Unit Testing in Sass
When this talk was brought up at the office upon our return, the first response from a senior developer was, “How does that even work?” This was actually my first response as well. The answer is that it works by using a library called True. True allows you to write assertions that it then compares to the output of functions or mixin and returns true or false (thus the name). The best part is that the tests are written completely in Sass, so whoever writes the code can also write the tests at the same time, or even bring test driven development into Sass-land by writing the tests first. If you’d like a more in-depth breakdown, the speaker’s company wrote a fantastic blog post titled How and Why We Unit Test Our Sass. I recommend giving it a read.
We frequently work with large, multi-brand, multi-file projects that have tons of mixins interacting. We work on several of the Wolverine World Wide brands including Chaco and Merrell. This is where True unit testing would really shine.
Code Reviews: That’s a Great Idea!
Code reviews are a lot like exercise. No one is anti-code review, but they can be pretty painful. Although there may be a trend of relying more on unit testing and less on manual code reviews, those reviews are still 30% more likely to catch bugs than unit testing. Here are a few tips the speaker gave to make code reviews even more valuable:
- Review small chunks of code, 200-400 lines.
- Give specific feedback, avoid generalizing with words like ‘never’ or ‘always’.
- Create a checklist of items to look for ahead of time, including style, code clarity, and efficiency.
- Give positive feedback along with the negative. If you see something neat, point it out.
Rekindle Your Love – Avoiding Burnout in a Fast-Paced World
Being in the tech industry, I’ve heard a lot about burnout and imposter syndrome, but this talk was the first time I’ve heard them connected to one another. The speaker proposed that people who feel imposter syndrome work extra hard to hide feeling like a fraud, thus creating an imbalance between reward and stress, causing burnout. He also stated that burnout and imposter syndrome could be present in your personal life as well as your professional life. Often, the things people are passionate about are the things causing burnout, due to extra time and effort spent on them. His solution? Take some time to self-reflect and write out your top five priorities. Ask yourself: Do my current priorities match my top five priorities? Why am I living like this?
Code as Communication
This one is really more of a theme I heard throughout the conference as there were several speakers who touched on it. Developers all know to write readable code as best we can, but what if we were to follow that to its logical end? If the code becomes good enough at communicating its intent, then we can let it stand alone without comments. That’s not unheard of but getting to that point can seem impossible. Fortunately, several speakers had some great tips to get us part of the way there.
- Making readable code starts with creating understandable names. Naming is tough but there’s a lot of little rules to remember to make it simple. A good name is not too long, but not too short, uses full words instead of acronyms and is specific. Ideally, you’ll be able to tell what something does from reading the name. An example would be writing ‘salesTaxRate’ as opposed to ‘tax’.
- When reviewing or writing code, ask yourself if someone totally unrelated to this code would be able to read and understand it. If not, then see how you can improve it to make it better.
- Unit tests can have a dual purpose when reading code. They say what the code is supposed to do and double as a bug log due to generally being written in response to previous bugs.
- Refactor bad code as you see it, a little at a time.
Hearing from industry experts on up and coming trends in the technology space always gets me excited for the year ahead. I’m already looking forward to next year’s CodeMash conference!
