We worked on the problem for 2 hours and we didn't fix the problem

I have been coaching at codebar for 5 years, and despite the comfort this familiarity brings, it doesn't shield me from the disappointment of a workshop where myself and the student have made no notable progress in the codebase. This has happened to me multiple times, I will find my self disappointed at the end of a workshop because a student has come with a problem, and hasn't managed to solve it. I need to remind myself not all coding problems can be solved in two hours.

Given the nature of codebar, the pairing system is prone to not be perfect, given I am an organiser of codebar Berlin, and often responsible for each pairing I will have a unique vantage point. Workshops start at 6:30 pm, but pairing/coding doesn't start till 7 pm. The first 30mins I talk to all students beforehand to get an idea of what they would like to do, not just the programming language, but what they would like to achieve, to make for a better match. Given the time constraints, and the ability to express a problem a student has it might transpire that a pairing is a bad fit. I will generally encourage people to contact me if there is a problem, and I am not averse to swapping pairings halfway through a session. The longer I know a student and a coach, the easier it becomes to pair, and over time I encourage students to express preferences of coaches they have worked with previously.

An important consideration is that coaches are not gurus. A Guru comes down from a mountain top says "Look at me I'm an expert I have all the answers" and will tell you how to live your life, a guide/coach is someone who has simply been there before. Guru's come from out of town, arrives and enthuses an audience but often can leaves people overwhelmed, I see this in the form of tech talks at big conferences or even small tech meetups. An individual will evangelise a new paradigm, technology or tool. But fail to connect with a large swathe of the audience, only because the audience is at different levels. I love such events and think they are invaluable for creating community and knowledge sharing but I just wish as an industry more of us compassionately shared our knowledge.

I see guiding and coaching others as more compassionate, a guide will meet a person occasionally, check in with them, listen, and nudge them along in the right direction from where they currently are. Speaking at conferences is often a measurable goal in performance reviews, and so it should be. As an industry, I wish we spoke more about coaching and mentoring others as a measurable goal.

Often a student will present a problem in a framework I have never seen before, in some cases a language I have never seen before. Last codebar session I had a student who was trying to solve a coding challenge in Java, we had no available Java coaches, I have minimal exposure to Java but worked with this student regardless. This does not mean I was not scared the problem might be too hard for me to help. There was a mathematical problem to solve, and a few test cases. What I tried to do was untangle the problem, wrote pseudo-code and broke the problem into smaller parts. The student wanted to solve it all with one loop, my approach was to pick one test case, and let's get that working if we see an opportunity to refactor later we can do that. In the end, I demonstrated the logic in my preferred coding language javascript. I explained each step, each function, so much so the student was capable of making suggestions, and questioning my logic. This approach gave the student to confidence to try the solution in Java. I once heard "Java is to JavaScript as the car is to carpet", but in this case, the student was very thankful for the explanation.

This reminds me of the question, "What should a coach do?" We give coaches at codebar coaching guidelines to help them, one of my favourites is "Let students have a go at answering the questions first. Help with open and leading questions. Encourage a discussion."

Like I said not all coding problems can be solved in two hours, codebar is slower than programming in my professional setting, as you may need to explain concepts, explain paradigms, and look up documentation as a pair. If no progress is made, it's likely the student has taken away more than you realise. It's a valuable experience to demonstrate what they are trying to do is hard, when I struggle on a problem alone for 4 hours I can be left demoralised, if I show someone else and they also struggle, then it reassures me that what I wanted to do wasn't so easy, and I shouldn't be so hard on myself. Coaches will demonstrate how they would solve problems, techniques to solve problems and resources they use. Demonstrating how to debug code, identify problems and breaking down problems is worth much more to a student than a coach who knows the particular library. In conclusion coaches at codebar are not there to solve student's problems, they are there to guide, explain and point people in the direction of trusted sources of information, in doing so nudging them along.

My views are my own and don't represent the codebar organisation. If you are learning to code, and you a member of an under-represented group, I recommend you join a codebar workshop sometime. If you are already a developer and you would like to improve your ability to mentor and coach, I would also encourage you to come along, sign up at codebar.io.