Tagged with Code Fellows

the gig is up

wocintech stock - 42

photo via #WOCinTech Chat

I landed my first coding gig!!

Long-time readers know that my job search started out with a bang back in November, marinated a bit over the winter holidays, and then resumed in full force these past few months.

Throughout it all, I had some heartbreaking near-misses and some real low points of thinking, “this will never happen for me.” My instructor helped connect me to a potential contract project that didn’t quite get off the ground but led me to develop a cool app anyway. I flirted with some near-coding opportunities like writing code school curriculum and Salesforce development before narrowing my criteria for what I’m looking for. I met other kind and well-meaning people who made a bunch of introductions, and followed those rabbit trails where they led.

And thanks to one of those introductions (which happened not as a result of going to meetups, though I did that too, but rather the practice of “find and follow cool people on Twitter” which I have been doing for YEARS), I met the team at ReadyPulse, a Bay Area/Redmond-based startup where I start Tuesday as a Ruby on Rails development engineer in test.

I’m so excited that I’ll get to continue to work in Rails, expand my knowledge of software testing, work closely with the client support team to understand and troubleshoot issues, and work with a small development team to ensure new features behave as expected with full test coverage. And at a market rate!! (Add to the heartbreaks: the company that wanted to pay me $35k a year to join them as a junior developer, and the company that rejected me from their job seeking site.)

As is not unusual in this biz, I’m starting out on contract for three months, with potential to convert to a salaried position (and possibly move from testing into feature development at that point) if we both agree it’s a good fit.

Some highlights from the interview process:

  • After being e-introduced, the VP of Engineering invited me to come to the office and after some chit-chat he had me do a whiteboard exercise where I built a simple Rails application. This was actually my first whiteboard experience outside of the Code Fellows practice environment, and it went really well. My interviewer was patient, supportive, helped when I got stuck, and didn’t ding me too badly for some minor syntax errors. After I got home, I built the actual app and sent him a link to a Pull Request so he could see 1) I know how to use GitHub and isolate my code changes in readable fashion and 2) that I paid attention to what we talked about and had the follow-through to create a functioning app.
  • He replied that the app looked good, and did I have any tests for it? So I added tests.
  • I did a second whiteboard exercise with the CTO that was similarly positive and even a little bit fun. At one point I was doing the talk/think out loud thing and I told him I couldn’t remember if Ruby hash supported the “shift” function and he was like, “oh, you can look it up on your phone if you want.” And I was like, “SERIOUSLY?” And he was like, “yeah, real programmers use Google. Go for it.”
  • When my interviewer was discussing the position with me, which involves writing tests and quality assurance for two versions of their software, I asked him “how’s your technical debt” LIKE A TOTAL BOSS and he was like “oh, good question,” and his response led me to a deeper understanding of the situation and excitement to take on the challenge. It is a giant milestone to know enough to ask good questions.

There’s still a lot of unknowns in the future, but I consider this a big step towards the career I want to build as a developer. I’m grateful to Code Fellows for my training, to my partner Josh for supporting our family during this transition, and to friends new and old who cheered for me along the way! I’m gonna keep building my network and do my best to help other new coders find opportunities to get into industry quickly — there’s no better way to keep learning than on the job.

I had one of these to celebrate and I invite you to join me!

Root beer float

Cheers!

a modest (code school) proposal

I posted awhile back that after two classes, I took a break from working as a Teaching Assistant with Code Fellows. Part of this was logistical: it’s hard to dedicate yourself to a job search while also working long hours to support students and instructors. The job opportunities I’d been hoping for didn’t materialize, so I decided to double down on my efforts.

The second part of leaving was emotional — It’s intense work. Two months seemed like a manageable amount of time to sustain that level of full-time effort. By the end, I was exhausted. I’d had a terrific first class working with my former instructor, and was excited to bring that experience with me to a second class with a new instructor and TA team. The last week of that class was particularly stressful when I clashed with just about everyone on their decision to throw out all the assignments done up to that point and heavily weigh “instructor gut feeling” and a hastily conceived and executed pen-and-paper “quiz” as grounds for student advancement, or not. In doing so, I watched in real-time as all the studies about gender bias in the classroom played out, and experienced the frustration of fighting back against it, all the while being treated to a lecture about how none of this was sexist, at all, the opposite in fact!

So I left that team. And since then, I’ve found myself distancing myself from Code Fellows and gravitating more to communities where inclusion and diversity are lived values. I’m also hitting month five of job searching, witnessing how other code schools have programs in place that help with the gap from code school -> industry, and feeling that Code Fellows is still for the most part sending us off with a pat on the back and a “go get ’em, tiger.”

But it doesn’t have to be this way! Code Fellows has a uniquely diverse and passionate student base and huge potential to be something great. As a friend and alumnus, I have some ideas. I will probably get labeled a “hater” for this, but it comes from a place of optimism.

Part 1: The Low Hanging Fruit

ApplePicker

Continue reading →

the plan, part 3

Oh hey, Happy Thanksgiving December! My last post was a cliffhanger that wound up more suspenseful than intended. And then December exploded and I’ve been busy with no time to blog. But I started down this path, so let’s dive back in. 🙂

Crater Lake

Andy Spearing, Crater Lake

Ok, so I was talking about my assumptions going into this year, and I left off at number 4:

  1. I can learn to code in a year — TRUE
  2. I will be job-seeking in a year — TRUE-ish
  3. I can tailor a program of free resources and paid classes for less money and time than the cost of graduate school — TRUE w/caveats
  4. As long as I can build software, the amount of math I’ll need to know is minimal
  5. An all-women learning environment is preferable to co-ed (but not a deal-breaker).
  6. MOOCs will be a great tech resource for learning computer science
  7. Meet-ups will be a great way to network, make connections, and find job leads

Continue reading →

the plan, part 2

Hey, you got a few minutes? Ok, let’s talk about The Plan.

In January, I quit my job to pursue a path in software development. I didn’t really know then that it was called “software development.” I’m still not particularly married to that job title or role, strictly speaking, but a lot of other roles stem from that one so it’s not a bad place to start.

(I am married to Josh, though! I wasn’t when I started. Pretty cool, huh?)

But be ye more educated than I:

credit Brandon Hays 2015 RubyConf talk, full slides here

Knowing very little about the tech industry, I made several key assumptions going into this journey.  In this post I’ll detail how these assumptions have panned out (and in a follow-up post I’ll talk about where things go from here).

Assumptions:

  1. I can learn to code in a year
  2. I will be job-seeking in a year
  3. I can tailor a program of free resources and paid classes for less money and time than the cost of graduate school
  4. As long as I can build software, the amount of math I’ll need to know is minimal
  5. An all-women learning environment is preferable to co-ed (but not a deal-breaker).
  6. MOOCs will be a great tech resource for learning computer science
  7. Meet-ups will be a great way to network, make connections, and find job leads

Continue reading →

try angular

this is what angular feels like, a bit

In the last two weeks of my Code Fellows Ruby on Rails bootcamp, we’re focusing on JavaScript, JQuery, and all their friends. This week we kick off with Angular. Angular is a JavaScript tool created by Google for fast, responsive websites. I completed the (free) Code School course “Shaping Up With Angular” and I’m about to embark on a quest to connect it to a persistent database. In my case it will be a Ruby on Rails app.

But first, let’s talk Angular!

MODULE

When you create a JavaScript file to hold some Angular, you initialize it like so:

var app = angular.module('gemStore', ['store-products']);

if you’re not well-versed in JavaScript, this is essentially saying: Declare a variable “app” and set it equal to an Angular module named “gemStore” that depends on another module named “store-products.” Once you’ve declared at least one module, you can get going filling it up with useful stuff like…

CONTROLLERS & DIRECTIVES

Controllers work similar to how they work in Rails. You can set up and assign a controller to a specific part of your webpage, and it can render and manipulate data in a variety of ways. In the tutorial, we set up controllers to manage information about the gems, the product tabs, product reviews, etc. If your code is getting repetitive and/or you want to isolate specific chunks of the page, you can create directives instead that will load a separate html page using naming-conventions (much like how Rails renders partials). Depending on what you’re trying to do, you may be able to include controller functions in a new directive and eliminate the need for a separate controller altogether. Neat!

SCOPE

Angular controllers are called on specific DOM elements , and operate within the scope of that element only. So for example, here’s some pseudocode:

<section id=gems ng-controller="gemController">
  <unordered list of gems>
    <gem 1>
    <gem 2>
    <gem 3>
  <end of list>
<end of section>

Outside this lovely, contained section, if you want information about gems you are entirely out of luck. Note how any of the list objects know about gems (and any child elements we might create under them, if we so choose)–basically anything that’s in the gem section family.

But not outside that family. They know about other stuff, maybe. Like maybe they know about…

DATA BINDING

If you’ve ever typed on a website and had text show up magically elsewhere, tracking as you type, that’s a two-way data-binding and Angular is a pro at it. Here, why don’t you go make some boxes to see how it works? Hmmmm… boxes. That’s not very try angular. Get it, triangular? I feel like this demo could be improved… perhaps a project for a rainy day…

DEPENDENCY INJECTION

Wow, that one sounds pretty grim, right? Coffee is my dependency injection these days. But we already saw this above — you remember in that top example how my app.js had an array of one element — it looked like this:

angular.module('gemStore', ['store-products']);

The app can’t run without the file where I’ve created a module named ‘store-products’, so injecting the dependency here tells my app where to look to import that info. Once it knows how to read ‘store-products’, it inherits any and all controllers and directives in that dependency JavaScript file, and the app can load as usual. Quickly, we hope!

Ok, off I go to attach this gemstore to a database… wish me luck and above-average retention as we dive into the last week of instruction (#justkeepswimming).