Lessons Learned – Stage 3

The goal of the Nebraska Dev Lab Pipeline Program is to take individuals with no software development experience and train them to be effective and productive software developers. This program will improve those individuals’ lives while also positively impacting the tech industry in Nebraska by adding more developers to a market that desperately needs them.

The Pipeline Program is comprised of four stages. The first stage focuses on teaching the fundamentals of writing code. The second stage focuses on how to structure code and processes to build real systems. The third stage is a capstone project where participants put the first two stages into practice by working with professionals from Don’t Panic Labs on an application for a local nonprofit. The fourth stage is an apprenticeship at the participants’ respective sponsor organizations, working on a development team alongside their mentors.

Our third stage involved the cohort working on a mobile application for the Nebraska Suicide Prevention Coalition. Software Engineer Jeff Kodad served as the cohort’s development lead and was a regular presence along the way.

What Worked Well

The third stage required us to think critically about keeping the cohort engaged while avoiding any frustrations that may arise as everyone was working remotely due to the pandemic. Here are a few aspects that we believe went well during this stage.
 

Office Hours

We knew it was vital that the cohort have quick and consistent access to development professionals. That is why we instituted “office hours” each morning and afternoon. This provided 2 ½ hours per day when participants could ask questions via video meetings. Having established times each day also minimized interruptions as Jeff still had to keep on top of his project responsibilities for Don’t Panic Labs.
 

Tools for Success

We had two primary tools to make sure the participants were set on a path toward success. The first was a set of test acceptance criteria that must be met before each activity could be considered complete. The second was participant-created white papers.

At Don’t Panic Labs, our team creates white papers as an exercise to facilitate the critical thought needed before any coding begins. For the cohort, white papers were used to ensure the participants understood their assigned activities and help them critically think through how they would approach their upcoming work. These papers included:

  • Their overall thought process regarding implementation
  • Documentation of any risks or assumptions they are making
  • Identification of tasks needed to develop their activity

Once drafted, the white papers were reviewed with Jeff before any work began.
 

Already-Established Infrastructure

Having the development infrastructure already in place helped the cohort get started with their work very quickly. We did this at the outset to ensure the project would be built as intended from day one. But as time went on, Jeff put more responsibility on the participants to create necessary parts of the infrastructure. While we could have provided more (specifically around having all the data contracts already written), we count this bit of up-front planning as a success.
 

Demonstrating Completed Work

We found that having participants demo their completed work for the Nebraska Suicide Prevention Coalition was extremely valuable. They got the opportunity to interact with project stakeholders, which created a sense of accountability in terms of meeting deadlines and product quality. 

Reconsiderations for Future Cohorts

As we reflect on the third stage, there are a few aspects where we see room for improvement.
 

White Paper Consistency

While the creation of white papers started strong, we became a bit lax in requiring them as the third stage progressed. Participants would benefit more from requiring white papers throughout the entire stage.
 

Better Awareness of Cohort Inexperience

We don’t think it can be overstated that this cohort’s ability to pick up and retain new concepts was fantastic. However, this may have lulled us into forgetting that they were still very young developers who lacked the experience to “look around the edges” and make sure their work was well-architected and functional.
 

Rethink Pair Programming

Participants worked in pairs for a short time before they began working on their own. It seemed like the participants were eager to get experience by doing the work on their own, which led to their decisions to split up. 

We are rethinking this and may not take a pair programming route in the future.
 

Choosing Future Projects

A mobile application may not have been the best project for such inexperienced developers. Mobile development comes with a large amount of complexity that can be overwhelming. We may look at web application projects for future cohorts.

What Surprised Us

As with the first two stages, we were amazed by this cohort’s ability to pick up new concepts. We assumed that participants would demonstrate about half the velocity of an experienced developer. However, this cohort was completing activities faster than we had planned, especially when they were comfortable with the domain and tech stacks being utilized. 

Now Seeking Sponsor Organizations for 2021 Cohort


Nebraska Dev Lab is now accepting applications from sponsor organizations for our next cohort.

Organizations interested in sponsoring participants should email devlab@dontpaniclabs.com to learn more about this opportunity.

More information can be found at dontpaniclabs.com/devlab.