on Friday, April 1 @ 4:13pm
As online education proliferates (read: online coding programs), its proponents and detractors develop increasingly stronger opinions on its effectiveness. Proponents tout online education’s low cost, accessibility, and flexibility. Students can learn anywhere, according to their schedule, and usually at a reduced expense. Detractors, on the other hand, cite high dropout rates and a lack of effectiveness. While both sides of this debate are correct, there is a strategy for succeeding in an online program.
A dedicated home office doesn’t require a large investment. As an online student you’ll work from home most of the time. You must find a space that’s quiet, clean, and allows for ergonomic amenities. 100 square feet should be plenty of space to create an office. You can find high-quality office furniture at IKEA, or buy used from a site like craigslist. Consider using a standing desk, or treat yourself to an ergonomic desk chair. Better yet, you can buy a sitting desk and build a modular standing desk, so you can stand or sit.
After your desk and chair are positioned, build the rest of the office around them. Hang pictures or paintings and buy a small bookshelf to fill with inspirational books. Save your money for perhaps the most expensive things, like a computer and monitor. It’s essential that you have a capable computer, and I recommend splurging on a large monitor. You’ll need to have multiple windows open from time to time, and a large monitor provides the real estate to do this.
Finally, if you live with other people, ask them to respect your office space. A clean, organized, and comfortable office will set you on the right path for succeeding in an online program.
When you take an in-person program, immersion in the topic is inherent. You’re physically near your classmates which means that you’re likely to discuss the program and share knowledge. As an online student, immersion is not necessarily inherent – you have to force the issue. Your program will probably have a community – forums, chat rooms and mail lists – and while those are good places to hang out, you shouldn’t stop there. Subscribe to blogs and podcasts and find people to follow on Twitter. Get to know the lingo of your topic of study, and some of its key figures. It doesn’t matter if you understand everything right away, it’s important to become comfortable with the “language” you’re learning.
In-person programs impose a routine of study because you have to go to class at specific times. Online programs offer more flexibility, so you have to manufacture a routine. Without a consistent and disciplined routine of study, you will not succeed in an online program. Whether you spend 15 minutes or 8 hours studying, you must study every single day. Create a habit for yourself. How long it takes to form a habit depends on the person, but you’ll know once you develop it because it will feel wrong not to study. Make sure that your study time is scheduled when you are at your mental best, and not when you’re tired or easily distracted. Find a method that helps you get into a relaxed zone, and make sure you schedule your study time around it.
The fact that you don’t have a classroom doesn’t mean you should avoid people and in-person interaction. An online program offers many benefits over an in-person program, but interaction in real life is something it can not offer. Fortunately, there are many options for meeting people in real life for many different areas of interest.
For example, if you’re studying to become a Rails web developer, there is almost certainly a Ruby or Rails meetup in your area. Join the meetup group, discuss your program with others, tell them what you’re working on and what you’re having trouble with. You’ll learn a lot from these experiences, and often in ways that are hard to duplicate virtually.
No matter how great your virtual community is or how many meetups you attend, as an online student you’ll spend most of your time alone. It’s easy to forget how much you’ve learned when nobody is there to remind you. You must make it a habit to remind yourself. At the end of every day, you should rebase. That is, think about what you know, compared to the prior day. Think about the problem you’ve been toiling over, and that you finally solved. Even though these may seem like small wins, celebrate them! Treat yourself to a beer, order a pizza, or do something to spoil yourself for every little win.
Celebrating your wins is as important as embracing your struggles. If you focus too much on either, you’ll derail your progress. Develop a balanced mindset for both, and you’ll create momentum to capitalize on your wins, and grit to push you through struggles.
It certainly can, but whether it does or not ultimately depends on your commitment, consistency, and discipline. The strategy outlined in this blog will ensure that you succeed in your program, but you have to embrace every part. If you do, an online program will provide you with a quality education, at a reduced cost, and on your own schedule.
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.
If you’re considering a career as a software engineer, then you may have heard how difficult it is to learn. But the right mindset can give you a significant advantage when learning and working in the industry. Software engineers who embody these seven character traits are valuable employees and productive contributors.
It’s what killed the cat, apparently, but that cat was a rock-solid engineer. Great engineers take responsibility for learning and exploration. They do not depend on their superiors to give them explicit direction for a new challenge – their curiosity guides them to reach their own conclusions.
At my first job as an engineer, I worked on an Android game. In the middle of working on a new feature, I noticed that some background tasks consumed an inordinate amount of time. After some investigation, I discovered that we relied on an Android API that took 50% longer on average to complete when compared to a simpler Java counterpart. I reported my findings and as a result, we swapped one for the other in all cases.
An engineer who seeks out new information and investigates the product may discover something new in the process. More importantly, the more versatile an engineer, the more valuable they become. Learn to serve your curiosities and feed them with research and experimentation.
All engineers require mental stamina. As a new engineer, you won’t solve the most challenging problems during your first attempts. In fact, you may have to spend days, weeks, or longer looking for a solution before finding one that meets both business and product requirements.
If you give up readily, you may not find yourself working on anything interesting, or anything at all. Engineers love solving problems and most refuse to give up until they work them out. Grit is what keeps engineers from throwing in the towel.
In 2014, the popular blogging platform, Medium, encountered a problem rendering underlines in Chrome. The author, Marcin Wichary, states that what was thought to be a one-night project turned into a month-long effort. After brainstorming seven approaches, the team settled on one and Marcin implemented it. Fixing something as seemingly trivial as a proper underline required incredible tenacity and the product is better for it.
This one is a no-brainer, but if you want to be a part of a functional team, you must communicate. If you’re shy or quiet, that’s fine. You can make up for shyness by communicating effectively in writing.
At Bloc, we rely on asynchronous communication – one out of every six employees works remotely. We use email, Slack, and GitHub to facilitate feedback and discussion. In these messages, we try to use as few words as possible and get to the point fast. This keeps our co-workers focused and eager to read and respond.
Your team needs to know what you’re working on and if they frequently ask for clarification, they may stop asking altogether. By communicating frequently and in brief but descriptive messages, your team will look forward to speaking with, and hearing from you.
Despite being another predictable member of this collection, attention to detail is vital for engineers and thus worthy of mention. If an employee at McDonalds applies two ounces of special sauce to your Big Mac instead of two and a half, will you notice?
As a software engineer, if you mistype even one line of code, it can crash an entire application. Details comprise software, and companies hire engineers to craft those details well. If you are someone that looks solely at the big picture, you have to learn to zoom in.
At Bloc, our students rely on our custom curriculum to learn the software trade. If we mistype a line of code or introduce a grammatical error, the student’s ability to learn the subject is significantly affected. We use grammar tools like spell check, linters, and Grammarly to draw attention to pain points.
Some call this, “thinking outside of the box,” but saying that would be yet another cliché and this post has reached its limit of those. When solving challenging engineering problems, the best solutions often come from adopting a new perspective.
If everyone took a crack at a problem from the same angle, they would ultimately arrive at a similar solution. But a diverse team whose approach varies among its members will generate more ideas and non-conventional solutions. You and your team will benefit if you broaden your ability to see things that others overlook.
To allow team members to share new ideas and solutions, we occasionally hold hack day events at Bloc. These hack days, like hackathons at Facebook, permit anyone in the company to work on anything. Thus, people who rarely interact with an aspect of the Bloc product can build new features or solutions that the dedicated team had not yet thought of. For example, our hack days helped us design a new payment flow, student portfolios, a student glossary for recruiters, and so much more.
Engineers collaborate, even when managers assign a task to just one engineer on the team. Team members review each other’s code before deploying it to production, and during these reviews, they may criticize or recommend significant changes to code written by their colleagues.
Engineers open to receiving critiques and feedback receive more support from their teammates, and the engineers that receive more support make bigger contributions to the product. More importantly, the product suffers if an engineer deploys code without revising it to meet the expectations of their peers. A good engineer is modest and willing to consider a different approach suggested by their team.
At Bloc, we have a thorough review process both on the engineering and curriculum side. Before we published this blog post, it received editing passes from two individuals that looked for quality content and prose. I was responsible for accepting modifications and including content suggested by my peers; the post is better for it.
It’s common for some engineers to isolate themselves and work without consulting their teammates. The industry refers to this proclivity as Lone Wolf Syndrome. Lone Wolves, much like the animals after which we’ve named them, do not survive for long. Wolves hunt in packs, and engineers must collaborate.
To be a productive engineer: seek help when needed, express yourself when overwhelmed, offer to help when you see peers struggle, and in general, engage with the group. No one on your team is excited when one person goes off and returns with unwanted or otherwise broken code. Acting as part of the team builds better relationships and trust among your co-workers.
If you believe that your personality is set in stone or that you’ve grown fixed in your ways, we recommend you read this article from Psychology Today. Those who study the mind believe that personality is flexible and with concerted effort, anyone can alter their disposition.