If you have to refer to the API documentation frequently, even for simple stuff, I don’t see how that’s adding any value.
If you have 100 lines of code but you can expose the logic in 30 lines, that’s probably worth the refactor. However, making your code 3 lines instead of 10 isn’t very important.
Too, there's SO MUCH magic in it, that unless you work in it all day every day the abstractions take longer to remember that they're there and how to use them than it does to just write what they're doing "longhand".
I'm starting a new job with Rails and while there's a lot of magic there too, I don't get the same "how the $#! do I do this again" angst I got with Django. Maybe that's to your "bad abstraction" point.
So it's a nice idea/concept, but difficult to study scientifically.
[1] https://link.springer.com/content/pdf/10.1007/s11251-009-911...
I know other coworkers have similar complaints. My theory is that we could make this less of an issue if our organization could establish communication guidelines/ expectations/ boundaries. Doing this would make you worry less about not immediately responding to Slack and folks assuming you aren’t working. We have some managers who monitor Slack status to make assumptions on if you’re working or not too.
The key is if people care if you are in flow or not.
I have a coworker that after being 4y in the company still asks the same questions which the answer is documented in the public wiki.
I'm in the camp of writing code in a way that requires a higher „germane cognitive load“ in juniors for the benefit of writing less but more robust, extendible and fast/easy to read code for seniors. I acknowledge that this method only works best for programmers with a longer background in practicing our craft. That is why junior engineers who work with me are given more time to learn the levels of abstractions that our systems are made up. This extra time allows to build up mental models around the abstractions — which increases the junior’s germane load and thus slows their speed for shipping code modifications. Maybe in the future, we will see distinct micro services in our systems which evolve together with involved engineers: services written and maintained by junior programmers will better support intrinsic cognitive load and avoid too much germane load, and as the service’s responsible programmers will grow so will the seniority and thus the level of abstractions of a service grow to eventually reduce lines of code written while increasing robustness and extensibility of the code. As such a transition requires a higher germane cognitive load — using the terminology from that article — juniors will need to be assigned new system services which can reflect their current capabilities: significant more but easy to read code due to less abstractions.
The article ends with a well balanced summary catering for all levels of programming seniorities, read: inclusion.
> Producing maintainable software depends on readable code, and readable code depends on controlling cognitive load. Successful abstractions minimise cognitive load - particularly, they avoid extrinsic load, and provide a smooth transition from germane to intrinsic load. Creating ever higher layers of abstraction just to reduce the number of keystrokes we need to make may not always be the right thing to do. Instead, by recognising that code reading is essentially a learning process, and considering how each line of code we write will be processed in the mind of the reader, we increase our chances of creating understandable, maintainable software.
They'll simplify things for themselves at the expense of others and justify it with a shallow reason like fewer lines of code.
Do they think that it makes them look better when others have trouble understanding their work? Less replaceable? Use it as an opportunity to deepen their skills?
I've never really understood why but I'll confess that as I gain more experience, I also care less about making things easier (for others), especially if doing so would take away from my own progress.
Programmers have such an affinity for technical-sounding terms.
