Month: April 2016

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.

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.

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.