Even for things that just query a database and pretty print results, having a degree can be advantageous when that database gets big and the number of types of

Even for things that just query a database and pretty print results, having a degree can be advantageous when that database gets big and the number of types of things that are pretty printed gets large and the relationships more complex. I've been working half time on a master's in software engineering for the past four years (graduating this May) and one of the most valuable things I do at my company, in terms of "pain and suffering averted" is map out object relationships, both in the database and in the API, in flexible and extensible ways. I can't tell you how many internal APIs I've seen -- even recently developed ones -- that look like: "/api/getAcctManagerUsers" Instead of, say: "/api/users?role=manager" And these aren't new developers who do this, either. Developers trying to export three and four dimensional data in a single CSV file and wondering why it's so gross to use. Developers adding multiple secondary indexes to a 16kb table that isn't anticipated to grow in size, just because "indexes make things faster." I've seen so many boneheaded things done, just because people were just muddling through and writing the app, rather than actually thinking clearly about the data and the system, or knowing how the pieces actually fit together. I would argue that a formal education in software engineering really can force you to think in certain ways, and develop practices that are useful, even in products that should be "straightforward"