3 Tracks for Veterans and Military Spouses

Code Platoon Graduate Javier Revuelta:How a challenging experience became rewarding, and led to a dream job

Javier Revuelta: How a challenging experience became rewarding, and led to a dream job

Javier joined our very first cohort back in January 2016 and graduated in May 2016! We asked him to share a few answers with us over email about his experience with Code Platoon.

Javier Revuelta

Former title: Korean Cryptologic Linguist, United States Air Force
Current title: Ruby Developer Intern at PowerReviews

How did it feel when you transitioned out of the military? What would you say to others who are going through/will go through the same transition?

Transitioning out of the military was an interesting experience, because despite my eagerness to start a new phase, there was a long period of adjustment back to life beyond the uniform.  I went straight back to school to finish a Bachelor’s degree and, while certainly useful, at the end of the process I felt like I had just gone through the motions, somewhat.  Get out, go to school, get a degree, go find a job—that sort of thing.  Code platoon was frankly the turning point that made me feel like I was on a real career path, rather than simply having a decent job.

To anyone who is transitioning out of the military, I would simply suggest giving yourself the time to really consider where you want to be in a few years.  Ultimately, we are all looking to be happy and fulfilled in our lives, but that can take many forms and half the battle is being honest with yourself about what that means to YOU.  Whether your choice places you near or far from the skillset you developed in the military isn’t all that important.  Don’t be afraid of going way out of your element.  

What do you do on a typical day now in your civilian career? Is it different from your time in the military?

I am currently a software engineering intern at PowerReviews.  I support two Rails applications, and have had the opportunity to collaborate developing new features and seeing the entire process of bringing a new application to life.

A typical day starts around 8:00 or 9:00 am with arriving to work and checking for pull requests that have been submitted by the team.  I familiarize myself with the work that went on the previous day and ask any questions that might come up while I do code review before we merge the newest batch of changes.  I will then take a few minutes to prioritize the day in terms of outstanding tickets I might have, and will try to do some coding before our standup meeting at 10:30.

Once standup time arrives, the team gathers and explains the work each person has done since the previous day.  We are encouraged to bring up anything that could be blocking our progress so we can address that quickly.  I will generally give some idea of where I am with projected completion times for outstanding tickets, and mention whether any of my work is relevant or could impact any of the work that the others are doing.  Standup meetings tend to be fairly short, so I am usually back at my desk within 15 minutes.

Once standup is complete, I can get a good coding session in before lunch.  Work tends to have a wide range of flavors, but taking today as an example, I spent the morning writing some tests for Active Record models.  Lunch was going for a quick run to clear my mind, and then it was back to tackling a few bugs in the code for one of our apps, as well as re-visiting an API I had written to expand its features, since requirements for it had changed.

The work that I did in the military involved foreign languages, so there are certainly some parallels to be drawn.  The process of learning vocabulary and phrasing in Korean ties closely with working out the syntax of- and well as writing idiomatic Ruby, for example.    

Why did you join the military? What does the military instill in you?

I was unsure about what I wanted to do with my life, so I walked into a recruiter’s office almost as an afterthought.  As soon as I got the option to become a cryptologic linguist, I knew that I would be in for a very special experience and the rest was history.  The military will teach you many things, but the most important ones are leadership and teamwork, which go hand-in-hand.  Nobody is above the team, nobody is dead weight, and nobody gets left behind—lessons are taught quickly and effectively if you struggle with any of those concepts.  What comes from that is a strong sense of self and core values, along with a level of camaraderie with your peers that will, in all likelihood, never be matched in your civilian life.

Why did you decide to join Code Platoon?

Code Platoon opened a door that I had long ago considered to be closed.  Going back to the reasons I joined the military, one of the things that the recruiter asked me after I had completed all of my assessments was whether I had an interest in languages or programming.  Back then I said languages, but I spent the next ten years wondering what would have happened if I had answered differently.  Code Platoon gave me a chance to answer that question again and choose a new path.

One of the most important things that led to my decision to join Code Platoon was an early conversation I had with Rod while I was finishing up my application.  It was clear to me that the best intentions were in place with this program: non-profit, veteran focused, etc., but I knew that if the right person wasn’t at the helm this would be short-lived.  Rod instilled an immense amount of confidence in me, and his absolute frankness about the program, the challenges ahead, and his plans to really build something great made this an easy decision.

Take all of that and add a generous tuition-assistance program coupled with companies willing to grant internship slots to new graduates, and you have a package that is unmatched by any other boot camp.

What was your favorite and/or most memorable part of it?

I will always remember the camaraderie and dedication that everyone showed day in and day out.  Most of us have been out of the military for a while and were complete strangers when we first started the program, but I know that I have lifelong friendships here and that I could trust these guys with my life.

Memorable?  Many things stand out: hackathon night pairing with the guys at Enova, the surprise of getting our graduation coins after presenting our final projects, walks around the block to try to clear our minds and discuss a given project, or even the cheesy ‘Welcome Back’ CSS animations for the e-greeting card we built for Rod when he got back from a trip.  I’ll never forget having our instructor take on multiple accents/personas to play ‘client’ or ‘consultant extraordinaire’ when we were tackling our projects.  It’s the small things that made this whole experience amazing.  

How did you feel at the beginning of CP?

I was excited to take on this new challenge, proud of myself for making the leap of transitioning out of one career to pursue my real passion, and also slightly nervous about my ability to get through it all and succeed.  Would I be able to handle the curriculum? Could I really build a new career as a software developer?

I would eventually learn that the answer to both was a resounding yes, but those first days definitely put us all to the test.

What did you think of Code Platoon overall?

        Code platoon was an interesting experience; it was certainly rewarding but immensely challenging at the same time.  We were provided an incredibly capable instructor (rewarding!), but the teaching style – in having to compress so much information into such a small timeframe – was not for everyone (challenging!).  I don’t think I could have achieved what I did anywhere else, and in that I give full credit to Rod, Josh, and Brent for doing an outstanding job as we navigated this new process together.

        Ultimately, I think what brought Code Platoon to life was the camaraderie.  For all the happy years all of us have spent as civilians, there is something to be said for being in a group of people who have also served in the military.  There is no leaving anyone behind, or losing sight of the goal – and that is something that was proven time and time again as we struggled, came together, and overcame many of the challenges that we faced in those sixteen weeks.   

What advice would you give to people who want to get the most out of Code Platoon?

        The most important piece to getting the most out of Code Platoon actually needs to occur before ever stepping into the classroom: gaining a full understanding of what programs like these demand of you and arriving at the right mindset.  I can’t say that any of us can fully appreciate that until we are in the middle of it, but reflecting on and accepting the demands and stresses that this would place on my life certainly helped me when the pressure was on and everyone was starting to crack a bit.  This will be difficult.  This will demand more of you than any academic endeavor you’ve engaged in previously, and it will beat you into the ground if you’re not in 100%.

How has joining Code Platoon affected your life?

        It changed my perspective on learning and completely redefined what I now consider difficult or challenging.  From a confidence standpoint, I am fairly certain that – given enough time – I could learn just about anything, programming-related or not.

        I am currently finishing the second month of a six-month internship, and that is thanks to Rod’s efforts to get enough sponsor companies lined up for us.  So far, the support here has been outstanding, and I find myself at a company where people really  seem to enjoy their work.  You wouldn’t believe what a difference that makes every morning when I walk in!  

What do you want out of your career today?

I want the fulfillment of knowing that I am tackling and solving difficult and very different problems while working with a great group of people.  I know that my happiness is tied intrinsically to satisfying a high level of intellectual curiosity—so far the work that I am doing has delivered in spades.  

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