The Software Engineer Curriculum

Software development, most generally, is the thought process involved in creating software. Doing so is tricky because you have variables at every step: what framework do you use? what inputs are you expecting from the user? which components do I work on first? Will this affect the license we release under? Should I turn this code into a library? How long will this take? Is any of this actually solving the problem? You have to figure out which problems to target, how to target them, and then how to adjust your code when your problem and target change in the middle of development.

While one factor of being a wizard programmer I've written about is the theoretical backdrop of computer science, the other, more obvious, factor is much simpler: the ability to quickly patch code together in a way that satisfies the problem. In practice, software engineering is mostly involved in these soft questions during development rather than deriving invariants every time you make a data structure. You're plugging together blocks of code in a sensible way. At the same time we all know that quick hacks can become legacy components, and make your code more difficult to work with in the long term. What if your project is due the next day? two days? How do we make these trade-offs and how should we even think of them?

There's a lot of little recommendations people do like saying:
-use a bug tracker
-working as a part of a team
-using version control

And while they're solid ideas, they only cover a narrow scope. Our fuzzy topic centers itself on soft concepts than any particular tool. Let me re-emphasize the first sentence: software development is about the thought process, the most general ideas related to making good code and the decisions leading up to that code. The way you structure your project is the way you think of your code, and vica versa.

Tacking on to those series of small questions you ask during development, you will have to consider higher scopes objectives such as:

• accurate time estimates
• clean internal and external interfaces
• good project management

In-fact, you could just call all of this a subset of "project management", but it's not only the manager that oversees a product, as every developer will have to make decisions and become a de facto floor-manager when modifying code.

These are all very much soft skills similar to business. They're hard to define and hard to learn without repeatedly applying them. What are the "hows", "whys" and end-goals? How do we incorporate this with other ideas?

All these ideas are encapsulated in the term Software Construction, which only exists because this guy wrote a really good book called code complete, and as you guessed it, this book answers all the questions we've asked by presenting a full dissertation on the concept of software construction.

Many other books exist, and many of them are dry and too large-scale. However, I feel like the material in code complete is so well-woven it deserves not just to be occasionally thought of during development, but to be applied in practice, and that's all this curriculum will be.

Like the questions we initially asked, it's simple because the lessons are simple. The only real way to become proficient at the soft development skills is through deliberate practice.

Anyway, I'll try to cover the material here in a nice digestible format, so expect in the coming months, posts where I try to synthesize concepts from the book, primarily with C and C++.