Tag Archives: soft skills

Holy Wars

1 Reply

I suspect most software developers worth anything will agree that language/technology/editor holy wars are bad. Why specifically though?

A holy war is at its core someone trying to convince you that they know the ‘one true way’. I’ve come to learn in my travels through this industry, and indeed life itself, that there is never ‘one true way’. The real truth is often much more complicated than a single best solution might claim to provide. Furthermore, most holy wars are actually about things that usually are the those that matter the least in the context of great software development. Spaces or tabs, Emacs or vi, newline braces or same line braces; It’s all the same and usually comes down to pure personal preference (though I’ve found most are not willing to admit that is so).

Time is your currency on earth: Spend it solving real problems worth thinking about.

How To Hire Great Developers

2 Replies

In a previous set of posts I talked about how the difference between an average developer and a great developer is enormous, how bad developers can effectively cancel-out your good developers, and why you therefor need to hire just the very best.

So how do you tell if someone is good? or bad? What are the core competencies and key indicators of an ‘A’ player developer? And how do you interview for them?

Great Developer Key Indicators

The following is a list I’ve accumulated over time. It’s never complete, and certainly up for discussion, but in my experience is a pretty good set of indicators for whether a developer is an ‘A’ player or not.

Great developers:

  • Can deal with many levels of abstraction simultaneously.
  • Are masters at managing complexity.
  • Know space and time trade-offs of the major data structures.
  • Understands multi-threading, resource locking, and how it’s implemented.
  • Understands that simple is better than complicated, every time.
  • Has used a DVCS (git, mercurial, etc).
  • Are masters at managing expectations.
  • Plays with new technologies and languages and stays aware of upcoming developments.
  • Understands what TDD is and why it’s a valuable practice.
  • Is likely to develop iteratively and incrementally, adding value with each release.
  • Understands how to accomplish loose-coupling and encapsulation, especially in things that are likely to change.
  • Is not a lone-coder who goes dark for long periods of time.
  • Knows how to communicate well, not just with developers, but all levels of management and stakeholders, and can adjust communication vocabulary/style per context.
  • Knows SOLID principles and practices them effectively.
  • Recognizes that code reviews are excellent ways to improve yourself, both as an author or reviewer.
  • Can grasp the bigger picture.
  • Doesn’t just accept work items and marching orders, but also proposes alternatives and improvements.
  • Knows 1 procedural language, 1 object-oriented language, 1 functional language, 1 scripting language, 1 statically typed language, and 1 dynamically typed language. (There is much overlap between these categorizations)
  • Fluent in major design patterns and how/when to implement them.
  • Knows most of these books:  Code Complete, Pragmatic Programmer, Clean Code, Mythical Man Month, Design Patterns by the Gang of Four, Programming Perls, Code: The Hidden Language of Computer Hardware and Software, C by K&R.
  • Keeps up with development blogs/twitter/podcasts.
  • Is highly passionate about software development.

Bad Developer Red Flags

There are some simple things you can do to immediately weed out the really bad developers in an interview scenario.

  • Have them write FizzBuzz; believe it or not most developers do poorly on this, and it’s a great way to identify them early on in the process.
  • Ask them what the last new language or development environment they learned was. If it’s been a long time since they’ve learned a new one, that’s a red flag.
  • Ask them what they think a great developer’s best attributes are. If the answer isn’t in the list above, it’s probably a red flag.
  • Have them explain dependency injection to you, and a simple example. If you get a deer-in-headlights response, it’s a red flag.
  • Ask them to solve problems that involve in-place manipulation of a linked list or string. If they don’t understand pointers or space/time complexities of a problem, that’s a concern. ‘Reverse a linked list’ is a good one to ask.
  • Find out if they have a GitHub/BitBucket/Codeplex/SourceForge.  Look for evidence of development both inside and outside of work.

What NOT To Do

  • Don’t ask questions that are just quick facts. A programmer that knows what port IMAP runs on isn’t going to be a better programmer than one who doesn’t. Knowing little C compiler optimizations doesn’t make you a better programmer.
  • Don’t just ask questions with verbal answers, or open-ended answers. Actually have them write code on the whiteboard. A lot.
  • Don’t use questions that are common enough to where they could be googled before hand or memorized.
  • Don’t just be satisfied that someone answered something correctly. Talk to them about their solution. Ask them to modify it. Ask them to test it. Challenge their thinking.

This is an organic post, and I suspect I’ll add many suggestions from readers.

 

Why You Need To Hire Great Developers, Part 2

18 Replies

In my last post I talked about why you need to hire great developers, and how the difference between average and great developers is easily 20x.

Recently, Robert X. Cringely found and restored an hour long interview with Steve Jobs from his days at NeXT. He’s put it up on the web as Steve Jobs The Lost Interview. In this video, you really get to see first hand a lot of Steve Jobs thinking. What I found interesting, in a deja-vu sort of way, is the following remarks from Steve Jobs about teams and the dynamic range of software developers:

“I observed something fairly early on at Apple, which I didn’t know how to explain then, but have thought a lot about it since. Most things in life have a dynamic range in which average to best is at most 2:1. For example if you go to New York City and get an average taxi cab driver versus the best taxi cab driver, you’ll probably get to your destination with the best taxi driver 30% faster. And an automobile; What’s the difference between the average car and the best? Maybe 20% ?  The best CD player versus the average CD player? Maybe 20% ? So 2:1 is a big dynamic range for most things in life. Now, in software, and it used ot be the case in hardware, the difference between the average software developer and the best is 50:1; Maybe even 100:1. Very few things in life are like this, but what I was lucky enough to spend my life doing, which is software, is like this. So I’ve built a lot of my success on finding these truly gifted people, and not settling for ‘B’ and ‘C’ players, but really going for the ‘A’ players. And I found something… I found that when you get enough ‘A’ players together; when you go through the incredible work to find these ‘A’ players, they really like working with eachother. Because most have never had the chance to do that before. And they dont work with ‘B’ and ‘C’ players, so its self policing. They only want to hire ‘A’ players. So you build these pockets of ‘A’ players and it just propogates.”

 

Respect Among Software Developers

5 Replies

Software Developers are really smart people, and that’s good. Unfortunately, there’s a subset of software developers who have a bit too much pride in their abilities, and compete with others as a way to convince others (and themselves) that they’re the smartest. It’s important for them to prove their superior abilities to you.

It’s too easy to view someone else’s code as being of poor quality, and convince yourself that you’d know better. It’s a lot harder to understand what circumstances caused the code to be in the condition that it’s in. It’s a lot harder to recognize intelligence in others.

Don’t Suffer Jerks

This is really important.

Gifted developers who have accomplished a great deal can sometimes be very difficult to deal with. You don’t have to look far to see examples of this:

Often this type of person is in a position of control. Sometimes this can be referred to JDD (Jackass Driven Development).

I’m sure you’ve seen it before. Usually this person is the one making all the big decisions, and who can break the rules because of his status. Usually this person has job security, because they are the only one who knows about thing X in the system, or is the only one who can fix thing Y when it has a problem. He’s the first one to point out problems, but never the first to point out a better solution. He’s the one everyone has to tip-toe around because of his superior status in the eyes of upper management. It seems like most organizations have one of these.

Don’t suffer this kind of person.

They aren’t as necessary as they might seem. Remove your dependency on this single-point-of-failure earlier rather than later. If you don’t, the organization will get slower over time as the paralysis of the dependency set in. I’ve said it before but it’s worth repeating: One gifted ‘hero’ programmer is not as important as having an entire team of average-to-good developers who can work together.

Criticality and Communication

Leave a reply

My wife and I had a discussion last night as we walked home from a screening of the extended edition of Lord of the Rings: Fellowship of the Ring.

Being a nerd, engineer, computer scientist, programmer, coder, web developer, or any other such title that you can lump us into, is hard. The increasing complexity of technologies and languages mean that we have to constantly keep learning, otherwise our abilities will languish and fall behind.

As hard as that is, it can be even more difficult for nerds because of the way their brains are wired. The biggest difficulty for some is actually around interpersonal relationship skills. We nerds find others behavior to be strange and alien; We don’t always understand. We marvel at how easily it can come to some, but at the same time we find that behavior baffling, because we don’t think the same way. We see the world through monochrome tinted glasses; A world of boolean logic, in which something either is, or it isn’t. This polarizing conviction is the same thing that drives a lot of deep seated views, holy wars about technologies, which editor to use, whether to put the braces on the same line or a new line, etc. We’re also very critical of those things which are not tidied, tied off, cleaned up, made parallel, and understood.

When you confront someone with a different view from their own, and that view is firmly seated in their mind, something psychologically interesting happens. They  actually end up sticking to what they know more adamantly than before. This is known in the psychology community as the ‘backfire effect‘. My wife postulated that this might actually be the cause of many of the world’s big problems (religious wars, government stances on moral issues, etc).

Nerd psychology is a vast, complex topic. The personality of the ‘alpha geek’ is so pervasive in the industry of software engineering, that you can often times learn how to deal with anyone of the type just by observing one. The know-it-all arrogant attitudes are like a poison, a poison which threatens to turn our programmers world of creation into a cesspool of bickering. It’s easy to dismiss someone as not being as intelligent, but it’s a lot harder to discover where your intelligence has holes. The value of other perspectives in software engineering cannot be overstated, and is too often a blind spot for otherwise gifted developers.

Don’t Go It Alone

Leave a reply

Are you the sort of software developer that holes up in their office and rarely collaborates with others on work until your ready to cross the finish line? Or are you the sort of developer who actively involves others in your process?

Many software developers have the notion that if they work on something in isolation, they have the freedom and flexibility to define the process. We devs tend to feel like our way is the best way; You can see it when we inherit someone elses code, as our WTF-per-minute count spikes. However, if you’re always working under that model, you’re really missing out on your full potential. In my experience, here’s what you may be missing:

The Gold Plating Leash Handler

We love building castles in the clouds. It can sometimes be difficult to apply the YAGNI (You ain’t gonna need it) principal judiciously. It’s easy to be tempted to write code that is not necessary right now, because we’re trained to think about how our software might be used in the future. We love to refactor the hell out of code until it’s absoloutely perfect. We know that isn’t ever going to be true though. You need someone who can see the forest through the trees, or at least act as a reminder.

Two Eyes Are Better Than One

I would hope this one is obvious by now, but you must have a code review. By the very definition of humanity, we are imperfect, and therefor not having a your code reviewed is basically accepting that your code will fail to work properly at least some percentage of the time. Also, if you are humble and accept the fact that others will indeed have better ideas and perspectives (or at the very least, different perspectives than yours), you will be cognizant of the value others can add. In fact, I’d go so far as to say that there is a hard limit on the amount you can improve as a developer without outside perspectives and ideas.

The Squelch Filter

The stakeholder is always going to try and squeeze “just one more” feature/story in. The business is always going to wish you’d work faster, and for longer hours. You need someone to hold off the barrage of work that will come your way, the meetings, the last minute tasks, etc. You need someone to sift through the pile of work, pick out and prioritize it, and interface with you and the stakeholder in such a way as to maximize your productivity without exceeding the means that you are capable of.

In Summary

Working alone is fantastic. You wield complete control over the direction of your development process. But in the vacuum of your kingdom, you miss out on your fellow developers insights and knowledge assets. Don’t go it alone.