Ask HN: First coding apprentice. Any advice for me (and him)?
6 comments
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!
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!
"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.
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.
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.
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.
"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.
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.
[deleted]
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.
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.
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!
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.
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.
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.
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.
This of course depends on how internally motivated the person is. There are some people that always need to have a task.
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.
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.
I personally wish I was given the following in my very early career:
* Encouragement of my progress; I nearly gave up early on because I thought I was really shit at programming
* Conversely, frankness in my weaknesses, and specifically being told how to improve, not just told I'm doing something wrong
* How to spot a resource I can trust (online resources that don't give outdated practices, books that don't leave gaping security issues)
* 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)
Here are some questions that will hopefully give you some ideas:
* What advice do you wish you were given when first learning to program?
* What advice do you wish you were given when you got your first job as a developer?
* What advice do you wish you were given when you got your first full-time job?
* Is there anything your first mentor(s) did that you wish they didn't?
* Is there anything your first mentor(s) did that helped you a lot?
* Have you tested any techniques with very green programmers that worked to help them learn much better (eg. pair programming)?