This is a story about things we learned on our journey through the past few years, how we managed to become better at what we love. It’s a long read and there’s no TL; DR.
Thing is, there’s a lot of good and bad advice out there that newcomers take for granted.
We’ve been reading a lot of articles revolving around front-end development lately. Some of them are great, others are outright ridiculous.
Thing is, there’s a lot of good and bad advice out there that newcomers take for granted. Last month I recollect reading an article that recommended PNG sprites. Who uses PNG sprites anymore, except for fallback? Yes, there are edge cases and SVG can have a big performance impact if used improperly. But, why would you use a decade old technique when in today’s world you have to support multiple resolutions and pixel densities?
Another article explained the revelation from switching from icon fonts to SVGs. We’ve been using SVG for the past 2 years. We never used icon fonts. (We tried but we stumbled on weird issues with Android that couldn’t be reliably solved). SVGs are way more flexible than icon fonts and so much easier to maintain.
My point is, take everything you read with a grain of salt. See if it fits your workflow, then test the hell out of it using a real project, with real data. We acknowledge that we don’t know everything and that also some of the work we do might not be top notch. We’re all learning new stuff every day.
Our latest project is the best project we’ve ever written.
I’m not going to tell you how you should write your code. I’m telling you to periodically re-evaluate your code and try to improve it. Create your own style. See what works for you.
I’ve met a lot of coders that told me they don’t have time to change the way they work, because they are always too busy. That’s same as saying: “I don’t have time to put gasoline into my car’s tank”. Eventually you’ll run out of gas.
We book a few days from every project, to improve the tools we’re using and the way we code. We sit around the office and discuss problems that arose in our previous projects and see if we can fix them. This time is budgeted and paid by the current project. We always end up tweaking our process here and there. That’s why, our latest project is the best project we’ve ever written.
Naming is monumentally important for your project’s success.
Looking back and seeing how we wrote our CSS a few years ago, I can’t help giggling. “What on earth were we thinking?”.
You might laugh, but when writing CSS, naming is the most difficult part. Naming is monumentally important for your project’s success.
Two years ago, we stumbled upon Harry Roberts article, “MindBEMding”. It was an absolute game changer for us. Since then, we’ve became huge fans of BEM and spent lots of time adapting it to our needs. You should also read the follow up “BEMMIT”, Chainable BEM modifiers by Jordan Lewis. They’ll blew your mind.
These guys are the real pioneers and they changed the way we write our code.
CSS is the actual language, preprocessors are tools.
Wenever jumped onto the SASS train from the start. Most people forget that CSS is the actual language. Preprocessors like LESS/SASS/Stylus are just the tools. If you don’t master CSS first, you can’t possibly write good, maintainable CSS. Regardless of the tools you’re using.
Stylus got picked in the end, because it actually allowed us to write CSS. (Edit: SCSS is comparable to Stylus nowadays). Our BEM syntax kept our code clean and the extra flexibility Stylus provided was worth it. When we’re writing in Stylus, we’re using the same old CSS syntax. We keep all colons, semicolons and accolades. We minimize the usage of mixins and use extends sparingly. Stylus is just the tool, not the language.
Be insane when it comes on how you write your own code.
The way you write your code is where everything starts. This is the most important selection criterion for our new hires. We don’t even bother with those who write messy code. It’s almost impossible to change someone’s bad coding habits and you can’t possibly do exceptional work with the wrong people. No matter how hard you try.
We went to great lengths to understand what we were doing wrong, and how we could build better projects. Someone we’ve worked with a while ago, told us we have impossibly high standards and that we’re insane regarding to how he should write his code. Well, that’s the point. Be insane when it comes on how you write your own code. It’s the first step on your journey to become a better coder.
You don’t have to adopt “best practices” and implement them mindlessly. Be informed, see what works for you, develop your own style. As long as it’s clean, organized and readable, it’s OK. There is no perfect or “zen” style to write code.
Resist the urge to switch to something new the instance it comes out. Let it mature, consider all the implications beforehand.
A few days ago, I sat with one of our developers and we talked about new tools and ways to improve our workflow. He showed me a new shiny new tool to replace our current Gulp workflow. He talked about how “cool” it was and the stuff we could do with it. After a while we realized that most of the current custom tools and integrations that we spent tens of hours building wouldn’t work with it. Ouch!
We put all the other options on the table and we ended up deciding to switch to Gulp. Configuring Gulp to work with our other tools and integrations went rather smoothly. After initial tests, it was 50% faster than our current Gulp workflow. It’s still a work in progress, but you can find it here.
What most young developers don’t get is that improvement is mostly incremental. There are times when you scrap everything and start over, but these times are rare. You can’t do great work when you start from scratch every time. Build solid foundations and improve incrementally. This is how exceptional work gets built.
Resist the urge to switch to something new the instance it comes out. Let it mature, consider all the implications beforehand.
Be practical, use the tools at your disposal for the purpose they were created.
I see a lot of concept work on CodePen and other sites. Some of it is cool, fun, or intriguing. Other concepts are created just for the sake of proving that is possible.
I must confess, I never do concept work that has no real purpose.
Let me give you a few examples. Recently, I stumbled upon one concept that was doing particle animation in CSS. Why use CSS when this would be trivial to create this using canvas and JS? There are also many that replicate vector graphics in CSS. We have Illustrator or GIMP for that.
Why would one waste time doing things that have no real value or purpose? Just to prove that it can be done? The “I did this in my free time” phrase on such a concept, doesn’t help either. It’s obvious it took tens of hours to do it.
So, be practical instead, use the tools at your disposal for the purpose they were created. Don’t waste your time with valueless creations. Create something of real value. This actually improves your skills and pushes you further.
If your designer is not challenging you, find one that does. A great designer will make you become a better front-end developer.
Working with a great designer will transform you as a front-end developer. Once you spend countless hours trying to implement the designer’s vision, exactly how he wants it, pushing pixels around, having endless conversations, you’ll create things you never thought were possible. If your designer is not challenging you, find one that does. A great designer will make you become a better front-end developer.
Travel, go to conferences, meet others like you.
Developers are a special breed. We feel contempt in our own little world, as Derek Powazek puts it:
Programmers are the Gods of their tiny worlds. They create something out of nothing. In their command-line universe, they say when it’s sunny and when it rains. And the tiny universe complies.
Thing is, you don’t live in a vacuum. Travel, go to conferences, meet others like you. It’s the best way you can share ideas, get honest feedback.
Where else can you share a beer at 5am, with a geek just like you, from another other part of the world, and debate why “Apes should take over the world”?