Fog Creek Software
Discussion Board




Categories of developers

The way I see it, there are two classes of developers out there:

- Class B (average)
- Class A (good)

The class A can be further divided into roughly three categories:

3) Good hackers
2) Good hackers with a CS education
1) Good developers

These three categories include each other:  2) includes 3) with something added, and 1) includes 2) with something added.  A "good developer" is a "good hacker with the big picture".  It's someone who can not only crank out code but

- has education and CS classes under their belt
- has higher knowledge than bit fiddling,O(n) algorithms and NP-complete problems
- knows about deadlines and making compromises to deliver quality "running" code (which is different from quality "static" code, also known as academic code :-))

Also, a category 1 developer:

- knows several programming languages (different paradigms a plus, like Java and Lisp)

- has a solid grasp of OO concepts (not just overriding and interfaces.  I used to ask for example if candidates can describe multiple inheritance of implementation and suggest a way to implement it like C++ compilers typically do).  Typically, the questions I ask cover OO notions that exist only on other languages than Java, such as C++, Eiffel, Objective C, Beta, etc...  Constrained genericity, covariance, etc...  There is a lot to choose from.

- knows about the contraints of working in a team, which includes abiding by coding conventions, communicating by email or verbally, treating everyone as equals:  managers, docs, QA, etc... (something that is usually not seen in categories 2 and 3)

- has an extended culture beyond the stricly engineering one.  This can be very broad and ideally include some bleeding edge notions.  For example, it can include (but is not limited to):  design patterns, aspect-oriented/functional/declarative/... programming, knowing both Windows and UNIX, or both X Window and Windows, knowing how a compiler works or having worked in assembly, reading a lot (I always ask candidates what their latest technical readings were and what they thought of it), knowing COM when your area of expertise is J2EE (or the reverse), etc...

Does this breakdown match your experience?

Cedric
Wednesday, March 06, 2002

Not at all. Delivering quality code (and getting on with other people) is IMO the /only/ attribute of a 'good developer' ... for sufficiently broad definitions of 'code' (e.g. extend it to include specs, design, maintenance, etc.).

The other things you mention (CS degree, knowledge of covariance, even knowledge of multiple languages) are a means to an end, not an end (IMO). You /will often/ find these attributes in a good developer. You might even say "this person is so much more likely to be a good developer than this other person, because he has these attributes ... therefore, I will bet /my/ money on this one" ... but I wouldn't /define/ a good developer as you did, nor confuse your 'bet' with reality.

But who knows, maybe the attributes you're requiring /are/ necessary for the job /you/ do.

Christopher Wells
Wednesday, March 06, 2002

I agree with the second post. I am a software "engineer" and I interview prospective hires. I have seen MANY resumes that say things like "12 years C++ experience", "5 years senior software engineer", "managed technical designs and 5 other engineers". During the interview, I ask them some Microsoft-style coding problems and, more than twice, I have had "senior" people not remember what the C mod operator looks like or does. Or they describe recursive O(n^2) algorithms to simple problems.

The moral is that resumes are helpful for starting conversations, but do NOT forget to ask real questions during the interview.

Banana Fred
Wednesday, March 06, 2002

There ARE two kinds of developers:

a) academic
b) pragmatic

Cedric is obviously of category a, actually worrying about things like "constrainted genericity", and knows what "covariant" means off the top of his head.  Such people tend to build elegant systems, exploring new and interesting ways to solve old problems.

Category b programmers worry about getting the product working well enough to get money in the door, and tend to use proven techniques and tools to keep development on track and on time.

Another way to describe these two types are:

a) researchers
b) engineers

There's a place for both, but to say that one type is better than the other is misguided and somewhat bigoted.

James Montebello
Wednesday, March 06, 2002

IMHO it depends on the setting.

I like creating little software components in my spare time to learn and explore the possibilities of software (I happen to view software as one of the cheapest ways to 'create' a working simulation of a concept or physical thing [which would take ages to do in the physical world]).
In that setting there is no money down the line but personal satisfaction of having learned and created something of value are huge payoffs.

Of course, this will not be the rule when producing software for getting money out of it. The set of criteria is then:

- generate cash
- do it fast
- do it without bugs

This is where proven recipes work. Repetition being the mother of skill, you'd better concentrate on some specific tools or domains... being a jack of all trades will make you the master of none. And this will lead to zero differentiation, something which is bad for your personal marketing in this field.

Philippe Back
Wednesday, March 06, 2002

<quote>
a) academic
b) pragmatic
Cedric is obviously of category a,
</quote>

Actually no, I'm totally on the b) side but my academic background allows me to dig a little bit deeper in people's resume.

The idea is that when I have established that I want to hire this person, I need to find out where they fit, and if someone can show me that on top of knowing how to code, they have some solid fringe knowledge as well, then I will consider them for a more senior position.

I have all sorts of developers around me and while I value some academic background, people with a strong academic bias can become counter-productive as the deadlines near and it becomes important to cut corners.

Hence my distinction between writing elegant "static" code (the code looks nice and is well architected) and writing elegant "dynamic" code (the code must be robust and be shipped on time).  Typically, a developer will spend 80% of the time of the release cycle writing good static code and will switch to dynamic mode as the deadline approaches.


--
Cedric

Cedric
Wednesday, March 06, 2002

there's one problem with people categorizing developers and figuring out which ones/types are better.  if you're at a good company or a good HR person-maybe you're picking the best of whatever category you're arbitrarily looking for.

for example, let's look at self-taugh hacks vs. college trained CIS types.  which group is better?  you can put +'s & -'s for both, but both groups have good and bad programmers-it's just that the percentages are different.  if you're an HR person at a bad company who's a shitty judge of people-you'll get bad programmers you'll be convinced you need to find people of the other type (before finding you can't find good people period).  if you're at a good company-you'll think you picked the right type to recruit.

basically-there's all types.  don't throw out the baby with the bath-water.

razib khan
Wednesday, March 06, 2002

I'm going to refer back to "Sources of Power" here because it's one of my favorite books, but more importantly it addresses this whole categorization thing rather nicely.

Sources of Power is a book about decision making. The author, Gary Klein followed fire marshalls, military commanders, and other high pressured decision makers around for a a decade or more on various research projects funded by various people like the Army, the FAA, etc. He learned quite a few interesting things.

The traditional decision making models - lay out all of your possibilities, weigh the pros and cons and choose between them isn't how these people made decisions. The more experienced you were, the more you were able to "see" what needed to be done and do it. You'd run a simple mental simulation in your head and look for flaws. If you found some you'd revise your mental simulation. You didn't however weigh pros and cons of two different approaches.

The more inexperienced (what you're calling academic) you were, the more likely you were to create various scenarios and weigh the pros and cons of each. I guess it helps you get a sense of the complexity, get your head wrapped around it.

I think we're all academic or pragmatic in turns depending on our experience, confidence, understanding of the situation, and other factors. If I had to design a flight simulator you'd be sure I'd go to the nearest room with a white board, and the bigger the better. However, earlier today I helped design the 2nd or 3rd similar project, and yes we used the white board, but mostly to hash through examples and explain our differences of opinion, the architecture we already understood, it was the details that needed to be worked out, and flaws found. We were less academic and more pragmatic this time around. "Yes we know that part works, now let's run through a few examples and see if it falls apart."

So, as in the Iceberg Secrets article, we are all at times the customer having our kitchen remodelled, we are all at times the academic and the pragmatic.

If you were visiting me and I gave you directions to the Metropolitan Museum, I, the pragmatic, would tell you "you get on the Q train and transfer for the 6 uptown..." You, the academic, would get out the map and look for the Q. I'm concerned with what gets things done, you're concerned with the theory behind it *because* you're trying to form a clear picture of it in your head.

Mark W
Wednesday, March 06, 2002

One more thing. What Cedric did was outline pointers, or indicators. See my post on resume selection http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=4157&ixReplies=7 for more on indicators. His is a more complex version of what I outlined.

Mark W
Wednesday, March 06, 2002

"The more inexperienced (what you're calling academic) you were, the more likely you were to create various scenarios and weigh the pros and cons of each. I guess it helps you get a sense of the complexity, get your head wrapped around it."

Uh, no.  Academic is not equal to inexperienced.  It's a mode of thinking and working.  It's also, as I'm stating it here, a desire to learn far more about a subject than is immediately useful.  Learning Eiffel, for example, is something an academic programmer would do, since there are virtually zero commercial projects written in Eiffel.  It's not useless by a long shot, but it's also not directly useful, and won't contribute directly to getting a project into the revenue generating phase.

Pragmatic (as I'm describing it) is also not a mark of experience, necessarily.  Engineers rely on researchers in many fields to do the long-haul work of breaking new ground.  They then apply that knowledge directly to solving a problem that usually involves making money.  The same is true (to a degree) in programming.

Both approaches are very necessary, but not every shop needs researchers (indeed, I think few do), but all of them need engineers.

James Montebello
Wednesday, March 06, 2002

i agree with a lot of what james is saying.  but a lot of "pragmatists" are a little under-versed in theory.  that includes me-though i'm trying to rectify that situation.  i've also heard of stories of academics (literally) taking a stab at industry and washing out because they don't have a good grasp of practical goals and time management.

razib khan
Wednesday, March 06, 2002

I'm not disagreeing with you, though I didn't directly address all of your points. I apologize. Perhaps I can make myself a little clearer.

Here's my case in breif:

Under deadline situations, we all tend to become pragmatic. In cases where we do not have enough information we become academic temporarily in order to gain an understanding of the situation enough to act.

What I didn't say explicetely (sp?) was that without deadline situations, we can all enjoy the luxury of being academic.

An extreme example would be a College Professor with Tenur and an Ambulance Driver. One enjoys the 'luxury' of exploring things for the sake of exploring them without pressure deadline. The Ambulance Driver is constantly making life and death decisions.

I'm sure there's a gray area where the Ambulance Driver teaches defensive driving on the weekend, and the College Professor gets locked into a race to be the first to unlock TOE. In that case it seems they switch positions, the Ambulance Driver doing something for without deadlines, and the college professor working as quickly and efficiently as he can.

Whether one personality gravitates towards one situation over the other is another discussion entirely. And if one does is it genetic or environmental?

Mark W
Thursday, March 07, 2002

i think ther is nothing more boring + pointless than trying to fit people into categories. ha, programmers.

Martin Dittus
Thursday, March 07, 2002

I think Cedric has an important point.

I think the quote from Man Moth still applies, a good program is 10 times more productive than than an average one.

The means of classification is a little limited, because there are other factors.  A lot of people who are excellent programmers will take objection because the descriptions will not fit them.

Some top grade CS students are not very productive.  Some self taught programming are total gurus.  However, a knowledge of Computer Science is important, but it isn't necessarily the product of formal education.

Steve McConnel points out in Code Complete, a programmer needs to know all of the standard Data Structures by heart - Linked Lists, Staks, Heaps, etc.  What the various trade offs are and how to implement them. 

Somebody who has this level of knowledge would be class B.

However, there are an awful lot of programmers who just use and SQL database or XML Dom for everthing.

This type of behavious would indicate a class A.

I think the pragamattic/academic distinction can be misleading.  A lot of things done by pragmatists in order to meet a deadline causes a project to take longer than it should.

Ged Byrne
Thursday, March 07, 2002

There are only 2 categories of developers.
Employed or Unemployed
It all speaks for itself

SSSSS
Thursday, March 07, 2002

Of all the programmers I have known (myself included), there are four types: those who fake it and cannot program, those who can write code but are unable to develope algorithyms on their own, and those who can develope solutions but cannot code, and those who can code and develope.

I have found the discussion over education as it relates to the job to be a waste of time, especially because it has very little relationship to the programmers ability to work.

I cannot code in most languages, but given a sample with enough documentation and a manual, I can transform the code into something else. I have found my best strength to be my ability to analyse and provide a solution to a problem, not my ability to code (I take far too long to do it, though the code is rarely buggy, usually have a max of 3-20 bugs per 10,000 lines of code, mostly errors in syntax, though I have had some very negative experiences with Java on the bug side).

Masterlode
Friday, March 08, 2002

I have a degree in mathematics and 10 years development experience.
I have a string of successful projects behind me, in several languages.

I really hate it when some manager asks me really hard questions about something they read last week and has decided that it suddenly matters.

Constrained genericity, covariance, and other examples quoted in this thread fall into this category.

Compiler questions are irritating to.

I, and many other successful software developers already have a demonstrated ability to understand, to solve and to adapt.

What better way of seeing what I can do than by looking at what I have done? Naturally problem solving type questions should be asked and also some technical exploration is good too, but please, no compiler questions, if I ever needed to know the answer I would, but I probably never did.

Understandably its different for recent graduates etc, but I suppose slightly more academic questions could be asked of those who have just exited the hallowed halls of education.

Tony
Wednesday, March 13, 2002

I contradict that outline regarding hackers as good developers. It sounds like car breakers (aiming to steal things inside) are well qualified vehicle engeineeres. Most valuable hacker's ability is to track down some technical feature that can be helpful to acheive system or protection damage. Usually a hacker even can't and doesn't mind how the whole system deployed. All that hacker needs is just to believe in system damageability. The belief may get weakened it the hacker's knowledge gets deeper.

Stans
Thursday, March 21, 2002

> I contradict that outline regarding hackers as good developers. It sounds like car breakers (aiming to steal things inside) are well qualified vehicle engeineeres.

Stan,

American programmers use the term "hacker" to mean something like this: http://www.tuxedo.org/~esr/jargon/html/entry/hacker.html

The [deprecated] sense in which you're using it is called a "cracker" (like somebody who 'cracks' safes or strongboxes), not a "hacker".

Christopher Wells
Thursday, March 21, 2002

*  Recent Topics

*  Fog Creek Home