It recently occurred to me that most of the software developers I know (at least those on Unixish operating systems) seem to fall into two groups:
- Those who mostly use the basic tools, APIs, and environment they're given.
- Those who, over time, begin to construct their own platforms by layering their own libraries, APIs, and--more fundamentally--their ideas and philosophies on top of the base platform.
It's interesting. At first I figured it had to do with how long someone had been building software on Unixish systems. But that seems to be a poor indicator. I know folks with lots of experience who seem to always go back to basics when building things. I also know of relatively new folks who are already building up their own tool boxes and platform pieces.
When presented with the need to write a new network aware application, hackers in group #1 will drop down to low-level socket calls (or the equivalent in whatever language they're using). Those in group #2 will realize that they've done it (or part of it) before and reuse that code, or re-factor it into a library that both applications can share, or even go looking for some 3rd party library that does the job better.
I'm not sure why I'm bringing this up now. I haven't really concluded anything from these observations. I think that, more than anything else, it brings up more questions in my mind.
- Are those in either group generally "better" software engineers (or maybe architects) than those in the other?
- Is this a conscious decision, a reflection of someone's training, or something else entirely?
- Does this distinction exist in the Windows world too?
In my limited observations, the folks in group #2 tend to be more productive--at least to the extent that they can work within the same general problem domain and stay on the same platform. Those in group #1 seem to be more flexible. They can hop from company to company or platform to platform without substantial drops in productivity.
It seems not to be limited to any particular language. I've seen both groups in the C/C++, Perl, and PHP worlds (those are dominant at work). I assume the same is true of Java, Python, Visual Basic, C#, and so on.
Thoughts? (Aside from the obvious...)
Posted by jzawodn at January 15, 2004 11:34 PM
For me, it almost always depends on the quality of the tools available. For example, I implemented a lot of my own file management stuff for an OS X app I wrote because the standard Cocoa APIs didn't provide things I wanted. On the other hand, I'm only too happy to use higher level APIs whenever possible. In other words, I hate to reinvent the wheel, but I don't shy away from writing my own code if the stuff provided doesn't meet my needs.
1. Are those in either group generally "better" software engineers (or maybe architects) than those in the other?
I think group #1 will *probably* be good at inventing stuff. The research kind of guys. They'd want to find 100 ways of doing the same thing, just for kicks.
group #2 will be better at getting the job done. Although I think over a period of time, group #2, having learnt from using so many existing tools, will be better than group #1 at inventing stuff.
As an aside, I'm in group #2, but I'm also flexible enough to be able to move to any company and work on any technologies.
2. Is this a conscious decision, a reflection of someone's training, or something else entirely?
I think it's training and culture. I've seen guys who don't want to write in Java, for example, because they don't get to learn low level stuff in it. Well, your company's putting its money on the project and you want to learn from it! Great.
The UNIX culture, AFAIK, is to reuse. It's more object-oriented than anything else. Everything's a file, etc. Lots of abstraction.
3. Does this distinction exist in the Windows world too?
Yes, I think it does. As much as you want to look down ever-so-condescendingly upon the VB crowd, they're simply doing their bit of code reuse. I hate people who want to write UI in VC++. It just sucks.
In your original post, you've interchanged group #1 and group #2 in the later paragraphs following the numbered list. I think you should correct it. My comment sounds all wrong because I followed the numbering in the paragraphs, not in the numbered list above.
The 3rd type of programmer is the 'googler' who searches everywhere cutting and pasting code from various places as a means to an end. :)
You never did say which camp you fall in...
Manish:
If you think I've transposed things, maybe I didn't explain well?
Chris:
You're right. The 'googler' is generally best avoided--or promoted until they can't touch code anymore. :-)
As for which group I fall into, I see aspects of both in things I do. But I think I tend pretty strongly toward group #2.
Ok, I think I confused myself a bit, but I see that you're right.
There is one more group to add Enterprise Developer, who is resposible to write business applications. Usually this type of developer does not care about platforms, just give them right tools for the right job.
Who is better? Well, I always ask people if they know how to cook, most guys (programmers) say yes. Does it mean they are good cooks?
Maxim
www.ipattern.com (do you?)
In the past, I very rarely had to do similar things twice, so I had very little opportunity to reuse code. Now for almost two years I've restricted myself to Cocoa apps (of course calling Carbon and BSD APIs whenever appropriate), so I'm finding myself copying & pasting stuff from past applications into new ones.
Things like about boxes, online help, and so forth. One unanticipated advantage is that once I figure out better ways of doing these things I can migrate the new code back into the old apps.
In my specific case, I see no advantage to putting this code into libraries or frameworks... people who work exclusively with image processing, or network stuff, or something like that probably will, though.
I admit it, I have a whole pile of libraries I wrote over the years for various projects and reuse a lot of that..
I think it all comes down to people, to individuals. I've seen brilliant engineers who started from ground zero almost every time; I've seen more than a few useless frameworks created by developers who obviously never asked the right design questions, most notably "Who is this for?" Some programmers are just driven to innovate, and I don't think it matters much how they go about it.
I think I fall into the platform-building group, but I've never had trouble switching technologies or companies or whatnot. In the past year or so in my professional life, I've had to go from a perl-based web framework of my own design built over the course of 2 years, to Flash-based web apps, to Zope, and now to ASP and VBScript. Each time, I start out with the bare platform, but start building up tools again.
It could be because I'm a masochistic fool and force myself, at least in my own tinkering, to abandon platforms (even my own) every so often and take up with something new and start over.
For me, the framework/platform abstraction/building isn't an investment in a body of work per se, but a process of sanding off the edges on a given foundational technology. After awhile, I'll of course get more productive because things are smoother and yield less friction. In the initial stages, I may be dropping down out of full-speed-ahead coding to cobble together some more general abstractions, but eventually that activity falls away.
I've been too firmly in camp #2 before, though, and *have* invested too much in a particular framework. That's what leads me to try or some where in the middle, now.
I think it's a function of the developer's preferred mode of creation.
My experience with actual tools written by #2 people is that they usually write frameworks for easier writing of tools which often try to anticipate every possible situation. It is in my opinion a very Microsoft-ish kind of world view (speaking in terms of their collections of APIs), where every problem exists in its own reality. In German, there's a term that translates roughly like "egg laying, milk giving wool pig" to convey the idea that something does anything and everything.
I will build a framework if forced to by necessity, but I find that a sensible platform provides users with a lot of tools to build flexible solutions with. When I'm building solutions, I try to use defaults. "Stick to the stock tools" and so on.
Sometimes, doing certain things is complicated and complex using just the stock toolset. In that case, I prefer to keep them as situation agnostic as at all possible so that they will intergrate well with what my environment already has.
Likewise, writing frameworks can be necessary, but that is even rarer than needing new tools. Indeed sometimes the existing libraries are just too low-level to be reasonably productive, but considering how many people use these APIs, I cannot believe that they are almost always too incomplete to work with.
In both cases, I am a strong believer in not attempting to accomodate code reuse before you had to reuse it. It is a refactoring process: I will stick to using the stock tools for as long as my work makes evident that I've had to solve the same thing a bunch of times. Only then, in my opinion, do I have an idea of what I really need out of a tool or framework, so that I can make an attempt at creating one. Frequently, the interface and guts will go through drastic changes in the first iterations until things are minimal but complete enough to become useful for many situations.
Sometimes, doing certain things is complicated and complex using just the stock toolset. In that case, I prefer to keep them as situation agnostic
Oops, that's missing a and I find myself writing a tool to cover those situation.
It shouldn't surprise anyone that this is a moderately common observation. The first time I heard it was from Mark-Jason Dominus in a Perl tutorial. The two groups he outlined were the "tool-builders" and the "tool users".
The distinction was not made in a derisive way. There are different factors to keep in mind when building a tool you want many people to use, or you want to use often. (His talks often focus on learning tool-building techniques, regardless of where you place yourself on the spectrum.) It's a different kind of focus, and we surely need both kinds of developers today.
Of course, both approaches can backfire. A tool-user is limited to the range of motion his tools allow: for example, I would hate to write code with heavy amounts of string processing using C alone. A tool-builder has a different kind of problem: there's a very seductive call to ignore the problem at hand and build a reusable framework instead. At the end of the day, the framework is utterly stunning, but flawed in some fundemental way (and the project is both late and over budget).
