Tips, advice, and guidance for changing your career.
on Tuesday, April 12 @ 8:22pm
Software developer positions are highly desired. Just as astronauts, Supreme Court justices, and Hogwarts professors must have a variety of skills and knowledge, software developers have a combination of technical knowledge and soft skills. This post explores the skills that many companies look for.
We’ve never formalized our core values at Bloc, but if you surveyed our employees you would probably see authenticity in the top three most cited responses — followed closely by swag and Batman. We’ll focus on authenticity today.
Authenticity is a word that we use very specifically, and we don’t use it to mean the same thing as honesty or transparency. The easiest way I’ve found to articulate the difference is to explain it in the context of someone asking a question:
Here’s an example: when we raised our Series A investment last year, a few of my friends asked me if I was now a millionaire.
An honest answer would be yes. On paper, if we had hypothetically raised a round with a post-money valuation over $5M and I owned at least 20% of the company I would have 20% x $5M = $1M ownership in a privately valued company and could technically be considered a millionaire.
The authentic answer would be no, not even close. The question my friends intended to ask was “do you have a million dollars of liquid cash that you can spend to buy me a Tesla Model S?” And the answer to that question is decidedly “no”, unless Elon would accept Bloc equity as cash.
The developer bootcamp industry has an obsession with something called “the placement rate number.” It’s meant to measure a program’s efficacy by quantifying the percentage of graduates who successfully start careers as developers.
Bloc is one of few programs that has never advertised a placement rate. Prospective students are eager to ask us for this statistic, and I don’t necessarily blame them given how appealing it is to use a simple benchmark to compare programs. We don’t publish a placement rate though, as we believe it would potentially conflict with our commitment to authenticity, not because we lack confidence in the efficacy of our program.
When a prospective student asks us “what is your placement rate?” we could honestly say anywhere between 0-100% depending on how we qualify our answer. We could, today, say that 99% of our students find jobs after they graduate from Bloc in a way that is both technically honest and legally defensible, but not authentic or ethical. It’s not very difficult to game that statistic.
99% of our “splorkdents” find “globs” within 90 days of “schmanuating”. – Credit: SMBC Comics.
The truly authentic answer has nothing to do with statistics though. The question our students intend to ask is closer to “Does your program work?” or more specifically “Will your program work for me?” We’ve found a better way to answer that question: our Software Engineering Track comes with a tuition reimbursement policy for students who are unable to find new careers in software development after graduating, and now our students don’t have to worry about landing on the wrong side of a program’s 90% placement rate.
When there are programs with less than 20 grads touting a 100% placement rate and dozens of hidden qualifications, that number devolves from a transparent industry benchmark to a disingenuous marketing prop. While we look for authentic and quantifiable ways to evaluate program quality, I’ll encourage students to dig deeper: ask about the curriculum, background and experience of instructors, tuition and opportunity costs, and the hidden qualifications of these placement rate numbers.
Bloc’s Software Engineering Track takes approximately 2,000 hours to complete. Depending on your pace, we distribute those hours across 48 or 72 weeks. That’s a long time, and students often ask if they can complete the track faster. Our answer is unequivocally, “no.” We insist on 2,000 hours because — like mentorship, curriculum, platform, and community — adequate time is essential for learning a new skill. It can not be truncated, even in the spirit of hustle or efficiency. To understand why time is so important, you must first understand how we view the path to mastery.
Any craft can be mastered, barring physical limitations. That is to say, I believe that I could become a masterful guitar player; but my dream of playing quarterback for the New York Giants is undoubtedly limited by my age, height, speed, strength, and my body’s inability to absorb blind-side sacks delivered by 250 pound linebackers.
But most crafts can be mastered, and the path to mastery has been well-defined for hundreds of years. During the middle ages, an apprenticeship system emerged where young adults lived, worked, and learned from an experienced mentor — a master. An apprentice signed a contract and spent seven years learning a craft like metalwork, medicine, cobbling, or tailoring. After their apprenticeship, the apprentice became a master, established their own business, and mentored apprentices of their own.
The apprenticeship system of the middle ages was successful, and still applies to current crafts, like electrical work, which has a standard apprenticeship of four years. The apprenticeship system is successful because of three factors: mentorship, practice, and time. In the middle ages, masters provided the mentorship and the apprenticeship contract ensured that practice and time were accounted for. Let’s discuss each of these factors.
A mentor is more than a teacher. Mentors know how to teach, but they are also masters of their craft. A mentor adapts to their apprentice and their apprentice’s learning curve. They understand when to pressure the apprentice, when to help, and when to challenge. A mentor can predict when the apprentice will struggle and adjust their lesson accordingly.
A mentor ensures that the apprentice practices realistically; they know that the apprentice can get only so far with drills and menial tasks, the apprentice must also work on real projects. The mentor knows how to administer these lessons effectively. In Mastery, Robert Greene discusses the benefits of learning from a mentor:
Mentors do not give you a shortcut, but they streamline the process. They invariably had their own great mentors, giving them a richer and deeper knowledge of their field. Their ensuing years of experience taught them invaluable lessons and strategies for learning. Their knowledge and experience become yours; they can direct you away from unnecessary side paths or errors.They observe you at work and provide real-time feedback, making your practice time more efficient. Their advice is tailored to your circumstances and your needs. Working Closely with them, you absorb the essence of their creative spirit, which you can now adapt in your own way. What took you ten years on your own could have been done in five with proper direction.
When you commit to learning a craft, you accumulate personal debt. “I will become a grandmaster chess player” is a lofty goal that will require an arduous apprenticeship. The only way to pay down a debt is with consistent payments over the course of months or years. In an apprenticeship, your payment is practice.
Your payment may be small one day and large the next – 30 minutes of practicing chess tactics or 4 hours of match play – but the key is that you keep paying. Any debt can be paid off, as long as you commit to a regular payment schedule. Consistent practice is absolute with an apprenticeship, without it there is no path to mastery.
Practice is effective enough to overcome the lack of natural abilities. Bill Bradley was tall as an adolescent, but not athletically gifted. Despite his lack of natural aptitude for the game, he fell in love with basketball and committed himself to playing it well. In another excerpt from Mastery, Robert Greene explains Bradley’s approach:
Managing to get his hands on the keys to the high school gym, he created for himself a schedule–three and a half hours of practice after school and on Sundays, eight hours every Saturday, and three hours a day during the summer. Over the years, he would keep rigidly to this schedule. In the gym, he would put ten-pound weights in his shoes to strengthen his legs and give him more spring to his jump. His greatest weaknesses, he decided, were his dribbling and his overall slowness. He would have to work on these and also transform himself into a superior passer to make up for his lack of speed.
Through disciplined and consistent practice, Bradley became an all-time great professional basketball player. He mastered a craft that’s constrained by physical attributes, which is a remarkable achievement. After he retired from basketball, Bradley applied similar rigor and work ethic to another craft he was not naturally suited for – politics. He served three terms as a U.S. Senator for New Jersey, and a campaigned for the 2000 Democratic presidential nomination.
Time is the most misunderstood factor in the path to mastery, because a beginner underestimates how long it takes to become proficient at a new craft. In Outliers, Malcolm Gladwell postulates that it takes roughly 10,000 hours of deliberate practice to master a craft. This has become commonly known as the “10,000 hour rule,” and has proliferated in both supporters and detractors. Gladwell defended the rule in his article Complexity and the Ten-Thousand-Hour Rule. Gladwell cited the conclusion of a 40 year old study about expertise, regarding their research of chess grandmasters:
There are no instant experts in chess—certainly no instant masters or grandmasters. There appears not to be on record any case (including Bobby Fischer) where a person reached grandmaster level with less than about a decade’s intense preoccupation with the game. We would estimate, very roughly, that a master has spent perhaps 10,000 to 50,000 hours staring at chess positions…
The time it takes to master a craft depends on the person, the craft, and the mentor, though 10,000 hours seems to be a reasonable average for most cognitive crafts. For 99.99% of people, there are no exceptions to this average. Mastery takes time, and there are no shortcuts.
The need for cobblers isn’t what it once was, but as software eats the world, the need for software engineers grows. The craft of software engineering lends itself to the apprenticeship system. It is complex and requires skills in reasoning, logic, art, math, and theory. Software’s complexity requires masters to develop it, and teach it.
Unfortunately constraints such as time, money, and competition in business impact the ability for masters to train apprentices. Formal software apprenticeships exist – thoughtbot, 8th Light, and Trunk Club offer paid apprenticeships where apprentices train with master software developers – but these apprenticeships are limited. They last only several months, are offered in specific locations, and admit a small number of apprentices.
These limitations demonstrate the difficulty with scaling apprenticeship programs. Coding bootcamps attempt to solve the problem of scale by offering online and and classroom-based focused training, but they lack the key factors of mentorship and time. The average coding bootcamp lasts 12 weeks, or approximately 500 hours.
This is the average learning curve for becoming a software professional. The minimum number of hours needed to become a proficient, entry-level full stack web developer is approximately 1,000 hours. After consulting with world-class engineering teams, we learned that there is a skills gap between a full stack web developer and software engineer, which neither coding bootcamps nor universities are addressing.
We believe that this skill gap can be closed with an additional 1,000 hours of focused practice, which is why we require a minimum of 2,000 hours for our Software Engineering Track. We support this requirement with a tuition reimbursement policy – if you’re not able to start a career as a software engineer after graduation, we’ll refund your entire tuition. We are able to make such a guarantee because we know that the apprenticeship model is effective, given proper mentorship and 2,000 hours of consistent and focused practice.
Bloc’s mission is to offer software engineering mentorship at scale; to provide a way for anyone, anywhere to learn software engineering as an apprentice. The tuition pays for the factors required in the path to mastery:
While it would be interesting to offer a 10,000 hour program for software engineering mastery, we believe that 2,000 hours is an appropriate amount of time to start a new career as a professional software engineer. A graduate of our Software Engineering Track will understand how to learn from a mentor, they will have disciplined habits and practice consistently, and with these skills internalized, they will know that the path to mastery is simply a matter of time.
It’s an inspirational idea – to think that you can master a craft with such a simple formula. Seek mentorship, find realistic ways to practice your skills, develop consistency in your schedule, and practice for years. You will become a master.
If you want to fail at something, make it your New Year’s resolution. “I will get in shape,” “I will be a better friend,” and “I will learn to code” are all unattainable goals. Goals in general are misguided and formless ideas. Achieving something is the result of many small steps performed consistently, not the result of an intangible idea.
I’ve worked at Bloc for three years, and have seen many students learn to code and change their careers. I’ve also seen students fail. I believe most students fail because they focus on the goal of learning to code, rather than the steps for learning to code. If you want to become a developer in 2016, don’t make learning to code your goal. Instead, complete small tasks related to coding, and do them consistently. Each of the tasks below requires only 10 minutes. To kickstart your new coding habit, do at least one per day. I’ve outlined six tasks, so even if you do all of them in a day, you’ll only spend an hour.
GitHub is where developers collaborate on software. You won’t be able to contribute code right away, but there’s no reason not to sign up for a free GitHub account. A GitHub account allows you to follow developers and source code (known as repositories, or “repos” in GitHub). Pick a few repositories and follow them by selecting the “Watching” notification, shown below:
You’ll receive emails when developers update the repositories you watch. Read the updates and focus on the narrative – you won’t understand the code yet – just read the comments and get a sense of what the developer is trying to do with the code they submitted. Here are a few active repos you can watch, though the actual repo isn’t as important as becoming comfortable in GitHub, and learning how developers collaborate.
Most prominent software engineers, developers, and designers use Twitter more than any other social media platform. Following them is a great way to learn about the software industry: trends, lingo, open source updates, hiring trends, etc. Unfollow Kim Kardashian, Justin Bieber, One Direction, and other people who don’t even tweet for themselves. If someone tweets their inane political ramblings – unfollow, pictures of their meals – unfollow. You get the picture; eliminate the noise in your Twitter feed. Once you’ve pruned your list of followings, consider following these prominent developers and companies:
This is a small list, but once you follow them you’ll receive recommendations for people like them. Spend 10 minutes per day reading their tweets, and you’ll start to learn about the software industry and how developers think and speak. The purpose is not to mimic them, it’s to understand them.
I’m always surprised at how much I can learn when I simply ask the right person the right question. No matter if you’re a total beginner or an expert, you will always have questions when learning. To receive a good answer, you must ask a good question; yes, bad questions exist. A question is bad if it’s not asked thoughtfully. A thoughtful question provides context, is articulate, and has a defined scope. Here’s an example of a bad question:
I have a Ruby array of two fruits, and I can’t seem to access an element successfully. What does “nil” mean?
That’s a bad question because it’s impossible to answer without more information; it lacks context. How are you trying to access the element? Which element are you trying to access? Are you getting an error? If so, what’s the error? Does nil refer to the problem you’re having or something else? Ask a bad question like this, and you’ll get a bad answer.
A good question looks like this:
I just started to learn Ruby. I have an array consisting of two fruits: fruits_array = [“apple”, “banana”]. I’m trying to access “banana” by referencing fruits_array but keep receiving “nil” in my irb. Why won’t it return “banana”?
This is a good question because it’s written well and is grammatically correct. It also provides adequate context: “I just started to learn Ruby,” “I’m trying to access by…,” “I keep receiving nil…,” etc. This question provides all the facts someone would need to answer it. It’s an easy question to answer for an experienced developer, which makes it likely that someone will answer it and answer it well.
There are many great places to ask questions. Quora is built for asking questions in general and Stack Overflow is built for asking technical questions. We’ve written “Getting Help on Stack Overflow” at Bloc, which provides details on using Stack Overflow. Once you have a GitHub account and have codified your Twitter feed, you can ask questions on those sites as well.
Writing is one of the best ways to improve your coding skills, because it forces you to clearly articulate your intent. Coding forces you to articulate your intent as well, only to a computer instead of a person. You write for people, you code for computers, but you use the same thought process for both.
Write 100 words (less than half a page) about anything you’d like. The only constraint is that you must try to clearly articulate your thoughts. Medium is a great platform for writing, and integrates with your Twitter account. As a separate task, read Writing to Learn by William Zinsser. It will open your eyes to the power of writing.
At some point, of course, you’ll actually need to write code. There are many places to write code – none better than a simple code editor on your laptop – though as a beginner you may want an easier place to start. Sign up for a free account with Codecademy and Codewars. Codecademy has tutorialized, in-browser courses that teach you the basics of programming syntax, while Codewars will challenge you to solve puzzles (called “katas”) with different programming languages. Both are great places to practice writing code.
Reading code is an under appreciated practice. It may not be as exciting as writing code, but it is equally, if not more important. GitHub and Codewars are great places to read code. You don’t need to understand all the code in a GitHub repo or Codewars kata; start small and pick a class, method, or single line of code. Use the Rubber Duck technique to explain the code to yourself. By reading code you’ll expose yourself to new patterns, syntax, logic, and approaches that you would not otherwise know. Tutorials can only teach you so much, reading code will take you much further.
All of these small tasks are free – they don’t require subscriptions or memberships. You won’t learn to code by doing these tasks consistently, you will code. Please, don’t make a grand resolution on December 31st – instead, commit yourself to small tasks and you’ll succeed in 2016. After you’ve created habits out of these small tasks, you may find yourself wanting to take your coding journey to the next level and change careers.
At that point, consider Bloc’s Software Engineering Track, where you’ll learn full stack web development, computer science, and open source software development with an experienced mentor. We guarantee you’ll get a job after you graduate, or we’ll refund your entire tuition.
I may not love New Year’s resolutions, but I do love New Year’s Eve; friends, college football, those tiny hot dogs… it’s an amazing night. Happy New Year, and I hope you find success in 2016.
The software industry uses words like hacker, programmer, coder, developer, engineer, and architect to differentiate between similar-but-not-identical skill sets. These terms are poorly defined, which causes ambiguity, and their appropriate uses are still debated today:
Bloc offers two related Tracks for students who desire to learn these skills: a Full Stack Web Developer Track, and a Software Engineer Track. Since the definition of these terms can be ambiguous, let’s be explicit about what we mean. (Others may use these terms differently.)
If you graduate from the Full Stack Web Development Track, you’ll be able to develop and maintain web apps. You will learn two programming languages, how to create databases, advanced styling techniques, and more.
But there exists a class of problems not covered by this Track. As an example, consider this question: “Given a list of cities and the distances between each pair of cities, what is the shortest possible route that visits each city exactly once and returns to the origin city?” It’s called the Traveling Salesman Problem because a salesman must travel through many cities and make the best use of their time. There are many problems like this.
For example, Airbnb might want its users to create search queries like “Given a city and a list of Airbnb rentals, what is the cheapest way to rent Airbnbs for three straight months, using only Airbnbs that have a dishwasher, a washer/dryer, or both?” A junior web developer may not be prepared to write code to efficiently answer that question. A software engineer grad is armed with techniques and skills that make them capable of solving these open-ended and complex problems.
Here’s an analogy outside of software development: a Full Stack Web Development Track graduate is like a construction worker who builds bridges. Bridge-building is highly skilled labor, requiring lots of practice and knowledge of different materials, approaches, scenarios, and designs. A great bridge-builder can adapt their approach to different types of gaps, different weight requirements, etc. But ultimately this person is combining existing tools to construct something, not designing something new.
A Software Engineering Track graduate is like an architect or civil engineer. This person understands the theory behind everything – not just which metal to use where, but why: how to measure it and prove it. This person also understands at a more fundamental level how the sausage is made: what goes into the metal alloy, or how the specific curve of a support beam is important. They are uniquely qualified to design new bridges, and make more creative, iterative improvements on existing bridges.
The former will likely always be employable, at least in areas with bridges. But the latter is indispensable to society: without them, we can never evolve. Ultimately, graduates of the Software Engineering Track can solve harder problems, handle more complexity, and create more robust software.
Now that you know the difference, consider which track to enroll in.
Given your hard work and diligence, Bloc Tracks will change your career and your life. All Tracks teach professional-grade software development skills, include dedicated one-on-one mentorship from an industry expert, and come with exclusive access to Bloc’s Employer Network and Career Services team. Each Track follows the tried-and-true Bloc approach of building real software, starting with carefully sequenced and technically rigorous curriculum and transitioning to independent work at the end.
Here are the main differences:
Compared to the Full Stack Track, the Software Engineering Track (SET) covers more advanced topics, and requires one thousand hours of additional work. Both are premium experiences designed to help you get a specific outcome: new skills and a new job. SET’s length provides its students with enough time to master the advanced skill set. Whichever direction you go, a Bloc Track will teach you to write outstanding software, improve your career, and enrich your life.