The Question

In addition to all of my blog posts about personal finance, I thought it might be interesting and valuable to start a more technical series of posts geared toward those of my readers who are software developers. I’m going to kick this concept off by answering a question I got in an actual technical interview: given an array of letters in the alphabet, which can appear multiple times, return a hash of letter counts sorted alphabetically. For example, the following array:

There are several reasons I decided to start here: first, I failed the interview, possibly because it was my first time coding on a whiteboard and coding on a whiteboard is, well, terrible—ask any developer, they’ll tell you. Second, this interview question could theoretically pop up for my more-technical readers, so this could be a good resource for them. Third, I wound up using a solution to this problem in a real web application several times at my job at Radial Development Group (AFTER the interview, of course), which means it is, at the very least, a practical question.

The question was given at a fintech/payment processing company, which, as you may guess, means that they work in the Java programming language. Possibly because they were aware I’m unfamiliar with Java, they told me I could write the answer in any language I want (I chose my first and favorite language, Ruby). They also told me that their stack uses JavaScript (which has nothing to do with Java, non-coders) pretty frequently.

So I decided to answer the question in all three languages for this blog post. Let’s start with Ruby.

My Answer in Ruby

First and foremost, I defined a sample array that we’re going to be manipulating:

Pretty simple, right? lettersarray[0] will return ‘s’, lettersarray[1] returns ‘a’, and so on. Ruby lets you use single or double quotes interchangeably (‘‘ vs ““), so this array could just as easily have single quotes around each character. The only significant difference is that double quotes allow string interpolation. It’s an urban legend that single quotes are more performant in Ruby.

I have some duplicates to make sure that my compiler actually counts, so the key ‘h’ returns 3, not 1.

Now we need to define a Ruby method that accepts the array, generates a hash, sorts it, then returns the sorted hash (line numbers added for reference):

Line 1 defines a Ruby method, which I named count_and_sort_letters. It accepts an argument, array, which we’ll be manipulating throughout the rest of the method. The method is closed on line 11 with end.

Line 2 defines an empty hash, letter_counts. I could inline this into line 3 by passing each_with_object an empty hash rather than letter_counts, but I only wanted to sort_by once, since sort operations are generally expensive. Therefore, I needed the variable declared outside of the each block.

Line 3 begins the Ruby each_with_object block. It accepts an enumerable as an argument (an array or a hash, generally, and in this case my empty object, letter_counts). It then passes two arguments into the block: the current element in the enumerable (whichever letter we’re on in letter_counts), and the object we passed in.

We don’t want to return values of 0 in the hash; that is, ”p” => 0 should not be returned. So on line 4 I check whether letter_counts[letter] is truthy or not (in other words, it checks whether that key has already been given a value, because nil is falsey). This means the first iteration is checking whether letter_counts[“s”] exists or not, and returns false. On the fourth iteration, however, letter_counts[“b”] DOES exist, so it executes line 5, incrementing letter_counts[“b”] by 1.

In the instance that the key isn’t already assigned in the letter_counts hash, the else statement beginning on line 6 is executed, creating that key with a value of 1 in the hash. So in the first iteration, letter_counts[“p”] gets the value 1.

After the each_with_object loop finished, I call sort_by on the hash on line 10. I pass it a one-line block (in Ruby, { } is the one-liner equivalent to do … end). It accepts the key and value of each element in the hash, k and v, and is told to sort using k rather than v (the letter, not the count). Since Ruby’s sort_by returns an array, I then call to_h to convert it back to a hash instead. Ruby methods return their last line unless you tell them to do otherwise, so I don’t need a return statement here.

Ruby acts like Ruby a lot in this example: it returns more or less what you want and doesn’t throw a lot of errors without much effort on my part, but it then needs to be told to sort properly and return a hash.

Like many Ruby developers, I sometimes forget where Ruby ends and Rails begins; I tried calling .present? on letter_counts[letter] and kept getting an error, before finally remembering that .present? is from ActiveSupport in Rails, not Ruby. My if statement works fine without it in this instance, but it wouldn’t act quite so gracefully if you pass in nil in an effort to trip it up.

My Answer in JavaScript

In my experience writing JavaScript in an actual app, developers tend to use libraries like Lodash to get many of the helpful functions other languages take for granted (simple sorting and type checking functionality, for example). For my JavaScript example, I didn’t do this, but I did use ES6 syntax to make for slightly simpler reading.

I set a constant, countedAndSortedLetters, to the value returned by a function on line 1. I pass in array as an argument again, and declare an empty object, unsortedCounts, on line 2. Line 1’s const countedAndSortedLetters = (array) => { syntax looks funky, but is just a slightly-shorter syntax than const countedAndSortedLetters = function(array) { in this case. At Radial, we frequently work with React, meaning arrow functions’ lexical binding of the this keyword makes our code easier to read and understand—we don’t need the const keyword inside our React classes, and we don’t need to call .bind(this) all the time.

I would normally use _.forEach or something similar because it tends to handle a lot of errors and JavaScript gotchas gracefully, but instead used JavaScript’s built-in forEach to iterate through the passed-in array on line 3.

I personally like using JavaScript’s bracket notation over dot notation for objects because 1. it reminds me of Ruby hashes, and 2. it makes it slightly clear that you’re referencing a value on an object, not calling a function (so I’m not hunting for the () at the end of the function name). Lines 4-7 are more or less the same logic as in Ruby: if the key has a value, increment it by 1; otherwise, set it to 1.

JavaScript doesn’t have a great way to sort, or even map, objects (again, Lodash or a similar library is usually very handy here), so instead I define sortedCounts on line 10 as an empty object.

I then get the keys from unsortedCounts as an array, sort() them, and forEach() one more time on line 11. This is a place where ES6 syntax really shines, by the way; .forEach((key) => {}) is very clear syntactically about what it is you’re doing.

Line 12 iterates over the sorted keys and sets that key’s value in sortedCounts.

Line 14 tells the overall arrow function to return sortedCounts, which then assigns that value to our countedAndSortedLetters const.

Some notes:

I was really feeling the struggle of JavaScript without any helper libraries. node_modules is a monster, but it’s also very helpful.

I’ve never liked JavaScript’s syntax for prototype functions, like Object.keys. It feels counterintuitive when I’m writing the code to pass a function on Object an instance of itself.

It’s more obvious here than in the Ruby example that I’m looping twice—as such, it’s probably also less performant than Ruby’s sort_by, if I had to guess. I may consider revising these to see if I can only loop through once to make a more-performant solution.

My Answer in Java

I used repl.it’s online Java compiler for this, which had me name the file (and therefore the class) Main in this example.

I import HashMap on line 1. It’s a Java utility, but throws an error when not imported, so I figure it counts as being part of Java’s main implementation. It gives me the hash structure I’ve been using previously.

Java throws an error if your class isn’t named what your file is named, so line 3 is a class called Main. I think I’ll just let Java be Java here and move on (Repl is great, but it also didn’t seem interested in letting me rename the only file).

public static void main(String []args){ on line 4 is, as far as I can tell from Oracle’s documentation, pretty standard boilerplate for declaring a new class. public means other classes can call this one; static is sort of like self in Ruby in that it’s saying it’s defining a class method, not an instance method for that class; void clarifies that this method does not return a value; and main is the method name, so we’re defining Main.main. (String []args) means that one can pass several strings into the method when called. Interestingly, Main.main throws an error if it returns anything, so this seems to essentially be a good place to call other methods, not a good place to define the main thing we plan to do.

Line 5 defines letterArray, as I’ve been doing. String[] means I’m defining an array of strings, not just one string. I found it confusing that arrays have curly braces {} around them coming from Ruby and JavaScript.

Line 6 calls a method called letterCounter with my letterArray argument.

Line 9 defines the letterCounter private method. private here appears to achieve the same results as defining methods below the private keyword in Ruby. It’s a class method, doesn’t return anything (returns void), is called letterCounter, and accepts an array of strings called letterArray.

Line 10 continues the trend of declaring everything in Java. In order to make a hash named letterCounts, I need to say that I’m making a HashMap with String keys and Integer values, and call new HashMap() to make it an empty HashMap instance.

I used a for loop on line 12, mostly because it was obvious when reading the documentation about it that JavaScript must have pulled this syntax straight from Java. Nice to have one familiar part, at least. As Java and JavaScript devs will doubtlessly know, the syntax here is defining an integer, which is incremented every time you loop through the array until it becomes equal to the array’s size. This is one convenience of having arrays start at index 0 rather than 1, you can say < array.length rather than <= array.length.

Line 13 was initially String letter = String.valueOf(letterArray[i]) because I had an array of chars rather than Strings which Java refuses to convert into strings unless I specifically tell it to.

Lines 14 through 18, again, are pretty much the same logic I’ve used before: to update the letterCounts value at i dependent upon whether it already has a value or not. It was interesting (not good or bad, just odd to my eyes) that Java’s HashMaps use .put and .get to set and get values. My brain immediately connected it to the HTTP verbs PUT and GET, which are similar but not the same.

Line 20 outputs the resultant letterCounts hash.

Some notes:

Java is very, very strict from my perspective, even stricter than JavaScript, which already feels strict to me coming from Ruby. If you don’t tell it exactly what you mean, it will fail, hard.

Errors in Java are wonderfully explicit, even to someone as new to the language as I am. In spite of being unfamiliar with the syntax, I was rarely confused about why my code failed. Even when the error thrown confused me (I’d try returning something the method didn’t expect me to return, for example), Java is like Ruby and JavaScript in that it has good documentation from both the maintainers (Oracle, in this case) and the community (a word which here means “Stack Overflow”).

There’s a lot of boilerplate in Java. I’m pretty spoiled by Ruby.

Java is the only language of the three that gave me exactly what it was I wanted once I played by its rules: the values are sorted all on their own, meaning I didn’t need to loop through the code again, meaning this is probably the most performant of the three letter-sorting methods.

Java feels like Ruby’s father who isn’t on speaking terms with Ruby but is mostly cordial at Thanksgiving. It also feels like JavaScript’s estranged stepfather from JavaScript’s mom’s third marriage. I noticed several object-oriented patterns I’m familiar with (and like) from Ruby, but also some syntactical choices that I presume JavaScript went with because it was how Java did it.

Well, this turned out to be a lot more work than I set out to do. But I hope this was informative for how to pull in a bunch of random, unsorted data, put it in a hash, sort it, and pass it along to the next part of your app—I’ve found this very helpful in Rails apps when pushing information over to a Webpack/JavaScript front end.

What improvements would you make to my implementations? Let me know in the comments!

Starting From Little: Stop Blindly Chasing Dreams

Two months ago, I posted about some of the most reliably-lucrative careers you can pursue in the United States, those that can reliably offer six-figure salaries. Predictably, the results were mostly jobs that require expensive college degrees (which is to say, at least a Bachelor’s Degree).

That’s all well and good for folks who are either wealthy, talented enough to get great scholarships, or who are so determined to pursue those fields that they don’t mind the enormous pile of student loan debt they’ll need to accrue to pursue them. But the thing is, a lot of us aren’t in one of those positions. A lot of us aren’t sure what we want to do. Mainly, we were told to “do whatever we want,” because this is America and you can, supposedly. This tends to lead people to “follow their dreams,” or what they think are maybe their dreams, except that they aren’t that confident that being artistic is really their dream because their heart isn’t quite in it enough to be practicing their art all the time, which is how frequently you need to practice your art these days if you want to stand out.

Some folks work on the art anyway, and persist, and deal with the downsides of pursuing artistic careers, and are probably fulfilled in that. Most folks don’t, because in the end they realize it’s not their dream and they have to prioritize paying their bills over pursuing dreams, at least until they’re financially comfortable.

Now don’t get me wrong, dreams are great. By all means pursue them. But chasing a dream, which might not even be the right dream through poverty or tens of thousands of dollars of student loan debt, is almost certainly foolishness. Don’t let anyone older than you tell you otherwise; they paid a lot less for college, rent, and a car than you’re going to.

Here’s a better plan: go make good money and also pursue a dream. After that, don’t ditch the day job until the dream job is reliably paying more. Exceptions can be made for folks with high-income spouses or generous parents, maybe, but you should take cost of living seriously in making these decisions, which is not usually part of the “chase your dreams” career advice discussion.

Furthermore, there’s another component to the equation we haven’t discussed: you have a certain cost of living right now, but that might not be the lifestyle you want to live. Do you want to drive a Porsche? If so, you should probably get a job that pays better than working at Target. Do you want to live in San Francisco? If so, I wouldn’t pursue a career at a restaurant.

The more you want to do this, the more money you should be planning to make first.

All that is well and good, you may say, but there’s a disconnect: all the high-paying jobs require degrees!

Not so. I decided to do some research on the subject, and while I found that a Bachelor’s Degree or higher tends to lead to more lucrative career paths, there are several jobs that you can do without an expensive, time-consuming, four-year degree that also happen to pay pretty well.

So how do you get started? Take the dream job visions out. Assume you can’t afford to continue to live at your current income level, meaning you can’t do four years of college to get this job. Assume the number one goal is to start bringing home a reasonable paycheck you can live on (which, if you don’t have one yet, should definitely be your goal right now). What can you do as a U.S. citizen in 2019?

I’ve compiled a list of answers to that question.

High School Diploma (or Equivalent) Opportunities

Sell Phones, Cars, and TV

Everyone loves to hate on salespeople. Car salespeople are criticized the most, with the folks selling smartphones, TV and internet, and insurance not far behind. And to be sure, salespeople can be frustrating and obnoxious. But the fact is, it’s not selling in general that bothers us, it’s feeling like we’re being sold to. We don’t get this feeling from a good salesperson, or good advertising. We typically get it when a salesperson doesn’t believe the words they’re saying to sell to us, which is pretty common on sales floors.

You might be surprised how much money you can make in sales (just don’t put it in a drug money briefcase like some guy did to make this stock photo).

But here’s the deal: if you can find a product or service you can get behind and vouch for yourself, most of the struggle of selling is taken away, and the pay can be pretty respectable. At T-Mobile I was paid roughly $55,000/year to sell smartphones, depending on commission. My former manager went to work at a Nissan dealership selling Leafs and makes over $70,000/year. Comcast/Xfinity/whatever they want to call themselves are making retail outlets now to sell both their wireless service and their cable and internet packages, and a friend of mine works at one making similar income. No degree necessary, no certification necessary.

Of course, the big thing to be aware of with these positions is that your mileage will definitely vary. The T-Mobile I worked at was a popular store, meaning there were lots of customers, meaning there was lots of commission to be made. The Sprint across the road was a ghost town, which I’m sure would be great if you want a job you can coast through, but it won’t help your commission check out next month.

Similarly, trying to sell unpopular car models will be a non-starter (heh). There will be a bit of fluctuation in your income at any of these jobs because they’re at least partly commission-based, but the phone stores, at least, pay a base wage so you’re always making something. If you can stick with it, though, you can eventually build up a base of repeat customers who you can work with over and over to make things easier.

Mostly, a good strategy here is to do your homework, but it’s certainly a better place to head to in retail than at a Target or a Walmart.

Work With Your Hands, Learn on the Job

There’s also a general distaste for blue collar jobs, even though it’s probably a great choice for a lot of people to work with their hands or work outside. If the idea of staring at a computer screen in an office all day is your worst nightmare, consider looking into a trade job. There are lots of opportunities for welders, plumbers, oil field workers, elevator repairpeople, nuclear reactor and power plant operators, transportation inspectors, subway and street car operators, electrical-power line installers, petroleum-pump-system operators, gas-plant operators, and boilermakers out there.

Also, you might actually look this cool one time.

All of these jobs pay $50,000-$70,000/year on average, and as long as you have a high school diploma you’re qualified to start in the trade because they train you on the job. You’ll presumably start below the average, but I’ve met plumbers and welders who make six-figure salaries in their trade. Consider looking into what opportunities are in your area and check them out.

Protect the People

A friend and reader wrote in to add another option to this list, which is typically missed by articles about high-paying jobs that don’t require a Bachelor’s Degree. There are several law enforcement jobs, such as police positions and dispatchers, which typically pay about $60,000/year, train employees on the job, and require neither a degree nor a previous certification. Plus, you will be doing a job that is unquestionably important and helpful to people, which is its own reward, especially if you have ever experienced the nearly-useless drudgery of working at many fast-food restaurants and big-box retail stores.

There are some minor caveats to being a police dispatcher—one major one is that you’ll be working some long hours (my friend said she works twelve-hour workdays pretty frequently). However, when I asked if she was expected to work graveyard shifts, she clarified that you are typically either a day shift employee or a night shift employee, not both, so she never has to work nights. That beats the inconsistency found at most entry-level jobs, let me tell ya, on top of that part where they pay about three or four times more.

High School Diploma + Certification Opportunities

Develop Software

I can tell you from personal experience that software developers are paid pretty well. I personally make $65,000/year and, at least in the Northern Colorado area, that’s considered below the overall industry average.

I don’t even see the code. I just see the head, the body, some gross PHP…

This link, which is mostly accurate and inspired several sections of this article, claims you’ll need an associate’s degree and will be paid $62,000/year for web development. In my experience, neither of these things are true. Now, to be fair, the company I work for, Radial Development Group, does both web and native app development (and the “app” part is probably worth noting—web apps and websites are very different things). But all the same, it is not unheard of to get a starting salary of $60-70k as a junior software developer, and I learned to code through an online coding bootcamp, not through a traditional college.

Operate a Plane or Boat

My former T-Mobile coworker was working on getting his pilot’s license the whole time I worked with him. As this site points out, commercial pilots need a certification, but not a degree, and are often paid around $73,000/year. Business Insider points out that you can earn similar income with similar qualifications as a captain, mate, or pilot of a water vessel (like tugboats and ferryboats).

It’s sure to be a more stressful task, but if you’re good at keeping your cool and staying focused, being an air traffic controller can net you up to $122,000/year, no degree necessary.

One important thing to consider here, as with some of the other jobs I have mentioned, is that you should consider how this job fits your lifestyle. Real estate agents are typically paid based on how many houses they sell, similar to how car and phone salesmen are paid. Busy months will mean a lot of money; slow months will mean you better have something saved up, or have additional income in the household to cushion the blow. If your income is one of two incomes, the fluctuations in commission-based jobs are likely to be easier to swallow than if you rely too heavily on the busy months to make it through.

Similarly, understanding how you will be paid can mitigate this. If you are always paid something in a sales job no matter how well you sell, that stability may be of greater value to you than a job that technically pays more, but fluctuates dramatically throughout the year.

Associate’s Degree Opportunities

Help People Stay Healthy

In my previous post, I discussed some of the healthcare jobs on the market that pay extremely well and require extensive schooling—surgeons, of course, are the absolute top of their field in pay (not to mention prestige).

But if you don’t have $100k or so to blow on schooling, you can also get a respectable salary as a radiation therapist, dental hygienist, or nuclear medicine technologist—right around $70,000/year. You’ll need an Associate’s Degree for these positions, but that’s a tiny fraction of the cost of a doctorate.

Takeaways

Some of these jobs, of course, are not going to be available in everyone’s area—it can be hard to get into a new industry, even one that allows for remote work like software development, when you don’t live near where the action happens.

Additionally, many of these jobs are labor-intensive or are traditionally gendered, which limits their ability to help everyone looking for a higher-paying career. Some are not for the faint of heart—air traffic controllers seem to reliably crop up at the head of the pack of high-paying jobs that don’t require a degree, but I’ve also heard it’s a tremendously stressful job.

Lastly, some of these jobs can pay well, but don’t necessarily pay well on a reliable basis because they rely heavily on commission or seasonal work.

Saving takes time, so don’t waste time at a job that will never pay you a living wage.

However, I feel there’s a good amount of variety here, enough that you can probably find something in this list that can help you get on your financial feet, even if it doesn’t quite make for a dream job. If you’re in a tough spot financially and you’re trying to land a dream job, it’s at least a better interim strategy than working at a fast food joint that will pay you as little as they legally can. All of these careers have the potential to put you in a much better position to save some money for a car, a house, retirement, or any other big expenses you see in your future, and if it turns out you like one of these careers better than that dream job you had in mind, there’s nothing stopping you from sticking with it.

Are there any other worthwhile career fields you know of that don’t require a four-year degree that you’d like to see mentioned here? Let me know in the comments!

Coming from a background of retail and food service jobs, Radial Development Group’s hiring process was strange to me. I first reached out to Radial while I was partway through my software development bootcamp curriculum with Bloc. Part of Bloc’s selling point was that they would not only teach you to code in high-demand programming languages like Ruby and JavaScript, but that they would also help you enter the job market. As such, they encouraged me to reach out to people in the development community near me, apply for jobs, and start working to get my foot in the door.

At the time, I did not hear back from Radial, possibly because they wouldn’t have had a clue who I was, and possibly because I’m pretty sure the company’s management structure was changing significantly around that time and there’s a good chance my resume was lost in the shuffle. Regardless, I got no response.

But the opportunity seemed too good to pass up. Radial wrote web applications in the same programming languages I was learning, so I felt I would be able to offer them relatively good value as junior developers go. Plus, they were located in Loveland, Colorado, which was a perfect geographic fit for me.

So I applied again when I was closer to the end of Bloc’s curriculum, sending a resume to the owner, co-founder, and manager of the company, Ben West. This time, I got a reply, and we met up and discussed how the company operated and if they were currently hiring.

(A quick note for anyone who really wants a specific job and didn’t get it the first time: apply again. I did this at Simply Mac, T-Mobile, and Radial, and there’s something about the second application that seems to show employers you’re worth taking a chance on, even if your resume doesn’t quite check all of the boxes.)

I got a strange answer about the company’s hiring status. There was a direct “No,” they were not hiring, but also an upfront statement of how much I would be paid in such a position and an offer to let me code at the Radial offices while I continued working through Bloc. I expressed interest in the position and that was the end of it.

I figured I might hear back if an opening came up, but for the time being, I kept searching. I went to a Boulder Ruby Group Meetup where Kate Catlin, founder of Find My Flock, was looking for support in contributing to an open-source project, Women Rising. Bloc’s curriculum asked for me to make ten open-source project contributions, so I jumped on the opportunity to contribute to a Rails project that had been started in Colorado.

As it happened, Ben was a friend of Kate’s, so I wound up chatting with him again over Slack. Now look, I’m not a destiny/fate/“it was meant to be and the stars aligned” type of guy, but it seemed like Ben and Radial kept cropping up everywhere I went. Kate told me at the Meetup how great Radial had been in supporting Women Rising, and that told me that it was really worth pushing harder to land a job there.

Long story short, I wound up working on Women Rising at the Radial offices—there was some strange issue where the form for one model needed to accept data for another model, and it was not really set up to do so. The solution involved an `accepts_nested_attributes_for` or two, at least one `f.collection_select`, and a lot of confusion on my part.

In short, I learned pretty quickly by pairing on the project with Rebecca Klein and Ben that my experience at Bloc was little more than a taste of what it was like to work on a live codebase with real users. Fortunately though, the Radial team was patient with me, supportive of my efforts, and open to my likely-stupid questions.

I ultimately delivered the contribution in the form of a sizable PR, which my Bloc mentor graciously counted as several open-source contributions rather than one. But more important than contributing to the code, truthfully, was the fact that it had given me the opportunity to work with the Radial team. I had met with Ben several Thursday mornings at a local coffeeshop, Dark Heart, and we had shared a lot of background about ourselves. We had both worked a lot of jobs full of thankless work and nearly-thankless pay; we were both critical of the gig economy as an underhanded way to get out of actually taking care of employees; and we both faced immense struggle with student loan debt that made the process of entering adulthood feel like it was a race run with ankle weights.

While I certainly know Ben and the Radial team much better now than I did then, these things all gave me examples of the Radial company culture. When Ben eventually offered me a job interview, I had a sneaking suspicion that the decision was more or less made before the interview began—if he didn’t like me working at Radial, I suspect he would have told me to leave before he started paying me.

Bloc had warned me about the possibility of technical interviews in the hiring process, where I would need to write a FizzBuzz function on a whiteboard or some such thing. Fortunately, my interview at Radial contained nothing of the sort, possibly because Ben himself was a developer and knew that FizzBuzz is worthless as a measuring stick of a software developer. I had only vaguely begun to understand this at the time, but now I can see with some certainty that every software project is specialized. Every project has particular needs that led to particular choices in the codebase that make it complex in a unique way, and no amount of industry experience can prepare you for it completely.

Instead, I got the sense that Ben wanted to know how I would lead a project, how I operated as an employee, and what I would do when handed hundreds of problems with no clear solution (incidentally, I think a lot of companies of all sorts could learn from this strategy). As I would later learn, the job I was hired for, Developer Lead, was not clearly structured; the projects I would work on had processes for development and deployment, but only in a vague sense that didn’t encapsulate their specific needs; and in general, the downside of the freedom and authority that comes from working at a small company is that there aren’t really any concrete guidelines for a lot of things. Ultimately, the job I was being offered was one that I would be making up myself.

The interview is now something of a blur to me. I always feel a lot of pressure in job interviews, no matter what the manager interviewing me does, and so I tend to forget what happened in them when they’re over. But I attempted to allude to the main thing I had learned from the dozen or so jobs I had held prior to working at Radial: school teaches kids to work exactly the opposite way from how the workforce works. In school, you are given tests, and the goal of a test is to avoid being wrong.

In work, there’s typically no way to study in advance, so the goal is not to avoid being wrong, but instead to be wrong now, to fail fast. Then you can figure out why you’re wrong and go solve the problem before it becomes your client’s problem. Super Target didn’t show cashiers any documentation on how to add a transaction to a gift registry or process a tax exemption; Old Chicago didn’t tell dough cooks they should mix their artisan dough first so it can proof while the cook is sheeting the cornmeal dough; Simply Mac’s training courses didn’t teach me how to check for liquid damage in an iPhone; and even two weeks of training at T-Mobile didn’t cover how to process Early Termination Fee reimbursements as opposed to Equipment Installment Plan Reimbursements. But I learned all of those things by asking questions and being wrong as soon as possible.

I think this is ultimately what landed me the job, whether Ben knew it before I said any of it or not, and I will always be tremendously grateful that Radial was willing to give me my first job as a software developer because of it.

As you may have seen in my Christmas letter, I am officially a Software Developer at Radial Development Group (or O'Radial, if you prefer)! I was super excited to accept the offer and have been working there since December in conjunction with my job at T-Mobile.

I will still continue to blog here occasionally, but I have also started blogging for Radial about my work there. My first post is about uploading CSV files through an asynchronous worker in a Ruby on Rails project. It's likely to be better than my usual writing because blogging at Radial means I actually have an editor to cut up my lengthy sentences and off-topic commentary. It's also pretty exciting for me because it means I'm being paid to write, which is kind of a dream I've had for a while.

In other words, you should go check it out here. Thanks to Stephanie and Ben for the help on this one!

Bloc was kind enough to do an interview with me recently about why I chose to learn how to code and why I chose them in particular (versus a traditional college degree or a different bootcamp). The interview can be found here. I already said what I needed to say there about my choice to study software development at Bloc, but I thought I would go into a little extra detail here about why this was, and is, a struggle for me. My responses to the interview were accurate, but I think I sounded more like I have life figured out in the interview than I really do.

Easily the most stressful element of choosing this path is financial. I don't want to make a career choice based solely on how much money I make, but one of the reasons I wanted to get into software development was that I knew it would teach me a more specialized skill, and more specialized skills generally result in higher pay, which is useful when you have a ton of student loan debt (like me). It probably doesn't help that our capitalist society has a strange, contradictory habit of looking down on people who want to make more money. Wanting more income is not greedy, in my opinion, at least not when you're trying to get out of debt and move up to a reasonable wage in the United States (which appears to be right around the $75,000/year mark, since that's when studies say there's no longer a correlation between income and happiness). Sure, there are hedge fund managers who make so much money that they could not spend it all if they tried, so giving those guys a raise does nothing to improve their quality of life and is therefore a waste of money. But most folks just want it to be easier to pay the bills without having to pinch every penny they get, and it's therefore nothing to be ashamed of to want a raise.

The second-most stressful element of going into software is that even over a year into it, I still feel extremely new to it. This is obvious in some ways–of course I'm new, it's a field that many people study for decades and still have lots to learn! But I honestly can't say that I had tried to learn a new skill in the eight intervening years between when I started learning to code at 24 and when I started learning to play guitar at 16. I was accustomed to being pretty satisfied with my writing ability, even though that too could doubtlessly use some improvement. It makes me second-guess my decision, though. Should I go back to a field I'm more comfortable in? Or should I stick to this one?

The last stressful element of it is that I overthink everything. And by everything, I mean everything. I overthink writing this blog post, I overthink code, I overthink talking to people. I don't really know how to fix that, but it's been a constant issue with trying to plan my future out (which really never works as planned anyway).

As I've been writing this article, I got a tentative, I think, offer to work at Radial Development Group, and that cheers me up immensely. But I guess planning for the future often stresses me out as much as it can excite me.

I have been hard at work completing the third of the four units in Bloc’s Software Engineering Track. This one, Software Engineering Principles, felt as though Bloc was taking the training wheels off. Generally, the first two units (Back End and Front End Development) had the implicit expectation that I get my code to work, but that it did not necessarily need to be pretty. As long as the Rspec tests passed or, in some instances, the web app I had built did nothing more than not crash, my work was approved.

In this section, the bar was much higher. From a purely technical perspective, the coursework was far more challenging, as it required me to build a Ruby object-relational map and a back end web framework using Rack. But on top of that, my mentor’s expectations in terms of the quality of my work were much higher. It was not enough to just make it work; my code also had to be more flexible and reusable, more efficiently structured.

It was an immense challenge for me, a year into my journey to learn to code. But now, BlocRecord and BlocWorks–the ORM and Ruby framework I built–are complete and approved. A developer could pull them off GitHub and build a back-end web application using them, in fact, complete with model-view-controller architecture, database management, and a search engine operation I built in myself. Be sure to check them out.

And now, on to the final section of the course: the open-source apprenticeship.

In previous posts, I’ve attempted to make convoluted coding problems understandable to most people. This is because in general, I want my blog to be mostly-readable to most English-reading people, which means I tried to speak generally about learning new skills and changing career paths. But at the end of the day, I am studying software engineering, and not everyone has a background in that, so to talk about it, I'll have to get into the weeds a little bit once in a while. This is one of those times.

Bloc’s Software Engineering Track starts you off slow. It assumes that you have no coding experience other than some of the prep work the course has you do before you really start working through their curriculum, so you start with the fundamental concepts of coding. The first unit of the course, Ruby on Rails Back End development, was therefore focused on the basics. What’s a variable? What are strings, integers, booleans, loops, arrays, and hashes? How does model-view-controller (MVC) test-driven development work? What in the world is Rspec? What is Ruby, and what is Rails?

What I looked like pretty much every day when I started my coursework at Bloc (I have fewer laptop stickers, though).

The Front End section focused on front end web development. Since all modern web browsers support JavaScript code out of the box, this meant I was learning JavaScript and some of the frameworks and libraries associated with it. There are dozens of these, like the super-popular jQuery library and AngularJS framework that I used to build Bloc Jams. There are more recent and obscure frameworks, like Meteor, which I have so far used to build the foundations of my personal project, Moneytracker. And there are many technologies that I have not yet been exposed to, like React or Express.

Because it’s so ubiquitous, JavaScript has a gigantic community. In fact, it’s the most popular language on GitHub (more than double the popularity of Java, the runner-up, which is closely followed by Python and Ruby, according to GitHub's 2016 statistics). So it was great learning about such an essential language in the programming world for this section.

The tricky thing for me was readjusting from JavaScript back to Ruby for the third unit, Software Engineering Principles, because Bloc’s course uses Ruby and some inspiration from Rails to teach me about algorithms and complexity, object-relation maps (ORM’s), and framework architecture.

The foundations of BlocWorks.

I am now nearing the end of the third unit. It does not have any big personal projects at the end for me to show off like the first two units, but it is significantly harder coding, and in the end I wind up with a functional (if somewhat basic) Ruby framework and ORM that could theoretically replace Rails and ActiveRecord. I noticed today, while struggling through a framework architecture assignment question (“Support instance variables in your framework that can be called in a controller method and accessed by its respective view”) that in order to even solve that problem, I had to know how to do a bunch of little things that would have stumped me all on their own a year ago.

To develop BlocWorks (the Rails-like Ruby framework I am working on), Bloc has me not only building the framework, but also integrating the ORM I built earlier, BlocRecord, and building a web app that utilizes the two, BlocBooks (which will allow users to make their own personal “libraries” full of books they can track, a bit like a simpler version of Goodreads). So to attack this assignment question, I had to:

build some Ruby controllers and Embedded Ruby views (files ending in .html.erb, which are basically HTML files that can compile Ruby code rather than JavaScript) for BlocBooks, passing some instance variables to them (like `@book`),

make sure the controllers rendered the views in question by inheriting a `render` method from BlocWorks’ `Controller` class, which I tested using (Rack-test), and

finally get to the part where I solve the problem, which I did by looping through all of the instance variables available to the controller method, and using the Ruby `instance_variable_get(instance_variable)` method to pull the values of each variable. In other words, once everything was set up properly, my solution was a modified `render` method for the BlocWorks controller:

To someone who has been coding in Ruby for years, all of that may sound somewhat unremarkable for them to accomplish. Customizing a framework (or not even using a framework) is not all that out of the ordinary, even if building a framework from scratch might be.

But for me, partway through solving this assignment problem I was reminded, quite vividly, that I had come so, so far since starting with Bloc. A year ago today, I could not have even told you what a view or a controller was, let alone written a functioning one. And that was just a very small part of the problems I’m solving now.

I don’t say this with the intention of bragging–far from it. I still struggle with new coding concepts on a pretty regular basis at Bloc. But I am now at a point where I feel confident that I can find the answer if I don’t know it offhand, and I can say with some confidence that I can code in Ruby. Not bad for one year of bootcamping!

There is still a lot for me to learn, to be sure; there are plenty of coding concepts I don’t quite grasp, and an endless ocean of languages, frameworks, and libraries I have never used. No coder can do all of it, of course, but I am excited to be at a point now where I can write about code (without feeling out of place), develop full-fledged web applications, and start getting more involved in the development community.