Originally published on Developer.com, November 23, 2004.
While working on a series of articles (which I promise are coming next), I was tearing apart various software development structures and roles and came to the realization that we call lots of people “developers.” Those developers have many specializations. In my last article, I broke apart how organizations have different software development groups. In this article, we’ll explore what it means to be a developer and the different kinds of specializations.
A Word About Specializations
Specialization can be a scary word. When the initial discussions began in the 1990s about moving software development offshore, I was thinking about what role, if any, the software developer in the United States would have. I thought specializing made it easier to eliminate me from my current position. I thought if I had a specialization in something that the organization no longer needed, I would be removed. I thought remaining a generalist with many skills would be more beneficial in my quest to remain employed.
What I’ve learned from years of being on the other side of the fence is that, although there are times when a specialist has to be removed due to a lack of work, there are an equal number of times when having a specialty has proven an invaluable trait for an employee. A person who possesses a specialty can be the right resource to keep: since they’re capable and willing to learn one specialty, they may be willing to learn a new specialty – one that hasn’t yet been identified as a need. Because of this, sometimes people with specific skills are more valuable than a generalist.
The General Developer
The general developer is the generalist described above. A general developer is someone who has the ability to do any kind of development, but either hasn’t yet developed a specialty, or has decided to stay in a mainstream development role that involves a wide variety of different kinds of development. Some developers spend their whole professional lives as general developers without any movement into other roles or development of specialties.
In general, those who fail to distinguish themselves within a specialty after a few years of development work will stagnate within the position for their entire careers.
The Database Developer
The database developer is focused on database access. This developer is particularly adept at creating mechanisms for accessing data in a database. They typically can take the role of a DBA in a pinch because they understand database technology thoroughly and can perform almost any role when it comes to a database. The database developer’s ability to troubleshoot performance issues and debug problems can be invaluable.
Initially, the position of database developer may appear to be a dead end job – once you define a database access architecture, what else is there to do? The answer is to assist other developers in the development of reasonable data access patterns, as well as deal with performance issues created by bad queries and indexes. There’s an endless supply of new database access situations; the typical developer doesn’t have a deep understanding of how a database works or the performance implications of the code.
The Technical Developer
The technical developer is the one who is at home with technical algorithms and the advanced techniques of data processing. Although not needed on a daily basis, the skill to create highly technical solutions is an important part of the developer spectrum. Technical developers fill that critical niche for solving problems that are more complex or that need a higher degree of technical sophistication.
Technical developers are most at home with memory management schemes, tokenization and compression, encryption, optimization algorithms and the like. These needs spring up in some of the most obvious projects; specialization in delivering technical solutions is a rare and invaluable quality.
I was reminded of this in a recent eCommerce project. I needed technical solutions for XML serialization beyond what the language supported inherently, an encryption scheme which allowed us to manage encryption keys for sensitive data, a memory management and thread handling solution that maintained a minimum memory footprint while optimizing performance across multiple threads, and dozens of other smaller but essential components of the overall solution. I handed the problem off to one of our most technical developers who handily met all expectations.
The Business Rules Developer
Expressing the complex set of ever-changing rules of an organization in a programming language or visual designer tool is an art form. This art form is one that the business rules developer has mastered. While reading requirements and speaking with customers, internal or external, they instantly identify paths that have not been explored, potential disconnects, and other logical loops which would make implementing the logic into the technologies available difficult or impossible. They are constantly seeking to understand the rules behind the exceptions and the exceptions behind the rules.
The business rules developer is in constant demand as more and more processes are automated and previously automated processes change. The value of the business rules developer lies in their ability to rapidly translate these processes into usable code. This individual typically must learn more about the business and how it works – an important consideration if one wishes to move into management.
User Interface Developer
The business logic coded into a program can be very valuable; if the program isn’t used, then the logic becomes worthless. It’s the job of the user interface developer to make the program interface so intuitive, friendly, and aesthetically appealing that everyone will want to use the program. It takes part research, part art form, and part inspiration to develop truly world class user interfaces.
User interface development is often considered trivial, mundane work done by junior or inexperienced programmers. This is sometimes the case; however, some of the most creative and experienced developers are tapped for tasks in programs where the user interface is very important to the program’s success.
The Reporting Developer
One of the truisms of information technology is that most organizations are drowning in a sea of data with little information. The reporting developer is one who has become adept at facilitating the conversion of data into information. In addition to learning the somewhat specialized report development tools, they learn how to evaluate the requests of business users and convert the reams of data into usable information.
Two important skills are necessary in any good reporting developer. First, a solid understanding of on-line analytical processing (OLAP) systems is a must. This skill should be present even if the organization doesn’t use any OLAP technology – it helps in the construction of reports from a completely different perspective. The second skill is that of aesthetics – not perhaps to the fine tuned level of a graphics designer, but an understanding of the simple rules that make reports more readable.
The Installer Developer
A rare breed, the installer developer is somewhere between the worlds of software development and systems integration. They must work with the developers to learn what the application needs to run, develop their own special program to perform the installation, and work with the systems integration department to determine what is possible in the environment.
Installer development work is deceptively simple. Copy a few files. Add a few registry entries and you’re done – or so it seems. Learning how to create MSI files that can be delivered to the organization through automated deployment tools is a challenge that few will master.
Many organizations aren’t large enough that this specialty has emerged within their ranks. However, it is one that has its own set of tools, techniques, and knowledge.
The Testing Developer
Extensive testing is performed in larger projects and in those with higher business impact. Eventually there comes a point where the level of testing becomes too cumbersome to execute manually. In those times, a test script, or program, is needed to exercise the program, just as if a user were sitting banging away at it. The test script can repeat the same boring test over and over again to seek out memory leaks, can be run at high quantities to load test the solution, and can be run exactly the same from one build of the system to another to ensure that no new errors were induced. The testing developer specialty also doesn’t exist within every organization; however, it is a specialty that can have a huge return on investment when needed.
What Specialties do you want to pick up?
Up to this point, each of the specialties has been examined in a vacuum. That rarely happens. Many developers take their general development skill and layer on it a technical specialty and a database specialty – or a few other specialties; this is perfectly normal and healthy. The more specialties you develop, the more valuable you can be to your next project. Once you’ve developed a specialty, you have to decide whether to deepen that specialty or branch out into another.
Getting the Opportunity
One of the frequent questions I get is “How do I get started?” The answer to that question is to get the ground work that is necessary to move into the specialty. If you decide that you want to be a database specialist and don’t know the first bit about how SQL databases work, you may need a database book or a friendly coworker who may be able to take you under his or her wing and show you the ropes. You’ll have to create the opportunity through your desire and drive – don’t wait for the opportunity to knock on your door.