David is a front-end developer from the UK who has been coding since 1998 when spacer gifs and blink tags were still a thing. He is a writer, speaker and coder who is passionate about moving the web forward. You can find his ramblings about this (and all things front-end) at Fed || Dead.
I recently spoke with a back-end developer friend about how many hours I spend coding or learning about code outside of work. He showed me a passage from an Uncle Bob book, "Clean Code", which compares the hours musicians spend with their instruments in preparation for a concert to developers rehearsing code to perform at work.
I like the analogy but I'm not sure I fully subscribe to it; it's that type of thinking that can cause burnout in the first place. I think it's great if you want to further your craft and broaden your skill set, but to be doing it every hour of the day isn't sustainable.
Whether you’ve just discovered BEM or are an old hand (in web terms anyway!), you probably appreciate what a useful methodology it is. If you don’t know what BEM is, I suggest you read about it on the BEM website before continuing with this post, because I’ll be using terms that assume a basic understanding of this CSS methodology.
This article aims to be useful for people who are already BEM enthusiasts and wish to use it more effectively or people who are curious to learn more about it. Now, I’m under no illusion that this is a beautiful way to name things. It’s absolutely not. One of things that put me off of adopting it for such a long time was how eye-gougingly ugly the syntax is. The designer in me didn’t want my sexy markup cluttered with dirty double-underscores and foul double-hyphens.