To me, software development is many things, but the inner loop is mainly characterized by two alternating modes: Trying things and Learning things.
The biggest hidden assumption I see is that we expect other people to be trying and learning things in the same way we do.
Experienced devs will write code to improve their own understanding, they will create tests to improve their own understanding, they will do research, they will do a lot of learning and all of that rarely gets talked about at standup or in a pull request. This work never shows up in a planning or budget meeting.
I see junior devs getting stuck hard on delivering production ready code - which is the WORK PRODUCT that we want; but that is not what the actual work of software development looks like. A lot of junior devs are hesitant to do throw-away work that does not get committed to source control - they feel like someone out there knows the answer and they just have to find them. And for a long time, that works - they can find someone to provide the answer they need, they can find a senior dev who glances at the code and fixes it effortlessly.
This whole thing is exacerbated by managers with no or minimal dev experience, who also confuse work product and tracked work items with the actual work of producing software.
(And if you're wondering who 'junior devs' is, it's me. I'm junior devs.)
Something which has been lost is RTFM. Anything tool, library or language you want to use you better get comfortable with the idea you'll have to read documentation (or RFC). Pasting code you don't really understand from anywhere is not how you'll master something, that's how you'll brick a VM trying to extend some partition. Multiple times.
But telling people to RTFM instead of giving the answer is rude now. Also tutorials should take more time to show to watchers / readers how to get the information they distill.
Simple example with our friend k8s: most tutorials will just give you some generic Deployment yaml. Never explaining (or only at surface level) those labels and selector. Especially why you want your spec.selector to match spec.template.labels. Tutorials should link first to the Deployment documentation https://kubernetes.io/docs/reference/kubernetes-api/workload... where you'll find a link to the selector specification https://kubernetes.io/docs/reference/kubernetes-api/common-d... explaining how it matches labels and on the Deployment page you also see that your spec.template is in fact a PodTemplate which is why you want the deployment selectors to match those Pods label. 90% of examples you'll find tend to use the same names for everything because they do simple things but when you try to do something a little more complex suddenly they don't help learning which names can be changed and what it entails. Traefik gets a gold star for having part of their annotations names being meaningful.
> But telling people to RTFM instead of giving the answer is rude now.
I wish the standard answer was linking to relevant documentation. Not quite "RTFM", since it can be hard to find the right part of the manual. But the reason humanity has gotten where it is is the scalable knowledge transmission of saying/writing something once and receiving it multiple times. It's embarrassing to regress from that.
> they can find someone to provide the answer they need, they can find a senior dev who glances at the code and fixes it effortlessly.
I have often taken pains to point out when something like this falls inside my area of expertise that the reason I can fix it so quickly is usually because I've made the same mistake before enough times and remember how to solve it.
The biggest hidden assumption I see is that we expect other people to be trying and learning things in the same way we do.
Experienced devs will write code to improve their own understanding, they will create tests to improve their own understanding, they will do research, they will do a lot of learning and all of that rarely gets talked about at standup or in a pull request. This work never shows up in a planning or budget meeting.
I see junior devs getting stuck hard on delivering production ready code - which is the WORK PRODUCT that we want; but that is not what the actual work of software development looks like. A lot of junior devs are hesitant to do throw-away work that does not get committed to source control - they feel like someone out there knows the answer and they just have to find them. And for a long time, that works - they can find someone to provide the answer they need, they can find a senior dev who glances at the code and fixes it effortlessly.
This whole thing is exacerbated by managers with no or minimal dev experience, who also confuse work product and tracked work items with the actual work of producing software.
(And if you're wondering who 'junior devs' is, it's me. I'm junior devs.)