Back To School

Late last year, the NYC Tech Talent Pipeline put out a call to IT professionals in the New York City area to sign up for the Tech-in-Residence Corps. This initiative is part of a larger effort, CUNY 2X TECH, aimed at getting more City University of New York students to graduate with a tech-related degree and start a career in technology. In order to dramatically grow the number of students who go on to start a career in tech, CUNY needs more instructors and a curriculum which meets the needs of today's technology companies. Tech-in-Residence Corps attempts to address this need by getting practitioners into the classroom to share their experience with students who will soon be graduating with a CS degree. As a CUNY graduate, Brooklyn College class of 2001, and a technology professional in NYC, I felt the need to join the Corps and help CUNY 2X TECH achieve its lofty goal. Now that my first semester is behind me, I'd like to reflect on my experience with the goal of encouraging more tech professionals to join this effort.

Picking A Subject

Photo by Eli Francis on Unsplash

When I was an undergraduate student, my expectation was that the instructor teaching the class was a professor, that is someone with a Ph.D. in the field and an experience in education. I don't have a Ph.D. in any field (for now), and I've never taught.  I'm much more comfortable sitting in a lecture hall than standing at the lectern. My first challenge was to select a subject that I felt qualified to talk about and one that would be useful and interesting to undergraduate upper-class computer science students.  Professionally, I've been developing software since 2001 and during that time I've worked in different industries creating a wide range of software products. I'm constantly learning how others develop software from colleagues and researchers. Looking back on my experience as an undergraduate and my early career, I spent a significant amount of time learning how people create software in the real world and I now think it is something that students need to learn during their undergraduate studies.  I felt confident that I would be able to turn my experience and knowledge into an interesting course on software engineering practices and processes. Additionally, I've given technical presentations on software engineering practices at LinkedIn. As it turned out, Professor Akira Kawaguchi, the Department Chair at CCNY one of the five schools participating in the first Tech-in-Residence Corps program, was looking for someone to teach a course on software engineering. Professor Kawaguchi and I met at an interview event hosted by the Tech Talent Pipeline and CUNY which connected the industry professionals with CUNY CS department leadership.  Everyone at the event got an opportunity to connect with representatives from different schools and talk about their expertise and the subjects they would be interested in teaching. There was a call for professionals who would be able to teach Web and Mobile development, Data Science and Analytics, AI and Machine Learning, and Software Engineering. After several conversations and submitting an initial proposal for a course, I was offered an opportunity to teach a Topics in Software Engineering course at CCNY.

Creating A Course

Photo by delfi de la Rua on Unsplash

Software Engineering is a very broad topic.  I needed to narrow down what I would be able to cover during thirteen two and a half hour lectures in the Spring 2018 semester.  I also needed to create a syllabus that would describe what the students taking the class would learn as a result. Having never written a syllabus, I was thrilled to participate in a training session hosted and facilitated by Susan Imberman, Director of CUNY Advanced Initiative for Technology Education.  Professor Imberman explained the importance of understanding the students' needs and keeping that in mind when designing the course and the syllabus.  I learned about the importance of a clear and fair grading policy as well as picking a textbook for the course that won't break the bank for the students.  Professor Imberman pointed out a few guiding principles. One was that my value-added is my experience working in the industry as a professional and the other was that I must keep the content interesting and engaging for the duration of the entire semester.  During this session, I also learned about the Backward Design method for curriculum design.  By the end of the course, I wanted the students to be able to develop software as a team following an iterative and incremental approach as well as understand how to deploy and operate that software in production.  In other words, everything they need to know to succeed in the industry. The best way to learn how to work as a team is to actually work on a team project. This project could also represent acceptable evidence that the students are picking up the skills and the knowledge they need.  The topics that I selected for the course were: Agile Software Development, Teamwork, Planning and Estimating, Tracking Progress, Testing and Software Quality, Source Code Management and Peer Code Review, Architecture and Design, Continuous Delivery and Deployment, Monitoring and Observing production systems, Handling production issues, and integrating User Experience into the development process.  I chose "Agile Software Engineering" by Orit Hazzan and Yael Dubinsky as the textbook for its evidence based approach on the topic and its affordable price.  Finally, I created a grading policy that made the team project the key part of the course since it accounted for sixty percent of the grade.  I also wanted to give the students an opportunity to explore a subject they are interested in deeply by doing a research paper that accounted for twenty percent of the grade.  To encourage students to attend class and engage with the material, class engagement accounted for the final twenty percent of the grade.

Showing Up To Class

Photo by Nathan Dumlao on Unsplash

With my final syllabus reviewed and ready, registration was open for the Topics in Software Engineer CSC 59399.  I had no idea what to expect. How many students would register? How would I make it to class on time? What would I actually do for two and a half hours?  Fifteen students have registered for the course that was scheduled for Wednesday evenings at The City College campus, about thirty minutes away from my office.  I couldn't imagine standing in front of the classroom and lecturing the entire time. With the help of Professor Abbe Mowshowitz, my mentor at CCNY, I came up with a classroom approach which was sensible.  Each class would start with a forty-five to sixty minute lecture on a topic of software engineering.  Next, the class would engage in a team activity such as brainstorming project ideas, iteration planning, or a release retrospective.  The session would finish with a student presentation either on a topic they have researched or a demo of the teams' work. The material for lectures was comprised of the content from the text book, current academic research, and my experience working at LinkedIn.  Before every lecture, I would spend time reviewing materials and creating presentation slides. I would review the slides on the train ride to school and make corrections along the way. Each lecture was like a conference talk and had a similar format to this conference talk from earlier this year: Scaling Collective Code Ownership and Code Reviews.  The first few sessions focused on helping the students get to know each other, coming up with potential team projects, and forming teams.  These activities also helped me learn about the students and start to introduce teamwork into the classroom. One such activity was a pitch session where students got an opportunity to present their project idea while the rest of the class listened and asked clarifying questions.  Then the whole class used Dot-Voting to select two projects to work on for the rest of the semester. The result: EZParkn, an application to help CCNY students find a parking spot near campus, and American Political Database, a tool to help voters learn about the public officials who represent them.  At the next session, the students self-selected into project teams based on their interest using activities described in "Creating Great Teams" by Sandy Mamoli and David Mole. I could not sleep the night before the first lecture, and the second.  It was around the fifth or sixth class that I started to feel confident about this whole thing. The feeling of being comfortable didn't last very long.  Next, I needed to start giving feedback to the students and I needed to grade their work.

Giving Feedback

Photo by sydney Rae on Unsplash

The Tech-in-Residence Corps members were strongly advised to share the grading policy with students and to make sure that students clearly understand the evaluation process.  On the first day of class, I went over the syllabus and the grading policy with the students. I answered clarifying questions and handed out printed copies. Now it was time to implement the policy.  I wanted to make this process similar to what I've experienced in the industry. Every two weeks the teams would put together a presentation outlining the work they planned to do, how much of the work has been done, and demo their progress on the team project.  I asked clarifying questions to help understand the process and made suggestion about the changes the teams needed to make. I then facilitated a retrospective session to help the teams come up with actions they can take to improve the software development process they were using.  A few sessions after the mid-term break, I provided a preliminary evaluation for everyone in the class. The feedback was based on the work the students have done on the team project, their participation in classroom activities and their research paper as well as presentation. The project teams hosted their projects in GitHub, and I was able to see how the team members were sharing the software development work and how they were making progress.  When providing feedback, I considered the individual contributions by reading their pull requests. From the pull request, I was able to gauge the relative complexity and quality of the contribution. I also reviewed pull requests to understand how the team was working together, who was providing feedback, and how conflicts were being resolved. For each student, I would capture and analyze all the individual work, what they did well, and what were the areas for improvement.  I also included actions the students can take to make improvements. My initial feedback included a preliminary grade as a range where the lower bound of the range was what the student could expect if they didn't address the feedback and the upper bound was what they could expect if they addressed all the feedback. The session after I sent out the preliminary feedback, we discussed the format and how to address the feedback in the classroom and several students also followed up via email with questions they didn't feel comfortable asking in front of the whole class.  The students had one more product iteration and an additional product release to address the preliminary feedback. The students had up until the last day the grades were due to address the feedback. After the last day of class, I reviewed the contributions the students had made since they received the preliminary feedback and wrote up individual final feedback based on how they improved. This feedback included a final grade which was the combination of the grade the students received for the team project, the research paper and presentation and participation in classroom activities.  I sent this feedback about a week before the final grades were due, this gave the students one more opportunity to respond to the feedback, in case there was something that I missed in my evaluation.

Learning Lessons

Teaching an undergraduate level college course is a significant time and effort commitment. The classroom and commute time accounted for about four hours each Wednesday.  At the start of the semester, preparing the material for a lecture took nearly twice that long, around eight hours. Toward the end of the semester, I was able to get the lecture materials together in about four hours.  It's great to have the support and encouragement of your colleagues and organization. My coworkers heard that I was teaching and offered their advice and support. After discussing the course with my manager at LinkedIn, I was able to allocate ten percent of my time to this project.  After all, connecting talent with opportunity at massive scale is our mission at LinkedIn, and the Tech-in-Residence Corps is helping do just that for CUNY students. If you want to join the Corps, plan to spend about 8-12 hours a week on your commitments to the program.

Systematic Literature Review research papers are a great resource for getting an overview of a particular research area as well as for learning which researchers and institutions are active in a particular field of research.  Some of the topics I wanted to cover in the class were new to me or had evolved significantly since the last time I was actively following the process or practice. I used SLRs to get up to speed on the latest research and the current state of the art in software engineering practice complimenting the research findings with my experience at LinkedIn and current professional literature.  I also learned quite a bit about the practices of software development as a result. I think it is an effective way for expanding my knowledge base. If you are planning to teach a course, try to pick a few subjects that are outside of your current comfort zone and read academic papers to help fill the knowledge gap. It will help you stay interested in the material you are teaching and grow professionally.  

In industry practice, you seldom get assignments that are clear and concise with an easy way to measure progress and success.  This stands in stark contrast to undergraduate course work where the assignments tend to be prescriptive and evaluation criteria simple.  I attempted to bridge this gap by providing iterative feedback on the work that was submitted while letting the students find their path through the team project and individual research assignments.  I received a clear signal from the class that more structure would have been useful during the semester and I plan to make adjustments to the team project directions that will remove some of the ambiguity, for example how to self-report progress, while letting the students make decisions about work assignments and collaboration tools.  I expect that I will need to make this type of adjustment a few times before I find the right balance between providing enough structure to meet the student’s needs and getting out of the mode of working to meet the precise requirements of the coursework. During one of the training workshops I attended, an experienced professor noted that a course needs to be taught at least three times before you really get the hang of it.

Next Steps

If you made it this far into this post, I suspect that you might be interested in joining the Tech-in-Residence Corps.  If that’s the case, I would suggest that you take the following steps. Talk with the engineering leadership in your organization and get support to allocate at least ten percent of your work week to teaching activities.  Select a subject area you are passionate about and start putting together a syllabus. You can submit your application here.  Good Luck, and if you have any questions reach out to me on LinkedIn or ask your question in the comments section below.