Leader vs. Manager


Some thoughts I’ve had lately while preparing for my next round of talks focusing on leadership...

I hate being referred to as a manager, I prefer the term leader.  Too often in the workplace the term manager is associated with the person to whom you report. A leader, however, may have those same responsibilities but also focuses on guiding others from within the team. A strong leader makes it easier for others to follow his or her vision or goal. 

That said, management still has it’s place. Certainly, I have to manage my developers and give them direction and feedback for specific tasks.  Management is a sub-task of the leadership role.  However, as the leader becomes responsible for multiple teams, the management role increases. I will focus more on the leadership role and responsibilities in my talks, rather than the management aspect.

Having the title of a lead does not mean that others will naturally follow you.  In fact, it could be quite the opposite! Some developers might resent the fact that an individual has been promoted to a leadership role. Sometimes the promotion is just part of the natural progression of the company, and not directly tied to the promoted person’s career path or goals. This can be problematic if the developer just wants to be promoted for the pay raise and doesn’t  have strong leadership skills. He or she may end up frustrated and not perform well in the new position. 

This poses the question: Are leaders born or made?  I say both! While I was not a natural leader as a kid, as I got older and entered the workplace, my interpersonal and leadership skills developed. Over time, others saw potential in me.  I got promoted into management early in my career, and in hindsight, I don’t think I was quite ready yet.  I had a lot to learn about coaching other developers, especially those whose skills were more advanced than my own. Over time, I learned that a leader doesn’t necessarily have to be the best developer on the team. A good leader's breadth of knowledge and coaching expertise can not only help the team succeed, but also helps individuals progress in their career. 

Focus on being a good leader first... opportunities and developers will follow.

Iowa Code Camp

I had a great time attending Iowa Code Camp a few weeks back. I would like to thank all of those who attended my session for their questions throughout! There was such a great mix of thoughts and questions that came from the audience, that I plan on altering my talk to focus on some topics they brought up. That's the great thing about speaking...your talk will always evolve based on everyones feedback.

If you do attend a conference, please make sure to give feedback if you are given the opportunity. Please let the speaker know what you would like to hear more of, or less of. That kind of feedback can help shape their next talk.

My next presentations will be at KCDC here in a few weeks. I am going to spice it up this time with a new talk on Ember.js.

Great Pointers for Speakers

I watched the following video by Ben Orenstein last year, and it definately gave great points on being a better presentor. Prepping for my talks this year reminded me of it, and I HIGHLEY encourage you all to watch it!


I am excited to announce that I will be giving to talks at this year's Kansas City Developer's Conference! It is defiantly a perfect time to meet up with some great tech speakers and get your networking game on. I would encourage you to attend, and definitely check out one of my talks:

FizzBuzz Buzzkill: Rethinking the Developer Interview Process

Hiring great developers is vital for your company's success. By focusing on key areas of an interview, you can identify great talent as well as promote your company's culture and career opportunities. This presentation will be geared toward technologists involved in their company's interview process, and how they can influence it to attract the best talent.

An Introduction to Ember.js

Does managing state in your single page app seem harder than it should be? Do you suffer from transclusion confusion? Let's dive into Ember.js, and learn why many developers have fallen in love with a framework that focuses on convention rather than configuration.


Consistency is something I have lacked this last month. I want to blame it on a busy work schedule and spending time out of town visiting family over the holidays. However, part of it has just been my own fault as well. Trying to write a post weekly turns out to be a little more difficult than I thought. But, I have been getting some great hands on exposure to things I have been wanting to dig deeper into over these last few weeks like Jade and Gulp. With new years coming this week, I figured I would revise my resolution to writing blog posts on technology: Write as often as possible, and accept that life may get in the way a bit.

Up next will be some thoughts on Jade, and how we are using it on a project at work. It is a valid tool, but I am still struggling with adding one more layer to a build process. More to come, hopefully later this week!

Leveling Up

A few weeks ago, I was going to focus on one specific technology per week, and then try to write up something about it. In practice, this does work great. However, given my schedule, it's harder to dig into working code when I get the free time. As you can tell by my posts, I am already behind one week...

It did come to me that I should not restrict my one-post-per-week rule to a technology or library that I need to develop in. Rather, since I mentor other developers at my job, I should also hit on subjects outside of the nuts and bolts of coding. It's other skills besides coding with a specific framework that has helped me to succeed in the last several years, and others might benefit from the things I have learned. One of them, is how I learned to level up my career.

Leveling up is a common term used in video games when your character gains enough experience to learn a new skill or skills. For example, by leveling up in a game you can use a more advanced weapon, or gain entry into specific sections of the game that you couldn't access before. If you are trying to increase your characters skills rapidly, you need to focus on leveling up. There are two main ways you can achieve this:

  • You can gain a bunch of experience in a short amount of time by fighting a few tougher foes, with the risk of losing the battles due to the tougher challenge. The risk is worth the reward.
  • You can gain a bunch of experience spending a lot of time defeating smaller foes. The lower risk is worth the lengthier time to gain the experience. You can almost do this type of leveling up passively in the game while doing something else.

If you want to be a better developer, you need to level up your career. I think the video game analogy options above fit perfectly in a developer's career as they are trying to progress. Now, granted, you can still gain skills as a developer over time just by doing your normal development tasks at your job. You will have tasks that are sometimes challenging, and other times not. Depending on the type of development or projects assigned to you, you could gain a massive amount of experience in a short amount of time. For those feeling that their day-to-day tasks are not leveling them up very fast, this post is for you.

Higher Risk Leveling Up

Everyone wants to learn the most they can, at the quickest rate possible. For a web developer, there is no way faster to learn a technology than being dropped into project and having to learn that technology on the fly with a tight deadline. Congratulations, you now have 100% focus on that technology whether you like it or not! This is a super high risk situation since there is little room for failure. You will learn, but given the project, you might learn the wrong way to implement the technology or not have enough time to refactor and deliver a product with too much technical debt.

However, some developers thrive in this type of situation. Their learning habits and personal lives' schedule may be able to adapt to this, and they will be able to make great strides in their expertise. They embrace these challenges, and find that "trial by fire" makes them a better developer. I tend to learn this way, due to my job at a fast paced marketing agency.

Lower Risk Leveling Up

As I mentioned earlier in the post, my schedule definitely can work against my goals of learning new things. However, I have learned over the last year that I can still learn a ton of information passively while I do everyday tasks such as commuting, or mowing the lawn. Podcasts are huge in my leveling up strategy, and they should be in yours as well. There are great podcasts out there that cover a variety of topics that will help your career, and all of them are free. I look forward to the boring car drives and time on the treadmill at the gym because I can knock out a few podcasts covering new technology while not even adjusting my schedule.

Reading books is an obvious choice, but does take a little more time out of your schedule and can cost some money. However, your career will flourish if you can read one nonfiction book per month focusing on a skill you want to learn more of. It really doesn't take that much time, especially if you follow my next advice...

Cancel your TV cable subscription. Seriously. I know this might sound like sacrilege to some of you, but there is no bigger time vacuum than the TV. The average american watches more than 5 hours of TV per day!. If you have a show you love, consider buying the season of it on iTunes or Amazon, and watch it...and only it. You can stay caught up, and still save a ton of money. By cutting out cable from my schedule, I have more time to spend with my family and find opportunities to better my career. It's probably the toughest thing in this post to do, but it is well worth it.

Take on a side project for a friend or relative. Try to find something that would allow you to experiment with a new technology, and allow you to adjust the schedule of completion. This way, you can take your time learning the information, and provide a quality product. Just be careful that you don't sign yourself up for too much work.

How do you level up?

I am always learning new things, and I know you are to. Leave a comment below and let others know some easy (and maybe hard ways) to boost their web developer experience.

Style Guides

Style guides can be beneficial to your development process. Most sites that I see worked on do not have a base style guide set up for them for all of the different elements on a webpage. You can find an example of what I am taking about here.

Granted, not all HTML elements will be used on the average site, but it can still be a great thing to test your styles against a single static page for a sanity check if you notice some weird styling happening on your site. Some developers might argue that this would be difficult with the type of site they are building due to multiple module types, and style rules changing out based on what modules are being used. I believe it might be a bit trickier to implement, but it can in fact be done...

I have seen an excellent solution on a project where the developer utilized Gulp to break out each of the different Handlebars templates being used, and with the help of Assemble, create a great site outline that showcased all of the different modules being used on the site. This would automatically be updated when the developer changed any Sass or HTML partial, and the output generated was easily passed off to the client for their review and reference. This is a great use case for leveraging your build process to output something else other than your normal asset flow.

While not the most amazing thing, small items like this added to projects really go a long way when turning over code to a client for them to implement.

Thoughts on Sass

Writing CSS can be tedious. Period. I have been doing web development for over 10 years now, and yet sometimes dealing with a CSS compatibility issue still can give me more heartburn than anything else. With the amount of trouble you can go through with browser compatibility alone, why make your life more difficult by writing all your CSS by hand?

You need a CSS preprocessor.

Most of you are familiar with what a CSS preprocessor does, so I won't go into the details of what they do. But, let's go into all of decisions/thoughts that drive me to recommending Sass as my daily driver.

So which preprocessor do you use? LESS, Sass or Stylus? I work with and coach many web developers at my job, and the flavor of choice that I have seen over the last few years is Sass. I don't think I have seen anyone develop in LESS at all, and I can count on one hand the amount of devs that fire up Stylus as their day-to-day. With that said, I tend to go with what I see the market trending with since I don't see any show stopping differences between them all. Since I am focused on creating front end architecture for projects where code could be passed off to other developers and even other companies quickly, I continue to choose Sass because of its popularity.

However, just because someone says they are using 'Sass' in their project doesn't give you the whole picture. I recently had a .Net developer say that the CMS we were using could handle all the .scss compiling because it was using Sass, and our workflow could be simplified. While his gesture was sincere in wanting to help out with the build process, in the end, that version would cause some issues. More on that later...

Choosing Sass seems like it should be the only commitment that you need to make when choosing a preprocessor. However, that is only the first step. There are several ways of running Sass, and all of them have their advantages and disadvantages. Not only can you choose what framework to run on top of Sass, but you can also choose how you want to run Sass, including which binary to execute against. Let's go into these options for a bit...

After you install the Ruby Gem for Sass, you can be up and running. So in theory, you can just start banging out nested classes and mixins with little setup. But, as all of us front end developers know, using a tool should never be that simplistic. We need more layers to add to our projects! Say hello to Compass.

Compass was the first way I got into running Sass a long time ago. It has some great mixins, and it's ability to create sprites was easy to add into your workflow. All the cool kids were using it, so it just naturally found its way into many projects. Dropping in a simple config.rb to setup your paths in your root directory, and running 'compass watch' in your terminal was dead simple. Plus, that configuration was easy to commit to your version control system so other devs could get up and running without the need of Grunt or Gulp. With all the power that comes with Compass, there lies one big problem...speed. Waiting on your .scss files to compile during your Grunt task was painfully slow. Slow enough to cause you to start drinking...Bourbon.

Bourbon definitely can take the edge off (in more ways than one). Bourbon runs noticeably faster than Compass, since it is just a lightweight library of mixins. While it is installed via a Ruby Gem, the logic itself is all contained within .scss files. Instead of another Ruby process like Compass to execute logic, all you need to do is include the Bourbon files and run Sass like normal. Some of Compass' mixins can easily be replaced with using Bourbon's (in some instances, the mixin names are even the same). If you need some more typography mixins, variables and functions you can add in another library like Bitters to help fill the gaps. So, unless you need all of the functionality of Compass, Bourbon seems to be the clear choice.

However, some people are not a fan of having to add Ruby to their already complex build stack. As I hinted to earlier, developers came up with writing a Sass compiler in C called LibSass and it is currently being used in one of our .Net environments. Not only does this remove the requirement for Ruby, but it also compiles MUCH faster. This can be thrown into a node.js build script using node-sass. Sounds like the perfect fit, right? Well, not exactly. While LibSass might have the edge in speed and portability, it lacks in functionality. Since it is a port, it has often been behind in features compared to the Ruby version, and those minor differences could end up causing headaches for teams depending on it. For instance, running the latest build of Bourbon with LibSass causes errors, due to C version discrepancies on functionality needed by Bourbon's mixins. However, it was recently announced that Ruby Sass is going to wait for feature parity with LibSass before moving forward and will then try to be maintained at the same speed. This is huge news, and will help out the Sass community. It will also get server side developers interested in adding it into their workflow as well since they can avoid the Ruby stack altogether.

So, where does that leave me with my current workflow? It's easy to install LibSass with Homebrew, and then wire that into my Gulp flow. However, the ability to have a nice library like Bourbon that stays fairly updated in my workflow outweighs the pure speed gain of using LibSass. So, it looks like Ruby Sass + Bourbon will be the preprocessor stack that I recommend for the time being until LibSass catches up. Then, I have a feeling a lot of people will start making the shift, including myself.

One week at a time.

Web development can be a pretty intimidating sometimes, especially with the sheer amount of technologies and libraries available to use.  I get the to "talk the talk" in my everyday job, but that often doesn't lead much time for me to "walk the walk" when it comes to implementing some of the newest methods.  Over the next several weeks, I am going to focus on one technology/library per week being used in the client-side development process and try to implement/experiment it in a way I haven't before.  For some of those libraries, the new way will be the first time I have implemented it in anyway at all! 

This first week's challenge will be Sass, and working on different versions of the runtime.  Most likely it will be focusing on the Ruby version, and implementing BEM for a simple site. 

Living History at Union Station

I just finished up helping out with one of the coolest projects that I have ever worked on at VML during my 9 years here.  This video sums it all up for you, and I highly recommend if you live in Kansas City to download the app and head out to Union Station to try it out! Also, notice the handsome gentlemen posing with Truman at 0:48 in the video ;-)

BarCamp Omaha

I recently had the opportunity to give at talk on interviewing web developers at BarCamp Omaha (See the recording below). Some senior developers get the great opportunity to partake or even head up the interview process with potential candidates.  This talk is geared at those developers, and focuses on the ins and outs of a technical interview.  It also focuses on one key thing that the interviewer should always remember during the interview: Sell your company!