Wednesday, December 24, 2008

Are Engineers’ Minds Wired Differently?

Back during the dot-com boom of the late 90’s a lot of people jumped into the IT field because they saw plenty of jobs offering good pay. And for a while they did fine, at least until the bottom fell out. Then many of those people washed out of the industry, leaving mostly the ‘core’ engineers with stronger technical skills and programming abilities. And in fact another version of that shakeout is also occurring today as I write this article.

So why did people who entered the field from outside ultimately not fare as well? Or more generally, why do some people succeed in software engineering, while others flounder? It can’t be a simple matter of comparative intelligence since smart people exist in all fields, and there are many smart people who just don’t ‘get’ programming. Even people you might think of as ‘nerds’ don’t always perform well in the programming realm. So what separates two people, both of them smart, but where one of them can program well and the other can’t?

It’s been said that engineers’ minds are wired differently than other (normal?) people, and this most likely applies even more to software engineers. Some will point to Meyers-Brigg and other personality tests to evaluate a person’s suitability for analytical tasks. However, just what does it mean to say that a task (or a person) is analytical?

I like to think there are two types of people in this world -- and I don’t mean those who like to categorize people and those who don’t. One group is interested in outcomes, and the other in the mechanics. Computer nerds might compare this to declarative vs. functional languages, if that makes any sense to you. An analogy is when a person admires a new car. Do they appreciate its aesthetics and comfort, or do they digest the specifications and performance numbers? Of course the two are not mutually exclusive, but people sometimes lean towards one or the other. Also think music fans vs. audiophiles.

Beyond the personality differences, there are also very real skills required to be successful in software engineering. Some of these skills can be taught, but others are innate. For instance, there is the ability to see patterns and complex relationships in large systems. Some people can easily juggle highly abstract, non-visual concepts in their head. They can read or hear about a concept and instantly see how it can be applied in a myriad of problems, and also understand where the approach might not be appropriate.

These people can look at a screenful of text (source code) and envision a program’s flow of control and spot logical errors. They can think of the possible potential and combinatorial ramifications of various decisions without resorting to a “let’s see what happens” approach. Like a good chess player they can foresee how various scenarios and branches will play out, evaluating them to a depth and level of detail that would overwhelm most people.

If you remember as far back as the 80’s you might recall the first time you saw a Rubik’s cube. Solving it (at least at first) posed an immense challenge, requiring the ability first to experiment, then figure out how the contraption worked. Thereafter you’d have to evaluate patterns and visualize how you would interact with the cube to get the configuration you wanted. Most people were so daunted by these things that they dropped the cube after a bit of experimental play, but others stuck at it and discovered its secrets. In a way, good developers have the vision, cognitive skills, and perseverance to stick with problems like these and solve them.

I hope this discussion makes some sense to you. I’ve spent a lot of time wondering why some people have better aptitude for software engineering than others, but I still can’t say that I’ve fully cracked the code.

Wednesday, December 17, 2008

What Makes an IN-effective Engineer?

When I ponder this question I think back to the various engineers I have worked with whom I would consider failures in their field. Unfortunately there is no single archetype of an ineffective engineer. Tolstoy once said that all happy families are alike, but every unhappy family is unhappy in its own way. Likewise, you could say that each failed engineer is a failure in his or her own unique way.

I had one employee who could not accomplish anything unless they had all the minute details of their project answered by management. How big should this button be? What should the exact text be for this label? Should I put this code into two files or just one? Perhaps they were trying to please, but they gave the impression of being unable to accomplish anything without excessive handholding.

Another engineer was an avid musician who did his day job just for the paycheck. He would do the absolute minimum work necessary to get by, and his teammates often found themselves having to fix his bugs and generally clean up after his mess. When confronted with the inadequacies of his work, he was a veritable fountain of excuses and blame. He refused to take responsibility for anything, and showed no accountability for his work.

There were also a couple of engineers who were just argumentative by nature. When there were the slightest little details that someone let slip by, these people would pounce on them. And where there were no controversies or disagreements they would manufacture them, just so they would have something to argue about. They did this in the name of generating healthy discussion, but in reality they just liked to argue and waste everyone’s time.

Then there was the fellow who had exhibited decent technical skills and quality, but who just rubbed everyone the wrong way. He was openly critical and dismissive of other peoples’ work and ideas. He was especially hard on non-technical people, all in the name of ‘honesty’. His influence was like poison on the team, and no one wanted to work with him – not other developers, product managers, project managers, QA, or anyone else.

Of course I’ve also had those employees who where well meaning and positive but yet just weren’t quite there technically. A few bricks shy of a load, as the saying goes. Not playing with a full deck. The lights are on, but nobody’s home. The elevator doesn’t go all the way to the top floor. A couple of fries short of a happy meal. But at least I could manage around these employees by assigning them simpler tasks and giving them more time to develop (hopefully).

You may wonder which of these people were eventually let go. Ultimately that’s not important; what is important is that you take away from these stories some qualities to avoid, both in yourselves and any people you might be involved in hiring.

Thursday, December 11, 2008

Seven Habits of Highly Effective Engineers

I want to expand on my previous article and describe effective engineers in another fashion, one that borrows from Stephen Covey, author of “Seven Habits of Highly Effective People”. I read the book a long time ago and while I couldn‘t tell you what all the seven habits were, it still seems like a good way to organize a list of positive traits I’ve seen in effective engineers.
  1. Be Proactive – I’m pretty sure this was one of Steven Covey’s items. Rather than waiting for others to take care of things, do what needs to be done. Volunteer to take on new tasks, to help others, and in general do the things that no one else wants to do.
  2. Follow Through – If you are asked to do something, follow through and report back on your success (or lack thereof). If there’s one thing managers hate, it’s requests that disappear into a black hole. If you are asked to do something, acknowledge the request and report back on it within a reasonable period of time.
  3. Manage Up – Engineers are often notorious for being overly optimistic with work estimates. But they need to be realistic and let management know when too much is being asked of them. This is often referred in management-speak as “push-back”. Otherwise the engineer runs the risk of overcommitting and disappointing everyone.
  4. Always be learning – Even if your job doesn’t offer a way to learn new skills, and especially if your job doesn’t offer a way to learn new skills, you have to work to keep your technical skills current.
  5. Share your knowledge with others – Some think that keeping their knowledge to themselves, whether in the technical or business domain, is a means to job security. Instead, it makes you an impediment. Those who share their knowledge with others will be regarded as subject matter experts and people will turn to them for advice, making them highly valued.
  6. Share the credit, accept the blame – Give credit where credit is due. Make it known whose hard work helped to make things happen. People will return the favor to you someday. Likewise, be wiling to accept the blame – if you screw up, don’t be afraid to fess up and fix the problem. And if you can’t do this because you’re in an environment where making mistakes is severely punished, well -- perhaps you shouldn’t be working there.
  7. Be positive – this may sound trite, but it’s not. Negativity is infectious, and it spreads through the team like a poison. Fortunately, positive energy is also infectious. By this I don’t mean a Pollyanah-ish type of naivete, but rather a “can-do” attitude. Negative people are often quick with excuses why something is not possible, but positive people will find ways to make those things happen.

Monday, December 8, 2008

What Makes an Effective Engineer?

Strong technical skills alone do not make for a great engineer. Believe it or not, coding is not necessarily the most important thing that an engineer does. It takes great communication skills, people skills, drive, and initiative to make a truly successful engineer.

This is not to say that technical skills are unimportant. Of course you need to understand the technology, and you need a solid foundation in the principles of computer science. But this is merely a prerequisite for success, not the full requirement. Technical skills alone are insufficient for true success.

Great engineers don’t just point out problems and expect others to fix them, or worse, just ignore the problems and hope they go away. Rather, they dive in and investigate the problems themselves, even if it’s in someone else’s code. They’re not hung up on finger pointing or on getting credit; they are just interested in getting things done. You can call it initiative, or call it being conscientious – I prefer the fancy term “a bias for action.”

Also, in any decent sized organization engineers will not be working alone in a vacuum. They need to work as part of a team developing features and products, and the entire team needs to be on the same page. To some extent such coordination is the responsibility of the dev or project manager, but each team member’s ability to work well with their teammates contributes to the overall effort. This is what people talk of as ‘teamwork’.

When I talk about teamwork I’m also referring to sharing information. Does the person speak up and volunteer information when they should, or do they stay quiet and withhold key knowledge? Or do they instead talk too much and soak up everyone else’s time? Are they able to split up a task and coordinate work with another engineer? These are important considerations in judging a person’s teamwork skills.

In addition, engineers will often have to work with other people outside of the team. This may involve other technical teams as well as product managers, senior management, sales, etc. These may be less technical or non-technical people, and the way the engineers interact with them can spell success or failure for the project (not to mention the engineers’ careers).

The best engineers are able to communicate with non-technical people in a productive manner, explaining technical issues in a clear and simple manner that everyone can understand. They are able to distill a problem down to the essential points instead of getting bogged down in technical details. i.e., they can explain clearly what the issues mean to the decision makers so they can take meaningful action instead of ending up confused.

Hence to be truly successful an engineer needs to work as part of a team, not just within their immediate group but also within the entire organization. They need to communicate well and spread understanding beyond just the engineering organization. This kind of interaction and communication skill set is not taught in school, nor is it necessarily innate. It’s something that can be developed over time, but unfortunately one that some people either do not understand or refuse to pick up.

Wednesday, December 3, 2008

Does Your Company Need Rock Stars?

A lot of companies, if not most of them, think they need to hire rock stars. It’s perfectly legitimate to want to hire the best, but where do you make the cutoff? Many companies insist on hiring only the top 10%, or the top 5%, or even the top 1%. If all companies thought like this then it’s a wonder that most people get hired at all.

“The Mythical Man Month” is a seminal work in Software Project Management, written over 30 years ago. It contains many ideas, some of which are controversial, and some that are dated, but one that I like is that of a “Surgical Team.”

A surgical team is led by an experienced surgeon who is assisted by more junior surgeons, anesthesiologists, nurses, and other supporting personnel. Transposed to software development, this model means that an architect or other senior engineer works on the most critical portions (i.e., architecture & design) while others support the architect by working on supporting tasks (i.e., coding & testing).

This model is attractive because it requires only a few rock stars compared to supporting characters. If you only need 1 out of every 10 engineers to be rock stars, that makes hiring a lot easier. Of course, the proportion of rock stars in the developer population is probably a lot less than 10%, but perhaps for some teams you could substitute a medium level star instead. So instead of a top rock act, you might have a good cover band instead.

Finally, consider the possibility that you may not need rock stars at all. CRUD development is a favorite whipping boy of mine, perhaps unfairly. But the fact remains that there are a lot of projects out there that do not require rock star level talent. And if rock stars were to work on them, they might quickly become bored and disillusioned.

Boredom in this case may result not just because such projects don’t use leading edge technology. It may also be because those projects actually rely more on other skills, such as project management, internal marketing & selling skills, political negotiation, and people management. Those are not necessarily the skills that rock star engineers possess, yet they may be essential to the success in the organization.

Monday, December 1, 2008

Are You a Rock Star?

I sometimes like to say that many people think of themselves as rock stars when they are just roadies. And no, I don’t consider myself a rock star either.

“Rock Stars” are a phenomenon that is not unique to software development; politicians like Barak Obama are often called rock stars, as are some top professors, and even (gasp) rock musicians! If you are at the top of your profession, any profession, “Rock Star” seems to be the requisite title. But that’s not a title you can award yourself, alas. It has to be bestowed upon you by your peers.

Detecting a potential rock star in a job interview is very difficult. Just because someone can answer all the technical questions in an interview does not mean they are a star; it just means they are knowledgeable. And as to whether they can learn their job quickly and perform all the duties of that position to a standard that significantly exceeds expectations, that’s something that only time can reveal.

That doesn’t change the fact that a lot of people consider themselves to be rock stars. And certainly just about everyone considers themselves to be above average, just like the kids in Lake Wobegon. But of course that's statistically impossible, just as no more than say 10% can be stars, and no more than 2% can be superstars. And yes, I just pulled those numbers out of a hat – but I think I’m accurate to within an order of magnitude.

So how can you tell if you are truly a rock star? Here are some signs:
  • Are people constantly coming to you for help or advice? (on technical matters, not just to shoot the breeze)
  • Is your calendar filled with appointments, half of which you cannot attend? (technical and design discussions, not pointless BS meetings).
  • Is your boss always giving you more work than you can handle? (and not just busywork)
  • When a crisis occurs, are you the first one they ask to troubleshoot? The go-to person? (and not as the fall guy)
Any of these qualities could be meaningless on their own, but combined they might point to you being the next Mick Jagger -- or Keith Richards. But hopefully not Ron Woods.

If these things don’t happen to you, you can kid yourself all you like but you’re not a rock star. Alas, you might even be a great performer worthy of the title but stuck toiling away in obscurity – rock stars unfortunately don’t thrive in caves. You should learn to sell your achievements to others, or at least get a good promoter.