5 ms·
This is actually a really smart idea... and it's how I gauge how good a developer is on my own team anyways... A junior/intern can barely understand the code,
by smaudet 4y ago
This is actually a really smart idea... and it's how I gauge how good a developer is on my own team anyways...
A junior/intern can barely understand the code, has little to no knowledge of the complexities of the code-base, and can barely produce a function that will not have an unintended side-effect elsewhere...
A mid-level developer or one with a cursory understanding of the code-base/domain will grasp the general concepts and have some idea of what to fix.
The senior level developer barely needs to read the code anymore, but they can ingest the code-base quickly and understand and explain the whole code-base to e.g. a junior/mid-level effectively. They are likely to immediately know the fix, and how it will likely effect multiple downstream projects.
OFC skill can push a developer between these categories - a low-skilled senior may be closer to an upper-range mid-level developer, and a highly skilled junior may be closer to a mid-level developer, but this is how experience seems to tend to affect a developer's efficacy in my experience.
- Lutger 4y agoI'm baffled how you think a senior can just sense the codebase without reading and effectively explain it even to a junior, who as you just described can barely understand the code. I think you are describing a topcoder who is working with a small, well written codebase and is familiar with the domain and stack, most of which in my experience is quite rare.
- yetihehe 4y agoI've seen this happen but without that "without reading" part. I've had a coworker, who about a 1-2 weeks after starting working in erlang (without prior exposure) on our big codebase was already able to contribute some fixes and soon new functionality and he was not even considered as senior dev when hired. Most of my coworkers are experienced and also able to work on new codebase pretty soon if required. They are not that rare.
- TingPing 4y agoA big codebase is full of the same patterns of every other codebase. If you've been doing it for a decade you'll recognize them.
- quantified 4y agoEvery codebase I've seen has a ton of brand new WTFs in it. If you've been doing it for a decade, you've seen between 1 and 8 codebases. A mix of "yeah yeah everyone does that" and weirdness bespoke to that culture. The "yeah yeah everyone calls 'new' to get a new object" isn't what needs fixing.
- TingPing 4y agoSeeing 8 codebases in a decade is a bad sign. I've significantfully contributed to maybe 30, contributed to at least 100 others, and read large chunks of 100s on top.
- rco8786 4y agoYou’re painting it too binary. Once you’ve seen a few dozen codebases you get pretty good at recognizing the patterns. A senior engineer could/should absolutely be able to familiarize themselves with the general structure of a new codebase in a matter of minutes/hours to the point that they could reasonably start directing a more junior engineer within it. It’s not “go to this file and do X, Y, and Z starting at line 105”, but more like “Ok so it’s likely that the source of this data is coming from a feed, track down the feed consumer by grepping for [upstreamservice] in the feeds directory, and from there we can get a look at what we’re doing with the incoming feed data”
- salawat 4y agoThat's different than not reading the code. Technically, that's applying tool assisted reading techniques to quickly determine what subset of code to read. I still find seniors are terrible in that they assume they know what code is going to do without having read it, or they refuse to learn the domain first.
- rco8786 4y agoI don't think that the things we're saying are mutually exclusive