Software Engineering as a University Major?

@jon_moore asked his Twitter followers what would Software Engineering as a University Major look like and he posted the interesting replies to to a storify post worth checking out. I found an interesting article, at Dr. Dobbs by Chuck Connell, on contrasts between Software Engineering and Computer Science that I largely agree with.

John Allspaw: “There is no Resilience Engineering … without real dialogue about real practice in the world.”

John Allspaw wrote a fascinating roundup of his thoughts on the 6th Resilience Engineering Symposium.

This, in particular, caught my eye:

There is no Resilience Engineering (or Cognitive Systems Engineering or Systems Safety for that matter) without real dialogue about real practice in the world. In other words, there is no such thing as purely academic here.

(via @jon_moore)

Watch: Jacob Kaplan-Moss Keynote at Pycon 2015

35 minutes that are absolutely worth it. Watch Jacob Kaplan-Moss at PyCon 2015 explain why he is a ‘mediocre programmer’ and why we need to take a hard look at our industry, how we define our careers, and the myths we tell, because they are flawed, and we are all the lesser as long as it remains so:

Kathleen Vignos, Director of Engineering at, on its new design

Read Kathleen Vignos, Director of Engineering at, on their new design, and launch on a new Web stack. It looks like has joined a growing, varied, and impressive list of large media sites using WordPress, including, Beyonce, Google Ventures, GM, TedNasa, and Forbes. I pulled together that list recently when putting together material for the TechGirlz and Comcast class on Worpress that I participated in. It was nice reading about some of the deployment and development pipeline they are building there. Nice work

Lifehacker’s 10 Ways to Teach Yourself to Code

Normally I wouldn’t pass along a list like this, but Lifehacker’s done a decent job listing 10 paths to teach yourself how to code.

Practical Data Science with Python

@radimrehurek has put together a fantastic intro to Python data manipulation using an iPython notebook that is worthy of bookmarking and keeping as reference as to what you can do quickly with Python.


“Distributed big balls of mud”

Read Simon Brown’s post about how microservices are not the Silver Bullet some are promoting them to be.  As always, pick the right tool for the problem *and* for who will be solving it (the team and organization matters!!!). Sometimes, yes, that’s microservices. Sometimes it’s not. Pick your poison, but do so with open eyes and a level of clarity.



Consider a system to be made up of procedures, some of which are stateful and others which aren’t. We have already discussed the difficulties of understanding the bits which are stateful, but what we would hope is that the procedures which aren’t themselves stateful would be more easy to comprehend. Alas, this is largely not the case. If the procedure in question (which is itself stateless) makes use of any other procedure which is stateful — even indirectly — then all bets are off, our procedure becomes contaminated and we can only understand it in the context of state. If we try to do anything else we will again run the risk of all the classic state- derived problems discussed above. As has been said, the problem with state is that “when you let the nose of the camel into the tent, the rest of him tends to follow”.

As a result of all the above reasons it is our belief that the single biggest remaining cause of complexity in most contemporary large systems is state, and the more we can do to limit and manage state, the better.

“Out of the Tar Pit”, Ben Moseley and Peter Marks, 2006


The “software crisis” was first identified in 1968 and in the intervening decades has deepened rather than abated. The biggest problem in the development and maintenance of large-scale software systems is complexity — large systems are hard to understand. We believe that the major contributor to this complexity in many systems is the handling of state and the burden that this adds when trying to analyse and reason about the system. Other closely related contributors are code volume, and explicit concern with the flow of control through the system.

“Out of the Tar Pit”, Ben Moseley and Peter Marks, 2006