[vlovich123]

A lot of technical skills sure. Algorithmic analysis sure (although in practice it’s a lot less formal and more intuition + rote knowledge.

But taste about the best ways to structure a codebase? How to balance speed vs quality and when to do that? What does good vs bad observability look like? How to handle services going down in production and run post mortems? How to handle ambiguity both at a leadership and technical level to chart a path forward for a team? Even reading about these things from blog posts and things is nothing like actually experiencing these things first hand and certainly not taught. It requires accurate and constant self reflection and retrospective to guide an exploration process and if that self reflection tool is askew you can end up learning weird lessons and habits that are difficult to correct (and we all have them somewhere).

I’m team learning and was team academia early on, but the real value in academia is in teaching you how to think and to give you some minimal useful knowledge to about that capability. But it often struggles to even that because it’s still following an assembly line model of teaching whereas learning is relational.

Source: nearly 20 years as a SWE from a well regarded university.

[mettamage]

Every company structures a codebase differently. So it’s best to be open. I have worked at many places where speed vs quality didn’t come up. Also it depends on the constraints. A HFT company is much more worried about getting cache hits whereas a big tech company seems more concerned about a big n. Good vs bad observability: well you better know your statistics well, otherwise you lull yourself into a false sense of security. Not my strongest area tbh. I haven’t worked at a company where post mortems are needed.

Ambiguity: there is a lot of ambiguity at uni as well. So you should have had the practice, especially working in groups of students.

> It requires accurate and constant self reflection

Skills I sharpened at university by studying psychology. Do you know how big the mind fuck was to grok the reproducibility crisis while being a 3rd year student in that program (5th year student overall)? I had to re-examine my whole degree.

I also had courses where self-reflection was a weekly part of the course. And I took that seriously.

> whereas learning is relational

I consider it a mode.

Try mathacademy.com it will teach you the “shut up and calculate” version of math really well, and there is nothing relational about (since it’s an app).

I also had courses that were about computer and network security in C and assembly. In it, I self-taught vim, assembly, C and git. The self-teaching was partially the point.

One thing I have learned from university is that what many people see as good practices is more akin to a culture rather than an actual good practice, because the actual empirical work in figuring out what works hasn’t been done. And I find what you say to strongly fit a particular culture of software engineering. But there are many forms. For example, in the Smalltalk/Pharo community it is recommended to extend the base classes to your liking. Whereas in other languages they look at you with horror. Back in the day (2012) Airdrop was what people used and didn’t want to use git, and these people have programmed for decades (I disagree with that one personally, just showing the culture).