4 ms·
This can only be true if your codebases are very small (e.g., at a rinse-and-repeat site mill). For anything non-trivial, as your code grows the amount of time
by unit91 8y ago
This can only be true if your codebases are very small (e.g., at a rinse-and-repeat site mill).
For anything non-trivial, as your code grows the amount of time required to understand it will grow too -- even if you're using "standard" frameworks, etc. -- because the business logic driving your design decisions is learned with experience. For example, we have a guy at our large company who's a terrible programmer but we keep him on the team (albeit somewhat quarantined) because he's been there forever and has enough institutional knowledge to be valuable.
As your systems grow even more, there will not be off-the-shelf solutions. You'll have to sit down and do some real-life architecting and that won't be learned in 2 weeks. Even if you could perfectly document all your systems and design intentions (you can't), well documented decisions still take time to be read and "soak in".
- whyaduck 8y agoExactly. Add interaction with highly complex custom hardware and you're looking at more like 2 years rather than 2 weeks to get to the point where anyone can claim expert level knowledge.
- bluGill 8y agoI've been on both sides of this with large code bases, and I disagree. A good programmer can get into even very messy code bases quickly. Even in the worst case of ugly code there is a structure/architecture trying to keep thing understandable. Or maybe it is easier in large code bases because the worst programmers fail? I don't know, I haven't worked with many tiny code bases.
- clintonb 8y agoI've been at a new company for a few months, and still find the codebase confusing/frustrating. At my previous job, I was a tech lead/architect. Here I feel like a dummy. Talent can't necessarily overcome poor documentation.