Happy and Productive Developers: Motivating Developers

Developers produce their best work when they are motivated. What motivates developers? That can be very different depending on the developers. It is important to build a relationship with a dev and learn what motivates them. Let’s look at some common motivators that can apply to most developers.


Developers motivated by money are never worth the money. Money is a very short term motivator. Devs that are primarily motivated by will cash change jobs frequently, and are usually the biggest complainers on the team.


Your marketing/strategy department is supposed to sell the customer on the product, but have you ever thought about selling the product to the person building it? I personally put in a lot more effort knowing what I’m building will make people’s lives better. You should frequently remind developers the value they are adding to customer’s jobs.

New Tech

Developers love getting to play with the new toys. I don’t know any developers that want to be coding in .Net 4 in five years. Devs get excited about new shiny frameworks and existing tools getting upgraded. Do your best to provide them the opportunities to utilize them as soon as they are available.


Tasks for entry level developers are rarely any fun. They usually involve maintaining existing code or minor updates on multiple projects. These become tedious and boring over time. Few developers want to stay doing the same tasks forever . You should be transparent with what growth will be available if they do their work well.


Most developers I know are heavy introverts. They don’t go out of their way to seek recognition from their peers. You can quickly boost their moral with some public recognition. One on one recognition can go a long way too. Simply saying “I like how you handled that challenge” can be priceless to a developer’s esteem.

So what do you think? Do you think you’ll need to move mountains to motivate your developers? I bet it will be worth the effort.

Happy and Productive Developers: Tearing Down Stereotypes and Understanding Developer Motivation

The first step in creating an environment for happy developers is to build a good relationship with them. You must start things off on the right foot. This all starts before your first interaction with them. This first interaction could be an interview if you manage developers. It could be the company’s all hands meeting where they are introduced. Your first impression of a developer can be incredibly skewed because of developer stereotypes.

Society has cemented stereotypes and cliches into our brains. They influence our first impression of people and cause us to be judgmental. Stereotypes in the work place put barriers between work groups and developers become victims of this pretty frequently due to the nature of what society makes them out to be.

There are plenty of appearance and hobby stereotypes for developers. They don’t care about their appearance, spend 20+ hours a week playing MMOs, and know the Star Wars lore inside and out. You can find out if there is any truth pretty quickly. Asking a developer “What do you geek out on?” may not yield positive results if the person doesn’t consider themselves a nerd or geek about something. Leading with an Office Space quote isn’t going to lead to positive conversations. You’d be surprised how different the typical developer is outside of work. Personally, I’ve worked with former US Marines, a marathon runner, multiple MMA/Kickboxers, several carpenters, a former pastor, and the list goes on.

Lets focus on actual work related stereotypes. The above may get an occasional eye roll or laugh, but they shouldn’t affect developer morale across your company… unless you’re just a total jerk about it. Removing work related stereotypes will improve your relationship with the developers you work with on projects, you manage, or the ones you simply work with.

#1 Developers will get your project done if you simply throw pizza and redbull at them.

There isn’t a developer in the world that will be willing to do this for no reason. Developers don’t want to be treated like slave labor. The quality of work will reflect how you treat them.

#2 Developers are difficult to work with

This is hard to defend because developer’s job is hard to do. Developers ask a lot of questions, challenge requirements, and resistant to change. There is a lot of truth in this xkcd comic.

A simple task can turn into a mountain with one requirement. Imagine you are told that you told to build a two page web app. That should be simple right? It’s a search page and a results page. Super simple! Oh we need the search page to search the entire internet…. Yeah, it’ll be just like Google. Both of you need to slam on the brakes. The developer is most likely going to panic and say it’ll take 10 years to do. You, the person wanting this product built, need to ask the right questions before throwing your hands up and requesting a different developer. Developers have a good idea of the level of effort required for work. You have to find a middle ground. Trust them and work towards success together.

#3 Young developers are better than older developers

This has become an increasingly more common thought over the past few years. New and hungry programmers will typically overshadow their well-seasoned counterparts. They’ve been engulfed in technology longer and pick things up quickly. There is a lot more to programming than simply knowing the latest language or framework. Older developers have already learned how to work efficiently, problem solve without panicking, and can offer a unique perspective.

#4 Foreign developers aren’t reliable

This stems from another myth that offshore work doesn’t produce as high quality work as local. Developers from a foreign ethnicity or speak English as a second language have an incredibly hard barrier to break down to get hired. There is a bunch of other garbage that we can throw around this that is hard to go into.

#5 Female Developers aren’t as good as Male Developers

Let’s pause for a second. Do you believe the above? If so, go ahead and punch yourself in the face….. Go ahead and do it again for good measure…

Women have struggled to get into the tech space. There are a lot of movements to help get women into the field Girl Develop It provides affordable programs to get women into development.

I’ve had the privilege of working with about 10 women developers over the years. Their skills stood out a great deal and they were all very motivated to excel in their respected programming languages. Because of this, I really have a hard time wrapping my head around the fact that this stereotype is still a thing.

Bonus: Inner Developer Stereotypes

Here is a bonus for you if you manage a group of developers. Developers love to banter with each other about what languages they use for some reason. This banter can quickly turn south and turn toxic. Keep an eye on your team and don’t tolerate disrespect due to tech stack.

Series Introduction: Happy and Productive Developers

I’ve been obsessing for the last 8 to 10 months about developer moral and productivity. Early last year, I read the book Team Geek and ran a book club over it with the developers I work with. Everything went downhill from there. I’ve been pouring ideas into a OneNote document for about 6 months now. I’m pretty sure I’m going to get too broad on the topic if I don’t start focusing on getting stuff on paper… or on the web.. whatever. The ultimate goal of this series is to build a foundation of ideas that I can take and present at tech conferences, user group meetings, and other gatherings of tech leadership.

I’ve collected topics from sources such as Fog Creek’s blog, Base Camp’s blog, and several other books and blogs, but the bulk will be from my personal experiences. I’ve gotten to work in an excellent environment for analyzing morale and productivity and I’m in a position/role where A LOT of developers come to me when efficiency is a concern, something is bothering them or they are down in the dumps. I’ve gotten to experience rapid growth in a company, extreme leadership shifts, no leadership, shifts in company focus, failure, success, politics, head count fluctuation, too much work, not enough work, politics (yes, twice) and most importantly…. drama. These sound like some pretty common topics that people in the industry can talk about, but I’ve experienced 100% of them as a developer. I can discuss many of these topics with confidence and I really look forward to putting all of this together.

I will be touching on these topics and more: debunking stereotypes for a better relationship, managing vs leading developers, trust, equipping for productivity and success, finding and retaining good developers, simple perks and benefits, how and why you should minimize distractions, and why no good code is written after the 10th hour.

Feedback will be more than welcome and I’ll answer any questions that are brought up in post comments.

NPM Nonsense and Open Source Grumbling

Disclaimer: Opinions in this post are my own and do not reflect the opinions of my employers past, present or future.

The dust has already settled on this whole debacle and I think I’m ready to chime in. If you happened to be away from the internet on March 22nd and 23rd, a developer unpublished a fairly popular node package.

The Story

The developer, Azer Koçulu, had a product called Kik. It’s a project kick starter/generator. Turns out there is a social media tool called Kik too. A patent lawyer at Kik requests Azer to unpublish his tool from NPM (apparently they were going to be publishing some packages there and wanted to avoid confusion). Azer says no, Kik emails NPM site support, NPM support team removes the module, and Azer unpublishes all his node packages from NPM (he had about 250). This probably wouldn’t have been a big deal with most developers, but Azer had an amazingly popular package called left-pad. It had about 2 million installs over the last few months. Azer’s medium post explains why he removed the modules.

I had honestly never heard of either of these “Kiks” before this situation and my initial response was to roll my eyes. I rolled my eyes again when I saw that left-pad was only 11 lines of code. I’m relatively torn reflecting back on it. Should we be frustrated at the developer for removing his module, or should we be upset with ourselves for relying on a dependency that should be easily replicated by any competent developer. Have we become so dependent on other people’s code that we’ve forgotten how to do simple low level logic in code? I’ve thought a lot about it and I’m pretty well inline with David Haney http://www.haneycodes.net/npm-left-pad-have-we-forgotten-how-to-program/. Deep down, developers that rely on solely on other people’s work annoy me. I use to see a lot of people advertising themselves as WordPress Developers that would simply find the right plugins and duct tape them all together. I feel NodeJS has fallen into the same boat due to the popularity of the Node Package Manager.

I’m an impostor too

I’m guilty for relying on other people’s code too. I do recall a time where I would hunt down jQuery plugins for the simplest application. I would usually end up spending more time configuring JS and hacking CSS to get the plugin to fit my needs. I eventually realized that I could build out exactly what I wanted in the same amount of time. There is a lot you can learn by reverse engineering other people’s code. I’ve spent a lot of time digging through YouMightNotNeedjQuery.com. There is a lot of JavaScript functionality you miss out on by learning jQuery before JavaScript.

I’ve caught myself recently falling back into this hole. I’ve been fortunate enough to be working on AngularJS projects for the last two years. I’ve dug through GitHub a number of times looking for directives and factories to speed up my development efforts.

The Real Heroes

I’ve recently developed a great deal of respect for developers that properly run open source projects. I’ve started a couple open source projects and just let them fall by the way side. Open source projects do not pay the bills and require a lot of effort to keep up. Any “community” on the internet has a knack for becoming toxic. There are too many projects out there that receive more flack than what they deserve. The community needs to contribute instead of complain to make the projects successful.

I have a few legitimate projects I want to open source, but I haven’t had the time to properly get them into GitHub. I’ll hopefully get something out there soon.

NPM Event Readings

I work with a Geek God

I love getting to build cool stuff, but my buddy has taken it to an absolute new level. My fellow technology architect Warner Skoch (aka “Wermy”) has blasted himself into geek immortality by cramming a Pi Zero into an Altoids Can AND a full sized Game Boy. Every thing I’ve ever built looks like a pile of dog poo with glitter on it compared to these sweet Raspberry Pi Zero builds.

I managed to make it to Stage 6 – Energy Zone in Contra on the GameBoy. The build is very sturdy.

So you want a promotion as a programmer?

Disclaimer: Opinions in this post are my own and do not reflect the opinions of my employers past, present or future.

I’ve been very blessed at my current job. I started in the lowest development job title and I’m currently in the highest non-management development position. I’ve received 3 promotions over the span of the 7 years I’ve been with the company. Getting a promotion without job hopping can be really challenging. I think there is much more respect to be earned by staying at a single company working your way through the ranks. Here is a collection of helpful tips I’ve seen through my own promotions and other people’s promotions. Keep in mind that all companies are different and these may not apply to every job.


Let your boss know you are interested in a promotion. I was once a holiday hire at a retail store and there were 2 spots for permanent hires after the season. I was the top holiday hire, but they overlooked me because I had been talking about applying somewhere else. I missed out a pretty decent gig because I didn’t let him know my intentions.

I would encourage you to sit down with your supervisor and make sure he knows your career goals. Follow up with them regularly to make sure you are on track.

Prove your WORTH

Have you ever thought “I deserve a promotion!”? If you have, go ahead and slap yourself really hard in the face. Like, right now! This is totally the wrong attitude to have when looking for a promotion. You need to prove you are worth a promotion.

Every company has a different method to determine the value of their employees. In my scenario, clients are charged per hour for my work. I pushed myself to learn as much as I could. This allowed me to work on more projects and being good at it.

You should not confuse this with working extra hours. Working 60 hours a week to prove you are Sr. Developer material will do more harm than good. You will set the expectations that you will always work those hours and you wont ever be able to get back down to a 40 hour a week work load. You should spend time outside of work reading and trying to expand your skill set. You wont always be provided opportunities to try new stuff and outside dedication will demonstrate your desire to improve and grow.

It’s important to never judge a promotion based off another employee’s experience. I helped out Sr. Developers on jQuery all the time when I was a Developer 1. I frequently thought the roles should have been switched and I was the one getting help. I thought that I should be the Sr. Developer because I was more intelligent on the subject. I didn’t think about the fact that the other developer had 8 years experience in the field and was much more experience in planning and execution than I was. Never assume that you should have the same title as someone else because you THINK you are better at the job .

Attitude is everything

This kind of follows what I said above. Keeping a positive attitude can go a long way. Never fight for a promotion as a response to someone else getting the promotion you wanted. This is more of an emotional response and will prove to be more harmful than good. It’s impossible to know what the other person went through to earn the promotion. They may have been lobbying for it longer than you or they are really good at some aspects you over looked. Occasionally, politics come into play in another person’s promotion, but you just have to get over that. Worry about yourself and not other people.

Whatever you do, don’t threaten by saying you are going to look for a different job. You are just going to burn bridges by doing this. The job interview with offer and counter offer maneuver just for a raise is really risky and could also damage relationships.

You also don’t want to push a promotion to get away from someone or to report to someone else. I’ve seen this backfire many times. It’s more beneficial to actually work through your problems with other employees than avoid them.

Know your company

Not all companies can issue promotions on the spot. Figure out how your company handles them. Company A may only have 5 Sr. Developer positions and only fill them when there is an absent seat. Company B may only do promotions every six months due to budget forecasting. Get the conversation going and make sure your superiors are aware of where you are wanting to go when these scenarios arise.

Job titles and responsibilities also change a lot. You need to keep up with this. A Sr. Developer for a company of 50 employees may have completely different responsibilities than when it becomes a company of 100 employees. Mold yourself and take on the additional responsibilities to prove you are ready for the title you want.

Stay consistent

Stay consistent with what you want. Do you want to go into advanced coding or leadership? Sit down and really think about it before you start pushing for it. Bouncing back and forth will give the impression you really don’t know what you want.

Be Patient

I cannot stress this enough. It’s really easy to get bent out of shape if things don’t go the way you think they should. Keeping a level head and a mature attitude can go a long way.

I hope you found something useful here. Let me know if you found this useful or if you think it’s hogwash. Thanks for reading!

How to be an effective remote developer

I’ve had the opportunity to work with a lot of remote developers. I’ve worked with some really great one and some pretty awful ones. A lot of people thing working remotely is exactly the same as working in an office, but you get to wear sweat pants and you get more flexible working hours. This is pretty far from true. Being an OK remote developer takes a fair amount of effort, but being a great remote developer takes a great deal of effort. Most of the really great remote developers I’ve worked with share the same qualities and work ethic. The apply a great deal to working in a different office than your team or when you are in the position of having to work from home more often than in the office.

You don’t just need to communicate. You need to over communicate and choose the appropriate channel. We have email, IM, phones, and issue trackers at my job. If you need someone’s immediate attention, don’t send an email. An email can be overlooked or ignored. Be specific with your needs and ask questions when you have requests.

Let people know your schedule if you don’t work the same hours as everyone else. Make sure your IM client status matches your actual status. It’s pretty irritating to see someone is offline for 15 hours, it’s the middle of the work day and you’ve seen emails and work being done. Being a stealth employee isn’t cool.

Make your presence known. It’s easy to forget about people you don’t see you every day. Your work is just as important as someone sitting in another office and it’s up to you to make sure they know that. Your coworkers may not even know your specific skill sets because they can’t look over your should every once in a while. Chat up other employees when you have been thinking about something complicated or have a good idea. There is a developer that regularly hits me up whenever he has a new idea about how to utilize Grunt in our projects. This lets me know he is motivated and interested in new tech.

Video chat whenever possible. We practice continuous performance reviews and we have regular check-ins with our bosses. Video chat if you have to do these remotely. This will help them know they have your attention and vise versa. There is nothing more discouraging than to be on a call with someone about your future and you hear them pounding on their keyboard the whole time hearing “Mmmmhmmmm”. Video chat also lets people know your work environment and what you look like. I worked with someone out of a different office for a year without knowing what they looked like. Their Facebook picture was a permanent throw back Thursday picture.

Up the discipline in your work. Make more specific commit messages, code comments and notes in your issue trackers. Your coworkers can’t just turn to their right and ask you a quick question about simple stuff. A little extra work can go a long way.

Are these “guidelines” the definitive guide to remote work? Hell no, but hopefully these few tips will help you out.

Managing a massive Steam Library

I have a massive Steam library. I’m not rich or anything, but I purchase a lot of Humble Bundles and I’m a sucker for 50 cent games on sale. I’ve acquired over 300 games/DLCs and it’s really challenging to keep everything organized in steam categories. I spent a long time with two windows open trying to categorize based on tags, genre and rating. I recently went through and setup all controller supported into it’s own category. I switched computers and Steam’s cloud system overwrote it. I eventually gave up and just let things go wild in my library.

Happiness returned when I stumbled upon Depressurizer! Depressurizer provides you an interface for managing your Steam categories very quickly. I was able to auto-categorize based on User Tags, Genre, Store Flags, Ratings and a ton of other fields. Depressurizer will write to your Steam directory, but also export it to a physical file in case Steam forgets all your hard work. I’ve stored my app in my Dropbox folder so I can work on my library on my Surface and my main setup.


This app is a must if you have more than 50 games in your Steam library. Plus, it’s an open source .net project! I may just contribute to it in the future 🙂

I was quoted on NimbleText.com!

A former colleague of mine send me a message on Facebook a couple of days ago. He had told me I was on the front page of http://nimbletext.com/. If you do anything with SQL statements or arrays, you should check the tool out. It’s incredibly useful.

my quote

What’s really cool? Scott Hanselman was quoted just a few paragraphs about me. I found NimbleText from his list of Ultimate Developer Tools.


Yeah, it’s kinda silly I’m freaking out like this, but Scott’s one of my development heroes.

Confessions of a Full Stack Developer

David Walsh has a great series he does called Confessions of a Web Developer. I’ve been reading them since about part 6 or 7 and I enjoy every one of them. I have been struggling with content here for a long time and he had some great tweets over the past few days that motivated me to put more effort into this blog. I’m really great at complaining so I figured I’d follow the master. As always, opinions are my own.

  • I haven’t felt challenged in my work for a long time. Thankfully, I’m in the position that I can inject challenge into my work. I try new design patterns, frameworks and testing strategies.
  • I’ve put a lot of effort into my Youtube channel, but it takes way too much time and dedication to run it well. I’ve kinda given up on it. Gathering resources and preparing a tutorial for a 10 to 20 minute video takes me about 20 hours of stop and go work.
  • I’m a hypocrite when it comes to commit messages. I tell everyone to keep them descriptive, but the last 50 commit messages to my personal repo is “stuff”.
  • I look over a lot of resumes at work. I pay more attention to where you have worked and how long you have worked there. I value loyalty more than skill. A developer with 2 – 5 year employments is more valuable to me than someone with 10 – 1 year employments. Constant jumps tell me you are more interested in promotions than improving your skills.
  • I can’t show off the vast majority of the projects I’ve worked on due to NDAs. I’ve been apart of developing and launching around 75 products. I’ve worked on around 125 if you include projects I’ve done maintenance or consulted on in the last 7 years. I can maybe talk about 15 of them. I feel like this puts me at a disadvantage in the job market, but I’m not looking for a job so it’s not an big deal.
  • I want to tell people that bash IE to just “Shut the hell up”. It’s beating the dead horse with his own fossilized bones. We all know IE 6, 7, and 8 are challenging to develop for. I think most of these people are too high on their Mac horse to look and see how much effort Microsoft has put in the newer versions of the browsers.
  • You’re dead to me if you hate on Win 8 without a good reason. The start screen change is not an acceptable answer.
  • To this day, I do not understand why open source developers hate on .Net developers. I’ve even seen “.Net snobs need not apply” on a Ruby On Rails job posting. It feels really immature.
  • I’m in a constant battle of whether I want to dress professionally or like a geek. I have a large collection of shirts, but I was known as “tshirt guy” for a long time. I really want to be respected, but it’s challenging wearing a Zelda & Dr Who crossover shirt.
  • I don’t think you deserve the help if you didn’t spend 15 minutes trying to find the answer on Google. You need to put some effort into it before asking someone to stop what they are doing to help you.
  • I value being an Eagle Scout more than being a college graduate. I didn’t take away a lot from college, but it did provide me a reference that landed me my job.
  • I only allow recruiters on LinkedIn to contact me so that I can tell them no. It’s an ego thing.
  • I’ve haven’t found responsive web design challenging or interesting in several years. I’m sure some people would say “You’re not doing it right”. I’ve looked at a lot of sites, gone through source code from frameworks, and read many articles. I’m confident in my skills and capabilities.
  • I judge you based on whether you use a GUI or command line for tasks.