Programming vs Software Engineering vs Computer Science

Programming, Software Engineering and Computer Science are three obviously interrelated disciplines, but people often use the terms somewhat loosely. In particular, people seem to use programming and software engineering interchangeably and it dilutes the differentiation between the two. People go to school for Computer Science then get jobs as programmers, developers and software engineers, which muddies the differences further. I want to try and differentiate how I see the terms.

To me, programming is the nuts and bolts of putting together software: constructing the logical flow of the program, implementing algorithms, writing classes and methods, using design patterns, etc. This is what most people think of as what programmers do. To be fair, it is a lot of what we do and part of what draws people into technology. It is definitely what drew me into technology – the ability to make the computer do what I want it to do. There is an amazing amount of depth here and what most people titled some flavor of “software engineer” focus on.

Computer Science is about the fundamentals of how we have built computers, their languages and the algorithms that run them: abstract syntax trees, parsers, lexers, state machines, and other similar concepts. This differs from programming for algorithms, in that it is designing new ones and evaluating their complexity, not implementing someone else’s design. These are all fundamental to building software systems but not something you would actually do often building most software programs since a lot of these problems are well known, and have prebuilt solutions packaged into default libraries. Computer science is important in day-to-day activities when your application gets to a certain size, e.g., where the difference between an O(n^2) and an O(n lg n) algorithm matters.

Software Engineering is a lot of the adjacent things to programming: support systems to help do programming; tools, processes, and utilities; version control; continuous integration; unit testing; linters; packaging and deployment. Intelligent use of engineering is what, in my mind, separates quality software projects from haphazard ones. You don’t need engineering, but it will make your life easier. This is what I’ve really become passionate about in my own work, since designing and implementing smart engineering can have a multiplicative effect across the entire team.

You go out to interview for a job as a Software Engineer, but generally get asked questions on programming and computer science topics. As an industry, we don’t seem to go looking for people with strong skills on the software engineering spectrum; I think a lot of this is because you don’t need everyone to have strong skills on all three disciplines and that someone with strong programming and computer science skills is more valuable than any other combination of two of the three. If you follow this to its logical conclusion, then you have teams where no one is strong on software engineering.

Lacking software engineering talent can cause the team as a whole to stagnate because it stops adding new ideas and tools that have the ability to give multiplicative gains rather than just additive gains from refining the current workflow. Even worse, if a team ends up trying something like TDD  and has a negative experience with it because it was unable to integrate the new working patterns and tools into its routines, it could resist other attempts at change in the future making it less likely to try and succeed at integrating other ideas in the future.

Evaluating Software Engineering interest and talent seems much harder than the other skills since, as a discipline, it has few challenging questions with objectively correct answers. You also want people who are familiar with the tools and processes that you currently use, but that doesn’t help you bring in other tools you aren’t already familiar with and even hinders it. The best way to find people with Software Engineering interest and talent would seem to be by finding those people who enthusiastically brought new tools to bear in prior projects with good results. But that isn’t the kind of accomplishment that would be sought by people who are exclusively looking for programmers, since it isn’t a programming accomplishment. If you think your team has been stagnating, you can change your hiring process to bring in someone who has an interest in engineering, or you can try to push yourself to focus more on the engineering aspects of the work.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s