Don't be a noob

Preston Haddock

Let’s face it: I’m a noob. I was an even bigger noob six months ago than I am now. I’ve leveled up, got some experience under my belt, and gotten used to a new environment and a new way of working. So now I’m going to share a few things I’ve learned on how to not be as big of a noob.


Working in a team environment can have its ups and downs. On one hand, the people are really awesome and easy to get along with; on the other hand, you’re at work and it’s stressful and you’re all relying on each other to get an amazing project completed on time. At times, there are decisions that the team butts heads on (butting heads is fine, just don’t draw blood).

Before I started at liquidfish I was, for the most part, flying solo on all my projects. I had no idea how to work with others or talk to others about issues I was having with a project. I felt like I had to solve all of the issues on my own and it was a struggle to get past that. Knowing when to open your mouth and when to hold your tongue is a pretty important skill to learn for work, and for life in general. Get comfortable with your team, you’re going to be spending a lot of time with them.

You have to develop some checks and balances as part of a team (a lot like the government but better because your teammates aren’t taxing you). When working on a project, everyone should feel comfortable enough to stand up for themselves. A developer should be able to call out a portion of a design that is too ambitious for the time frame of a project. Accordingly, designers need to be able to argue why a specifically designed feature should exist. Copywriters need to be made aware of the limited constraints, if any, a specific page or aspect of a design has in order to keep copy down to fit and be easily readable by the users. An amazing design and well-executed and developed site needs to keep the user informed, engaged, and wanting to come back for more. In the end, everyone needs to balance each other out and make the best product they can individually as part of a team effort.


We’ve all heard of them and some of us hate them. Okay, no one hates them but they do have their pros and cons. Typically the pros outweigh the cons. They are out-of-the-box deployable code bases ready to be used in a real world scenario. They take a lot of the grunt work out of the picture when creating a website from the ground up. Using a framework lets you sidestep creating a lot of the base functions you need and move straight to custom functions hand-tailored for the project you’re currently working on. But do your research. Not all frameworks are created equal. I’ve used two frameworks since I started using PHP: Yii and Laravel. It’s been years since I’ve touched the Yii framework, but in my opinion, I’d pick Laravel over it every time. Not to say Yii is a bad framework, but Laravel was a lot easier to pick up and use out of the box.


Automation is amazing. From compiling files, automatically creating icons from SVGs, to linting and minifying javascript files, automation can execute any repetitive task. That sounds all fine and dandy but how do I automate anything at work? Well, I’d like to tell you I use a hamster wheel and a lot of duct tape but that would be a lie. I use Grunt. Some people use Gulp, and there’s probably more out there, but I’m sticking with Grunt.

Grunt is a node package that runs inside Node.js and can be setup to do just about anything someone else has programmed it to automate. Or if you’re daring enough, you can write your own plugin to automate your workflow. However, we’re skipping writing our own plugin and going straight to what is running in the background every time I hit CTRL+S (CMD+S).

CMQ (Combined Media Queries): CMQ takes all the media queries you’ve written and, well, combines them. CMQ will even run across multiple files and hasn’t failed me yet. CMQ works especially well with preprocessors like Sass where you’ve embedded media queries so far into nested element styles, they can hardly see the daylight. Also, don’t nest that far. Try to keep it at 3.

CSSMin: CSSMin does pretty much what its name says it does: it minifies your css files. You’d typically run this last in your CSS tasks to finalize everything down to a smaller file ready for spectacular speed tests.

Concat: Concat for Grunt will take a specified list of javascript files and concatenate them together in order. Combined with a minifier this can save precious bytes off of files for better site performance.

Watch: Okay all of these tasks are basically what their name imply. Grunt Watch will watch any files specified and run predefined tasks on them when the file changes. This is the bread and butter of Grunt. You can use Watch to automatically run the other tasks anytime a file that you’ve specified changes. Be careful though: the more tasks and files you start watching the longer compiling takes. You go from being able to instantly refresh a page to having to wait 3-5 seconds depending on how many tasks will be run.

Getting' Sassy

Before I started this job I scoffed at LESS and Sass as a concept. I didn’t think I would need them and thought they were silly. Some of my coworkers even think they’re silly. Well I was wrong and they’re wrong, too. Sass, Syntactically Awesome Style Sheets, is as awesome as its name implies. I highly recommend it, especially with how the web is going almost fully mobile first as it makes media queries a walk in the park.

Sass provides functionality to CSS that isn’t available currently and likely won’t be available for some time. Variables, mixins, functions, loops, all these are unheard of with plain Jane CSS and it’s really sad that some people aren’t taking advantage of it.

One of the main things you’ll find yourself using the most in Sass is nesting. Sass allows you to easily nest selectors within each other for cleaner and easier to read code. This lets you nest selectors in a similar manner that you would nest your HTML elements. However, don’t go too crazy on the nesting—you could cause more problems than what it’s worth with overqualified selectors. Oh yeah, remember how I mentioned media queries? You can embed them right into your selectors and Sass will compile it out for you without blinking an eye. Combine that with Grunt’s CMQ task and you’re on your way to becoming a Sassy Wizard.

Mixins solve the issue of very repetitive CSS. For example, anything with a browser prefix can be solved with a mixin. You simply write your mixin once, call it, and provide it with parameters if needed. Sass will notice you called a mixin and when the Sass is compiled down to CSS, it’ll place that nicely written code block right where you want it without having to type those four additional lines of code.

That’s enough about Sass, if you want to learn more about it be sure to check out their website here.


Here’s the Too Long; Didn’t Read of what the previous wall of text was trying to make a point of. Embrace the tools that surround you. They’ve been made for a reason. Someone somewhere has figured out a way to make their life easier by implementing a framework, some sort of automation, or using Sass. So shouldn’t you follow in their footsteps and make your life easier too? Get to know your team because they are going to play a big role in how successful you and your projects are going to be. Don’t be afraid to ask questions or for help. In the first few weeks, I don’t think I ever stopped asking questions!

If you’re not sure where to start, maybe this little post can be of some help. Almost everything I mentioned in this post was provided to me by a handful of developers I currently work with. I credit them for showing me these tools and thank them for making my life a hell of alot easier. You’ll always be a noob to someone, but just try to be less of a noob than you were yesterday. That’s progress... and progress is always a good thing.