DEV Community: Dhwanit Shah

The Importance of Using Source Control

Dhwanit Shah — Sat, 18 Mar 2023 17:43:44 +0000

A young monk arrives at the monastery and is assigned to work with other monks who have been copying the old canons and laws of the church by hand. He notices that each of them is copying from another handwritten copy, and not the original manuscript.

The next time he meets with the abbot, he points out that if any of the monks makes even a tiny error, then it could be passed down in subsequent copies. The abbot says they have been doing things this way for centuries, and such mistakes just don’t happen and decides he would compare a recent copy with the original manuscript to prove to the young monk the wisdom in their ways.

And so the abbot heads down into the basement of the monastery where the original manuscript is stored in a locked vault. Several hours later, when he still hasn’t returned, the young monk gets worried and heads into the basement, where he finds the abbot completely distraught, openly weeping. He runs over to ask what has happened, and the abbot keeps repeating, “we missed the ‘R’!”.

The young monk walks over to the manuscript to see what the abbot is talking about.

The word was celebRate.

And this is why you should always use source control.

Photo by Vlad Hilitanu on Unsplash.

Some Advice for New(ish) Developers

Dhwanit Shah — Wed, 21 Sep 2022 17:23:35 +0000

There are professional developers out here who weren't born when I started, so I've been around a while. I have worked on some incredible systems and even built many of them from scratch. I have worked for non-profits and governments. I have worked with startups and multinational conglomerates. I have helped build organizations from the ground up. Suffice it to say people who know me professionally don't consider me incompetent or inexperienced.

I still spend a ton of time looking things up on Google. I still make mistakes and get stuck on silly things. I still ask other developers for help because:

It's okay not to know how to do something
It's okay to be wrong about something
It's okay to make mistakes
It's okay to ask for help

Anyone that tells you otherwise is a fool, a jerk, or both.

Be kind to yourself.

You got this.

Photo by krakenimages on Unsplash

A journal entry about confirmation bias

Dhwanit Shah — Wed, 10 Aug 2022 20:03:44 +0000

8:35 AM: hearing an odd noise from outside
8:37 AM: confirmed noise coming from passenger-side front of the car
8:45 AM: back at home; examination of passenger-side front wheel shows nothing out of the ordinary
8:55 AM: pulled over in a lot and more thoroughly examined passenger side tire, wheel, and surrounding area to confirm nothing is rubbing or dragging
9:02 AM: ignoring noise not fruitful; imagining wife at my funeral, wishing I had discovered the hole in the fuel tank before mustache-twirling bad guy dropped a match on the trail of fuel I was leaving behind
9:07 AM: confirmed fuel tank intact; found a small tree branch under the driver side of the car instead

If the wheel was grinding against something, the noise would have gotten louder when I opened the passenger-side window, or there might have been some vibration as the car moved, or may have felt resistance as I tried to steer. But I was convinced that my initial assumption was correct, so I ignored the lack of evidence and missed the obvious problem just a few feet to the left.

I stopped and looked under the car twice, but because I was convinced that it could only be an issue on the passenger side front, I did not notice the obvious issue, just a few feet to the left.

The cabin is sealed for a quieter ride, except for the cabin air filter, which is in the glove box on the passenger side.

What if you don't want to hire someone until they can prove they have what it takes?

Dhwanit Shah — Wed, 20 Apr 2022 23:06:00 +0000

Do you want to hire talented people, but you also don't want to commit?

Do you find that you start disliking people after a while, and would rather spend a bunch of time making them do things for you first so you can be sure you won't hate them later?

Did you have to jump through hoops to get where you are and don't feel obliged to give anyone else an easier time?

Well, do I have a product for you!

Introducing Money™.

With this revolutionary product, you can acknowledge to a candidate that your hiring process requires more of their time than other employers and thank them for going through it.

Invented again and again by our ancestors over thousands of years, Money™ is accepted everywhere goods and services are sold.

In a double-blind scientific survey, 10/10 candidates preferred receiving Money™ for interview-related work over not getting Money™ for it. It was also tested on animals a few times, so you know it's safe!

To find out if Money™ is right for your business, visit DoPeopleDeserveToBePaidForTheirTime.com.

Photo by Tim Gouw on Unsplash

Staying in Your Lane is Hard

Dhwanit Shah — Sat, 17 Apr 2021 02:54:33 +0000

For the first few years, Energy Ogre was fewer than ten people, and I was the only technical resource. We had contractors that came in for specialized work, but on most days, I was everything from technical support to the programmer behind all our systems.

These were tumultuous times, not tracking when days ended and nights began, fitting in work before and after (and sometimes during) time with family. I was once in line at a roller coaster at Six Flags while spelling out a SQL query over the phone, one word at a time, to a coworker so they could type it in and hit run without understanding what it was doing. When it was our turn to get on, I told the group behind us to go on ahead because I needed another minute to finish the call. The look on my wife's face made me hang up and get on the ride because I'm not a complete idiot, but I was back on the phone the second the ride ended. It was not one of my better moments, but the website was down, and, well, someone had to fix it.

We were building something amazing, and the only thing limiting us was how fast I could make it.

We got a little bigger and brought in another programmer, and things started moving. We grew a bit more, brought in some fantastic people, and as that happened, naturally programmed less and less, opting instead to focus on the bigger picture.
I have not been a software developer for over a decade, but when someone asks what I do for a living, I still say, “I’m a programmer.” It’s who I think I am, and it’s also something I am not likely to be again.

It’s a delicate dance between staying up to date with what's new and not putting in so much time to learn it that you fall behind on your day job. And while I can only speak to my own experience, I have seen and heard similar sentiments echoed by people in leadership positions in many other fields: I wish I had the time to do it again.

You find something you like, and you learn everything about it. You start to get good at it and get a job doing it. You do it well; well enough to move up. Move up enough to where doing it is not a good use of your time anymore. Then you look at someone else doing what you used to do, and long for that old time, maybe even give it a shot again for a little while, because staying in your lane is hard.

And so it goes.

I don’t have any advice or some lesson learned here, just a poem:

Look at that happy idiot,
He doesn’t give a damn.
I wish I were an idiot...
Well, damn, I think I am!

Cover Photo by Matt Duncan on Unsplash

Dodging Learned Helplessness in Your Teams

Dhwanit Shah — Thu, 27 Aug 2020 15:51:01 +0000

I have long believed that, complicated though it might seem, human behavior is incredibly predictable if you pay attention to their tells. A few weeks ago, a random stream of Google Fu led me to reading about learned helplessness, and like a child that learns a naughty word, I can’t stop telling everyone I know about it.

So back in the late 1960s, a psychologist named Martin Seligman was conducting experimental research on dogs, as one does. He discovered that when they received unavoidable electric shocks, they stopped trying to take steps in avoiding getting shocked--even when it was easily possible. They essentially accepted their fate and just took it. I don’t understand why someone had to conduct experiments to determine that when bad things happen to you, you expect more bad things to happen, but here we are.

He went on to conduct similar experiments on humans, but by playing loud noises instead of electric shocks, because people are liable to punch you in your tenders if you shock them. Turns out, when things are hard, we tend to want someone else to do them.

Learned helplessness is the expectation that outcomes are uncontrollable, and having worked for most of my life in some sort of “IT guy” capacity, holy shitsnacks is this true.

I work with quite a few college students, recent graduates, or people who are new in the IT field. This has given me the opportunity to help many people not make many of the early career mistakes, including not attempting something they for sure don’t know how to do. Taking risks and attempting something you don’t know is important to get better. Now that doesn’t mean running update queries in production when you don’t know what it does, but trying something you’re bad at is a great way to be not as bad at it the next time you do it.

When we have new interns start, we let them pick out a rubber duck. They are told they can ask anyone for help with anything, but they have to ask their question to the rubber duck first. Framing the question often gets you the lead you need to solve it. If they don’t have the answer after speaking with the duck, they can find someone who knows.

This also comes into play with end users, though it’s not always effective with everyone. Whenever we’re making a technical change that will affect how the users behave, I go out of my way to provide an explanation for the why behind the what. Most end users could care less about changes to your firewall or to the underlying framework behind your software, but the more aware people are, the less likely they are to simply accept it when something doesn’t work, waiting for someone else to do something. Knowing they have a way to get involved in the process is an empowering prospect for someone who is traditionally expected to just shut up and use the tools they are given.

In every group I have worked in, I set up multiple channels for end users to report anything unusual they see--and highly encourage them to do it. If you see something, say something! Oftentimes what they notice is a non-event, or they found something that’s already been reported before. But once in a while they stumble upon an edge case we hadn’t considered, or a design element we hadn’t thought of. The more involved the user is, the less helpless they are likely to feel--and the less likely they are to cause you additional work.

And that is my ultimate goal--to never put off till tomorrow what I can avoid doing altogether. Trust your users, trust your team mates, and worry less.

Not All Men…

Dhwanit Shah — Tue, 11 Aug 2020 11:04:11 +0000

It is a sign of my privilege as a man that until very recently, I did not realize that "not all men" was the man equivalent of “all lives matter”. It's the argument men jump to when they hear about a woman being harassed or discriminated against or otherwise mistreated in the workplace, or at school, or at the store or basically any other place they exist.

“Sure, yeah, by bad actors, but not all men are like that…”

Sounds completely reasonable, right? You don’t pick on women, you don’t make rude comments to women--hell you’re half woman yourself, on your mom’s side! After all, you have sister(s)/daughter(s)/wife(s)/neighbor(s)/celebrity crush(es) that are women. You’re a decent man, not like those other jerks, so you’re good to go, right? But being a man automatically gives you a leg up in most industries, and you likely don’t even consider it. Men are automatically considered more competent and harder working than women, and that’s a privilege you should acknowledge.

Many years and a few lifetimes ago, I was the manager of an infrastructure team. My wife was a software engineer at the time, which made me, by association, pretty woke. I had also hired a (talented/hard working/fully qualified for the job) woman, which pretty much proved that I was one of the “good ones”. The average maturity level of all the men on this team was that of a 13 year old, and we routinely picked on each other with jokes that weren’t exactly safe for work. The woman on the team, J, noticed early on that we behaved differently when she was around, and insisted that we treat her like “one of the guys” because she was totally comfortable with our dumb jokes.

She wasn’t.

We’d also routinely schedule down time and maintenance after hours and on weekends. While several of us had kids, we almost never considered childcare before scheduling these outages. J was a single mother and sole caretaker of her three children, but she would agree to these crazy hours, always insisting it was no big deal.

It was.

I periodically had one on one meetings with every member of my team, and they were set up on the calendar. The ones with the men were often skipped because we had chatted over coffee or lunch or during a late shift at the data center recently, but the ones with J usually happened in a conference room at the scheduled time. I didn’t offer to have lunch or coffee with her alone, because it felt awkward, and she said the extra formality just for her did not bother her.

It did.

These things did not occur to me as strange at all at the time. My wife had faced blatant sexism at every one of her jobs so far, and I was upset, outraged about the behavior of these horrible men with big egos and small egos (heh heh), while being completely confident I was doing everything right.

I wasn’t.

I now lead a team of some of the brightest technical minds around, and half of the team comprises women. While I feel confident that every person I hire is the best person for the job, the higher than industry average for women on this team is not an accident. I feel like I am definitely one of the “good ones” now. But when I check with my wife about things I say or do at work, I still find that I have more to learn.

You can’t truly experience what things are like for someone you are not, but acknowledging that you were allowed to jump higher than someone who did not have a safe place to fall can help you make better decisions.

“Being privileged doesn't mean that you are always wrong and people without privilege are always right. It means that there is a good chance you are missing a few very important pieces of the puzzle.”

― Ijeoma Oluo

Things Are Getting Out Of Hand

Dhwanit Shah — Fri, 24 Jul 2020 03:57:28 +0000

The concept of hell as a place you go during your after life if you are “bad” has been around since the day humans developed the ability to bullshit. Some believe hell is weeping, wailing, gnashing of teeth, darkness, flames, burning, torments and everlasting punishment. Some others believe it is a low budget courtroom drama where all the bad decisions in your life are played out by actors that don’t look anything like you, and you’re expected to explain your actions. The reasonable among us believe hell exists right here on earth, and we experience it daily. I was at a Starbucks the other day and after waiting in the drive through lane for, like, 4 minutes, they tell me their cold brew machine is down. I had to drive 2 more minutes to another Starbucks to get my fix. You think that other stuff is worse than this agony?

Okay fine, the modern definition of “hell” among us sinners is more like a mild inconvenience than true adversity--a heck, if you will. It is also fair to say that for the past few months, the vast majority of us have been living in heck, and I, for one, am tired of suffering through it quietly.

This global pandemic has forced me to spend entirely way too much time away from work. I have been unwittingly made to spend more time with my child and to get far more involved in his education and frankly, his personal life--learning about his hopes and dreams and hobbies? Seriously. I have been coerced into the unfortunate situation where I have several additional hours a week I usually spend commuting that I now spend walking my dogs and sharing quiet moments with my wife as we both catch up on our many hours of phone reading. I have been exercising more and grumbling less, and find myself in a better mood more often. There is a disturbing amount of positivity around me.

It’s not just at home either! I am experiencing heck at work as well. I am spending a tiny fraction of my time in long meetings now than I used to. The awkward small talks in the kitchenette with whatshisface from that other department have all but vanished. Incidents where someone interrupts me in the middle of debugging an issue, irreversibly breaking my train of thought and costing many more hours of frustration have all but vanished. The monotony of staring at a computer screen, unable to control lighting or temperature or ambient noises has now been replaced with occasional visits from the pets, the child and the wife. That's entirely just too many good things for a reasonable adult to function--no one can be expected to be productive in this kind of environment!

And it gets worse! This epidemic appears to have spread to the rest of my team as well. People are being far more productive than they were before, causing us to deliver projects under budget and ahead of schedule. Can you imagine the precedent this is setting? It’s almost as if the point that software developers work better in remote settings is being made for me with actual facts and tangible results. Meetings are being replaced with Slack conversations and emails that are far better thought out. People are collaborating more and getting along better. Folks being able to work on their own schedules has put them all in far better moods, leading yet again to more productivity. At what point do we draw the line and say, enough is enough!

It's as if despite my best efforts, something useful is coming out of this crisis. Something like this can’t possibly force our hand into using technology that has been available for decades to permanently change how we work for the better. How can we claim to be a part of a functioning society if we can’t even pack people into wide open spaces lined wall to wall in cubicles, with oppressive lighting and a constant hum of background noise? How are people going to contribute to the larger picture if they can’t be present during all the unrelated conversations that happen around them for the times when they might serendipitously add something to the idea? Without an oppressive environment chipping away at their very being, so that they are a partial husk of themselves by the time they make it home at night, how are they expected to grow as the future leaders? This is not the America my moderately well to do parents emigrated to.

It's not enough that we as a species have made it to the top of the food chain, but now we have to think about things having more than one dimension?

"When life gives you lemons, don't make lemonade. Make life take the lemons back! Get mad! I don't want your damn lemons, what the hell am I supposed to do with these? Demand to see life's manager! Make life rue the day it thought it could give Cave Johnson lemons! Do you know who I am? I'm the man who's gonna burn your house down! With the lemons! I'm gonna get my engineers to invent a combustible lemon that burns your house down!"
-Cave Johnson

How I Retain Amazing Developers

Dhwanit Shah — Sat, 23 May 2020 02:19:53 +0000

If there’s one thing I hate more than being micromanaged, it is having to actually micromanage someone. I have had my fair share of working for and with managers who want to have a say in every aspect of the work done by their teams, and that just seems like such a miserable existence to me, akin to telling my keyboard how to convert my intentions into electrical signals, or telling my car engine how to, uh, engine. Yes, yes, referring to people as inanimate tools that you use is probably not a great analogy. But then, I’m not that great of a person.

Moving on.

My job as a manager is to make sure my team succeeds, because if I could do all the work my organization needed done, I could just do it myself. It doesn’t matter how great of a developer I think I am, I am bound to make more mistakes than a team of developers. Having more people ensures that my company doesn’t have to pay for the sum total of all of my mistakes.

Mistakes Happen

Speaking of mistakes, the first rule of software development is, people will make mistakes. Doesn’t matter how experienced they are, doesn’t matter how much testing is performed, mistakes will happen.

Technically minded people tend to think in binary terms more often than not, and getting them to accept this is often difficult. This doesn’t mean delivering a sub par product is acceptable, of course, but once they understand that making a mistake is acceptable in my team, I can actually see a marked increase in their performance.

I Lower Hanging Fruit

As I mentioned in my previous article, people go through quite a bit of testing before they join my team. The upside to all that testing is, before they start, I have a pretty good understanding of their development ability, and I can adjust our approach for their assimilation in the rest of the team to what makes the most sense for them. Even if they have experience in every technology we use, I don’t actually expect production quality work from a new member on the team for at least two months.

“If you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.”

I accept and fully embrace that happy people do better work. I get that some jobs require you to be present bright and early, and to have butt in seat time during business hours, but you can easily get away with not requiring that from most of your employees, especially software developers.

All Ducks Are Birds But Not All Birds Are Developers

I have been a software developer for a couple of decades, and at just about every place, most of the staff was non-technical. Developers are usually treated the same as other employees, especially when it comes to working environments.

The thing is though, software development isn't the same as selling or marketing. Sometimes it takes hours to get to the bottom of a problem, and a simple distraction like your neighbor asking you a question could set you hours behind. So on my team, every developer gets an office where they can close the door when they want to, select how to furnish it and what type of desk or monitors or keyboard they use, adjust the lights and temperature, and determine the hours that work the best for them. It's not always easy convincing management to allow for such large concessions, but I can do it because it brings results. It's shocking how well a Lamborghini performs when you don't try to haul lumber in it.

I Encourage Honesty

The world would be a better place if more people would say what they think instead of bullshitting. I understand the need for diplomacy, but there’s a difference between calling someone’s baby ugly and telling the emperor he has no clothes on. I encourage everyone I work with, especially people on my team, to be honest and upfront with me, knowing that if they told me the truth, even if it was unflattering, I would not react badly towards them. I am not paid by my employer to boost my ego--I am paid to bring results. If they trust me to take bad news well, I am more likely to find out about something bad happening when it actually happens, rather than when it gets noticed by others. I am also honest with them when something they are doing isn’t working out, which helps avoid conflict in the long run.

I Bulldoze (Some of) Their Problems

I make it a point to meet with every member of my team at least once every couple of days, and often it’s to talk about something not related to work. Rather than reciting platitudes about how “my door is always open” and “you can always talk to me”, actually engaging in a dialog with my team members makes it far more likely that they will feel comfortable sharing something with me.

Every person on my team is here because they know more about some aspect of our technology stack or our business than I do. It isn’t often that I can find a solution to their problem on the spot, but I try to fix it for them anyway. I have one on one meetings with each of them every 3-4 weeks, where I ask them to take their most annoying or time consuming problem and make it mine. I will either solve it for them, or find someone who can. This doesn’t always work, because not many people are comfortable just passing the buck on a problem they feel they need to be the one to solve, but I have found that if I keep offering, eventually they pick me up on it.

Reality Check

Unless your primary product is a piece of software that is used by other software developers, the work you end up doing is rarely completely aligned with what you think is the best possible way to do it. Technology tends to change much faster than the business around you, and while you’re ready to toss everything that was done over the past two years for the next shiny thing, the business is more focused on the “what” of your tool, not so much the “how”. So a pragmatic approach to real world software development involves balancing the “cool” with the “functional”. And this means that your developers need to actually understand your business, and not just the product they are working on--knowing the “why” behind the “what”.

Keep the Stones Rolling

I make it easy for my developers to stay on top of what’s new by making sure that they not only have access to training resources, but also the time to actually learn new things.

“Even the finest sword plunged into salt water will eventually rust.”

Even if what they’re learning is only tangentially related to the work that we do today, there’s no telling it won’t be useful for a future project. Time spent learning is never wasted. In fact, over the past year we’ve enrolled people from several non-technical areas in the company in programming classes, which has not only helped our users become more tech savvy, it’s drastically improved the interactions they have with our developers because they’re able to understand the moving pieces behind the curtains much better.

Dollars spent on training far outweigh the dollars gained in increased productivity and additional harmony with the muggles. I mean, uh, business users.

Ultimately, this isn't something I do just out of the goodness of my heart--though it does make me feel great to be a part of a team where people like working with each other. This just makes sense. It takes extra effort on a day when you're feeling stressed out and annoyed to put your problems on hold and help someone else with theirs, but it ensures the larger machine keeps functioning.

I have seventeen people on my team, with education ranging from high school to doctorate, and with backgrounds in several different fields. This is the first job out of school for some, while some have been doing this work for decades. Some are parents of young children and work remotely, some go to school at night, while some work odd and unpredictable hours. They are immigrants or first generation Americans from eight different countries--many of whom we sponsor. Different cultures and languages and experiences, but we are able to function together as a team because there is mutual respect, and a common goal of building things that are, frankly, bad ass. And in all honesty, my job is far simpler now than it has ever been before, because all I have to do is remove the occasional roadblock, and we all go home feeling good about what we've accomplished on most days. Even setting aside the feel good element of this setup, this is a far more cost effective way for our business, because this team easily delivers the work product of a team twice its size.

TL; DR; Train people well enough so they can leave, treat them well enough so they don't want to. --Richard Branson

How I Hire Amazing Developers

Dhwanit Shah — Fri, 22 May 2020 23:16:50 +0000

It takes me about three months to hire a new software developer, from the time we decide we're looking to hire till I put out an offer to a candidate. I've been told that this process is too slow, or that my standards are too high, or even that I am too hard to please. I agree that it's a slow process, but I have had some great results with it, and I hope that years of my wasted time coming up with this will help save some of yours.

"IT people don't work well with others"

This is a phrase I have heard uttered by business leaders at just about every organization I have been a part of. And there’s some damning evidence to support it. Technical work, especially in an organization where its primary product or service is not technology, sometimes breeds cowboys who don’t work well in teams.

In my younger (and more egotistical) days, I had the reputation of someone who didn't work well with others, but I made up for that by delivering projects ahead of schedule and under cost. Of course, I did this by working twice as hard as I needed to, just so I could prove that I could do it alone. I also found the idea of taking partially baked ideas and building them into full fledged solutions exhilarating. It also didn't hurt when people marveled at how I managed to get it all done... alone. I often found myself saying things like, "this isn't like digging a ditch where two ditch diggers will work twice as fast as one," to push back on business leaders asking to add more developers to a project.

Attitudes like these are not only accepted in software development, but sometimes expected. I have seen my fair share of companies that are held hostage by a "mad genius" that built everything, but now refuses to share knowledge. On several occasions, I have been hired to help the company mitigate their risks by having me find where the bodies are buried, so to speak. This gets them out of the ditch for a little while, but without a shift in attitude from the leadership, they end up in the same ditch again. I once lead an effort that ended with me being the next trigger man, and made it a professional goal never to create a situation like that again.

I have put together IT teams in several companies now, and hiring software developers that work well with others has always been harder than other IT professionals. It may just be that my approach with developers was lacking because being a programmer myself I had higher requirements from developers than from "hardware people", but even if that were the case anyone who has had to build a team of developers will tell you it's easy to make mistakes. After over a decade of trial and error, though, I think I have found a strategy that works, and I will outline it for you here.

More Time on the Job Description

I have put together IT teams at several companies now, and hiring software developers that work well with others has always been harder than other IT professionals. It may just be that my approach with developers was lacking because being a programmer myself I had higher requirements from developers than from "hardware people". Even if that were the case, though, anyone who has hired developers will tell you it's easy to make mistakes. After over a decade of trial and error, I think I have found a strategy that works, and I will outline it for you here.

No Technical Interviews in Person

Hire technical people with asking them technical questions? Seriously?

Yup. Here's the thing: an interview isn't a normal situation. Will the candidate ever have to write code on a white board in front of an audience after they are hired? Will they have to take quizzes about archaic functionality of a programming language? If not, why ask them to do it during the interview?

More Testing, Less Talking

I test candidates on things that matter. An aptitude test that determines skills in math, verbal acuity and spatial reasoning. A personality test that rates twelve different areas of personality that would determine what working with this person would be like. And a project for the candidate to demonstrate their coding and problem solving abilities. I give them some code that compiles and runs, and includes unit tests that fail, because a method is incomplete. A document explains what they have to do to complete the project, and if they do it well, the included tests will pass. Someone that can code could complete it within 2-4 hours. The project is written in a way that even someone not as familiar with C# could work it out, if they know how some other object oriented language. It’s a problem that has several different solutions, and their code gives me an insight into how they think and how they work. Did they fully read the whole spec, or just enough to pass the included tests? Did they consider edge cases not covered in the spec? Was their approach similar to how the rest of our team works? Do they have strengths where we have weaknesses?

Data > Gut Feeling

Bringing a person on our team has a lot to do with gut feeling. But this is the same gut that told me eating yogurt two weeks past its expiration date was a good idea. Do I really want to make a decision that could cost our company tens of thousands of dollars based on that fickle jackass? But if I could get some data on aptitude and personality, now I can compare apples to apples. Low on patience and low on excitability? No thanks, the position of annoying talking animal is already taken. By me.

Will They Like The Work We Do?

Next, I pick a task off our actual backlog that’s representative of the work we do and can be done in roughly 6-8 hours. I modify it so someone without knowledge of our codebase can still work on it, and have the candidate work on it as a paid assignment. Same as before, I give them a software solution that is mostly built, so they can focus on only the meat of the problem. This tells them what kind of work they'll do when they join our team. If they don't like it, we go our separate ways, but they're still compensated for their time.

Will The Rest of The Team Like Them?

The last step is the actual interview.

Many candidates that make it this far come from other parts of the country, so I fly them in and have them spend some time in our office. If possible I have them attend one of our team meetings, so they can see our dynamic. I also take them out to lunch with other team members, so they can interact in a low pressure environment. The goal is to get them to see who we are, and for us to see who they are--not just who they are presenting themselves as at an interview.

And then I ask my team how they would feel about working with this person. They will spend a lot more time with this person than I will, it's only fair that they get a say in the decision. And if their response isn't an enthusiastic "yes", I take it as a "no" and pass.

They May Be Right For Us, But Are We Right For Them?

Interviewers spend a whole lot of time trying to determine if a candidate is right for the position. They may stop to check if there are any questions, but more often than not they don't go out of their way to make sure this place will be a right fit for them. The attitude is, well, I'm the one doing the hiring so you need to impress me! If someone starts working here and then realizes that this isn't a good fit for them, at best we'll have an unmotivated employee, and that's not going to work out well for anyone involved.

It's Worked Wonderfully For Me

So there's my blueprint to hiring talented developers that like coming to work. It's helped me hire people that not only know how to do what we want them to do, but actually want to do it. People that I interview, even the ones that don't end up getting hired, routinely tell me how much they enjoyed the whole process. Many have told me they would use this process when they get in a position of hiring. It may not work everywhere, but the team we built with this approach has accomplished some amazing things at Energy Ogre.

Did I Mention The Process Is Slow?

I lose about a third of candidates on the aptitude/personality testing phase. Of the ones that remain, more than half drop out during the first coding project. Another fourth or so drop out during the paid project phase. But once someone has made it through those steps, I feel pretty confident that they are technically capable, and when we meet in person the only thing we need to focus on is how well they will fit in to our team.

I have gone through over 2,000 resumes and had hundreds of interviews, and ended up with a team of 10 developers, all of whom were hired through some variation of these methods. Just about all software used by our employees and members is built in-house by this team, and together the tools we created have had a market impact of over $100 million within the past three years, and helped many tens of thousands of people in the process. Every developer that came on full time has stayed with the company since. Not all of them had programming degrees or had worked as programmers before, but they all proved that they could learn, and are now able to perform. There is so much mutual respect between them that disagreeing and arguing competing points has never lead to issues. We’re more aware of each others’ personalities, about what kind of work each of us prefers to work on, and how we prefer to do it. This makes us work much better as a team, and as their manager I am far more aware of what is likely to motivate each of them to do their best work.

TL; DR; If you spend a lot more time up front before you hire a developer, you will save exponentially more time later, produce far superior results, and have more fun managing your team.