on Wednesday, March 23 @ 3:16pm
New coders, does this sound familiar? You’re finally getting the hang of programming. But then you overhear a conversation about a language you’ve never even heard of. Oh no! How could you call yourself a programmer if you’ve never even heard of Haskell? (How many programming languages are there?)
Easy, tiger. Impostor Syndrome is setting in hard. You feel like a fraud, even though your accomplishments show otherwise. Maybe you have successfully coded your first app but you feel like you’re pulling one over on the world by calling yourself a programmer. Or perhaps you enjoyed dabbling in Codecademy, but you could never actually make the switch to becoming a developer. Feeling this way is not only normal, it could actually be a signal of greatness.
Learning to program lends itself tragically well to Impostor Syndrome. There is so much to learn about programming, it’s impossible to be proficient in every aspect. Do you know how many people know everything there is to know about Ruby? Zero. Not a CS grad, not your smartest developer friend, not even the guy who created Ruby in the first place.
Rest easy, you’re not alone. No matter how experienced you are, you will always hear other developers talking about a new concept that you have never heard of. You may feel like you don’t belong in the conversation, but you do. Frame it as an opportunity to learn and become a better developer, and remember, everyone feels this way.
I can’t think of a group more prone to feeling this way than bootcamp students. The beauty of programming bootcamps is that they allow people with little to no programming experience enter and succeed in the field. Thus, if you called yourself a developer before you enrolled, you really would be an impostor.
At the most recent Bloc Career Talk, Bloc students shared their experiences with impostor syndrome. Hillary, a student in the Rails course, shares her experience:
I started as a technical analyst at a company that created a proprietary application that worked alongside SharePoint. For the first few months I imagined myself getting fired daily. Six months after starting I was promoted, and three months after that I was promoted again to a managerial position.
Hillary says she’s feeling impostor syndrome all over again as she sets out to land her first developer position, despite crushing her course and having four completed projects under her belt (way to go, Hillary!).
Okay, so there’s a name for this rotten feeling. Now what? As with many struggles, your first step is to recognize the issue. It’s only overwhelming and soul-crushing if you believe you’re the outsider. Think you really are the only person that feels this way? Try voicing your misgivings about your developer skills to a community of developers—I’d bet a lot of 1’s and 0’s that you’ll hear many others feel the same.
Once you realize that it’s a common struggle among beginners in any subject, the problem shifts from an internal judgment of yourself (“I’m just not a programmer”) to an opportunity to expand your skillset (“I have a lot that I can continue to learn”). The key to persisting through this forest of self-doubt, hopelessness, and anxiety is to accept what you don’t know, and challenge yourself to master it.
Then you can focus on progressing in your work to prove to yourself that you’re no impostor. If you’re facing an overwhelming problem, which is likely what led to all those “impostory” feelings in the first place, break it into tiny steps. Whether this is fixing a bug, writing an app, or getting to the end of your foundations, it will feel more manageable if you break the problem into pieces and celebrate the small wins.
At Bloc, students can connect and commiserate with fellow students on this topic and others in our Student Slack Community. During our Career Talks, students also get to fire their burning career switch questions at our captive Director of Student Outcomes, Courtland Alves.
This blog post is based on the recently hosted Bloc Career Talk covering Impostor Syndrome. Career Talks are bi-weekly seminars that facilitate discussion among Bloc students about the career search process.
Note: I struggled the entire way while writing this. Who am I to think I’m a writer? #impostorsyndrome
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.