The Craftsmanship Academy has become a "graduate opportunity" for Coding Boot Camp graduates. Boot Camp graduates (or those expecting to graduate before October 1, 2015) can apply.
I've previously written about why the Academy is different than a Coding Boot Camp.
I have wondered why any company would pay some of the salaries I was hearing about for Boot Camp graduates. Recently, I came across a great article Will a "Programming Boot Camp" Help Me Get a Coding Job? that has some very good reflection with respect to where the industry is with Boot Camps. (NOTE: I'd encourage anyone considering a Boot Camp to read this article) Although I expect that Boot Camps will continue to grow, there will be a growing understanding that Boot Camp graduates need significantly more training for all but the simplest programming jobs. I'd be interested in seeing a deeper study in the kind of jobs they are getting and how their college degrees and previous experience are playing into that. (NOTE: 75% of graduates are employed in a job requiring skills they learned at a bootcamp, and 71% of students have college degrees, and the average age of those students is 29).
It appears that Boot Camps as an alternative to college are only a small percentage of reality. Boot Camps evidently work well for those that feel that their college degree didn't lead them to a job they loved (or could pay the bills). I'm confident the vast majority of boot camp grads aren't building solid software assets. They MAY be on the periphery… doing some of the tedious and low-risk work on a team building solid software assets.
There is a huge gap between colleges teaching Computer Science (laying a foundation in theory without much practical training), and Boot Camps teaching coding (laying a foundation of knowledge without much depth in theory and real world projects).
The gap needs filling, and many Boot Camp grads are generally on their own as to how to fill the gap.
In 2011, we announced the Craftsmanship Academy as the first of its kind. At the time, there was only one "Coding Boot Camp" that I knew of: The Starter League (which was then called the "Code Academy"… not to be confused with Codecademy) I spoke to the founders, and they recognized that what they were doing was completely different than what we were doing. They were clearly taking someone from "clueless" to "beginner." We were clearly interested in taking "beginner" to "solid junior developer on their way to becoming a Software Craftsman."
My call on our industry was that other Software Craftsmen all over the country would open their own academies, each having their own emphasis based on the personality and focus of the Craftsman who led it. The goal was to have places that would intentionally produce Software Craftsmen versus people who merely had a degree in Computer Science or Computer Information Technology or even Software Engineering. We wanted more people who build software and build it well… the kind of people who created The Agile Manifesto.
Although I was an enthusiastic early signer of the manifesto, and would have been at the meeting that generated it if I weren't busy writing a book on applying the principles, I have grown to recognize that the most important part of The Agile Manifesto isn't the four assertions it makes. The most significant part was the preamble:
"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value…"
The authors of the Agile Manifesto were not just philosophers, they were accomplished Software Craftsmen. They learned what was important about software by doing it and helping others do it. And every single one of them had built multiple large systems and had been doing it reflectively for years. These are the people who embraced "best practices" and learned "best times to use best practices." And they continued to build software and help other people build it. They built software that was more than simple websites or what I call "marketing apps." They built software assets.
When I started taking on apprentices, I was looking for someone who had "learned to program" through intro courses and small projects, loved it and dreamed of becoming really good at it. I did that for many years in an informal way between 1998 and 2010 and saw incredible success. Apprentices at RoleModel grew to be some of the most sought after developers in the Triangle area. But it took years for them to get there. They were involved in multiple significant projects before they were Craftsmen.
When I formalized the process, it started with the "immersion phase" where I taught amateur programmers how to think about professional software development and applying each of the most important principles through cementing them in projects. We used a variety of different technologies so they could see how the principles applied in different contexts. They had mentors who were building advanced software focusing on the quality of their understanding and how it manifesteed itself in what they did.
The results have been great, but it doesn't scale well.
Coding Boot Camps scale well. According to The Course Report they've gone from non-existent in 2010, to a projected 16,000+ graduates (with an average tuition price of qualifying courses is $11,063, with an average program length of 10.8 weeks).
With so many graduates… they have produced the level of skills I've always looked for in an apprentice.
In the two (2) official "classes" we have conducted since 2012,
Of the five that made it to full-fledged positions at RoleModel, they all had done more programming before they came in than the ones that did it, and they scored well in my Interactive Programming Skills Assessment, where I look not only for clear programming skills, but also examine how they go about solving problems that they've never seen before.
Of the two who finished the immersion program but didn't make the progress we wanted to see at RoleModel, there is no question that they are better prepared than many for a career in Software.
So, we're just turning our Academy into a potential entry level into RoleModel Software and raising the bar on who we are taking in our next Academy. Boot Camp graduates are welcome (whether an in-house or self-paced). They should have enough programming experience to cross the first hurdle. My Interactive Programming Skills Assessment is the next hurdle.
We currently have two people signed up for our October 1 Academy who are currently going through coding boot camps.
Apply if you have graduated or are graduating from boot camp and want to fill in the gap.
Recently, I have met a few graduates of The Iron Yard Academy.
From what I can tell, they have done a decent job of introducing people to some modern tools of the trade. I suppose many other "Code Schools" or "Boot Camps" do the same.
I've not talked to the folks running Iron Yard enough to figure out what their "job placement" entails. One of my clients hired a graduate who seems to be a bright young guy, but he definitely has a lot of holes… some of which would have been filled by our different approach to immersion, others can only be filled in a different context. It is something that no "boot camp style code school" can do.
I have been one of the first to point out that becoming a software craftsman does not require a college education.
But, to do it well, one needs more than a bootcamp.
I've seen no better path than apprenticeship.
I have been pointed to The Apprentice Programmer post by several people over the last few years. Many boot camp's marketing might lead one to believe that they will turn you into a professional software developer in 12 weeks. If what they mean is that someone might hire you, they are correct. You might be hired. In my circumstantial sampling of 3 recent Iron Yard graduates, 1 had a job. I'm sure my sampling does not represent their placement rate, but it clearly is not 100%. All of the factors that feed into why some have jobs and some don't are far beyond what I want to tackle here.
The one hired by my client is in a pretty good environment to learn a lot… and they have brought me and my team in to help it be even better for inexperienced developers like him. But many are hired by naive employers who have no idea how to mentor these folks and it will be a lot of trial and error learning with very little guidance. Many seem to be hired by startups.
Startups are full of optimism. They have to be or they wouldn't ever get started considering the success rate of a startup is around 10%. (Google startup success rate for some interesting reading). In my experience, the ones who are so optimistic that they think they can build their product with cheap, inexperienced programmers have a much lower success rate. Most startups don't make it, and most solid, experienced developers won't take the jobs that are being offered to these boot camp graduates. (NOTE: Sometimes there is an excellent software craftsman at the startup who will do a good job mentoring the newbie… then the newbie has hit the jackpot whether or not the startup succeeds).
In my experience, those who have been apprenticed like Tobi Lutke (the author of the aforementioned blog post), or the folks who have come through RoleModel Software, achieve a depth that very few achieve who just enter the field and take whatever jobs they can get.
We only take a few into our Academy. If you don't get in, I'm sure that Iron Yard and others are a great place to learn some very useful things.
But seek apprenticeships, not just "fast tracks to a job". The difference to your career will be significant.
Walt was fascinated that Tom and others at Taylor have set up a Software Studio for their students.
This reminded me of this paper that Nathaniel Talbott (currently founder and CTO of Spreedly) & I wrote in 2000 that was submitted and published by the ACM as part of the OOPSLA 2000 Educator's Symposium. Nathaniel was RoleModel's first official apprentice, though Ken had learned a lot about apprenticeship through various means at his previous company and other venues in life. This paper was based on our reflections of our experiences at the time. Nathaniel & I also gave an "Invited Talk" at the Symposium and a few people were enamored with what we were saying and others said, "He's going to ruin that poor kid".
Well, in spite of what some of those educators' thought, I think Nathaniel has done pretty well in his career… and he still doesn't have a college degree. For those that decide to pursue a college degree, I hope that the type of environment that Taylor University has set up is the beginning of a trend. A recent study showed that roughly $59M will be spent in 2014 on "Developer Bootcamps".
Though it seems like learning about Software in a studio environment has gained some traction, unfortunately, many of these bootcamps and "higher institutions" are not "wisdom based." There is still so much to learn and wisdom to be gained in how to best impart wisdom. Very few have been at it as long as we have, and I think the wisdom we have learned over the years sets us apart from many of the rest, but no matter what our claims - or anyone else's claims - are, we must all be careful how we walk. There are still too many who ignore true wisdom which shouts in the streets.
Extreme Programming was introduced to the world in the late 90s as a way to embrace the change that is inherent in Software Development.
Though not a perfect approach to software development, it is a vast improvement over many of its successors.
RoleModel Software was one of the pioneers in the application of the principles of Extreme Programming (see Extreme Programming Applied), and we have continued to evolve the way we apply these principles and others every day.
The heart of Extreme Programming is to diligently apply, examine, and refine, best practices of software development. The heart of the Craftsmanship Academy is to train up craftsman who diligently apply, examine, and refine best practices of software development.
As one of his assignments during his Residency, Braxton Plaxco read Extreme Programming Explained. Below he has shared his insights into the application of the principles as he is learning to put the theories into practice.
Extreme programming (XP) is best described by Kent Beck when he says, “When I first articulated XP, I had the mental image of knobs on a control board. Each knob was a practice that from experience I knew worked well. I would turn all the knobs up to 10 and see what happened. I was a little surprised to find that the whole package of practices was stable, predictable, and flexible.” A few of the practices he described are: The Planning Game, Short Releases, Metaphor, Simple Design, Testing, Refactoring, Collective Ownership, Continuous Integration, 40-Hour Week, On-Site Customer, and Coding Standards. Working in a studio that strives to implement the principles behind these XP practices in their daily operations has given me the opportunity to experience and grow from each of these in one form or another.
The Planning Game consists of defining a scope for the project in light of business priorities resulting in estimates for each task. While working at RoleModel I have had the opportunity to work directly with customers in determining which new features should be implemented in the next release. I've had to learn how to give estimates for a variety of tasks, while also assessing the value that certain features will add to the project. Often a feature is started with general concept in mind. Refinement of the feature takes place as it is being developed. Refinement comes in the form of questions and input from the client. The project continuously evolves as direction is defined to meet the needs of the clients.
The concept of Short Releases is to put as simple of a system into production as possible and to release new versions on a short cycle. Short releases help to continually add value to the project as well reduce code conflicts. In most of the projects I have worked on with RoleModel as soon as I am finished with a task, the tests are run, the code is reviewed, and then the feature is deployed for customer review on a staging server. Once the customer is content with the feature and all of the final tweaks have been made, it is deployed to production.
The Metaphor for the project is a narrative explaining what the system does. The metaphor guides the development process and helps the developers to keep the project's overall goal in mind. I've worked on projects that have had a strong, clear metaphor. I have also worked on projects where the metaphor was not clearly defined. Projects with strong metaphors were fun and enjoyable to work on. I knew the direction of the project, and this increased my motivation for completing tasks. It helped me to take ownership of the project and to want to do everything in my power to see it succeed. On the other hand it has not been as enjoyable to work on projects with out a clear metaphor. In those projects I often find myself wondering what the purpose is of the feature I'm working on. This usually leads to frustration. It is hard to take ownership of a project when you don't know exactly what it is that your project is trying to accomplish.
This is one of my favorite parts about XP programming. It is designing a system as simply as possible, while removing unneeded complexity from its components. When writing code I try to break the task down into its basic elements, figure out how each element might be approached, and then see what the language has to offer to solve the problem. I am not a fan of overly 'creative' and 'clever' solutions because they can be difficult to maintain. I like code that is easy to read at a glance, and I love when I have opportunity to clean up existing code, making it more maintainable.
This was one of my least favorite parts about XP programming. Programmers are supposed to write unit tests for each part of their code and all tests should pass for the project to progress. Also, customers can write high-level feature tests. Note that I say that it was one of my least favorite parts. I've actually grown to enjoy TDD (Test Driven Development) quite a bit. It allows me to code with more speed, confidence, and precision. The speed and confidence are because I am less fearful that I'm going to break a part of the app. With good coverage I know things are working properly. If I do make a change with unexpected side effects, a test will fail and I will know that I affected more than I meant to. I haven't actually had the chance to have a customer write the feature tests yet, but I usually take the task card and turn it into a feature test, so that I know that when my feature test is passing then the task is complete.
Refactoring is going over code again, removing redundancy, simplifying it, making it more flexible, etc… without changing it's behavior. I love this part of coding as well. It's a fun challenge and helps me grow as a programmer. There have been times in projects where I got it working but it was only so that I could wrap my brain around the concept. The code was never intended to go into production (at least not in its current state). It still needs to be refactored. We were brainwashed… I mean indoctrinated… I mean taught the phrase "RED, GREEN, REFACTOR!" while in the Craftsmanship Academy. This phrase means you should always have a failing test, then make it pass, and finally refactor the code ensuring higher quality.
This is the concept that no one person owns the code in a project and therefore anyone is free to make changes anywhere in the code. With good test coverage, it is nice to know that if anything needs to be changed to meet the changing needs of the customer, it can be. In every project I have worked in I have had to change someone else's code, I couldn't imagine how tedious it would be to have to get permission from another coder to make those changes.
Continually integrating your code into the project makes it very easy to see who introduced a bug, therefor who should fix it. After working on each new feature I run my entire test suite. The goal is to have 100% of the test pass 100% of the time. So when I start working on a feature the test should be passing both before and after the feature is implemented. Continuous integration also helps to reduce collisions making deployment an easier process.
The 40 hour week is a concept of XP stating that you should come in fresh in the morning and leave exhausted in the evening. Constant overtime can be a sign that something isn't going very well in the project. I don't always get exactly 40 hours on my timer, due to parts of the day that are not exactly billable to the customer, but I do manage to spend that much time in the office learning or putting effort into some project. It is increasingly more difficult these days to divide home life from work life. I have had calls from clients asking me to deploy features on the weekend. I will do it of course, but I do try very hard to keep a clear division from home life and work life, so that I come in feeling refreshed and ready to go each day.
An On-Site Customer is exactly what it sounds like. A customer sitting with the team answering questions and resolving disputes about the functionality of the application and its interface. We very seldom have this opportunity, but we do our very best to keep an open line of communication between the developers and the customer. I usually use technologies such as Trello, Skype, conference calls, and GoToMeetings to keep that line of communication open. An On-Site Customer would be better, but leveraging technologies efficiently is the next best thing.
Coding Standards ensure that code is uniform and concise. It should be difficult to tell which one of your team members wrote a specific line of code. A good coding standard should include DRY code (DRY means Don't Repeat Yourself) and Intention Revealing Names at a minimum. The key is that the code communicates. The rule at RoleModel is that two sets of eyes see (and approve) all production code. I love when good coding standards are in place. When the code follows a set order it is usually easy to add new features and functionality. I was surprised when coming to RoleModel with how high the code quality is. Seeing these high standards has helped me to become a better developer.
It is not the merit of the individual practices that makes XP so great, but rather the combination of them. If you tried to focus in on only one of these practices, parts of your project would fall through. When each is applied appropriately, it creates a certain synergy. I am very pleased to have been introduced so early on in my development career to a studio that implements XP principles, and I look forward to learning and applying everything I can from this experience.
Source: Extreme Programming Explained (Embrace Change) by Kent Beck, Pages 53 – 70.
Two of the recent Academy class members are about to start their second phase of Residency. Braxton Plaxco, who has been working under Tim Irwin, introduced how he has applied some of the Apprenticeship Patterns to his work so far. Now, we will hear from another of our Residents, Kyle Smith, who has been working under Ken Auer on a pretty exciting application we'll talk about soon.
I've been reading Apprenticeship Patterns by Dave H. Hoover and Adewale Oshineye. I was recently able to apply a few patterns: Confront Your Ignorance and Breakable Toys. I'm hoping I will also get a chance to apply The White Belt through how I'm applying the other two patterns.
My friend Braxton and I recently took on an internal project for RoleModel that we're building using Node and CoffeeScript. This is allowing us to apply each of these patterns.
If there are some gaps in your skills, work to fill in those gaps, one by one. One good way to do this is to build Breakable Toys.
Meanwhile, Braxton had done more server-side than I had, but not as much client-side, plus he wanted to learn CoffeeScript.
To fill in these gaps, we took on this internal project which we decided to build in Node using only CoffeeScript. Our plan is that Braxton will work on the client side, while I work on the server side.
Attempting things that may be beyond your skills, things you may fail at, is a great way to learn, but when you're in a situation where failure is not an option, you need to build a "toy" project where failure is safe.
The deadline for my main project is coming up soon, which puts more pressure on everyone involved, creating an environment where failure could easily cause a lot of harm. Working on this second project, since it's very low-pressure, gives me an environment where I don't have to be afraid of failing.
When approaching new situations, while still retaining your previous confidence, intentionally set aside what you already know and force yourself to learn the solution, rather than relying on your previous experience to provide the solution.
I expect that building the server-side portion of this project and working in CoffeeScript will give me plenty of opportunities to set aside the experience I've gained through client-side programming over the past few months.