http://www.developer.com/

Back to article

Anatomy of a Software Development Role: Developer


June 9, 2005

In a previous article, The Many faces of the Developer , I walked through some of the different types of developers that there are - different specializations that developers have worked on. In this article we'll take a look at what the job is in general, how to get it, and what to do once you have it. (If you've not been following the series, you should read Cracking the Code: Breaking Down the Software Development Roles.)

What is the developer?

Ask any developer and they will tell you that the heart and soul of the development process is the developer role. Developers are often the huddled masses yearning to create software. They are the workhorses of the whole system creating the code that the other roles only influence. (The exceptions are the development lead and solutions architects who write small amounts of code from time-to-time.) Click here to see how the SA fits within the full organizational chart.

From a technical perspective the developer is at the most basic level expected to be able to translate algorithms and technical specifications into code that can be executed on a computer system. The language syntax and structures of code must be understood. The language syntax for writing programs is typically the easiest skill for a developer to learn. There are many books, training programs, and tools to teach you the syntax of the language.

But knowing the syntax of a programming language is only the basic requirement to be a programmer. What offsets a developer from this are a number of additional skills. Additionally, the differentiating skills that separate the good developers from the typical developer are many. However, some of the important ones are below:

  • Developing Understanding - Nearly anyone can blindly follow the instructions laid out for them, however, good developers make it a point to understand what they're doing so that they can identify potential issues and opportunities for improvement at every turn.
  • Structures and Algorithms Mastery - In software development there isn't any one "right" way to do things since the same problem can be solved dozens of ways. However, there are ways that are "more right". Mastering structures and algorithms means that the problem is solved in the most straightforward manner no matter what the language. Algorithms are step-by-step patterns that explain the process of performing an action. Structures relate to this by being the containers for the information that is being transformed by the action. When woven together they form the fabric of an application.
  • Specialization - As mentioned in the article The Many faces of the Developer specialization demonstrates initiative to learn more and to grow which can help to separate a developer from the pack.

Getting Started as a Developer

Getting started as a developer may seem like a daunting task. Developers must have that prerequisite syntactical and algorithm skill to begin their professional journey. The question I most frequently get asked by aspiring developers trying to get started is: "What language is the right language to start with?" The answer I most frequently give is "It doesn't matter." Of course, it does matter. I wouldn't want to send someone off to learn COBOL or FORTRAN or ADA or any of the other languages that haven't really got any real potential for new developers, however, most often the question is whether they should learn C++, C#, VB.NET, or Java. The reality is that any of these languages and associated development platforms has a sufficient following to allow someone to find a job. If you're trying to get started, what language you pick won't be the primary issue in most cases. Although some specialties will gravitate to specific languages the cases where this will be at issue are few Learning the language itself and developing some experience with it will be.

Getting that precious first experience can be key in becoming an employed developer. Despite the initial reaction that there isn't any way to get experience without experience it is easy to find places willing to let you get experience. You'll find that clubs, churches, and other not-for-profit organizations are always looking for someone to donate their expertise. It's a great way to get some experience without having a paying job.

What's in their toolbox?

Developers have a relatively limited toolbox. They are expected to be able to use the development environment including compiler and debugger for the language or languages they've chosen as well as a handful of the common tools that every member of a development team is expected to know how to use. These tools are typically integrated into one platform that functions as both a compiler and debugger. This is typically the same tool that was used to learn the language so learning a development environment isn't typically a big challenge.

In some organizations a basic familiarity with the automated testing tools is also required. This would include unit level testing tools designed to test basic code assumptions as well as tools designed to perform system level tests. Generally testing tools are primarily operated by others, however, developers may need to activate scripts written by others to verify that their changes haven't adversely impacted the build.

Developers who have specialized may find that they need to learn special tools as well. For instance, an install developer will have to learn about the installer software being used. The database developer will need to have use of database management tools.

Where's the position heading anyway?

Another very popular question I get asked is "What about offshore development?" For those in the US, that means the movement of developer positions to countries where companies charge less for coding. In those countries programmers require lower salaries to sustain a good living. While this is a concern for programmers, the reality is that the demand for developers is approximately flat according to the ITAA 2004 survey of the IT workforce (link: ITAA workforce survey). Although the outlook for new developers joining the ranks may seem dim it's important to realize that programmers represent the largest portion of the IT workspace and that positions and opportunities will develop just through attrition and upward movement.

Although there are a number of successful off-shoring case studies there may be nearly as many case studies about how off shoring may not work. The concept has been around for more than a decade and programmers remain one of the largest groups of IT workers in the US. Despite the "gloom and doom" picture that some people like to spout the reality is much closer to a optimistically cautious view.

Once we accept that there are going to be enough development positions for everyone it's important to investigate the trends that will be impacting the developer role going forward and how that can mean.

The Good, the Bad, and the Ugly

No role is perfect and the developer role is no exception. Here are some of the things about the developer role that you'll want to consider before deciding it's what you want to be doing with your career

  • Good: Upward Mobility - Since the development area is one of the largest in IT and because there are so many different specializations and roles within the software development process there's nearly always the opportunity to move up within the hierarchy. The developer role is the foundation upon which most other positions are built. For instance, you're more likely to grow into a development leader role from development than from any other position.
  • Good: Stability - Developers are indispensable to the organizations they work for. They are in point of fact the only people who truly understand how the systems do what they do and why they do what they do. As a result programmers have a relatively stable position even in times of cutback. This is most true of developers who are doing maintenance on critical systems but can apply to all developers. This is not to say that developers are recession proof or that they can't be laid off, that happens in every field. However, when compared to other positions in the software development lifecycle things are relatively stable.
  • Good: Problem Solving - If you like problem solving the developer role may be for you. Developers are in a constant cycle of building and debugging their code. Both sides of that cycle can heavily lean on a problem solving skill. While coding the developer exercises problem solving by figuring out how to get a piece of information that's difficult to get. During the debugging part of this cycle the developer is focusing on identifying the source of the bug or bugs and determining how to eliminate them.
  • Bad: Cube Land - Developers are often relegated to cube land with little interpersonal contact. Because of the need for focused time during development distractions are likely to be minimized. For those with an extroverted personality this might represent a challenge.
  • Ugly: Dysfunction abounds - One of the ugliest things about the developer role is that it's at the end of a very long whip. When the software development process works well the developer feels the crunch of a deadline. When the software development process doesn't work well, and it often doesn't, the developer can be crushed by conflicting needs to get the product completed and a series of quality or incomplete feature issues. The truth is that many managers in most organizations do a really bad job of managing the software development process, which can create very painful positions for developers.

Conclusion

The developer role is the core role into the software development process and is the one that there are the most open positions for. The role itself has its own set of trade offs, however, for the upwardly mobile professional it may be the way to put yourself on the path for the position you really want.

About the Author

Robert Bogue, MCSE (NT4/W2K), MCSA:Security, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert's more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. He was honored to become a Microsoft MVP for Microsoft Windows Server - Networking. You can reach Robert at Robert.Bogue@CroweChizek.com

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date