Great kid, don’t get cocky….

Those immortal lines uttered by everyone’s favourite space smuggler… they ring true to me more often than I would like.

Development is part art, part science… some bits are perfectly measured repeatable bits of functionality bolted together, some parts are more “gut feelings” or instincts. Sometimes, especially when starting a new project, or even new block of functionality decisions need made. What technology stack do we use? What language do we write in? How should we approach this? and usually in the back of your head somewhere… “What if we get this wrong?” I guarantee you every Technical Architect, Senior Developer and CTO has thought that at one point.

What if I suggest something and it’s totally wrong?

Now, lets use a metaphore here… driving. Would you get in a car with someone who had been driving a few months or years, and thought that they were the greatest driver on the planet? Michael Schumacher reborn. Couldn’t make a wrong decision if they tried. Hell no. That person doesn’t make mistakes, everyone else does. They would drive beyond their ability, too fast, break too late, swerve in and out of traffic. It’s dangerous. Lets call this driver number one.

Now what about the other side of the spectrum… would you get in a car with someone who always drives 10mph under the speed limit, grips the steering wheel like their life depends on it, does a 5 minute check of the car and engine before setting off every time and sits at junctions waiting for a mile of space? Hmm, for a while but you wouldn’t get anywhere, everyone else on the road would hate you and do everything in their power to get away from you. You would probably get pretty frustrated quick. This person might be a good driver, but their lack of confidence is holding them back. Lets call this driver number two.

I’ve seen those two scenarios played out with developers before. Mostly in young developers (including myself) right the way through to senior level (including myself) the first usually happens slowly over a period of time, the developer delivers a few successful projects/functions, someone else doesn’t, they think “huh… I’m pretty good” and that slowly simmers. It builds over time, they start to flaunt that superiority, maybe talk down to peers or juniors.. and they really do start to think that they are king of the hill. These developers can make potentially great devs feel bad about themselves, maybe even doubt their own skill… keep quiet at standups, and think that maybe this career isn’t for them. These people are poison. If you don’t quickly meet this with antidote, it will kill creativity, talent and progression on your team.

Driver number two, the timid one, the who is scared of his or her own shadow (which can frequently be caused by driver number one if left unchecked) could be a talented dev, maybe they just don’t have a huge amount of experience, maybe the made a bad decision once and got chewed out for it… but when left with a job to do, they freeze up. They google stuff, they don’t understand the first answer on StackOverflow, so they assume it’s too complicated for them and they start to doubt themselves. They don’t trust their own ability, if they can’t copy and paste the answer, they don’t move forward. You check on their progress two weeks after giving them some work to do, they are nowhere, a few commented out lines in ConsoleApp1… “Why didn’t you ask someone for help?” … “I uh… ummm..  I dunno”

Both of these people need checked ASAP.

You need to take developer/driver one aside and have serious words with them. Maybe they are talented, but they are part of a team and need to work with others. Maybe they are afraid if they don’t stand out they will lose their job, you need to reassure them that helping others and being a team player gets them a lot more credit than being a semi-talented lone wolf. There are no John Wick’s of Software Development. You can try assigning them someone to mentor, and make sure they both get some credit when the padawan gets something right. Driver number two needs some attention as well, this one can be equally as challenging, are they actually just shy or are they really not cut out for this? Some one on one meetings, training courses (I am a huge fan of pluralsight), positive reinforcement, make sure they know they are valued and can speak up… if there is a developer one holding them back, try and identify that problem and negate it. Maybe find an area they are good at and make that their baby, work with them and suggest things, make sure they are on track, and get some success under their belt.

Brining out the best in your team members, whether they be peers, juniors (or even seniors) is by far the best tool for productivity you can get. There is a great happy medium between the two drivers. Make decisions, suggest other options, be prepared for other people to have different opinions, learn from them. You can’t freeze up and hide when you don’t know something, or if you get something wrong. That being said, you will make mistakes, and that’s ok, everyone does. You learn from them, and you can help others avoid them in future. A bit of confidence can be a great asset for getting started and moving forward, generating momentum when things get stale. A cautious step can stop you getting too far down the road with the wrong tools or design. Find that balance and you will save yourself a lot of headaches.