
Ask HN: How do you work with complete beginners? - vommina
We&#x27;ve hired a bunch of fresh graduates from college for a software dev job. This could be hard to comprehend but let me try to put it in the best way possible. The part of the world where I&#x27;m from, we don&#x27;t necessarily hire only CS folks for such job.<p>Most of our IT &#x2F; Software Dev hires could be ranging from CS to Aeronautical to Mechanical Engineering students. All we look for is an engineering degree to validate analytical skills.<p>With that background, I&#x27;ve been assigned a couple of absolute beginners who I&#x27;d be working with to ship a feature in a __couple of months__.<p>While I strongly believe it&#x27;s my responsibility to get junior devs on par in terms of knowledge &amp; execution speed, I really don&#x27;t have any previous experience working with absolute beginners who&#x27;d barely qualify as devs let alone junior devs. What best to do in this situation? Should I accept I suck at this and bail out for everybody&#x27;s good? Is there anything I __can__ do, to comfortably work with beginners?
======
NicoJuicy
\- 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.

~~~
Gokenstein
"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.

~~~
NicoJuicy
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

~~~
Gokenstein
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.

~~~
NicoJuicy
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.

~~~
Gokenstein
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.

------
0xBE5A
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...](https://meta.stackexchange.com/questions/66377/what-is-the-xy-
problem)

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

~~~
NicoJuicy
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 :)

------
caseymarquis
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.

------
cimmanom
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.

------
CyberFonic
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.

------
jaspal747
\- 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.

------
ollysb
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.

------
tmaly
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.

------
rolleTx
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!

------
fpalmans
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.

------
afarrell
* 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/](https://jvns.ca/blog/good-
questions/)

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

