Also in Developer Stories

The modern veteran: A coding superhero

While we speak a lot about #LearningInPublic, we rarely talk about #TeachingInPublic. While difficult, it can be gratifying, as it gives education opportunities to those who might not have access to learning resources that live behind a paywall.

It also minimizes the point of entry to giving back to people, particularly those coming from community-taught backgrounds like myself, so you don't have to go back to school for the degree and teaching certificate. All this also helps you become a better programmer because it reinforces the things you think you know and makes you learn how to communicate them with people who are not coming from the same position you are in the journey of writing code. Finally, it's been a lot of fun to build and interact with people from all walks of life as we focus on becoming better software engineers.

It all begins with the repo

Much like open-source projects, the repo is the single source of truth when teaching. Files, resources, and tools should be linked or stored in it, as it's the base of operations for you and the learners. The README needs to be manicured, descriptive, and in-depth. The new dropdown component at each heading and link has been a joyous update and helps me create an efficient and easy-to-navigate curriculum. If you want to condense for clarity, you can add multiple READMEs. The important thing here is not to skimp.

Remove whatever barriers you can

Yes, developers need to learn to set up their own development environments. But it can be a distraction from more important concepts, one that can ultimately be a small but annoying barrier to learning. Although still in beta, I've enjoyed using GitHub CodeSpaces during the teaching process, and it's a definite game-changer. While storing the files in the repository helps learners tremendously, this feature turns your resources and code into an accessible programming environment within the browser that the learner can execute code indirectly. This feature is beneficial in ensuring that the education sticks and keeps tab switching and frustration down. All of this improves the experience so that newer developers can focus on learning the hard stuff.

Communicating requirements

At Vets-who-code, we teach Kanban and write user stories as a part of the learning process. This method helps us ensure clarity in the workload when we use project boards for assignments. People often ask: "Shouldn't every learner do every portion?" On their capstone, yes, they should implement everything they learn on their project. Still, Github's real power with learners teaches them how to work collaboratively as a team and communicate needs and blockers across the team to complete the assignment, which is how you work at a real job. So when I teach, every project is a group project. It helps me learn more about developers to see what they gravitate to and see who needs what type of support. I have the devs assign themselves a ticket. This creates a form of accountability to the team, which they bring with them into the workforce. I also enjoy the process of watching them escalate, pick a ticket, escalate it to an issue, make a branch for the issue, solve it and then merge it with a PR. Practicing this workflow makes it easier for students to tell employers how they work, making it easier to hire them because a methodology to the madness is one of the things hiring partners look for in new developers. 

Keeping the conversation open

We have a current cohort building a feature that we hope to go live on web app this year. While doing so, I also wanted to ensure that those not in the cohort could see what is going on without having to enter a messaging app channel, so we have been using GitHub Discussions to speak about the feature so that anyone in the VWC community can chime in. 

Keeping the communication open on this feature while also giving them freedom teaches them how to lead the creation of a product. Beyond the parameters placed regarding our stack, my goal is to be as hands-off as possible because I want to see what new ideas come out of their minds to make the web app better that I might have missed. Once you set a course of adhered to parameters, you learn a lot from newer developers when you listen, allow them to come up with new ideas, and experiment.

Focus on fun—especially after difficult segments

If Computer Science is the most dreaded part of VWC, I think the most enjoyable part is learning about workflows and automation in Github actions. Setting up the actions and creating workflows to automate from the chosen serverless tool is easy and powerful for two reasons: one, after working with Javascript for two months, YAML is like your favorite iced beverage, and two, the process of building a workflow to automate a deployment makes you feel closer to a real developer. A mixture of relief and empowerment is needed after a tough session like that, so it's good that there is something available to give them that feeling.

Use templates to guide feedback

One of the things we have to teach is giving and receiving feedback when learning how to code. I'm not going to go into details, but you can't give feedback the way some of my veterans are accustomed to getting feedback (every U.S. Marine reading this is currently chuckling right now). So we use a prepared template in Github Issues to guide how to communicate things to each other and the team in a technical, respectful, and constructive way.