|
There are three disciplines that come together in the tech industry: programming, computer science, and software engineering. Programming is the act of writing programs, and is a skill like any other. Some folks are good at it; some people struggle with it; most people can do some of it if they learn and try hard enough. Programming is what creates value for 95% of the jobs in the tech industry, and if you get good at programming (and programming on a whiteboard) you'll do exceedingly well. Computer science is the theory of computing; it is a branch of mathematics. Djikstra is famously (wrongly) attributed with saying "Computer Science is no more about computers than astronomy is about telescopes." Many (but not all) amazing computer scientists that I've worked with are terrible programmers and software engineers, but their value has been outsized. Any good programmer can integrate a Raft library into your code for consensus. The computer scientists are the ones that not only apply the correct CDRT theory to your custom-built database, but can prove that it converges consistently. Software engineering is the practice of delivering the right software on time and on budget; good software architects think in terms of software engineering. In the 1980s, when computers were going in to _everything_, military projects were at the forefront because Reagan ensured that we were spending mad cash there. It was like the dot com boom of the 2000s; you just couldn't go wrong bidding computerized systems. Because they were new, the contracts were cost-plus, and the military-industrial complex screwed the federal government blue with cost overruns. Anything with software on it typically had budget overruns in the 500%+ range. Not wanting to be screwed blue, the Feds reached out to CMU and said "How do we stop this?" So together they built the Software Engineering Institute to put some science and best practices around delivering software. And the SEI screwed them blue, coming up with CMM and a bunch of other bad ideas, but also some good ones along the way. When thinking about the skill sets of the teams I'm putting together, those are some primary aspects I look at, and the ontology by which I think about them. Of course, there are lots of specialties in each of them, and many people have experience and skills in several of them. It depends who you're talking to, of course. The goal of language is to create shared understanding, so you need to have shared definitions, whatever they are. Nobody else shares my definitions, so I mostly keep them to myself if I'm not pontificating. If you're speaking to a recruiter, you are whichever one of them pays the highest. If you're speaking to an academic, you're a computer scientist (perhaps a mediocre one). If you're telling your mom what you do, you're a software engineer because it makes her feel good. |