4 ms·
I feel like the documentation/source code skill works the other direction too. A lot of software engineers who grew up as hobby coders before doing it professio
by cheschire 6y ago
I feel like the documentation/source code skill works the other direction too. A lot of software engineers who grew up as hobby coders before doing it professionally seem to have a hard time going to the documentation, and will start refactoring stuff to figure out how it works.
Sure, it's possible to approach code in that way, but to me it's similar to never developing taste. The defining characteristics of the software (the documentation) is for many intents and purposes simply illegible to them, and they're basically saying "I'll know the entry / extensibility point / bug when I see it."
I interview for this in part by asking the interviewee what the most interesting new features are about recent versions of X language.
- toast0 6y agoI like looking through documentation, but between knowing how to read documentation and knowing how to make sense of code, the later is more important, because the code is always there [1], and documentation is often missing, outdated, inaccurate, incomplete, or misleading. When you have documentation you can trust to be accurate, complete, and up to date, it can be very helpful to use it though. [1] unless you're building on top of binary only software, and you're not comfortable with reverse engineering