The difference between a developer and a programmer.
Why is software development so hard? It could be argued that software development is so hard because programming is so easy. Since this seems to be contradictory, I will explain what that means.
Whether or not most people realize it, the titles "developer" and "programmer" are not interchangeable. Nearly all of us (myself included) start out as programmers. We learn the programming languages, the syntax, the data structures, the program flow controls, and how to assemble these elements to produce useful components. A good programmer knows the languages, the object models, and the techniques that are capable of producing stable, working pieces of code. But a good programmer is not a software developer. Some people remain very good programmers without ever moving to software development.
To become a software developer takes a good programmer who breaks out of the "program" mindset. A program does a specific task very well, but most professional development projects must go beyond specific tasks. When a company or government agency starts a project it is very seldom a project to create a program. Instead, it is typically to create a solution. This is a very important distinction. A program is a software solution to a single, focused problem while a system is a collection of programs that satisfy a much broader class of problems.
For example, a project to transform data from a legacy system to XML results in a program while a project to make data across legacy systems available to a web-based front end is a system. The difference is that while the transformation program does a single job very well, the legacy to web system consists of many, many components, any of which at their core are a program.
From this view of program vs. system, it makes sense that a software developer is not the same as a programmer. While a programmer must be an expert in a very narrow domain of the overall problem (depth), a developer must have a solid understanding of both the depth and breadth of the problem. Not only must the developer know how to create programs, but he must also know how to assemble the many programs that perform the various tasks required to solve the larger problem.
Going back to the original statement that software development is so difficult because programming is so easy can now be seen in a new light. As many modern programmers come into the trade, they cut their teeth on highly abstracted development environments such as Visual Studio and NetBeans. While this is good for productivity, it is not so good for learning what is going on "behind the curtain" as programs are compiled, and linked. With the excellent development front ends available for free today, it is entirely possible for someone to make a living as a programmer without really understanding the nuts and bolts of what they are building. Programming has become much easier.
While the same development IDEs make it easier to build solutions (i.e. systems) as well as programs, the context of what is being done is so hidden that programmers attempt to apply the programming mindset to system development. This results in some pretty convoluted code and produces a situation where the person or people writing the application don't really understand the logical separation of the pieces, how the pieces interact, or how to manage the interaction between them. They tend to flatten everything out and put business logic in the views along with data access. In other words, the tools available make it easy to jump from a program to a system without having the knowledge and experience of a real developer.
This is by far not the only reason that software development is difficult to get right, but it is a large contributing factor. The introduction of the "Software Engineer" title further blurs the line between programmer and developer because it gives no context as to what level the person is working at or is capable of working out. Many programmers graduate with a Computer Science or Software Engineering degree with no domain knowledge of the languages they are hired to work in, much less the entire development environments. They are often told by their professors in college that they are going into the working world perfectly prepared to produce world-class software and should expect the salaries to match those skills. This from a guy who has probably never worked on a business development project outside of the University he teaches at. This sets false expectations for the new programmer by giving them the impression that they already know all there is to know about software.
I was in the Army and went to SATCOM School. This is a very intense technical school that lasts for a full year. That is a full year of eight hours per day of classroom instruction, which comes to about 2000 classroom hours used to teach everything from electrical theory to satellite orbits, data encryption, error correction, and troubleshooting techniques. I can say without any doubt that the Army (and I would assume any branch of the military) is excellent at teaching highly technical concepts. You have no option; you learn it through complete immersion or else.
I finally graduated from SATCOM School after exactly one very long year, amazed at what I knew. I had just spent most of my waking hours for an entire year learning about a single subject: Satellite Communications. I was absolutely certain I was ready to jump into the job and perform it perfectly from day one. Imagine my shock upon arriving at my first duty station (Fort Belvoir, Virginia Earth Terminal Complex) when the NCO in charge told me "Forget everything they taught you at that school. We don't really do things that way." The amazing part was that he was telling the truth.
In many ways, that is the way of software development. In college you learn the theory, the science, the techniques, and then you land your first programming job as a Software Engineer. You walk in expecting to be producing world-class applications in a few days, but if you are lucky enough to be assigned to work with a senior developer, you quickly learn that most of what you learned is good information, but not the way things are really done. The real learning starts when the classes end.
It sometimes sounds as though I have a chip on my shoulder for new Software Engineering or Computer Science graduates, but this is not the case. I have a chip on my shoulder for anyone who is unwilling to learn and relearn as the situation requires and instead spends their time arguing the virtues of obscure programming techniques.
To become a good developer, a Software Engineer or Computer Science major (or anyone else) must accept that they know very little about the day to day work that they have been hired to do. They must strive to continue to learn every day and actually listen to the men and women around them who have been doing this work for eight or ten years. Eventually you will become a good programmer, and if you keep learning, you will become a good Software Developer. Only when you arrive at that level of knowledge will you realize how little you knew as a green recruit.
M@
Whether or not most people realize it, the titles "developer" and "programmer" are not interchangeable. Nearly all of us (myself included) start out as programmers. We learn the programming languages, the syntax, the data structures, the program flow controls, and how to assemble these elements to produce useful components. A good programmer knows the languages, the object models, and the techniques that are capable of producing stable, working pieces of code. But a good programmer is not a software developer. Some people remain very good programmers without ever moving to software development.
To become a software developer takes a good programmer who breaks out of the "program" mindset. A program does a specific task very well, but most professional development projects must go beyond specific tasks. When a company or government agency starts a project it is very seldom a project to create a program. Instead, it is typically to create a solution. This is a very important distinction. A program is a software solution to a single, focused problem while a system is a collection of programs that satisfy a much broader class of problems.
For example, a project to transform data from a legacy system to XML results in a program while a project to make data across legacy systems available to a web-based front end is a system. The difference is that while the transformation program does a single job very well, the legacy to web system consists of many, many components, any of which at their core are a program.
From this view of program vs. system, it makes sense that a software developer is not the same as a programmer. While a programmer must be an expert in a very narrow domain of the overall problem (depth), a developer must have a solid understanding of both the depth and breadth of the problem. Not only must the developer know how to create programs, but he must also know how to assemble the many programs that perform the various tasks required to solve the larger problem.
Going back to the original statement that software development is so difficult because programming is so easy can now be seen in a new light. As many modern programmers come into the trade, they cut their teeth on highly abstracted development environments such as Visual Studio and NetBeans. While this is good for productivity, it is not so good for learning what is going on "behind the curtain" as programs are compiled, and linked. With the excellent development front ends available for free today, it is entirely possible for someone to make a living as a programmer without really understanding the nuts and bolts of what they are building. Programming has become much easier.
While the same development IDEs make it easier to build solutions (i.e. systems) as well as programs, the context of what is being done is so hidden that programmers attempt to apply the programming mindset to system development. This results in some pretty convoluted code and produces a situation where the person or people writing the application don't really understand the logical separation of the pieces, how the pieces interact, or how to manage the interaction between them. They tend to flatten everything out and put business logic in the views along with data access. In other words, the tools available make it easy to jump from a program to a system without having the knowledge and experience of a real developer.
This is by far not the only reason that software development is difficult to get right, but it is a large contributing factor. The introduction of the "Software Engineer" title further blurs the line between programmer and developer because it gives no context as to what level the person is working at or is capable of working out. Many programmers graduate with a Computer Science or Software Engineering degree with no domain knowledge of the languages they are hired to work in, much less the entire development environments. They are often told by their professors in college that they are going into the working world perfectly prepared to produce world-class software and should expect the salaries to match those skills. This from a guy who has probably never worked on a business development project outside of the University he teaches at. This sets false expectations for the new programmer by giving them the impression that they already know all there is to know about software.
I was in the Army and went to SATCOM School. This is a very intense technical school that lasts for a full year. That is a full year of eight hours per day of classroom instruction, which comes to about 2000 classroom hours used to teach everything from electrical theory to satellite orbits, data encryption, error correction, and troubleshooting techniques. I can say without any doubt that the Army (and I would assume any branch of the military) is excellent at teaching highly technical concepts. You have no option; you learn it through complete immersion or else.
I finally graduated from SATCOM School after exactly one very long year, amazed at what I knew. I had just spent most of my waking hours for an entire year learning about a single subject: Satellite Communications. I was absolutely certain I was ready to jump into the job and perform it perfectly from day one. Imagine my shock upon arriving at my first duty station (Fort Belvoir, Virginia Earth Terminal Complex) when the NCO in charge told me "Forget everything they taught you at that school. We don't really do things that way." The amazing part was that he was telling the truth.
In many ways, that is the way of software development. In college you learn the theory, the science, the techniques, and then you land your first programming job as a Software Engineer. You walk in expecting to be producing world-class applications in a few days, but if you are lucky enough to be assigned to work with a senior developer, you quickly learn that most of what you learned is good information, but not the way things are really done. The real learning starts when the classes end.
It sometimes sounds as though I have a chip on my shoulder for new Software Engineering or Computer Science graduates, but this is not the case. I have a chip on my shoulder for anyone who is unwilling to learn and relearn as the situation requires and instead spends their time arguing the virtues of obscure programming techniques.
To become a good developer, a Software Engineer or Computer Science major (or anyone else) must accept that they know very little about the day to day work that they have been hired to do. They must strive to continue to learn every day and actually listen to the men and women around them who have been doing this work for eight or ten years. Eventually you will become a good programmer, and if you keep learning, you will become a good Software Developer. Only when you arrive at that level of knowledge will you realize how little you knew as a green recruit.
M@
[1] Comments:
Excellent post !
I really liked the way you diffrentiated between the Software Programmer and Software Developer.
I appreciate your work :)
Post a Comment
<< Home