- Help everyone at first.

- Filter out those that don't ask the same things 2x - 3x.

- Those that ask things a lot and can't do much, assign them small tasks.

- Assign features and more important stuff to the more independent ones.

- Lessen helping everyone, but move to the "only bother me if you're stuck" mantra. Let them work more independently and use the online documentation to find something.

- Have a daily standup, so that everyone knows what they are doing. If they have questions, this is when it (from now on) should be requested.

- Make sure you have an alpha, beta and master environment. Be on top of everything as soon as it enters the beta environment. Don't let them change in production ( except a seperate branch for a bugfix). They develop on the alpha branch or a feature-branch.

- If someone can't develop or work independently, try to change them more to "testing".

- Use kanban / agile.

- Don't be afraid to filter people out, it happens that some beginners take a toll on the time of the team, because they develop errors / don't test code.

- Try to push the "don't commit, if it doesn't work" mantra.

==

I personally let them develop the entire time and when UX doesn't make sense or has not logical things that keep dragging on. I then spend an evening on fixing it as much as possible and explain the things i've done the day afterwards, without name calling.

Clear, crisp guide. Thanks a lot.

> Those that ask things a lot and can't do much, assign them small tasks.

This is what I'm stuck with. Most times when this happens, I blame myself for not being capable of empowering them. Like you said, I should stop taking this hard and give some time for me as well as the person. Thanks.

Newbie mistake, just try to spent enough time the first time. So you are sure they understand, be less helpful the 2nd time.

"Don't be afraid to filter people out, it happens that some beginners take a toll on the time of the team, because they develop errors / don't test code."

I would put a huge caveat here: Make sure you're deeply involved the process and understand what's going before taking any steps to sideline a programmer that's underperforming.

I worked for 3 years on a project that was underperforming by every metric. Major features were constantly riddled with bugs, rewritten, over budget. We had no way to push our issues above the PM who was throwing the developers under the bus.

The functional requirements would change daily, deadlines would not move, we were getting less and less QA time and 0 time to write or update tests and we were trying to write an integration with a service that was still in development (trying to hit a moving target).

They brought in a BA and kid you not, she quit 3 weeks in. That got the notice of management, finally, and our semi-technical schizophrenic partner on the client side was let go. Before we were able to escalate these issues there was a very different impression of the work we were doing. Afterward it was like black and white. Perfect releases, on time, on budget, and we were delivering real value to the client.

You are talking about your POV as a developer under a bad PM, which is unrelated to the question in my view :)

I agree, it seems harsh because I talk efficiently. But I suppose most of us try to fill in the social aspects according to their situation of the roadmap I "suggested", we are all adults here and nobody will become a dictator and reference my comment, I hope :p

I thought I emphasized the point pretty well: Get involved in the process if you're managing a team of developers and don't just look at metrics. They can be misleading if there is no way for developers to communicate UP to managers or if there are self interested parties between you and your devs.

I've never thaught about a PM that isn't "involved" and only relies on metrics.

My experience is that PM's are part of the team ( and mostly a senior developer), not part of management.

They translate management decisions to their team and take responsibility for it. They shouldn't live in their ivory tower and not know what is going on.

Their experience gives them insights in developer efficiency issues and can solve more advanced problems.

Sometimes they help program, sometimes they are doing infrastructure ( Eg. Cloud management) or deployments.

They did good in the past and now do something else as a way of promotion and encounter new social aspects in managing a team and deploying a project.

Some should better stay developers and some like the challenge.

And if I interpreted the OP well, he's a promoted developer close to the team. And not a hired worker that thinks he's a PM without Dev experience.

Oh, we've had very different experiences relating to project management! I've never had a PM that was a former developer, and in my world senior developers usually act as solution architects without the title, mostly removed from the day to day development tasks unless they're briefing developers on documentation and implementation details.

You make several very good points.

I feel that we could also note that given, say, 10 team members, 2-3 will never become really competent. 1-2 might catch on quickly and the rest will become average given enough time, like 12+ months and with lots of mentoring.

That's a good list but don't mix being independent and being alone.

Beginners shouldn't be left alone for any sort of feature even if they are competent.The first couples of months you need a lot of feedback (more then a stand up every day). I'd say pair programming is the way to go.

He mentioned a new software job. An onboarding "event" should more or less happen existing software /architecture. This wasn't mentioned.

Pair programming is slow. You want everyone to be B+, while they become C's.

I keep the A+'s and migrate the F's to testing or something else.

I never excluded meetings anywhere.

I suppose the normal flow of analysis and explaining inner workings/features is still possible, I hadn't banned them. Just mentioned the stand-up as a recurring event for normal development days

Looks like i am too nice, but i see potential in them :)

I might try to directly help them a bit less.

I like giving them independent tasks that require some thought - but that aren't critical.

I spent a lot of time on helping out others. I'm perhaps a little quick on ruling someone out.

But i blame it on tight deadlines and multiple team members + seeing a pattern that works.

This list is almost perfect, but I’d add “Be patient” to round it out.

And learn them to use documentation and read open source code, would be another one ;)

Coming from someone who never did any coding (beyond assignments in class) during college and learned it within a month after starting my first real job, you'll have to take on the role of mentor for them. One of the things holding me back from learning programming earlier was having no real "entry point", it's easy to get the basics (syntax etc) down but when it comes to actually applying them, I've found it incredibly helpful to have someone I could ask my "stupid" questions. Teaching yourself new things is a skill that comes with time (imo) but when you don't even know what you're looking for, it can be very hard to find that info yourself - so having someone looking over your shoulder who knows things like "oh there's already a built-in function for that" etc is invaluable. You should also get acquainted with the XY problem: https://meta.stackexchange.com/questions/66377/what-is-the-x...

And I second the daily standup suggestion, if only to keep the ball rolling & so everyone keeps track of their progress.

Nobody is barred from learning online, they can request a meeting to discuss coding. As long as they plan the questions in advance and don't interrupt every 5 minutes for a new question.

But programming involves so many questions if you are staying. It would be best to let them learn documentation and let them read open source code.

If you want to spend 24/7 on teaching coding, you should have a different profession :)

Teaching is difficult because everyone is different. I had an intern once and completely messed it up by giving them the perfect environment for a younger me. I think what I learned is that constant communication is critical, and that you shouldn't assume the way that you learn is the way everyone else learns.

- Split up the task you have in mind into smaller tasks and assign each dev to them

- Make each of them watch online videos and do independent research and learn as much as they can in 1-2 weeks. Measure them every two days.

- Post two weeks ask them to build a small application in the third week. eg:login functionality with password reset and captcha.

- In the fourth week, ask them to build the entire chunk of work you cut out for them. Push them a little to achieve it. (They might need 2-3 weeks to get it done though)

- Keep adding new tasks and assign new learnings.

How long would it take for you to develop this feature solo?

I would expect for your novices to be a drag on your development speed for these two months rather than contributing anything useful. Heck, for most beginners that would still be the case after 6 months of study.

Use those two pieces of information to determine whether you’ve been set up to fail, and act accordingly.

I am assuming that you have reasonably well rounded experience as a programmer and are well versed in your organisations standards and methodologies. If not, then my advice is probably not going to be much use. I have re-trained Cobol and RPG programmers to develop OOP systems using the following. And I have taught SE at university so I have some experience, but never with complete absolute non-programming mindset folks.

"Ship a feature in a couple of months" ... WTF? ... is you management even sane???

Putting that brain snap aside ...

You need to establish what programming language, framework, tools, conventions you will be using. Then with that in mind, create a series of progressive exercises that introduce basic programming concepts (as are applicable to the features that you will be expected to ship over the next 12-18 months). Basically you would do a "teaching session" with handouts, examples and some live-coding on your part. Then you follow that with a "tutorial session" where your team gets to practice what they have just learnt. For a week or two that is all that you are likely to be able to achieve.

Once you get over that initial hurdle, you would need to design that first feature and assign segments to each member of the team. During that time you will be mentoring and assessing how well each member of the group is "coping".

Realistically, if you could complete the required feature on your own in one month, then the above exercise will probably take three months. But the next feature will take probably half that if your team come up to speed at about average rate.

For your sake, I suggest that you have your management on-side. I have seen too many managers who think that programming is nothing more than typing. Those PHBs are the bane of any software development project.

I am aware that this is becoming a long read. But I hope that your team is not expected to do analysis nor design. That has to be done by people with considerable domain and development expertise.

Your typical bootcamp course takes 8-10 weeks. It's (hopefully) a carefully crafted experience that will get people to a standard where they can be useful within a fairly constrained setup e.g. build crud apps with rails. Given that you're not going to be able to provide this and that even if they did have a bootcamp available they wouldn't be available for a couple of months your task sounds impossible. If switching jobs isn't an option you need to work on expectations and push for alternative resourcing options.

First, you should try to write everything down. If you have a twiki or internal site, organize the information and how things are done.

Encourage others with experience to also document everything. This will form some of the basis for your on boarding of junior developers.

If you do not have guidelines for how your code should look, how code is tested, and how code is released, get the team together and write them. Having the basics available for the juniors to learn from is incredibly helpful.

I come from a non CS background, at the company where I work they let me do some unit testing and it helped a lot to understand how things work!

About a decade ago, while working for a large a multinational headquartered in Silicon Valley, I had the wonderful experience of working with a bunch of interns; an experience I believe to be very relevant to your current challenge. Working with junior employees, irrespective of their area, can be an extremely rewarding experience, both for yourself as well as for the new hires.

In my case, the interns were made available due to a direct agreement between my employer and a nearby university (SCU). This reduced the costs of an intern, from a budgetary perspective, to zero. This was significant, imho, because most of colleagues who were assigned interns, considered their value to be equal to their costs, which I believe was a grave mistake. I am mentioning this to further qualify my personal experience.

Regardless, even though from a budgetary perspective, the interns were 'cheap labor' I never considered them as such. From my perspective, I had an obligation towards them. My job, with respect to their 1 year internship, was to teach them how to be a professional. The better I was at my job, the more valuable they would be to me and to my company. This was in strong contrast to how my colleagues approached the interns assigned to them. Suffice to say that within months, most interns ended up under my care.

Now - to finally answer your question; I developed a particular approach to educating the interns. Briefly summarized, these were the steps:

(btw: always try to refer to a framework to aid communication, as you can see below)

1. Teach your new hires how to communicate. It is impossible to stress how important this step is. The framework I used was based on a training I had taken my myself and is called SCIPAB. "Situation Complication Implication - Position Action Benefit". What this basically means is, whenever they communication they need to tell what they are talking about (Situation), what the issue is that is making things difficult (complication), why that issue is important (implication), what they think about it (Position), what they think I (or they) should do about it (Action), and why that action will make everything better (Benefit). It helps if you know this framework. I made them leave me voicemail messages (max 2 sentences) daily for about two weeks training them on how to communicate to me. The benefit to me was that they could communicate efficiently with me.

2. Further I taught them what it meant to be a team member. Group projects at university are a terrible way to prepare people to work in professional teams. I used the Belbin team roles framework to discuss this with them.

3. As the final portion of their initial training, I explained to them the different emotional stages they should expect to experience at work. Elation (at getting the job), Fear (not knowing what is expected, nor how to be successful - fear of failing / impostor syndrome), Depression (finally figuring out what is expected, but struggling to keep one's head above water), Confidence (finally knowing what's expected and how to achieve/exceed expectations. I always added that as soon as they reach the confidence level, I'd immediately 'promote' them so they'd go through the cycle again.

4. On the first or second day they started, I warned them that I would set them up for failure. Even though I told them in advance that it would happen, it still took them by surprise. You have to make your junior employees fail. Failure is a part of life, it is part of one's career. You, as their mentor or manager, have to create an opportunity for them to fail as part of their training. Giving them an opportunity to fail in an environment you control (a failure which does not negatively impact their careers) will allow them to experience the emotions associated with failure and give them the opportunity on learning how to deal with those emotions constructively.

5. As a final point, I had the tendency of implicitly trusting my intern's work. For example, a new intern had joined my team less than three weeks ago. I had gone through the first three steps above and had asked him to prepare a document for me. He had sent me a draft of the document via email and I called him, asking him if the document was ready for review. When he answered 'Yes,' which, of course, it wasn't (the intern was kid - what did he know, right?!) I immediately (and without proof reading) forwarded the document the cross-company team leading my project. The people on that team were of a sufficient level that the interns (and most others on my team) would fear their judgment. Now, my intern (as I expected and I eventually confirmed with others in my team) freaked out completely. Though, in his mind, I ended up with the proverbial egg on my face, from that day forward, he always made sure that whatever document he sent me was either ready for scrutiny, or he would specifically review it with me prior to sending me a copy.

This last point, though it seems added as an afterthought, is truly vital. Your employees will deliver work to the level of trust you give them. If you always insist on reviewing their work, they will give you a product in need of review. If you show them you trust their work, they will make sure that they earn that trust. As a side note, if you implicitly trust them and they fail your trust significantly after the first two or three months of employment, you will have to let them go. (This is a difficult thing to learn as a manager. Sometimes it just simply doesn't work out. It benefits neither you, nor your employee, to avoid the inevitable....)

This is but a brief summary and is hardly detailed. There are many more steps to making a green hire competent and valuable. Getting them to become valuable members of your team is the most rewarding part of being a manager.

Anyway, I wish you all the best on your journey in shaping the new engineers which will make your company great!

EDIT: fixing errors in first draft.

* Set clear expectations ahead of time. For example, when NicoJuicy says "Filter those that don't ask the same things 2x-3x", if you decide to take that advice then you should be clear with them "When you ask me a question and I answer it, I expect you to both write down the answer in a place where you can retrieve it for yourself and to ask follow-up questions to ensure you understand it." If you are afraid to hide your expectations because they sound harsh to you, then reflect on how stressful it is to know that you are expected to do well but to not have direction.

* Make a learning plan alongside them. You have a much better ability to curate resources that are relevant to your toolset than they do.

* Help them learn what makes a good question. Question-asking is a real skill and since they are fresh grads they might not have it. Julia Evans has some good writing on this[1][2]

* Expand the menu of questions that they know they can ask. For instance, it might not occur to them to ask you for 45 minutes of time on your calendar in order to walk through the structure, interaction flows, or major data models of the project.

* Be wary of asking them for estimates. Estimating software timelines is a hard skill. I've seen multiple new managers ask a junior dev for an estimate, receive "I don't know" in response, and then pressure the junior dev into lying. That sets up a communication roadblock. If you want to work with them on doing the task-breakdown required for an estimate, that can help as a means to teach estimation.

> comfortably work with beginners

Why is it a requirement to do so comfortably? Doing things that you are not yet skilled at is both uncomfortable and necessary to grow. It seems to me that you'd want ability to identify situations where discomfort is necessary and to tolerate discomfort.

For instance, you might decide to try programming-out-loud with them. Here, you tell them to grab notebooks and you book a conference room with a projector. Then, pick a ticket and you talk through your whole process of investigating, breaking down, planning your approach, reading through the relevant code, writing tests, refactoring, and writing code to solve the ticket. This could very well be uncomfortable for you to do and it will likely be uncomfortable for them to stop you mid-thought and ask you to explain something they didn't understand. Does that discomfort mean you shouldn't do it? Only you can answer that, but you should probably call out this discomfort explicitly and say you're going to work through it and you expect them to work through their discomfort.

[1] https://jvns.ca/blog/good-questions/

[2] https://jvns.ca/blog/answer-questions-well/