Application tips and how to make the most of your time when you’re at coding boot camp

Part II: You picked a school and decided to apply

Congratulations! Hopefully you’ve considered your answers to all of the questions in Part I carefully and are eyeing the school of your dreams (if you haven’t, here’s where you can read Part 1).
But don’t get too excited yet, you still need to get accepted into that dream school…

1 How do I get in?

Most coding boot camps have a fairly long application process. If there are short answer or essay questions be sure to answer all of them and try to reflect passion in your writing. If there is an interview or coding test, try to show your thought process and your amazing problem-solving skills rather than focusing on just getting the right answer. This gives boot camp recruiters a reason to accept you even if you’re answer was slightly off or if your code was a little buggy.

3

Recruiters will probably ask for a normal, paper resume as part of the application, but it would also be highly beneficial if you had a strong online presence. You can display any prior coding skills on GitHub, make a personal website, and perfect your LinkedIn page. These simple things will help you have a stronger personal brand and appear more professional when your application is being considered.

Code Platoon’s application process only requires the DD-214 and Statement of Service forms for eligibility, and then 60-100 hours of pre-work on computing basics, for example.

2

2 What should I do to prepare myself for boot camp?

Frankly, a lot of things. And you thought applying was hard.

If the coding boot camp you want to attend doesn’t already stipulate a few tasks for you to do, to make that boot camp price tag pay off, you should first practice coding as much as possible, in whatever language it is that you will be learning. There are most definitely going to be online resources that you can use, such as the aforementioned Codecademy, Free Code Camp, and so many others that are accessible once you hit ‘enter’ on your favorite search engine. There’s also the all-around great resource Bento.io, which aggregates online resources that are available to learn coding.

3 What should I do while I’m at boot camp?

When you are in a coding boot camp, what ultimately matters is how hard you are willing to work. Perseverance and grit make the programmer, not how many languages they know. Working hard should be your number one priority if you want that ROI to be as high as possible. When you’re not in class, you should be studying or practicing what you covered in class. You need to put in all of your effort for those 10 or so weeks; again, the best boot camps tend to be immersive, which means plan on putting aside most of the rest of your life while you are going through the bootcamp.

Apart from working as hard as humanly possible, you should be asking questions. As many as you can. Try to answer your own questions first if possible, but don’t be afraid to ask for help. Your instructors are a great resource and your classmates will appreciate your engagement with the material.

Finally, network, network, network. Get to know your fellow developers-in-training. Talk with your instructors and attend events and career fairs. Connect with potential employers and companies that you would like to work for on social media by following them and replying to their posts.

1

4 What do I do after boot camp?

If you’ve graduated from coding boot camp, you should now have the skills you need to land a job as a developer if you’re boot camp was worth its salt. So what are you waiting for? Research companies! Apply to jobs! Maintain and hone your new skills! Start that new career in tech that you have always wanted and have worked so hard for.

 


About Code Platoon:

Code Platoon is an immersive, beginner-friendly coding boot camp located in the heart of Chicago. Code Platoon offers to cover 80% of tuition costs if you are a veteran, so the total out-of-pocket cost is $2,500. Code Platoon provides instant leads internships, interview preparation, job counseling, employer matching. Join us today by signing up at here.

Why I Chose Fish Over Bash

Why I Chose Fish Over Bash

Why I chose Fish over Bash for students

I’m currently the lead instructor at Code Platoon and an instructor/developer at the Turing School of Software and Design.

I’ve been advocating the Fish shell and when the choice is up to me, I choose that for my students. Enough people ask about the decision, particularly in relation to the preinstalled Bash shell, that I figured it’s worth laying out my reasoning.

TL;DR

Fish addresses many of bash’s shortcomings and is much kinder to newcomers, with only 3 or 4 new things to learn for people coming from Bash.

The decision give students my defaults

I used to let students choose whatever shell/editor/etc they wanted. But most students are not in a position to understand the tradeoffs, and they fear making changes. This would often lead to situations where students would defer all choices and 6 months into the program wouldn’t have so much as a coloured prompt. Why does a coloured prompt matter? It means that every command they type, they have to scrutinize carefully to see what the command was and what the output was. Add that to all the other costs of being new, and it gets expensive quickly!

The problem with being a beginner is that you get a lot of practice in staying a beginner. What a beginning tennis player does most of the time is chase the ball. They get to be really good at chasing the ball, but all other forms of tennis involve hitting the ball.

— Tim Gallwey

I eventually decided that letting them choose had little value because it meant inconsistent environments, most in some state of brokeness. Students were mostly overwhelmed by all the decisions they had to make, and were too ill-informed to understand the tradeoffs anyway. It turns out that overchoice leads to dissatisfaction, regret, and paralysis. I know the tradeoffs, and what they struggle with, so I’ll make those choices for them.

So then, the question becomes “what environment should I give them?” I’ve tried 4 different editors now (Sublime, Atom, RubyMine, and Vim), and two different shells (bash, fish). In the end, I realized that most of the decisions I make for myself are better than the defaults, and due to my prioritization of feedback, my choices are generally good for learners. One of those decisions was the Fish shell, and this post is intended to explain why it is a better default than the Bash shell.

The case for Bash

Based on conversations I’ve had, there are 3 arguments for Bash:

  1. It is already installed.
  2. Most shell code is written for Bash.
  3. Most people that can help know Bash.

My perspective: We are installing many new things already, and don’t accept this as an argument that we should stick with many other defaults. Fish is mostly compatible with Bash. And there are only a small number of new things someone with Bash knowledge needs to learn in order to use Fish.

The case for Fish

Highlighting

Fish will highlight the command they are typing differently from the arguments they are giving, making it apparent that this first bit of text is different. If it is not made explicit like this, students can go months before they understand that the first thing they type is a program and the things after it are arguments.

highlighting args

If they type an incorrect command, it highlights this in red, so they immediately know, as opposed to knowing when they get an error message after running the completed command.

highlights incorrect commands

It highlights quoted args differently to let you know they are a single argument, and if you have incorrect syntax, it highlights this in red:

highlighting identifies command vs arg vs quoted arg vs incorrect quoting

Suggestions

Fish will suggest previously typed commands. What was that command to start postgresql? type pg and it will suggest whatever I put last time! This is even directory aware, so that suggestions will be be prioritized based on where I use them!

suggestions

It understands program options and lets you tab complete to see what the option is and a brief description of the option:

suggests option completion with summary

Highly compatible with bash

Syntax for common use cases is usually the same:

Wildcards are the same

wildcards are the same

Redirects are the same

redirects are the same

Pipes are the same

pipes are the same

Things Fish does much better than Bash

It correctly handles string escaping where bash completely falls down (Bash later added $'this kind of string' to compensate).

fish quotes correctly bash does not

It’s much easier to set up a prompt that changes based on the success of the previous command (bash can do this, too, it just took me several years to figure out the right way to do it — the PROMPT_COMMAND variable, if you’re curious)

success displays in the prompt

When you get to scripting it, the language syntax is dramatically more understandable. I tried to write a function just now, in bash it took me 2 tries, then I wrote it long-hand so I could press up to see how it translates to one line (5 tries in the recording because I messed up). Notice that even if the fish version wasn’t obvious, the autosuggestion from my previous success would let me know. And while defining it, I get syntax highlighting and proper indentation.

functions in bash vs fish

Fish handles string escaping and allows you to edit across lines. I’m not sure what library bash uses, but watch what happens when I try to go up to edit what I wrote (also notice I got the name wrong at first, but fish highlighted it in red, so I knew to go fix it). It’s good enough that I’ve written 30 line programs inside of strings in the shell!

editing in bash vs fish

Bash only recently got basic data structures like hashes and arrays, and the syntax to use them is both unintuitive, and forgiving of mistakes (meaning it is easy to do the wrong thing, and difficult to realize it). Here’s an example: setting arrays involves complex syntax, whereas in fish, it’s the same syntax you use for everything else (a command followed by args) and look how many ways there are to access it wrong in bash, many of which you wouldn’t realize you got wrong unless you knew to check it against an element with a space. And you have to opt into safe behaviour by quoting everything… I’m not even sure what the unquoted use case is!

arrays in bash vs fish

And here’s bash’s syntax for hashes: http://stackoverflow.com/questions/1494178/how-to-define-hash-tables-in-bash

Another thing about Bash

Also, the relationship between .bashrc, .bash_profile, and .profile is utterly confusing and leads to bugs when things get placed in the wrong file (I’m pretty sure this is because it’s inconsistent across operating systems). A very competent friend (maintainer of gems we all use, who prides himself in knowing everything) once confidently told me what they all did, and I tried it in front of them and it was incorrect.

Summary

So, Fish addresses many of bash’s shortcomings and is much kinder to newcomers, with only 3 or 4 new things to learn for people coming from bash. I documented most differences I could think of over here, and that document goes much further than even I actually need. In our material on the shell, there’s only one place we need to differentiate it from bash, which is in how environment variables get set (12). So the cost is low and the value is high.

Salutation

Hope that explains my motivations sufficiently