I believe the title is misleading out of context, I think it is meant to lack conclusions or clear statements and simply outline some areas for discussion ... a proposition paper?
I'm not familiar with what that really means, just jumping to an assumption about the intent of the paper that I think was not made clear in the title as is.
In that case I won't waste my time reading this, but submit my outline of a Useful Theory of Software Engineering:
It comes down to making a good choice in each of the following areas. (My choice is in parens, along with my comments.)
Cloud Platform
(For historical reasons I am on Azure. I have some experience with Google. It does not hurt of course to work in several, but the cognitive overhead of gaining a real in depth devops knowledge on very many platforms will be overwhelming for many people, especially as the vendors invent stuff on the fly.)
Relational Database Management System
(Strive to learn SQL and 1 or 2 platforms, mine is SQL Server, as best as possible. There is only one useful data model, and it is the relational model. You will store data with other means over your career, but learning them is mostly trivial, and if your are intentionally using a different data model than relational, you should have a good reason. Also learn to data model using natural keys. This is a huge topic unto itself. The main justification is it will simplify the queries you end up using. A friend of mine is working on a book on nat keys. There is a real shortage of good literature on this topic.)
An application programming language
(Mine is F#. Learn one or 2 languages well, chosen because the compiler and canonical workflows do so much to keep you out of trouble. You will have to know 1 or 2 scripting languages our of necessity. Given the other areas you need real expertise in, I am not a fan of spending a lot of time with the language of the month club. Become an expert in the language(s) you use. It's a career-long pursuit.)
Project Management
(Recently saw a good overview video of the "no estimates" approach. I was sceptical before I saw it. Not really impressed by Agile, but I don't want to wade into that swamp.)
Specification Language
(A new area for me. I am interested in TLA+, but I'm still learning it. The idea of a specification language that delivers an unambiguous spec at an arbitrary level of granularity that you can manipulate and refactor is very appealing to my sense of propriety. We spend too much time going straight to prototype in our favorite language, refactoring it, etc. TLA+ forces you to focus on actual spec and not implementation details. The prototype approach leads us all to confuse implementation and spec.)
It's not just you. I found it very abstract and... theoretical, even compared to other theoretical CS papers. The wording is vague and verbose in some parts, and definitely has a feel of being padded and "business-speak"-ish.
proksoup|8 years ago
I'm not familiar with what that really means, just jumping to an assumption about the intent of the paper that I think was not made clear in the title as is.
jackfoxy|8 years ago
It comes down to making a good choice in each of the following areas. (My choice is in parens, along with my comments.)
Cloud Platform (For historical reasons I am on Azure. I have some experience with Google. It does not hurt of course to work in several, but the cognitive overhead of gaining a real in depth devops knowledge on very many platforms will be overwhelming for many people, especially as the vendors invent stuff on the fly.)
Relational Database Management System (Strive to learn SQL and 1 or 2 platforms, mine is SQL Server, as best as possible. There is only one useful data model, and it is the relational model. You will store data with other means over your career, but learning them is mostly trivial, and if your are intentionally using a different data model than relational, you should have a good reason. Also learn to data model using natural keys. This is a huge topic unto itself. The main justification is it will simplify the queries you end up using. A friend of mine is working on a book on nat keys. There is a real shortage of good literature on this topic.)
An application programming language (Mine is F#. Learn one or 2 languages well, chosen because the compiler and canonical workflows do so much to keep you out of trouble. You will have to know 1 or 2 scripting languages our of necessity. Given the other areas you need real expertise in, I am not a fan of spending a lot of time with the language of the month club. Become an expert in the language(s) you use. It's a career-long pursuit.)
Project Management (Recently saw a good overview video of the "no estimates" approach. I was sceptical before I saw it. Not really impressed by Agile, but I don't want to wade into that swamp.)
Specification Language (A new area for me. I am interested in TLA+, but I'm still learning it. The idea of a specification language that delivers an unambiguous spec at an arbitrary level of granularity that you can manipulate and refactor is very appealing to my sense of propriety. We spend too much time going straight to prototype in our favorite language, refactoring it, etc. TLA+ forces you to focus on actual spec and not implementation details. The prototype approach leads us all to confuse implementation and spec.)
userbinator|8 years ago