I feel like the current trend of agile development process common in startups now somewhat works against senior devs' interests to mentor junior devs. There simply isn't time allocated for this. Senior devs are held accountable for what they deliver, and doing so on time. This is among other things like code reviewing PRs and attending meetings. For most senior devs working under this circumstance, the best they could do is answer questions of junior devs when they ask them.

I was fortunate enough to be moved into a lead role at the current place after a few months, and expectation of my amount of individual-contribution is set lower than that of other IC members of the team. This has allowed me to spend a little more time on mentoring junior devs. I can see that for other senior devs, it simply isn't realistic to expect them to spend time on mentoring, with the agile schedule. This is how I had felt myself before moving to the team lead role.

> I feel like the current trend of agile development process common in startups now somewhat works against senior devs' interests to mentor junior devs. There simply isn't time allocated for this.

If you're a senior dev, you should be gaming the system a bit to create the time needed to fulfill your role. Never let the keeners fill your time up to 100%, unless it's truly neccessary. There's always going to be some infrastructure that needs fixing, research that needs doing, refactoring that should happen, etc. And you should always have some slack for mentoring and whiteboard discussions.

I almost always start an agile sprint with a self-generated task or two already in my queue for just this reason.

If the system has to be gamed to achieve the best results for your team then the system is flawed.

The system is flawed.

My team counts new devs and juniors as 1/2 person from a point perspective when we are doing planning. Juniors usually get this sand bag until we start beating our sprint goals again.

Perpetually flawed. No matter how much resources you throw at fixing it.

There's a huge difference between "no system is perfect" and "the dominant process for development work in our industry completely ignores work that nurtures employees into being better employees."

The goal of agile, as implemented in most shops, is to get things done quickly and to establish a reporting cadence with management.

Nurturing employees, and indeed software quality, is the product of company and team culture.

The development process is concrete (and “SMART”), so that’s what many managers focus on. The cultural aspects are more nebulous, so they are ignored.

"...and a whole bunch of other important things."

Always.

The system sets the board rules. You play the game. No system will ever play for you.

Working in an agile team at the moment. I have zero time to be able to help the junior members of the team. Having a mentor is important but having a good mentor, somebody with the right skills and attitude is crucial. I'm watching helpless as the junior Devs take advice from the worst possible sources because they are the ones with the free time

I doubt that agile is the problem here. I've seen organizations which weren't even agile having the exact same problem, not just for devs. It's pretty much the same with manager/project manager positions.

I think a much better explanation is outsourcing. A company which does a lot of outsourcing only needs a few people managing the partners. Managing an outsourcing partner is next to impossible for a junior as they lack the crucial experience. So they try to focus an experienced personnel. I don't know if that is the way outsourcing is supposed to be done, but at least its the way I have experienced it.

There might be other reasons for this senior-only sickness, but I am pretty sure pointing at agile is the wrong direction. If you are unhappy with the 'agile schedule', maybe its time for

> Responding to change over following a plan

Agile doesn't really foster collaboration in general. You can't have one ticket assigned to two developers and have them pair program, from the business perspective rather than the best way to develop inexpensive new talent pair coding is a massive waste of time and resources. However agile works really well for remote workers who have little social contact outside of the daily standups and slack. It helps to be an autodidact in the industry in general no matter where your skill level is. I've had kids with almost no experience smoke me on react because we were both having to learn it at the same time and the kid was a better autodidact than me.

Actually you can have a ticket applied to more than one person in an agile process. You must've been thinking of Scrum in particular which does not allow the practice.

(The original agile process called Extreme Programming actually mandated pairs.)

Indeed, a task not budgeted in time is not done. That pertains to tests, static quality analysis, performance optimizations and use case analysis. None of these are explicitly budgeted in agile processes, though they say "write tests" or "definition of done", these are taken as suggestions.

Strongly agree. I would like to spend more time teaching junior developers what I know. But anything that slows down a small, agile startup can mean the death of the startup, so this tends to undercut my ability to do any kind of mentoring.

Excerpt from a real life situation I was in:

===========================

June of 2015:

Sital was a beginner. In general, there is nothing wrong with being a beginner. All of us are beginners at some point. And for the most part, I think corporations in the USA can do more facilitate apprenticeships to help people start their careers. However, we were a startup that needed to move fast. Could we succeed when we had a beginner in a critical role? I had doubts.

July of 2015:

I felt no sympathy for John. Hiring Sital had been his call, as was failing to hire Arthur. These last few weeks had offered plenty of evidence that Sital was a liability to the team. If John wanted to stick with Sital, he would have to live with the consequences.

I would feel very differently if Celolot had a formal commitment to an apprenticeship program, and if I had clearly been given the responsibility of running that program. And I do think corporations in the USA can do more to help people start their careers. But it was ridiculous to both want to run an aggressive schedule and also train a beginner. The one contradicts the other.

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

> Could we succeed when we had a beginner in a critical role?

This is core issue. This has nothing to do with startup team vs team in corporation. Neither can have beginner in a critical difficult role. Both can make use of junior, assuming they dont put him to critical role.

Where is best to place a beginner? Too easy and they get bored. Too hard and they get demoralised when somebody else has to step in. Give them side projects and the work load for the team goes up with code review etc for unnecessary work.

I agree with what you are saying in that it needs to be called out that time needs to be specifically set aside in agile / sprint planning for mentoring. My manager understood this and I was allocated at least a day sprint to just 'mentor' my junior dev through a 8 months rotational stint in the team. Mentorship is very rewarding and I found out that I got just as much out of the relationship as they did. It also helped that for the first 4 weeks I was allowed to run her through a self lead learning program that I designed for them. Giving a new hire out of univiristy time to learn enough of what they needed to tackle some high value work just made the final outcome so much more successful.

You are supposed to modify and fit Agile into your specific process, not follow it dogmatically. It's literally the first thing on the manifesto: "Individuals and interactions over processes and tools". Change the process, or change the culture around this instead of blaming a broken process.

To add an example: At this company they have the concept of an IP (Innovation and Planning) sprint. This means that one sprint out of 5 we take to fix technical debt, add instrumentation, verify documentation. You should have some time carved out for mentoring.

At the very least, don't count the juniors in your capacity. This way you'll be able to handle their pace while keeping your velocity.

We account for that during spring planning. We plan on pairing on tasks/stories for general knowledge transfer and mentoring. If this affects velocity, that is actually a good thing (tm). Velocity should decrease when onboarding and mentoring, and then should increase as those team members become more efficient.

I have the same suspicions about the agile process as well. Great to be fast and producing but it's counter-productive if not everyone is at a similar level of output.

This... has made me realize how lucky I am. I do get asked to mentor our junior people, and I also enjoy the look on people's faces when they get that sudden realization of how something works. And I like explaining how things work anyway; I find it's the second-best way to realize what pieces of the system -I- don't know.

And - being perfectly honest about myself - I also enjoy the (brief and usually undeserved) "wow, he's a wizard!" that I get right before - just as a random example that has nothing to do with today - spending two hours trying to debug why some simple iptables rules don't work without testing that the network was working before adding them.

I've worked at 5 companies during my 13 years of programming and while I live in Eastern Europe and not North America, I can still confidently say luck has nothing to do with it. Companies who work on long-term projects usually hire junior devs, companies that work on short therm projects don't, it's as easy as that. Companies that hire more junior devs tend to pay less and usually struggle to keep the rising star devs that they helped train for the last 3 or so years. It's just the way things are, I don't get the entitlemend of the article.

I totally agree, this is just the way things are. Yet, I think it's still possible that businesses in general have become more short-term oriented nowadays. An abundance of short-lived startups, companies being managed for short-term objectives, etc.

Therefore, it's possible, that there are relatively more short-term projects than long-term projects these days (comparing to, let's say a decade ago).

Full disclosure: I work at Dropbox. Dropbox is a company that values mentorship. It is something that is explicitly called out and rewarded in performance evaluations, and it's one of the reasons I chose to accept the job offer from Dropbox. I have been lucky enough to work at a place that pushed me to be a mentor, and another place where I got to influence culture to value mentorship, and I have seen junior developers who barely had any idea what they were doing and needed lots and lots of guidance, grow into some of the most amazing and capable engineers I've ever worked with.

> The short-termism that's infested our culture--it seems like all Western culture--is truly sickening. It feels like "Well, I got mine, screw the next generation." This goes way beyond just junior developers.

This is a byproduct of the erosion of loyalty that's pervasive in business these days. Businesses use to be loyal to their employees and in return their employees were loyal to them. That's no longer the case because over the last 30-40 years businesses have shown they aren't loyal to their employees.

Pensions are gone in favor of the 401k scam with many employers no longer even matching contributions. Medical Benefits get worse every year while the cost to the employee rises. Merit increases are virtually nonexistent and in many cases you're lucky to get a cost of living increase.

Why would an employee have any loyalty to a company that treats them like a commodity? It's gotten to the point that many functions are just outsourced to another company (e.g. HR, Maintenance & Facilities, Administration, IT). The staff are employed by the contracting firm and thus they are a fixed unit cost commodity and there's no long term obligation to them.

> The short-termism that's infested our culture--it seems like all Western culture--is truly sickening. It feels like "Well, I got mine, screw the next generation." This goes way beyond just junior developers.

It's a bit of a leap to conclude that on the basis that you weren't asked by management to mentor junior devs. In fact, it's possible management assumed you would do mentoring and didn't need to be told.

The impression I got was not that he was inferring that short-termism has infested culture due to the fact that he is no longer able to mentor junior devs.

I believe he was saying that short-termism (which his belief is everywhere and I assume he has this opinion based on external beliefs not listed here...) is the root cause of this. Not many people hire junior devs anymore.

I tend to agree with him, and believe it has a lot to do with the death of "lifers" in business.

The quickest way to progress a career nowadays is to jump every few years, and that applies to both management and tech people. If people do this, what incentive is there to properly mentor a junior developer? Train them up for them to get nabbed in a few years?

There is not much loyalty in both directions nowadays and that has some genuine downsides.

Implying management isn’t tech? You mean isn’t engineering? (Well, people engineering....)

It isn't tech nor engineering nor science. Managers do not properly and scientifically measure their performance or performance of their teams. Nor run proper experiments on management practices.

Do you read the newspaper? Watch TV? Have you genuinely not noticed an increase in short term thinking and f*ck you, got mine mentality in North America?

If not, over what time span are you considering?

The "f*ck you, got mine" was probally always there.

It seems like it's just getting worse though.

Morality/ethics used to be more noticed, and rewarded. I don't know who to blame. I sometimes think it's the lack of listening to a sermon on Sundays?

I do know this, I can usually spot the selfish bastards around us, and try to steer clear from them. If I can financially harm them, I try. If they happen to be family, they are emotionally cut off.

I have a very financially successful sister.

She is now over fifty, and misserable. She lived the American dream, but did it ugly, and now just has a 25 year old husband that doesn't care about her. Yes--she got a pre-nup.

She still emails me with some new spiritual thing she discovered. It's always the same email. Why don't my brothers, and mother call me? My kids only call when they need money. What did I do?

She knows what she did early on. It's no mystery. At one time she had it all. Her good looks got her so much. The looks are fading, along with that power. I knew in my twenties she would have a wake up call later in life, but I didn't know she would burn down so many bridges clawing her way up. And no--if she was a man, she wouldn't have it easier.

I've never been explicitly mentored but I've been lucky to work places where there have been colleagues with things to learn from by example and inference. There does not need to be an explicit mentor relationship for knowledge to spread if work is done in teams and culture of open communication is cherished (at least on the team level).

I don't think dedicated mentorship is required for junior devs.

There's usually code reviews in which they can pick up on a lot, a mountain of resources online, and there's nothing stopping them from asking for help/opinions from fellow co-workers when tackling a problem.

Junior programmers may not (even probably don't) have a good idea of what questions to even ask. Younger juniors (e.g. right out of college) may even feel intimated or anxious that their question is "stupid". This isn't helped by the software industry's reputation (well deserved, in my opinion) of being populated by arrogant people with little or no tact or empathy.

Reliance on online resources is, in my view not a substitute for experienced mentorship: there is the paradox of choice, and the plethora that creates this paradox is of generally poor quality. Except for textbook or trivial problems, moreover, much of the resource material online is too generic or only marginally applicable to the depth and breadth of technology issues that face a real business and its needs.

Totally agreed. This is, in essence, what I would define as the line between "junior" and someone escaping it.

Learning how to discern relevant info from random and how to ask useful questions in new areas are skills that take time (and a ton of context) to acquire, but are utterly essential to doing anything beyond what other people tell you to do.

> "This isn't helped by the software industry's reputation (well deserved, in my opinion) of being populated by arrogant people with little or no tact or empathy."

I don't get this attitude at all, but perhaps that is because I transitioned into software dev from the trades. In the trades you want your apprentices to ask questions, I don't see why Senior Devs would be assholes. In my experience, when I asked my Senior Devs questions, and this was after initial research efforts on my part, they were all receptive and helpful. It is much better to ask the question as a Junior than commit to prod and create even more work for the Seniors.

Ask the right question is a skill, and a good indicator for growth. If you have an ineffective team member on your team, you will know the pain. Junior dev isn't necessarily bad, some of them can ramp and contribute really fast, but some are just lacking.

When you hire a junior developer, they are themselves a project. How else could it be? The need for mentoring is what makes them a junior. If they didn't need mentoring, they would not be a junior.

Code reviews are a reactive exercise. They allow people of influence to criticise work. But it is important that people of influence have first stepped up, and laid out a clear direction.

As the mentor, you should have a mental plan for their one month, three months and eighteen month progressions. If you do not have this in mind, you should not have hired them.

From here, you should set a tempo that steers the junior to grow. The things you are growing are their skills, judgement and initiative. You need to balance the need to make sure they are heading down a good path against the momentum of their own initiative, which is valuable but also prone to misfiring.

This path will be different for each person. So: have a plan, but be prepared to adjust it regularly.

There comes a crossover point where their judgement and ability becomes strong. You realise that your steering efforts are holding them back vs their own initiative. There should be some conversation where you explain that you are stepping back, and that they should be careful with the extra rope they will be getting. With graduate hires this will be at least eighteen months out.

Im hired as junior dev. at a relatively large non-tech company, to provide them with software tools, I built all these tools by myself with no mentoring and no help, My fear is this, my code looks clunky (probably not written according to good software design ?), and hard to read for others, I also have no skills in collaboration, how would I be able to grow these skills without a mentor ?.

You sound as if you are already able to teach yourself, just read more open-source code to find out what is good or bad style.

I would consider soliciting a formal mentor here on hackernews. Hacking on a open source project together would be a way to recieve that help in a remote fashion.

Sounds like there should be a thread to match mentors and mentees here on hackernews. Maybe a bunch of mentors post some open source projects that they want mentees for?

I would jump on something like that, I'm a senior university student currently with no work experience on my resume. I have been unable to do internships during summers because I usually need to spend that time helping out my sick father every year, and it terrifies me that I'm going to have to jump into the marketplace with no internships or anything really on my resume.

Every time I try to 'contribute to open source projects' online I get overwelmed by the size and complexity of most codebases, I have tried numerous times, and have never been able to fix a bug.

This type of thread is something I'm sure I and others would take serious advantage of.

When I started my first job out of university I worked in a team where we were tasked with fixing various issues and requests (e.g. reports or minor features) from the business, so that teams working on features could focus on those. Even senior developers would be rotated around into this team, but as a junior develop it was where you first started, to learn the ropes.

It was a great experience, as other members of the team, who were more senior than you, may not have even understood how the application you were looking at worked (we had ~40 applications/services), so you would have to work together to figure it out - both completely clueless. Usually we would pair because of the unfamiliarity, but if we were familiar with the application we would occasionally work solo, even as a junior.

The best bit was the management: there was enough pressure that you knew you had to get this fixed soon, but not so much that you were stressing out.

Code review is horrible way to teach. Especially with reviewers common in tech who just can't tell difference between differences of opinion and crappy code. Or difference between "how I would did it" and bad code.

I don’t agree with this at all. It’s up to the participants to argue their points and see who has more valid designs. I became a much much better programmer by learning from senior devs who review my code.

Except when Juniors are humble and like "yes sir yes sir", don't defend their design assuming seniors know more and internalize everything. And except when seniors give conflicting feedback based on what they read yesterday. It was mostly impact on those juniors I found bad. They were told their code is crappier then it really was and lost a lot of confidence. They started humble and ended afraid to do anything except simplest tasks.

Also, they got only and exclusively negative feedback. Instead of being told in advance how to do things where we are opinionated or being encouraged to ask questions or just being led/given hints, they were expected to do it alone. Then they were told they done it badly and were effectively dictated how to rewrite it.

Tech is not different from anything else - teaching people should involve more then just telling them they suck. It should involve telling them what they are expected to do in advance.

I feel like the problems you're describing are more workplace specific and not specific to the method of CR itself. For example,

> They started humble and ended afraid to do anything except simplest tasks.

It's the job of the team leads to create an environment where people (especially new people) shouldn't be afraid to try something out and learn from it. I've had plenty of CRs which went for some huge number of iterations when I first started, generally this was solved by spending some time thinking about designs on my own and then having a meeting with senior devs to discuss pros/cons and any suggestions before writing any code.

> Also, they got only and exclusively negative feedback.

This sounds really shitty, and this seems like a problem with the people on the team. I always try to put at least one positive thing in a CR after lots of criticism, and if there isn't that much criticism even better!

All in all it sounds like with or without CR, the team you're describing probably wouldn't be a pleasant place to work.

I agree with you, through I am pretty confident the seniors were well meaning. Insecure in more then one way, but still well meaning people with no intention to cause anything bad.

It is not that CR is has no place in the process. It is that it should not be primary tool for teaching, mentoring and leading. Nor talked about that way. Every forum and blog posts talks about CR as teaching tool and every discussion about juniors puts a lot of emphasis on CR and none on other tools. A lot of people think and act that way.

Yeah, it was a long time ago (2000-2003) but I still clearly remember implementing everything twice as a Junior Developer - first my way, then their way.

On the other hand it's possible for this to lead to senior developers who can't or won't leave their comfort zones entrenching designs and patterns that degrade the efficiency of the organization.

What you said is basically a tautology. "This method of mentoring won't work if you have bad mentors".

The person you're describing shouldn't be mentoring. The problem isn't the methodology, but their personality being poorly suited to the task at hand.

This industry frequently conflates effective producers of lines of code, with an ability to function in a senior role. If you look at other lines of work, seniority often implies things beyond "does the basic job quickly".

1.) Depending on the team, code review is either done by everyone non-junior or by the people most responsible for code base and expected to know most about it. It is last approve/reject step before admitting code.

So yes, this person will do code review. And code review has more functions then mentoring.

2.) Mentoring starts on task selection. Latest when junior start working on it - with senior occasionally checking the junior out while the task is in progress. Code reviewer might be someone completely else who might have noticed that junior is working on code only after it is done.

Sane mentoring should not start when junior finished the work.

If the reviewers are giving crappy code reviews, what makes you think they would be better at mentorship?

I it is different task. And you could assign it to different person.

Also, there is level of knowledge to be acquired about teaching and working with people. A culture that does not conflate code review with teaching nor talk about it as a primary means of how to deal with less experienced developers have better chance to develop that knowledge.

As in, admitting that those are different tasks is first step.

How would you feel about mentoring non-technical people? Uber seems to be piloting an apprenticeship program for people from non-technical backgrounds:

https://eng.uber.com/engineer-apprentices/

I don’t really know why Uber is doing it, but I wonder if in-house apprenticeship programs are going to become more of thing now.

Vocational + apprentice systems of all types are going to be a massive thing in the next ten years. Most likely we'll all be sick of hearing about it a few years from now. It's starting to pop up everywhere in the US, an idea that has caught the culture's imagination again. It's the ideal counter to the stupid practice of everybody must get a four year degree as a base qualification. And it's the only way the bottom half in the US are going to finally start making progress again.

> How would you feel about mentoring non-technical people?

I'm not sure what you mean by "non-technical" people. Didn't we all start at zero technical skill? If Uber have gone about this the right way and have some motivated hires with some of the right basic competency then they should do well.

In terms of technical mentoring I'd be very happy to engage with individuals inside a program like this. It's a very different story when you've got someone who was originally hired for a different role and you are tasked with helping them make the jump from a non-technical role to technical one. This can fail for a number of reasons, but it often boils down to motivation, and the individuals might have been better quitting to do something like a bootcamp.

I will say that I have gotten a lot of benefit from coaching/mentoring non-technical people on specific things. An example would be teaching a customer success manager how to capture useful info from the browser dev tools. They have a superpower and that results in them getting better troubleshooting info to help customers.

Well, you don't have to be asked directly to do that. I assume, you work in senior position, so read your role description and contract, for most senior positions I have seen "mentoring" and "team leading" is explicitly written there. Sure, don't expect to get assigned time and classroom with whiteboard for teaching in typical company, as it is expected to be done on fly ("don't know something? go ask our guru").

The way to learn professional coding as a junior dev is to consume massive quantities of programming books while working on side projects. Mentoring is great, but its value is usually very local to the current needs of a team.