As an instructor, I find myself giving the same advice frequently to many students. In this article, I’ve distilled my most common recommendations into one place, especially since I worry that students might be missing out on advice if I don’t say it in front of the class.

This article contains advice for students in different stages of their programming career, from entering the bootcamp to landing their first development job. It describes some keys to success:

• As a bootcamp student
• As a programmer
• As a job applicant
• As an employee

My hope is that this will be a resource for all students of the Re:Coded bootcamps (and possibly other bootcamps, but it’s catered to my experience).

For the students: as with all improvement, simply hearing or reading it once isn’t enough to build good habits.

Table of Contents

• As a bootcamp student
  • Learn to read technical writing
  • Stop watching so many videos
  • Be emotionally aware
  • Don’t compare yourself to others
• As a programmer
  • Be able to explain every variable
  • Stop assuming
  • Learn to spot the difference
  • Focus on debugging skills
• As a capstone project member
• As an employee
  • Do a good job
  • Seek new things
  • Don’t be overly eager for the first opportunity

As a bootcamp student

Learn to read technical writing

From the first day, students should focus on their technical reading skills.

In programming, videos will bring learners 30% of the way there on basic concepts. But after a certain point in the journey, videos won’t even be present for topics one has to research. Software development is a heavily reading focused process: when leveraging a new library, working in a framework, understanding an application with private code, and so on.

I’m not saying that videos shouldn’t be used at all; they are excellent at teaching the foundational concepts (see the next section for caveats). However, many students skimp on improving reading skills, thinking that the dream of learning from videos will carry on forever. Reading skills must be developed in parallel.

There’s a reason that programmers want people to RTFM, not WTFV.

Stop watching so many videos

To learn football or piano, can this be achieved by mostly watching videos? Coding is no different.

Videos are good for introducing basic concepts. They are also good for building familiarity when typing alongside the video. But after a certain point, improving isn’t about watching more videos: it’s about doing the activity (coding) and identifying mistakes (see the debugging skills section). This is the general loop in all skills, not just coding.

It’s no coincidence that the students that plateau the most are the ones that are adamant about watching videos, repeatedly reaffirming that they learn better by watching videos (a statement true for most of the population). In the finite time available in the bootcamp, it takes away from the time to practice application.

Students frequently tell me this: “I understand the concepts but I’m having trouble when I actually write code.” At this stage, the solution is not to watch another video to reinforce the concepts; it’s to practice writing the code (though arguably the first step could be done by following step-by-step from a video). There is no substitute for writing code.

Even though most students seem to understand that piano and football can’t be learned by watching videos, I believe that, because coding happens on a computer, some get stuck in the video mindset, making it feel different from other “tangible” skills such as instruments. Hey, we do real things with our keyboards.

Be emotionally aware

I encourage all students to think carefully about the best ways they can support their peers’ experiences. The bootcamp can be a stressful experience for a lot of students. Students grapple with their own self-image and ability to learn, and each student plays a role in impacting the experiences of others through their actions.

Let’s take, for example, the phrase: “this was easy.” In my opinion, even if the activity was actually easy for the student, an emotionally aware but advanced student would focus on the hard parts nonetheless – showing even the struggling students that each person has difficulty with something.

This is simply one example, and it doesn’t imply that students shouldn’t present advanced work or express their opinion, but often there is a clear separation between students who are aware of how their behavior affects the mentalities of the rest of the class and those who are not aware. Students should consider how their words may affect other students’ mentalities. The goal is to create a better learning experience for all students.

Don’t compare yourself to others

Comparing yourself to others is usually unproductive. While it’s a natural reaction, try not to do it.

Everybody can compare themselves to another person. When you start programming, there’s already somebody who will learn faster. When you get your first job, there’s another entry level developer out there with a higher salary. Simply focus on improving yourself.

As a caveat, comparisons can be productive, but this depends on your personality and mindset. In my experience, the comparisons that my students make are mostly not productive.

Productive: “This person is doing well. I’m inspired. I’m also going to strive to reach that level of skill.”

Not so productive: “This person is doing well. I feel really behind and unsure, I’m not sure if I’ll be able to do this. Everybody else does it better.”

As the CS50 course says on one of their very first slides: it’s not about where you end up relative to your peers, it’s about where you end up relative to where you started.

As a programmer

Be able to explain every variable

When code isn’t working, I advise students to strive for this state: if I point to some part of the code, the student should be able to correctly explain the type and the approximate contents of every variable.

One of my most common questions to students is this: “What does this variable contain? Is it a string, a number, an array, an object?” Especially in the early parts of the bootcamp, I usually receive the wrong answer.

Take it slowly: students should build an understanding of each variable’s contents, double-checking that understanding with logging. For students that feel they are plateauing, I advise them to achieve a more intimate understanding of their own code: make sure that every variable’s value is understood. See the next section about assumptions.

Stop assuming

Don’t assume that the code or variables do what they should be doing, and use the console liberally.

All programmers are familiar with this sequence of events: after a long period of debugging everything else, even though you were so, so, so sure that this variable contained some value….well, it didn’t. It had something else.

When I help students with activities, one of my most common actions is to simply tell them to log a certain variable, and that generally sets them on the right path. But there’s nothing magic about this; it’s simply that I don’t assume the variable is working as intended. Often, the student chose not to log it because they assumed that a variable contained something without checking it themselves. The instructor simply went “to double check.”

I often say that programming is a humbling art: when we debug, we have to assume that we are wrong, revisiting our own mental image of the code.. One of the most poisonous thoughts can be being overly sure in yourself: “I’m sure this variable contains X, nah…no need to check it,”

Learn to spot the difference

In coding, where we often work with example code or existing code, “understanding the difference” between two pieces of code is a crucial skill.

I explicitly draw attention to this skill because developers leverage this frequently. For example, when reading the documentation for a library, looking at code on StackOverflow, using teammates’ code as a guideline, etc. All of these will ultimately involve “spotting differences” in code, whether to fix or adapt.

Examples

• My function is giving a syntax error, but the function in the demo works. What’s the difference?
• One of my pages is working, but the other is not. But they have the same structure. What’s the difference?
• This example code works, but my code doesn’t. What’s the difference?

Sometimes spotting the difference can be as small as a single character. Sometimes we can’t be sure if the difference is the cause of an issue. But the mentality here is to be suspicious of everything; any perceived difference could be the cause. I often hear this: “I saw this this difference but I didn’t bother to investigate it, it couldn’t have been that!” From the last section, we know how this turns out. Don’t assume.

Focus on debugging skills

Debugging skills – finding mistakes in code – are extremely important in programming. Many students begin with the misconception that the majority of programming is about writing code and later fixing a few small mistakes here and there. The truth is usually the opposite: most of the time is spent fixing mistakes in the code!

Debugging is a methodical, iterative process in which we learn from our mistakes. I encourage all students to put in an active focus in improving their debugging. I write this because it’s often something that students passively develop, but I want to highlight an explicit focus on debugging skills here. Take every bug fix, and try not to repeat the same mistake.

This is related to why videos are limited in their helpfulness. Videos usually teach how to write code for a certain concept, but they don’t focus on the correction of mistakes. See this StackExchange question on effectively debugging code.

As a capstone project member

After the first three months, students participate in a “capstone project” with sprints and code reviews, managed by a lead engineer from Re:Coded. This is meant to mirror the real development process.

I will simply share the mental checklist I go through when I evaluate a student on the capstone projects, in order of most important to least important (though all of them are important).

1. Did they learn from their mistakes in code review and pull request preparation, infrequently making the same mistakes?
2. Did they review their peers’ code thoroughly and in detail, applying principles from their own code reviews?
   • Or are most reviews simply one small comment followed by LGTM?
3. Did they respond in a timely manner as both a reviewer and reviewee?
4. Do they habitually proofread their code reviews after asking for a review?
   • Or are log statements, wrong newlines, failing tests, typos, etc. frequently present?

Answering no to any of the main four questions above indicates an area of improvement. In my eyes, how well a student did in this project essentially maps to “how much yes” or “how much no” for the answers above (nobody is perfect).

All of these are less about technical knowledge and more about the care one takes in their work. This type of quality and attention is noted in the workplace.

As an employee

Do a good job

There is no substitute for doing good work and achieving results at a workplace. Focus on excelling in work – writing clean code, being a good communicator, being a good teammate – and it will open up more opportunities.

Somebody who does good work is valued. And somebody who is valued generally has more agency in their life – agency to choose a team, a company, a project, and to some extent, a salary.

Seek new things

Say yes to new projects, new technologies, new teams. This will pave the way for being a well-rounded developer.

After “learning to learn”, one should embrace the challenge of learning a new technology or framework. Over-comfort should be discomfort; it’s a sign that it’s time to go seek new knowledge. Nobody wants to be doing the exact same thing for 25 years.

Of course, there are a few caveats, such as a draconian boss that wants to milk 18 hours a day from you, career risks from moving to new teams, and so on – but to have a fulfilling career, one should keep the general principle in mind.

Don’t be overly eager for the first opportunity

Know your value. A lot of my students, even the ones that excel highly in the course, have the mindset that they’d love if someone offered them a job. When I hear this, I worry that they might simply snap up the first job that they’re offered, consequnetly giving up on comparisons with other opportunities on culture fit, learning opportunities, or salaries.

Keeping this mind, I encourage students to understand their worth and make their best effort to explore options, rather than immediately settling for the first. While we should all be grateful for the opportunity for employment, my graduated students are often surprised by the level of demand for developers. In short: you’re probably more valuable than you think you are (economically speaking).

As a disclaimer, this is completely dependent on the person’s financial and life situation. In this particular case, most of my students spent four months in a coding bootcamp and generally aren’t in financially urgent situations, consequently having the luxury of spending time for a job search.