Ask HN: Do coding coaches exist?
When I used to play online poker, I had weekly coaching sessions over Skype with a pro who reviewed my play, or talked me through particularly difficult hands, and gave me things to work on. It was incredibly helpful.
I am wondering if any similar thing exists for programmers. I would love to have guidance to improve my programming by someone that is better at it than I am, and be able to get opinions and guidance on my thinking and decisions about particularly complex problems.
I do read a lot, and I have discussions with other programmers, but what I am looking for is something more in depth. I would like a situation where I can get regular, specific feedback.
I haven't heard of such a thing before, and would love to know if there are people out there doing this, or that would be interested in doing this.
68 comments
[ 3.6 ms ] story [ 144 ms ] threadI'm not sure if others work the same way, but I know my coding-brain is much more receptive to learning and improvement when the feedback is on code that I've already (tried to have) thought through.
I could read 100 books on Advanced Ruby Theories and "learn" a lot, but take a block of code I've already written and tell me how I could make it better and my synapses will go wild :)
That said, if your team does peer code reviews, you get a lot of that coaching that you ask for, directly from your team members.
In fact, if your workplace doesn't have any way by which you can regularly collect feedback on your work, I'd be very worried. If nobody cares about the quality you produce, chances are small they care much about what you do at all. In any sufficiently important team, code reviews are a must in order to guarantee a sufficient level of quality.
That said, feel free to reach out to me if you'd like to discuss it, and perhaps we might be a fit (or I might know someone who is for your needs).
http://phpmentoring.org/ is a site set up to help people match up with each other, but I've no idea what sort of success any of them have had.
If anyone is interested, I have a more detailed roadmap for this idea, a couple of domain names that would work as well as technical and financial resources at my disposal. One of the domain names is ExpertHour.com, which I think is decent enough. I don't necessarily want to co-found this with you, but I might want to commission it or invest what I have for a very small return. Email me if you want to know more.
If you'd like early access email me at will@liveninja.com
Thanks!
Google Answers was awesome: http://en.wikipedia.org/wiki/Google_Answers
Tutors w/o industry experience are useless. And virtually no one with the experience will do the tutoring outside the work.
I only do that on a lightweight volume (and I am paid for that since this year).
I believe Avdi Grimm does something similar too.
This is something I really enjoy doing, and I'm surprised that it's not more widespread.
Getting the incentives right is tricky. Money is often not going to be the right incentive here.
I don't think its true that they can necessarily make more programming themselves than I can afford to pay them either. Remember, I am not wanting to hire someone full time, but for only a few hours a week. If I have to pay multiple hours of wages for an hour of high quality coaching, that is perfectly fine with me.
Please also email me if you'd like to be featured on the site as a Ninja/Expert for our launch.
Thanks!
https://github.com/rails-oceania/roro/wiki/Available-mentors
One of the things I've realized is that I love to teach this stuff. I'm not talking about syntax and "what is an object" and all that stuff; I'm talking about stuff like:
- Programming is simultaneously much easier and much harder than you imagine. The trick is to determine what your mind and society just convinces you is hard (before the fact) versus what ACTUALLY separates average or beginner coders from the masters.
- In anything but the smallest script or test application, architecture is EVERYTHING. But architecture is more of an art than a science. It takes more skill than most imagine to figure out what to name things, how few or how many "buckets" to construct such that current and future functionality fits in the right bucket, how to recognize when your current architecture needs to be amended or replaced, yet how to restrain yourself from designing a cathedral when all you need is a two bedroom apartment, and how to develop the discipline and leadership to keep other programmers (and yourself) within the architecture that you've laid out.
- Along the same lines, how much easier it is to code something when you have thought through the overall concepts in your head, not in the world of your favorite programming language.
- The skills you need to learn new programming languages in minutes or hours rather than days or weeks.
- It is fun and enlightening to understand what's happening at the bits, bytes, and machine code level at the same time you understand what's happening behind the layers of abstraction that your programming environment provides. By connecting concepts "all the way down", I've seen many wonderful "a-ha!" moments.
- The notion of "audience". Just as you must design your top level interface to the audience of your end-user, so must you design the layers of your code to the audience of the programmer-user who will use that layer to implement higher layers. Truly understanding that programming at each layer is about designing the best, most usable interface you can for the layer above you is, I've found, one of the quickest routes to respecting and appreciating architecture.
- The true barriers to becoming a great programmer are not often the technical ones. Things like algorithms, idiomatic coding in a certain language, database design, performance analysis, and design patterns are challenging and are worthy to learn, but they are almost unlearnable in a vacuum. When you're just getting started, the same can be said for just learning how to program at all. In my experience, you MUST have a project in mind. You can read all the "21 days" books you can find, but in the end if you don't have an idea that you just can't wait to implement, you'll be sitting there with a blinking cursor and nothing to type but the examples in your books and tutorials. I don't care if it's Space Invaders, you have to have SOMETHING in mind.
- Debugging is often a more important skill than coding. You must be able to shake all superstitions and approach problems from a rational basis. Just like an experimental physicist, you have to learn how to form reasonable hypothesis, understand what would falsify them, and then go about doing so in a methodical fashion (in a process that often looks a lot like binary search). I still occasionally make use of fancy graphical debuggers like those in Xcode and Visual Studio, but the more I studied and mastered the art and science of the debugging process, the less I relied on those things. Nowadays, it is often faster for me to debug a problem with nothing but print statements. I also find debugging to...
Apart from the areas in which I know I'm deficient, I also want to uncover the unknown unknowns in my coding, since I am self taught and have doubtless developed poor habits along the way without even realising it.
I think it's wise to study the great open source projects of the world and, if possible, to contribute to them. It is also wise to continually take on projects and challenges just outside your current skills and comfort levels. Who says you can't write a database? A compiler? A video game? Your first attempts may not be professional quality or even usable outside your own little world, but they will help you grow.
A programmer wakes up in the middle of the night and asks "gee, I wonder if I could boot Linux inside a web browser on top of an emulator written in JavaScript?" An average programmer says "Ha! Maybe if I were a wizard." A master knows that anything but attempting it is an excuse in mediocrity. And then Fabrice Bellard shows us all what can be done when the shadow of "The Great Wizard" is cast aside and replaced with the pain and slow but inevitable rewards of real work and productive failure.
> I would really like to read your opinion on what exactly the skills are to "learn new programming languages in minutes or hours rather than days or weeks.
In this there is no substitute for practice and a little drudgery. It is a lot like sight reading sheet music. At first each new piece is a struggle (more so if you are learning the instrument at the same time). But over time, you naturally develop a set of "meta skills" that make you much better at sight reading. Many of these skills you are not even totally conscious of, but they do develop and before long you can play most new pieces just as you can immediately read most new books (though it still takes a deeper read to appreciate the nuance).
So, here's some advice for developing this skill:
- Learn a lot of programming language and, if possible, learn them simultaneously or in rapid series. You're not shooting for mastery of each, just understanding and casual proficiency.
- Again, having a really cool mini-project helps. If you're a math guy, Project Euler is a good way to start building your personal Rosetta Stone. If not, pick a game or some simple app. It needs to be something that fairly well exercises the 20% of each language that is used 80% of the time, but also has enough complexity to warrant playing with the remaining 80%.
- The "Rosetta Stone" example is, I think, apt. Your goal is not to build yourself a personal decoder ring such that you can just match up the equivalent symbols, but for something deeper. You're aiming for something that aligns the concepts in each language such that the superficially similar things are blindingly obvious, but the deeper differences still abstract out to a higher-level similarity that you can train your mind to see when new languages come along. For example, how are object-orientation and functional decomposition, though dramatically different in form and theory, both just translations of a single higher level concept or two? I can't tell you that, because I would be wrong or, at best, trivial. You have to discover those deep mappings yourself. Only then will they really speak to you.
- Syntax is just, like, the language designer's opinion, man. No, really. Stop caring about the syntax while you're learning. Just accept that you're painting with someone else's idea of a paintbrush and move on. As you get more advanced you'll come to have "aesthetic taste" in syntax and you'll know which languages look, to you, like beautiful paintings and which, to you, look like so much angry scratching. But when you're learning a new language (or 10), it's best to put your aesthetic judgements aside and just let it ride. Haskell is a good example of this. At first I absolutely HATED the kind of "sharp" syntax and bizarre ordering of things. The language felt "pointy and argumentative" in the area of my mind that has developed this weird "code sense synesthesia" that has developed over years of looking at so much different stuff. But I put that aside to really learn the language, and while it's still not my favorite language syntactically (that goes to Clojure or CoffeeScript), it became more beautiful and ordered in my mind and took on a kind of beauty that, like certain forms of architecture, is only visible once you understand a bit of the purpose. But in any event, really, ignore the syntax and just treat it as "the rules of the road" until you become more adept.
- Similarly, just because a language LOOKS difficult doesn't mean it is. Tell yourself that it's "just code" (I use this term a lot) and struggle through. Before long you'll invariably look up from your frustrations and say "oh. This isn't as hard as it looked." coughScalacough
- When learning about a language, read about the history of its development and guiding philosophy first. It helps to understand a language more when you know where the designer was coming from. You may not AGREE with the designer(s), but you'll appreciate that there's a reason behind the apparen...
* Learn Factor instead of Forth - it's similar, but modern :)
* Try logic and declarative paradigms (Prolog, Mozart...)
If you're looking for a real reboot, consider Hacker School (hackerschool.com) or App Academy.
Disclaimer: I'm one of the founders of App Academy. Read here (http://qr.ae/8QbUb) for how experienced devs thought that App Academy helped them level up.
When I did it for money, both clients were appreciative, but I think it went better with the one I'd previously written a lot of their backend code for, who were also well-heeled. This gave me specific knowledge and more time to give them.
(I could be available for some more of this after the Hacker School term is over, late December.)
I've been a mentor on there for ages and I've "mentored" several people - probably around 7 or 8. The reason I put quotation marks around "mentored" is because of all the people who have applied to be mentored with me, only one has actually applied themselves to the task at hand and consistently requested feedback and guidance.
As a result, that was really the only rewarding mentorship interaction I've had via that site, which is a bit disappointing. One of my colleagues signed up too, years ago when that site launched, and I think he's had better luck; he has a postcard on the wall near his desk from someone he successfully mentored in China.
The reason I bring this up is because I think anyone who wants to be mentored must realize that the relationship goes both ways: you want a good mentor, but your mentor in turn wants a good student - and anything less than that is disrespectful.
Since "coding" itself is a huge field, just be sure you pick a project that interests you and has a lot of scope instead of $random_famous_opensource_project.
Good Luck :)
We're still in alpha stage, but the idea is to solve challenges and get feedback and reviews from more experienced programmers.
I have to do just that to help the kids along, to learn, to fix small things and generally become more independent.
I love it.
We were talking and have come to the conclusion that this arrangement might be somewhat scalable for learning - an apprentice model for coding, that benefits 3rd parties. It certainly gets around some of the weird power dynamics of traditional apprenticeship/mentoring and paid tutoring. Further it is a good way to get some needed talent to good non-profits that may not be able to otherwise arrange such a thing.
Finally, and this is the kicker - it gives novices practice in real development, and it gives experienced people (who may be hiring) access to people to see how they are at problem solving in a real environment, rather than interview tests, potentially faked code samples, etc. (Not to mention, someone willing to go through the effort of something like this is probably already a great candidate on the strength of "wants to learn more and actually takes effort to do so", which I have found to be a strong indicator for a good employee).
I don't know where you are located, but if you want to get into some more discussions about setting up something like I described above, feel free to email me:
I don't think that there is really any weird power dynamics in this kind of coaching, at least not in my experience. On one hand we are dealing with a domain in which reason is the ultimate method of arbitration, and a good coach would not be presenting me with opinions or ideas that I could simply disagree with due to some difference in personal belief. Instead, they would be challenging me with different ways to think or different ways to approach a problem, and be able to explain its benefits if they weren't obvious to me.
On the other hand, the trust that can be built in this type of relationship can be quite useful for the learning process. Having someone that I respect as a programmer as well as a coach allows me the comfort to know that I could come to them with either a specific problem of general deficiency and get the kind of response that will give me the most enlightenment in the long term, which is often different to what you'd get when asking a question online.
First the idea of paid, but not directed tutoring is a bit weird. When a person is paying they exert an influence over the person they are paying. So in a tutoring situation, the student can say "no I don't want to focus on that fundamental thing because I don't see it as important and you have to do what I say". This can turn off a lot of tutors, because they honestly know that understanding that bit really helps (e.g. knowing about how HTTP works, even if you are just writing DJango apps and never deal with anything other than an abstracted object representing the request). The goal of a lot of tutors is to help people learn, and not just make money. Further it is a bit sticky, because if the student decides not to learn stuff, and can't get a job or doesn't really gain skills, it reflects poorly on the tutor - a bit of a problem if that is your business.
The reverse situation exists in programs like internships or company-internal mentorship programs. The mentor/boss always holds a trump card of "because I am higher in the hierarchy and say so" which can influence the student/learner to not want to rock the boat or express disagreement or initiative. This sort of thing really has the same fundamental "I need to work and keep working to afford life" pressure on it.
The traditional solution to this is a mentorship program (basically what you've been describing). This is generally a safe place to be able to express opinions and disagree, and I completely am on board with your entire post in this sense. One of the problems with mentorship generally is that it can be hard to really get deep tho. Conditions like NDAs on work can really limit shared context - problems are kept in the abstract and specific code review/pointers can be lost. This makes the problem hard. Further, finding mentors can be hard, because from the mentor side doing that task falls into the volunteer/contribute to fun oss projects/hobby category, and therefore the task is in competition with other worthy tasks.
So this is why we were talking about the structure I described. It provides a mentorship opportunity with all the benefits you stated, with the added benefit of easily allowing shared context for the mentor and learner, and reducing the opposition of "competing choices". Essentially it is a way to foster mentorship in a way that everyone wins, with the benefits for all parties being a bit more clearly defined and in focus.
A final note about the software field:
At the end of the day - there are lots of equally good technologies, and people, even the best, will have preferences and beliefs on what is a better solution. Things like architectural style (e.g. event driven or threading?), language (python, ruby, clojure?), and on and on don't actually have a "right and well reasoned" answer. It is hugely style/belief/experience driven. Even at the code level this is true - is a facade or strategy better here is regularly unclear. Is a decorator or descriptor the better way to do this thing in python? How should I break up my classes is a huge source of disagreement even amongst people subscribing to seemingly the same philosophical set (e.g. srp, dry, yagni).
Sometimes the decisions made are based on subtle factors that are impossible to easily clearly explain, and it sounds like hand-waving: "down the line it will be easier to refactor for what we actually need rather than figuring out perfect right now" is a statement of belief and experience, not of reason and fact. Particularly when the same person will say "lets do it right - we won't want to change this later" on a seemingly similar problem. I do that. I try to explain why to my team. It really comes down to "because it just is in my experience - the problems are not similar on a human/project level,...
Coaches for online poker had that convenient that you could get a coach whose prices would always been within your reach: if you were a regular winner (or break even) at, say, $25NL then you probably had a few $25 buy-ins you could use to pay a coach begin a regular winner at, say, $50 NL or $100 NL and both of you could find value in doing that.
Then there was also this idea that you could learn from someone only a bit better than you: someone who was beating one or two levels above yours had already stuff to teach you and would be unlikely to give you bad habits.
But for programming I'm not too sure: it's not really a good idea to learn from someone who's just "a bit better" than you. And if you want to learn from someone who can do $100/hour consulting then it may cost you an arm and a leg to learn anything from him.
I don't mind paying for quality coaching at all. I see it as a worthwhile investment in terms of both productivity and happiness (I love learning!).
On the whole, I think high level education is very undervalued. When you think about it, how long is the payback on a $100 coaching session if you get just one really good insight that improves either the efficiency or quality of your code?
Benjamin Franklin quotes (American Statesman, Scientist, Philosopher, Printer, Writer and Inventor. 1706-1790)