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

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

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.