

Ask HN: First coding apprentice. Any advice for me (and him)? - mhotchen

I work for a PHP powered finance company (I promise it's not as bad as it sounds) with a wide range of projects, from 8 year old crufty internal systems to fairly bleeding-edge and genuinely interesting projects.<p>A new chap started a week ago and I've been assigned to train and manage him. His programming chops extend about as far as basic use of arrays and objects in PHP, and a bit of MySQL/javascript. He's quite competent in frontend/design stuff though.<p>He's clearly very smart and a quick learner from what I've seen so far, so if I handle this right he should have a very successful career ahead of him. This is also his first full time job.<p>I personally wish I was given the following in my very early career:<p>* Encouragement of my progress; I nearly gave up early on because I thought I was really shit at programming<p>* Conversely, frankness in my weaknesses, and specifically being told how to improve, not just told I'm doing something wrong<p>* How to spot a resource I can trust (online resources that don't give outdated practices, books that don't leave gaping security issues)<p>* The reasons for doing things certain ways, instead of just cargo-cult shit (I got told "that's just how we do it" so much)<p>Here are some questions that will hopefully give you some ideas:<p>* What advice do you wish you were given when first learning to program?<p>* What advice do you wish you were given when you got your first job as a developer?<p>* What advice do you wish you were given when you got your first full-time job?<p>* Is there anything your first mentor(s) did that you wish they didn't?<p>* Is there anything your first mentor(s) did that helped you a lot?<p>* Have you tested any techniques with very green programmers that worked to help them learn much better (eg. pair programming)?
======
jfaucett
During my internship I was in a similiar position to your new guy and I was
fortunate enough to have had a great mentor. I even used some of his teachings
later with my little brother when he got into development.

My mentor, Philip, did several of the things that you mentioned you wish had
been done when you were starting out. For instance, whenever I programmed
something that was good he gave me encouragement and praised me for it, but
then only on the things I programmed that really were good which made me
respect his opinion. He gave me tasks that were almost always a little bit out
of my reach in terms of my abilities but let me know that anytime I needed
help he was there.

I would say overall, he was great for the following reasons:

1\. He gave advice willingly but not with an overkill, mostly only when I
asked for it, but every now and then he say 'hey, you wanna learn how to
manage linux users, or tighten up apache security',

2\. He was a really good programmer so he always had my respect.

3\. He let me handle problems on my own and had faith in me, letting me always
know he was there if there was anything I couldn't handle.

4\. He had great advice in general for example:

he considered the best programmers to be "lazy" programmers because they would
take their time - not start coding immediatly - think through the task and its
solution, and only then begin programming with the goal being to solve the
problem in the easiest way possible i.e. so that future imports to a database
could be called from a simple shell script requiring the programmer to just
hit enter.

Another great one was when he told me about two types of workers. Type A he
said is someone who you send to find out what's wrong with a crashed server,
he goes out comes back and tells you. Type B he said is someone who you send
to find out what's wrong with the server, he comes back tells you what was
wrong with it, how he repaired it and any other pertenant information.

I hope this helps you a little bit, its been fun reminising about the good 'ol
days back when and I hope it works out well for you and the new guy!

~~~
mhotchen
"but every now and then he say 'hey, you wanna learn how to manage linux
users, or tighten up apache security'"

This is great. I'll definitely do stuff like that.

"He let me handle problems on my own and had faith in me"

I'll try and rail myself in a little bit as well, I've taken to asking him if
he needs help if he looks stuck rather than letting him come to me. Thinking
about it now that might be killing his critical thinking/problem solving
abilities.

------
endersshadow
I won't give any real advice on learning to program--I think there are a bevy
of resources out there, and there are folks much smarter than me on here with
regards to pure application/web development. What I can tell you is some
things I've seen and things that really helped me out a lot.

My mentor was incredibly keen on knowing _why_ you do something. I've seen
many new developers come in, and they were taught that X is the best way to do
something in college or from a blog or what have you, but they've never really
understood why. So, when you introduce some new condition (let's say
compliance), and you can't do X (or X is now remarkably costly), then what do
you do? The best way to do this is to do code reviews, and have him walk you
through it. Take that time to suggest better approaches, understand his
thought process, and evaluate whether or not he understands what he did.

Code reviews take time, but it's the best way for you and him to get on the
same page and understand each other. Don't approach it from a, "I'm an expert,
and I'm going to show you up" context. Approach it as a learning exercise
where he can learn from your experience, and you can learn more about how he
works.

Another thing my mentor did was took me with him to meetings where we reviewed
the code. Getting to know your users and understand who you're doing this for
is incredibly important. So many organizations try to abstract them away. It
was something that put a face to the end user, and gave the user confidence in
us to understand what they needed. I've seen a lot of folks not have that
opportunity, and want to build ivory tower software without ever talking to a
user. It also makes the job much more rewarding.

Anyway, those are just a couple of ideas. YMMV. Best of luck--though, if
you're asking questions like this, I'm sure you'll be just fine.

~~~
mhotchen
"Another thing my mentor did was took me with him to meetings where we
reviewed the code. Getting to know your users and understand who you're doing
this for is incredibly important. So many organizations try to abstract them
away. It was something that put a face to the end user, and gave the user
confidence in us to understand what they needed. I've seen a lot of folks not
have that opportunity, and want to build ivory tower software without ever
talking to a user. It also makes the job much more rewarding."

A great thing I forgot about; when I got my first job I was dying to meet
clients and learn how to start a project, rather than just being told "this is
what you're doing". I'll definitely bring him in on (relevant) meetings and
let him have his say.

------
icefox
Understanding that there is a large amount of knowledge out there that you
don't know and to always take the time to learn.

One simple example I was told to do early on was when I pulled up the man page
to a command rather than just reading the one section I wanted take the time
to skim the entire thing. Slowly but surely you become more familiar with the
capabilities and features that are out there so you don't re-invent the wheel
or take six hours doing something that could have been a few unix commands
piped together.

~~~
mhotchen
This is probably as relevant to me now as it is to the new guy. I have a habit
of not taking the time to fully learn my tools; I'll try to make sure I don't
pass that habit on!

------
glimcat
I know we often look down on the mushy stuff in engineering - but most of all,
be kind. It's surprisingly easy to crush people without meaning to,
particularly when they look up to you.

~~~
mhotchen
My current manager (who I greatly respect) is awesome at handling this; when I
fuck up, he'll come over smiling, and tell me a tale of how he did something
similar (only worse) whilst helping me fix the situation. The tale could be a
lie for all I know, but it always instantly puts me at ease.

------
pizza
If he's smart and a quick learner, make sure he's always got something to do.
No faster way to kill productivity than to get bored.

~~~
caw
For some people, a slight amount of boredom or free time will sometimes lead
to new ideas that previously weren't thought of. There's a lot of problems
that can be solved with the thinking "It would be really cool if..."

This of course depends on how internally motivated the person is. There are
some people that always need to have a task.

