Entry level philosophies: How should new developers become exposed to a codebase?
-
I've been in this career for almost 20 years. I've climbed the ladder from junior to senior to team lead/manager throughout, and for the past year one of my responsibilities is delegating tasks to my team which ranges from veterans of our codebase up to fresh out of college graduates who have varying skills to work with.
Throughout my career, it seems the typical course for anyone new is to start out being handed bug tickets, usually low-priority ones so they can fix them at their own pace. The idea of this is to give them raw exposure to the codebase and figure out how things work. It's what I did as an engineer throughout. And for me, it kind of worked. Many of the bugs were simple enough for me to figure out on my own, and I had help with the ones I struggled with. Some dev teams are more strict about this than others. I've been in places where there was a very strong line between, "Support Developer" and "Feature Developer" where it seemed to be a mortal sin for any support developer to ever work on any ticket marked as a 'story' or any feature developer to work on any ticket marked as a 'bug.'
However, my experience as a manager has revealed this might not be the best approach. I work for a fairly large company that my smaller team is sort of ancillary to. We kind of are our own independent team that works mostly autonomously. Their approach in their larger teams are similar to what I've seen before: Maintenance devs who fix bugs are typically the junior devs who have to prove themselves before they're promoted to more mid-level or senior devs who would then work on new features. It's a pattern I see in a lot of dev outfits.
I apply the same thing here, and I've found it seems to result in less productive work. We have three new developers:
-
One is among the weakest skill-wise. He graduated college recently in comp sci, and seems to lack motivation and gets frustrated easily. The bugs I assign him are not too difficult, yet he struggles with just "where to start" troubleshooting, seemingly opening random files to figure out where to go. I've tried to give him some help with methodology but he just doesn't seem to "Get It." However, I did give him a few net-new feature stories which he seemed to be able to figure out quicker than bugs.
-
Another is fresh out of college. He similarly struggled with bug fixes albeit not as much as the one above, but when we assigned him a few small improvement/new feature stories, he excelled far greater in that.
-
Another is another new hire, but he is more senior level. We basically gave him a couple bug tickets before sending him into the fire working on some new features. He's proven himself in that.
The pattern I'm seeing is the inverse of what seems to be the defacto norm. Bug fixes are more easily solved by those well-versed in the codebase, especially those with code ownership. Now, really, this certainly makes sense. After all, it's easier to fix something you built yourself rather than come at it clean and having to figure out the moving parts before coming to a cause and solution (often times fixing it with a poor approach, requiring alterations in the PR). New features, on the other hand, you do need to know enough of the codebase to understand the patterns and overall architecture of the software, but it's more on a big picture level usually, so you're more apt to be able to accomplish something sooner than you would sorting through lines of code to figure out a bug.
For the second developer, we decided the senior dev who worked primarily on that part of the codebase and has ownership of it should be the bug fixer, while the junior should work more on new features rather than bug fixes. This approach has worked well for us. The bugs get fixed quickly, and with some assistance, the junior is able to produce those new features. And he may then become the owner of some of that codebase so he can then work on bug fixes as necessary.
It seems there is sort of a stigma among developers who's primary purpose is to "fix bugs" rather than "create something new." And I get it... it's more exciting and rewarding to create new stuff rather than fix what broke, but from a performance standpoint, it seems more effective and time efficient to let the seniors handle the bug fixes for what they had previously created, than let the meek juniors inherit the machine the seniors created and figure out how to fix what was reported broken.
Certainly there's going to be exceptions to the rule. And obviously there are lots of new features that require an experienced architect to come up with at least the groundwork and scaffolding necessary to build the feature. Juniors can't do all of it on their own and they'll need mentoring and assistance from the seniors. But in my experience, bug fixes just doesn't seem to really help people learn the codebase as well as people seem to make it out. Not saying they don't learn anything but I have seen better craftsmanship skills developing by having them work on smaller feature items and work up from there and, over time, gaining more and more confidence building bigger and more complex features with the help of seniors and leads. Juniors can still solve bugs, but I don't think it should totally exclude them from ever working on new features.
With that, they do gain some experience with troubleshooting because they're going to be troubleshooting what they built. They can adapt those skills to cases where, for instance, a feature owner leaves the team, requiring one to inherit the codebase. A suitably experienced dev who's worked on the overall codebase and likely certain things tangental to the feature set can still be an effective problem solver.
Is there something I'm missing?
-
-
@The_Quiet_One the "make the new guy eat bugs" approach was never actually a rational approach. It's just a thing people do in groups. The status perception of features vs bugs is of similar provenance. One time I moved the CIOs Overton window onto tech debt, and he promptly burnt the whole PMO - illusions are wobbly like that.
-
@The_Quiet_One said in Entry level philosophies: How should new developers become exposed to a codebase?:
Is there something I'm missing?
Ultimately, the best thing to do is what makes the real team you've got actually productive and effective overall. We can try to learn the lessons from other teams and so on, but that doesn't really mean that we should do exactly the same; sometimes, those lessons are going to be negative ones ("don't do this because it really sucks!")
If someone has little experience, they probably can't tackle anything tricky that cuts across lots of concerns — dealing with that sort of thing is what really takes experience so that not too many weird extra problems are caused — but what is tricky isn't always clear; it certainly isn't the case that bugs are necessarily simple or new features necessarily tricky. Perhaps a better thing would be to encourage people to speak up if they're having problems, because it could be something where they just lack the specific knowledge to handle it, or maybe it is a chance for a bit more mentoring; bad teams are ones where nobody talks to anybody.
-
@dkf said in Entry level philosophies: How should new developers become exposed to a codebase?:
bad teams are ones where nobody talks to anybody.
And the worst, IMO (and I've had way too much experience with this), are the ones where the new person on the team (junior or very senior) asks a question, but nobody answers.
-
@The_Quiet_One said in Entry level philosophies: How should new developers become exposed to a codebase?:
Bug fixes are more easily solved by those well-versed in the codebase, especially those with code ownership. Now, really, this certainly makes sense. After all, it's easier to fix something you built yourself rather than come at it clean and having to figure out the moving parts before coming to a cause and solution (often times fixing it with a poor approach, requiring alterations in the PR).
I agree with this, modulo "fix this typo in the UI" type defects.
-
@Benjamin-Hall … which is a kind of thing you can't have anybody do for long because you'll bore them to death that way.
-
In my first development job, I started off as a "maintenance" developer but I was doing features or new reports in 3 months.
It worked better than it seems to for you, but that shop was a full on agile place, with pair programming and everything. By the third month I didn't need the hand holding and could do it "all" myself.
I'd suggest something "like that". Have a senior (or even the team lead) buddy up with each of the new guys for an hour or two a day and give them enough guidance to be successful and complete.
Heck, depending on how big the team is, you can maybe rotate all the seniors so they all meet and work with all the juniors.
-
In my experience there are (roughly) two kinds of developers; those who design things and those who slap things together until they work.
The first kind is better for complex features. They think before doing so it takes them longer to write something, but then it behaves consistently and has few bugs. But they rely on this to avoid debugging, because they suck at it. So don't assign them obscure bugs in ancient code, they'll be totally lost.
While the second kind is used to kicking and poking things with a debugger until they start doing what they want. Those are good at tackling obscure bugs, and usually even enjoy it, and you can ask them for a quick prototype here or there if you need it quick, but don't give them complex features, they are not up to big designs.
So, for new hires, you have to start with tasks that are restricted to small parts of the codebase, so they don't have to learn everything at once, but whether they should be bugs or features depends on
- what they are good at, and
- what they enjoy, because the last thing you want is to prematurely burn out anybody.
-
@Bulb the first type will lead to systems that mostly work and are hard to debug. the second type will lead to systems that mostly don't work and are easy to debug. choose wisely.
-
@The_Quiet_One said in Entry level philosophies: How should new developers become exposed to a codebase?:
especially those with code ownership.
This is something that my last two jobs have made a priority. Within a month or two as a new dev you will own some part of the software. You might not have written it, but you are now the primary resource for any tickets that come along (the dev who wrote it is still fully available for help and guidance, but you will be the one writing the code).
-
@Bulb said in Entry level philosophies: How should new developers become exposed to a codebase?:
@Benjamin-Hall … which is a kind of thing you can't have anybody do for long because you'll bore them to death that way.
And hopefully you don't have that many typos
-
Personally, I find the maintenance/features developer split to be a distasteful concept, because in my experience it leads to features
duhdevelopers just throwing things over the wall and rushing off to the next cool new thing without any real care to how well the last new thing they did actually functions or integrates with the system, because that's not their problem.I think the ideal way to bring new developers into a codebase would be to have them pair with different senior developers on a rotating basis, and work through issues with those developers. Of course, in the real world, some juniors learn well in a pairing environment and some don't... some seniors can teach that way, and most will just bulldoze over the junior and do the work while the junior hopefully picks up one fact from the firehose of watching the senior do his work (and I've met some seniors that basically resent being forced to drag somebody else along and get slowed down by them, soooo)
Failing that, I'd settle for throwing the junior into the kiddie end of the pool and making sure they have good access to a
lifeguardmentor for questions & clarifications.
-
@Bulb said in Entry level philosophies: How should new developers become exposed to a codebase?:
In my experience there are (roughly) two kinds of developers; those who design things and those who slap things together until they work.
The first kind is better for complex features. They think before doing so it takes them longer to write something, but then it behaves consistently and has few bugs. But they rely on this to avoid debugging, because they suck at it. So don't assign them obscure bugs in ancient code, they'll be totally lost.
While the second kind is used to kicking and poking things with a debugger until they start doing what they want. Those are good at tackling obscure bugs, and usually even enjoy it, and you can ask them for a quick prototype here or there if you need it quick, but don't give them complex features, they are not up to big designs.That's a good synopsis. And I like that you find the strengths in each type, as the second kind is often stigmatized as a "bad developer" but really their approach can be useful and productive in some cases. We have a very seasoned senior dev who is the second kind, but we've subconsciously sort of pigeonholed him in that position, where he's very much the "researcher" who comes up with proof of concepts of new features and is able to just hammer at bugs with macgyver tools to come to a solution that we may clean up a bit when he's done. But his work is invaluable because a lot of other people, myself included, don't like the brute force strategy that he enjoys.
So, for new hires, you have to start with tasks that are restricted to small parts of the codebase, so they don't have to learn everything at once, but whether they should be bugs or features depends on
what they are good at, and
what they enjoy, because the last thing you want is to prematurely burn out anybody.The second one is an important part, yes. And another reason I am not a fan of the strict separation approach.
@izzion said in Entry level philosophies: How should new developers become exposed to a codebase?:
Personally, I find the maintenance/features developer split to be a distasteful concept, because in my experience it leads to features
duhdevelopers just throwing things over the wall and rushing off to the next cool new thing without any real care to how well the last new thing they did actually functions or integrates with the system, because that's not their problem.Totally agreed. This strict separation is something I'm consciously trying to avoid. I think having an ideal mix of maintenance and feature tickets is the best approach.
I think the ideal way to bring new developers into a codebase would be to have them pair with different senior developers on a rotating basis, and work through issues with those developers. Of course, in the real world, some juniors learn well in a pairing environment and some don't... some seniors can teach that way, and most will just bulldoze over the junior and do the work while the junior hopefully picks up one fact from the firehose of watching the senior do his work (and I've met some seniors that basically resent being forced to drag somebody else along and get slowed down by them, soooo)
We always do some kind of pair programming of sorts for certain things. We also give them the round robin tour of the codebase to at least give them a big picture view of how things work.
Failing that, I'd settle for throwing the junior into the kiddie end of the pool and making sure they have good access to a
lifeguardmentor for questions & clarifications.Yeah, the kiddie pool is sort of what I'm already doing. The problems with it are we only have so many tickets that fit this goldilocks trifecta of tickets that aren't high priority, are small manageable tickets for a newbie, and really aid in gaining some useful understanding of the codebase so they can move onto bigger fish.
In the past we've had the problem of hiring one dev, assigning them those tickets, then gaining a second dev a few weeks later. By the time the second dev is starting, all the goldilocks tickets are exhausted, and it's more difficult to find bite sized ones for them.
-
@The_Quiet_One I don't think you are missing some Magic Thing
. In fact, I agree with what you said, and this is also more or less how we do things in my team, which seem very similar to yours.Like you, we are a small (tiny nowadays...) part of a much bigger organisation and when we get someone new we can't really spend much time on them doing just bugfixes, because when we manage to get someone it's to work on some project. But I also believe that bugs are better fixed by someone who knows the code, for reasons explained above. So we tend to give new people small isolated features to build, and work from there.
This has worked reasonably well until now, so I'll keep doing that.
Though to add some criticism, the one drawback I've seen is that some people tend to become somewhat isolated and may e.g. not get very familiar with some useful bits of our codebase (or conventions -- loosely speaking, I'm talking about more than just where we put braces). For some people (again, very people-dependent), I suspect that working on their own feature might contribute to that. Obviously code reviews and whatever other communication exist, but... still, it's easier to do your own thing when you're asked to, well, do your own thing.
-
@izzion said in Entry level philosophies: How should new developers become exposed to a codebase?:
Personally, I find the maintenance/features developer split to be a distasteful concept, because in my experience it leads to features
duhdevelopers just throwing things over the wall and rushing off to the next cool new thing without any real care to how well the last new thing they did actually functions or integrates with the system, because that's not their problem.If there is a bug in a feature Jack wrote three month ago, it should definitely be Jack fixing it. And doubly so if it was previous sprint. Because he remembers most about the code. Who currently understands the code in question the most is important criterion.
But for maintaining the five years old pieces the original author of which has left long ago, there are people who are good at it, and people who would quickly get frustrated by it, so some split will appear. Not along the bugfix/feature line, more along the legacy code/new development line. If you need to add a feature to the legacy code, you go to the brute-force type maintenance guy, because the legacy code often can't be easily cleaned up, it has to be kicked into a round cube.
-
@The_Quiet_One said in Entry level philosophies: How should new developers become exposed to a codebase?:
It seems there is sort of a stigma among developers who's primary purpose is to "fix bugs" rather than "create something new."
Welcome to Google!
-
@Bulb said in Entry level philosophies: How should new developers become exposed to a codebase?:
But for maintaining the five years old pieces the original author of which has left long ago
I think that even in that case, another dev that has been working on the same overall codebase for 5 years is likely going to be more efficient than a brand new dev. That is, provided there is some overall consistency to the code base, and of course there is some individual variation.
Still, I'm not convinced by that whole idea that bug fixing is for juniors/new devs and features for more experienced ones.
-
@remi said in Entry level philosophies: How should new developers become exposed to a codebase?:
Still, I'm not convinced by that whole idea that bug fixing is for juniors/new devs and features for more experienced ones.
I'm pretty sure that's a bad split. I suspect a better one has to do with whether the change interacts with how people use the basic data model of the app; the deeper you go down that rabbit warren of complexity, the more experience you need to not fuck things up. Another area where experience tells a lot is when dealing with things with a lot of failure modes, including some very rare ones. Networking is one of the classic examples of that, as it is really much harder to get right than it appears to be.
By contrast, much UI programming is mostly fairly simple, with a lot of detail but that detail being largely limited in impact to its immediate environment. As such, it is often something that a junior programmer can take on. (Of course some new UI features require backing by model changes, and not all UI coding is simple either...)
-
@remi said in Entry level philosophies: How should new developers become exposed to a codebase?:
@Bulb said in Entry level philosophies: How should new developers become exposed to a codebase?:
But for maintaining the five years old pieces the original author of which has left long ago
I think that even in that case, another dev that has been working on the same overall codebase for 5 years is likely going to be more efficient than a brand new dev. That is, provided there is some overall consistency to the code base, and of course there is some individual variation.
Of course. What I am saying is there will be people who are better suited to maintaining that old code with a lot of technical debt and others better suited to other things.
Still, I'm not convinced by that whole idea that bug fixing is for juniors/new devs and features for more experienced ones.
You shouldn't be. It is patently absurd.
-
@The_Quiet_One said in Entry level philosophies: How should new developers become exposed to a codebase?:
Some dev teams are more strict about this than others. I've been in places where there was a very strong line between, "Support Developer" and "Feature Developer" where it seemed to be a mortal sin for any support developer to ever work on any ticket marked as a 'story' or any feature developer to work on any ticket marked as a 'bug.'
This needs to emphasized as an exceptionally bad idea and something to actively avoid. Developers needs to fix their bugs to learn for the future. It's not just about the programming craft alone; the code might be actually bug-free by itself, it's just used in a completely unexpected way (for the developer) and this should be reflected in new features.
-
What I think worked better for me was doing a kind of pair programming with the new people, showing them around as they try to do stuff.
These were senior developers being adapted to a new programming language and business, I didn't had a chance to test it with juniors
@The_Quiet_One said in Entry level philosophies: How should new developers become exposed to a codebase?:
And I get it... it's more exciting and rewarding to create new stuff rather than fix what broke,
I like fixing bugs, you have a faster reward to cycle that works well with my ADHD than a longer project. It's frustrating when it's a bug that is really hard to reproduce and/or debug, but the normal bugs are fun
-
@sockpuppet7 said in Entry level philosophies: How should new developers become exposed to a codebase?:
I like fixing bugs
It is important to note that people are different. So some will like fixing bugs and others not so much. The only universal is that nobody likes to be stuck for long.
-
@Bulb said in Entry level philosophies: How should new developers become exposed to a codebase?:
The only universal is that nobody likes to be stuck for long.
-
@dkf And Wally does not at all need any on-boarding program, except the introduction to the coffee machine, and the men's room.
-
@BernieTheBernie said in Entry level philosophies: How should new developers become exposed to a codebase?:
@dkf And Wally does not at all need any on-boarding program, except the introduction to the coffee machine, and the men's room.
The Coffee Ring of Surcease.
-
Ah, distinctly I remember it was in the bleak December,
And each separate dying ember gave out its fast-fading heat.
Eagerly I wished to be wired; — against fate I had conspired
To earn some surcease of tired — tired for the loss of sleep —
Tired and wracked with work, far too much to even sleep —
Tech debt... is far too deep.
-
@The_Quiet_One Speaking as a senior level developer lured into, and fired from, at least one junior developer job, making new people fix bugs is insane. Often the "senior" people are soooo smart they've created an undocumented Rube Goldberg machine that can't be tested and can't tolerate peeking out from ticket tunnel vision. Yet the "dumb" n00bs with no domain knowledge are somehow supposed to figure out not only what's wrong but how it should work? Get out of town.
Earlier in my career, new people started on more isolated projects. But the enterprisey kitchen sink world we're in now doesn't like that. Ownership also went the way of the dodo once everything had to be an integrated jack of all trades. New people get stuck on support because it's a shit job (with the side effect that it's easier to prove "non-performance" if a threat arises) and that's all there really is to it.
-
@Zenith Long ago I heard a saying along the lines of “debugging is harder than writing it in the first place, so if you wrote it as smart as you could, you're already in trouble”.
-
@Bulb said in Entry level philosophies: How should new developers become exposed to a codebase?:
@Zenith Long ago I heard a saying along the lines of “debugging is harder than writing it in the first place, so if you wrote it as smart as you could, you're already in trouble”.
I heard that too, attributed to Ken Thompson.
-
In any case, the correct answer is "by binary search".
-
@Gribnit Oh no! The Guacamole thread is
