[weliketocode]

> It is not realistic to give an early software engineer defects within the first few months of a project assignment. So this skill area might not apply until a little later in their career.

what?

Please don't listen to this. Give junior engineers bugs right away. It forces them to set up their environment for debugging and begin to understand the flow of the project.

Even if he/she needs to be guided to the solution, this is a GREAT litmus test for the standards of your documentation, and ease of environment setup.

[lnsru]

This!!! Nobody gained any skill from writing vanilla code or “hello world” type programs. Experience comes from spending days and sometimes weeks on ugly bugs. Bugs are perfect to level-up juniors quickly and find ones with weak motivation. Because having no progress for hours is really really frustrating. Went recently through this cycle teaching colleague. Found out, there is no motivation at all.

[bitL]

Some people thrive when bugs are assigned to them early, some people thrive when whole new functionalities are assigned to them. Usually intersection of sets of these two kinds of people is close to empty and the worst mistake is to assume bugs first are good or new stuff first is good automatically.

[0xEFF]

When you give someone new functionality to implement and they don’t have experience fixing defects, they’ll likely add more defects along with the new functionality.

[bitL]

I am in the group that prefers new functionality; I can build state-of-art $10M business from the scratch in 3 months but if you ask me to debug old stuff for longer periods of time, I'll most likely leave or underperform. It's good to know what people you have on your team instead of assuming certain traits.

[TimTheTinker]

Our team always assigns a few cosmetic bugs to new developers during their first week - only because it helps them learn their way around our codebase.

Where they proceed from there depends on their strengths and interests.

[wolco]

I like both as long as they as smaller items. Bugs will help you to understand what is there and new functionality can be a good bridge where a new person can leverage existing experience.

[z3t4]

I was very fortunately that my skill level followed the complexity of problems, only several years into my career I had to deal with systems level complexity and scaling issues, working as a high level web developer. Some things are just magic for a beginner. As a manager you should make people feel confortable, and some people do not have the mindset for constant self improvement. And some people you need to protect or they would over-work themselves. The trick is to have a load/capacity balance. Take games for example you usually progress the difficulty, you do not start with the end boss, or most players would quit, and those that pass would find the rest of the game boring.

[gregmac]

Exactly. Fixing bugs is one of the best ways to learn a new codebase. Assuming you have a process for code reviews and some form of testing in place, it's not like there's much risk of a bad change getting out.

I'd actually lean the other way: No one should be adding new features to an existing codebase without having successfully done some fixes first.

[fatnoah]

>Please don't listen to this. Give junior engineers bugs right away.

Right?!? That's how I get every junior developer into the code. Hell, that's how I get myself into the code at a new job.

[lunias]

Agreed, this makes no sense to me (sounds like something an "engineering manager" might recommend). If not defects, then what? Surely it's not the recommendation that someone who struggles to fix bugs should be given greenfield work...

[JamesBarney]

Definitely this. Bugs are great for new devs. Nothing teaches why code quality matters and what types of code quality matter like investigating bugs and why they happen.

Also jr. devs require lots of sr. dev time to verify their work. But bug fixes are usually easier to verify then features because the ratio of code written to investigation is much smaller.

[yalogin]

Yes. Agree completely. Giving new hires bugs is the best way to bring them up to speed. They get to delve into the whole software stack, interact with people, understand data flows, familiarize themselves with code names if any, and generally get an appreciation and understanding of the product. This is my go to move for new hires.

[dfeojm-zlib]

Heck, you should try to give interviewees real bugs so they're solving real problems (not to exploit them but to see how they think and work) instead of theoretical chalkboard problems or standard brainteasters.

Certainly, guide them towards easy-ish bugs rather than complicated ones right away, because there is something to risk management of new people attacking gradually-increasingly critical code / difficult bugs. Of course you probably wouldn't give a random interviewee root access to a credit card processing system, but you should ratchet-up the level of trust incrementally as fast and as frequent as a staff member has proven themselves (treat people as adults, not kids).

[lmilcin]

Debugging stuff is still my favorite task when I join a new team. This is absolutely the best way to quickly learn about the project.

It is also important to select right kinds of bugs for newcomers.

[nilkn]

I couldn't imagine having a new developer go several months without looking at a single bug. Sure, I'm not going to give them something that I know is going to be really difficult and frustrating, but I generally try to get people in the swing of development within the first week.

[NicoJuicy]

Yeah, our software manager gives everyone new new projects, that of course are never completed.

Lol, some "managers"

[jammygit]

When I was an intern I spent most of the year fixing bugs, between other assignments. It was the most beneficial educational experience I could have had. I got really good at it by the end too.

There isn’t a better way to learn a codebase and new tech than one issue chosen by you at a time

[techslave]

I think this comment misses the point by being myopic.

The great majority of devs are not very good. (Same for managers.) Here at HN you are only seeing the pretty good to great devs. Not boot camp grads and unranked school grads.

The other thing is that this comes from the management school of management. One where managers mentor ICs and managers drive skill growth. As opposed to the SV ideal (rarely met) where mgmt gets out of the way. They remove blockers, not give opportunities. They communicate information, not hoard it.

So, from the management school of management style, managing lackluster devs (the 90% that you reject at phone screen), it’s true. These devs get in over their head when the first thing they have to do is actually understand the spaghetti codebase. This is not a road to success for these devs.

With that POV and that reality in mind, the advice is sound.

[closeparen]

Debugging requires an extremely thorough understanding of the project, so much that you can not only find each responsibility in the code, but anticipate their emergent properties, what mistakes might have been made, and how their interactions might go wrong. Debugging a system successfully is the culmination of successful on-boarding, not a starting point.

Doing the actual code changes to fix a bug which has already been analyzed and localized to one or a few sites in the codebase is a bit more reasonable.

[jolmg]

> Debugging requires an extremely thorough understanding of the project

That's precisely why it's great for a starting point. It's work that mostly consists of research of the current code, to look for inconsistencies that cause a well-defined misbehavior. It involves writing little code and therefore involves little decision-making if any, so you avoid the newcomer making changes or adding stuff that, in ways, may be inconsistent with how things are done in the project.

[commandlinefan]

> an extremely thorough understanding of the project

Right - so no time like the present to get started understanding!

[biehl]

Right. But sometimes this clashes with new developers expectation of actually being able to produce an acceptable solution and getting it merged within a reasonable amount of time.

Have those expectations never clashed for you?

[closeparen]

You can get started by doing smaller and better-defined projects first, rather than going for ~weeks before knowing whether you have any traction.

[e40]

Agreed. We do this and it has worked out amazingly well.