I made a promise to my friend Chris Spintzyk that I would write an article detailing my philosophy of educating software developers at Nashville Software School.
This article, as the title suggests, focuses on the What and, tangentially, the Why. If you want to read about the How, you can take 10 minutes and read An Alternative for Teaching Software Development which details the methods, processes and topics that we use to teach.
Vocational software development schools are in their infancy. No one really knows exactly what works yet because there is no real data. Even Nashville Software School is only 4 years old, as of July 2016, and the curriculum has evolved many times over those years as we discover what leads to higher comprehension with the students.
In various articles that have been published in the past 4 years, a recurring opinion rears it ugly head.
"You can't teach people to be software developers in 6 months"
-- Uninformed Biased Human
Invariably, this opinion is from people who have neither taught a cohort of students, nor were students themselves. Therefore, very little weight can be given to their thoughts on the matter.
Having been the instructor now for 6 cohorts of students, I can tell you, unequivocally, that you can teach someone to be a software developer in 6 months. I know, I've seen us do it. Is everyone of the same caliber? Of course not. There's a bell curve just like in any random sampling of human beings.
My loosely held belief is that people who react negatively to coding schools are coming from a place of fear. Perhaps they are threatened because they may be truly thinking, "you can't teach someone to replace me in 6 months." That, of course, is true. We are producing junior developers who need further guidance, mentoring, and support.
But, you better watch out...
I Wish I Had NSS in 1996
If I had the opportunity, waaaaaaaaay back when, to spend six months with a senior web application developer, who had worked in a wide variety of industries, and built myriad products for them, I would be a better developer today. Unfortunately, back then, there were no senior developers for building web applications, because they didn't exist.
Again, up until 4 years ago everyone working in the industry was self-taught. That, unfortunately, causes the typical period of chaos, uncertainty and fear as a new generation of developers are being trained by highly skilled professionals, and come out of the gate with skills that immediately compete with self-taught developers who have years of experience.
I've worked on more teams that I could possibly count after 23 years of software development. I've been fortunate enough to lead a good number of them. Based on that hands-on experience, I can tell you that the students coming out of NSS do have the ability to immediately contribute as both developers, and problem solvers.
I make that distinction on purpose. I've worked many developers who were simply that... developers. Tell me what to code and I'll code it.
Problem solvers are a different breed.
They ask why. Then they ask for clarification. Then they help identify if it really is a problem that needs to be solved. If it is, they come up with options for how to solve it. They constantly help refine the problem and the solution to make sure that people benefit from the work.
Building Problem Solvers
So that's what I do now. I decided to take a break from building software so that I could make our tech community stronger by building problem solvers. I don't teach people how to code. I teach people how to solve problems with code.
You want to learn to be a coder? Go to an online resource. Watch some videos and write some code that solves very esoteric, discrete puzzles with no context to complex teams and systems.
What does that mean?
Can you teach that?
You sure can.
A typical week 2 in a coding bootcamp is learning how to use jQuery to make DOM querying and manipulation easier. Perhaps it's learning some cool CSS techniques to make your pages responsive.
Here's what students at NSS learn in week 2.
- How to ask questions of a product owner to get clarifications on requirements so it is understood what needs to be built.
- How to define core features of a product before a single line of code is written.
- How to build an effective Trello board so that tickets can be equitably worked on by every member of the team.
- How to use an online tool to create wireframes of an application to ensure that there is clarity on the elements and their interaction with each other.
- How to effectively use git and Github to work as a development team to build something together with minimal conflict.
I teach them the 70/30 rule. If you spend the required to time to design the solution and are crystal clear about what should be built, then 70% of the time ends up being design, and code that needs to be written is obvious.
Throughout the course, they refine these skills with guidance from the instruction team. They learn how to work in a diverse team with divergent skill levels. They learn how to compromise and find consensus when there are conflicting options.
Likewise, when they start the 2nd three months of the program, they learn how to design a database. They take on the task of thinking about the relationships between resources in an application and how to create the appropriate ERD, and subsequent tables & keys to make the application scalable.
They learn the value of testing and how it's a crucial part of the design process because it forces you to think about the code and the relationships before you start to write the implementation.
After they learn these - and many other - contexts and concepts, then they can start to find the correct syntax to solve the problem.
Real(ish) Experience
My absolute favorite part of the first three months is one of the group projects. When I first assign the task to the students, I make it clear that I am the Product Owner for the duration of the project. I provide a vague wireframe and some fairly vague requirements and tell them that they are not allowed to make any product-level decisions about the project without consulting me first.
Using the skills they have been developing, it is their job to talk with me to get clarifications and directions for how the product should behave and look. I force them to give me options when they tell me one of my ideas won't work.
Then, just when they think they are done, I call them back into the classroom and tell them that the core requirements for the product have changed because I've had more discussions with potential customers. The look on their faces is quite delicious.
But they need to know that it will happen when they are in the field. It's all part of being part of an agile development team. Respond to change. Respond to customer feedback.
I make them go back and change their entire codebase to reflect the new requirements. After some time doing that, I call them back to the classroom to do their presentations.
Except they aren't doing their presentations.
I change requirements on them again, and then tell them that they have to implement the changes on another team's code base. Guess what, guys? You'll rarely have the chance to build a greenfield project. The vast majority of your career will be working on inherited, legacy code.
Syntax as a Byproduct (SaaB)
Being a great software developer means you can solve problems with code, so being proficient at the actual skill of coding is critically important. However, as any senior developer will tell you, syntax is secondary to knowing what to code, and how you can use the tools at your disposal to solve a problem. Knowing the syntax is a Google search away.
I often tell students that if you go into an interview and the focus of the conversation is about syntax, you might start asking questions that raise the bar, and make sure that the team there cares about your skills to design a solution. It's a red flag.
Therefore, as the students are given exercises, quizzes, group projects, and challenges, they learn the core syntax that is needed to write the skeleton, the frame, of their solution. It's picked up organically more than taught to them in lecture. Retention and comprehension is much higher with that format.
Wrap Up
To bring it all together, there's three things that we teach at NSS.
- How to be effective problem solvers, with code as their main weapon.
- How to be a good teammate, with git, Trello, and effective communication styles as their main weapon.
- Learning how they learn best. Oddly, this is a skill that is not often learned in traditional education.
Knowing syntax for the language of choice for the cohort is one of many important by-products of their time in the program.