The Right Words

The following is a speech I wrote as my introductory icebreaker speech for a Toastmasters Meetup I attend. If you want to learn a little more about me, this is a good place to start. The paragraphs are broken up a little more than they would usually be because it made it easier to read in the form of speech notes.

A bit literal, but thanks, Pixabay.

The Right Words

The ability to find the right words for an occasion has always been, and will always be, of critical importance to me. It has defined my life, my relationships, and my career.

When writing words down, it has become my primary skill set. But when it comes to speaking words out loud, I have a shakier background, which is enormously frustrating to me because in conversation, I often find the right words... after the moment has passed. Have you ever come up with a great response but about thirty minutes too late? That's me, all the time. And I look forward to changing that.

Hi everyone. If you don't know me yet, my name is Dan. I joined Toastmasters because words are my craft and my passion, and I want to get just as good at speaking them as I am at writing them down. In this speech, I'm going to describe four personal anecdotes from times when words, right or wrong, changed my life completely. By the end, I hope you'll understand my passion for finding the right words, what that means to me, why it matters, and maybe learn some things about me, too.

My first story is a happy one. I was ten years old. My fifth grade teacher, Andy Kinard, asked everyone in the class to write a creative story for our Writing period. We could write any story we wanted, and we would read it in front of the class. We would then vote on the best story (without voting for our own), and whoever won got a Cinemark movie theater gift card.

The story had to be one page long… so I wrote eight. I had never been so excited about a homework assignment. I read the whole darn thing to the class when it was my turn, with Mr. Kinard getting me glasses of water as I plodded through. The class voted, and I won the gift card. But better still, Mr. Kinard took me aside after class and told me I was very talented and should consider becoming a writer when I grew up. I had never won anything in my life and no one had ever suggested a career path to me before that day. This was the first time I had written words down and met with success when I put them in front of others.

The second story is less cheerful, unfortunately. One year later, I was in a car with three other students my age and a parent who was chaperoning us to the CSU library. I was in Advanced Reading class with the other students, so we were driving out to find research books for our "Young Scholars" project, which was supposed to be about what career we wanted to pursue. The other three were talking loudly and completely ignoring me. I asked them to stop talking, and got angry when they blew me off.

I couldn't articulate why I wanted them to so badly at the time, but the reason was that their talking was an incessant reminder that they had friends in the car and I didn't. I couldn't express the feelings I had: jealousy, frustration, loneliness.

For the first time, I said out loud that I wanted to kill myself.

That year was the worst year of my life, which sounds melodramatic to say about sixth grade, but it was bad. For one, it was the heaviest homework load I ever had until junior year of college. I had exactly one friend, who wasn't in most of my classes, so I often felt isolated and lonely. And at home, my parents had started screaming about getting a divorce in the living room when my sisters and I were upstairs trying to sleep. I had thought about suicide before the drive to the CSU library, but had never said it out loud.

The parent chaperone told my parents, who got me into counseling. I was diagnosed, mistakenly, with depression. I was later diagnosed with bipolar disorder. Looking back on it, I feel like my problem wasn't that I hated myself, it was that when I didn't know how to say what I was feeling, I felt powerless and worthless. I needed help to find the right words.

The third story would be depicted as a montage in a movie, or I like to think it would be.

• I met my best friends, Nathan Liston and Ian Barry, in ninth and tenth grade respectively. Nathan was patient enough to let me come up with the words I needed to come up with in conversation, and Ian could match my ability to speak about abstract concepts and big-picture problem-solving.

• When I was twenty-two, I got my first actual job as a writer. CSU's Rocky Mountain Collegian has a joke of a pay scale, but my job as an Opinion Columnist was the first time I was paid to write in my life. My editor told me that one of my articles, which was about what it's like to have bipolar disorder, was by far the most-read article on the paper's website all semester, an uncommon occurrence for opinion articles.

• When I was twenty-four, I met the woman who is now my wife, Aarica. She is the best listener the world has ever seen (she has to be, she's a teacher), and she's helped me learn to express feelings I didn't even know could be put into words. With her support, I got off my medication at twenty-five. It was the first time in fourteen years I wasn't taking pills for a mental disorder.

So my fourth story is the culmination of it all: I constantly see examples of people wanting me to write for them or help them find the words they need. My manager at my day job, Radial, sponsors my blog. One of our clients pays me to copyedit his marketing materials. And my coworkers come to me for help when they're having a hard time explaining something in an email.

Being able to tell your own story, to say how you feel or describe an event, is so, so important. People who can explain their stress, their fears, their anxieties, these people can vent their emotions and face the day with a level head and firm foundation. For me, words are my craft and my passion, so they matter all the more. I hope you'll continue to help me find the right words as a public speaker here at Toastmasters going forward. Thank you very much.

Post number 62.

Working at Radial: Embracing Empathy

I’ve worked a lot of jobs. Fifteen of them, in fact. This has been a tremendous benefit to my career as a software developer because it has taught me most of the soft skills I need, leaving only the actual coding to focus on. I’ve worked with lots of coworkers, lots of customers, lots of managers, and lots of companies. Because of this experience, I can tell, for example:

• when a customer relationship is not worth the time to maintain because their end goal is to screw the company out of its service, not to pay for the service

• when a coworker or manager is toxic and dragging a team down

• the difference between a job interview initiated through networking (friendly, open-minded, with the interviewers genuinely trying to understand you) and a job interview initiated through the cold (in)efficiency of recruiters and job postings (nitpicky, austere, largely pointless unless you’re vastly overqualified for the position)

• when and why punctuality and professionalism matter

• when a customer feels they are being misled due to a lack of information

• how to positively and negatively deliver both good and bad news

But there are also some enormous gaps in my knowledge of how work gets done, many of which have yet to be filled. And while I have sometimes found that Radial would have done better to have taken my advice in certain instances in the last twenty-one months of me working at the company (as hindsight has proven), both management and company culture have shown me just how much of the picture I was, and am, missing.

Job Flipping

Remember how I said I've worked fifteen jobs (sixteen if you count Uber and Lyft separately, seventeen if you count my two stints at Old Chicago separately)? Bearing in mind that I’m also twenty-seven years old, this may give you a picture of how frequently I’ve doubled-up on jobs, switched jobs, and hunted for jobs since I entered the workforce at sixteen. What’s up with that, you may ask?

I’ve sometimes wondered this myself. On reflection, my mindset of perpetual career motion stemmed from three key elements:

• financial desperation. Most of the jobs I’ve held were retail, food service, or worst of all, gig economy jobs, none of which are known for paying well. It has been a simple matter to find a job that pays better than my current one for most of my career.

• a lack of allegiance on both sides. I was laid off from my very first job as a Toys R Us cashier (and thank goodness). There are countless articles that talk about how it pays better to switch jobs than to stay at one. Both personal experience and the world around me was saying “Companies don’t care about you. Why should you care about them?”

• there was nothing to stick around for. I’ve liked some coworkers and managers, to be sure, but I’ve always felt that if I only want to spend time with a person because I see them at work, the relationship can’t be that special. Furthermore, most jobs in retail and food service are dead-end jobs. Promotion to a position that pays significantly better is usually a slow, arduous, thankless process.

In short, the companies I’ve worked for were never really a part of how I defined myself. My performance at work, the work I do, has been a part of how I define myself for quite some time. But the company was not mine, and neither was my coworkers’ work. I could build myself a segmented locus of control within the company, figure out the system of mundane tasks entry-level jobs ask employees to do, and do them well. I have never been laid off since that Toys R Us job. Most of my managers from Silver Mine onward have been surprised to hear I was quitting because they took me for a satisfied, devoted worker. “Really? Why?” was usually their response to “I’m putting in my two weeks’ notice.”

They got the satisfied part wrong, that’s all.

A Promotion and Good Pay

Things started shifting a bit, again starting with Silver Mine. The key milestones were as follows:

• A coworker at Silver Mine told me, “At first I was worried about how you’d do here. Then you started asking questions.” This flipped the switch in my mind that had failed to flip up until then: in school, you study before you take the test. In the workforce, no matter what job interviewers, recruiters, or anyone else tells you, you learn as you take the test.

• One day, a different Silver Mine coworker and I were the only two people closing down the store. This coworker went to high school with me. We were both twenty at the time. That’s right, that entire Silver Mine branch had been entrusted to two guys who couldn’t legally drink yet. It struck me then that I am being entrusted with adult responsibilities, and adulting is not that hard if you stay out of your own way.

• At Old Chicago, I was paid slightly better than Silver Mine when all was said and done because of how expensive car maintenance became as a delivery driver. Even so, $9 hour was… kind of low. I negotiated for a $1/hour raise and got it. In doing so I learned that, depending how I clocked in (for a dough cook shift, a pizza line shift, or a dish shift), I had been getting different pay rates, some of them below $9/hour. The raise corrected this.

• At Simply Mac, I got my first promotion. I was working at the Fort Collins branch and got the job at the Greeley branch, even though an employee at the Greeley branch had also applied.

• I ditched Simply Mac anyway because it paid better to be a part-time sales rep at T-Mobile than an assistant manager at Simply Mac

By continually swapping jobs, I was finally getting to positions that were more interesting to me (selling computers and phones is more my style than making food). I had started getting raises and promotions, which told me I was a valuable employee to the companies I worked at. And at T-Mobile, I finally stopped being financially desperate when I went full time and averaged $50,000-55,000/year in income (though much of it was held back until tax season because it was commission pay).

Ultimately, this meant that I worked at T-Mobile for three years, with a few side hustles in the form of a (very) brief position at 7/11, an internship at the Colorado Senate, Lyft and Uber driving, and a job as a JavaScript curriculum writer for Upscale Academy. But I couldn’t ditch T-Mobile. I didn’t have any serious allegiance to the company, and the career ladder required me to either have that allegiance or pretend that I did, so I knew I didn’t want to stay there forever. But it was a much harder task to find a better-paying job from that point.

No, we don’t make tires.

The Obvious Wins of Radial

Radial paid about the same as T-Mobile when I started, ignoring the commission tax issue (it now pays a bit better—$65,000/year for full-time developers). I made the switch for the quality of life and career growth improvements that come with being a software developer rather than a sales associate, which turned out to be one of the best decisions I’ve ever made in my life. Here are a few obvious reasons why:

• I used to go to work, stand around all day in a violently-pink room, and get yelled at by people who charged phone games to their bill and then wondered why the bill costs more now, albeit with a lot of coworkers I like (before that, the room was violently green). Now I go to work and type code into a computer, also with a lot of coworkers I like.

• I used to get six weeks of PTO. I now get eight.

• Healthcare is a company expense at Radial, not an expense withdrawn from your paycheck. U.S. healthcare still sucks, but it takes the sting off a little.

• The snack room used to contain expired donuts brought there by schmucks trying to schmooze me into selling the latest (likely-to-explode) Android phone to everyone I spoke to. Radial has snacks chosen by the employees, for the employees.

I say those are the obvious reasons because those are the reasons you’d expect anyone coming from a retail job to prefer a software developer job, barring perhaps the coworkers they like and the snacks. Fortunately for me, Simply Mac, the Collegian, T-Mobile, and Radial have all had great people working at them. Coworkers I dislike are the exception, not the rule just about everywhere I work. Chalk it up to luck or an educated northern Colorado populace, but I don’t typically have a problem with my work teams.

A Less-Obvious, But More-Spectacular Win: Retrospectives

Radial changed my work week in some ways I did not expect, which I’m confident are uncommon in any job, in any industry. Take, for example, the oft-despised all-hands meeting with the manager. At many of my previous jobs, these meetings were miserable. The manager would talk extensively about whatever his manager told him, and how we’d be in trouble if we didn’t fall in line with what our manager’s manager said. This is a terrific strategy for making your employees fear for and hate their jobs. It’s a terrible strategy for making your employees feel wanted, appreciated, or cared for in any way. It’s also a terrible way to get any valuable insight from your employees, who are after all on the front lines interacting with the paying customers. When employees feel afraid or unsafe, they’re not going to come to you with their problems, and they’re also not going to be open with their opinions in meetings.

The fatal problem here is that companies that operate on fear are run by managers who don’t care about what their employees think in the first place. To them, a fear-inducing meeting kills two birds with one stone: it forces employees to behave a certain way (or appears to, briefly), and prevents them from disturbing the manager, which is more important to this sort of manager than understanding the company’s problems. This is precisely why communication lines fail at this sort of company. You can offer “open door” office hours, a phone line to call if you feel uncomfortable with team members, and every other “we’re open, talk to us!” line you want. But at the end of the day, running a company (or branch) through fear is guaranteed to render these communication lines useless. By never receiving feedback about what’s happening from your team, you can never help them solve the systemic problems crippling their performance.

Radial is completely different in this way. Retrospective meetings are held, not with the purpose of management declaring from on high that “things are gonna change around here,” but with the goal of tapping into the frustrations, worries, and problems that arose since the last meeting amongst the members of the team. Management will then create “action items” to be completed by either management or the best-qualified person to complete the item, which are written with the goal of resolving the issue.

I’m sure many companies have retrospectives. I’m sure many more companies have all-hands meetings. But this approach to company improvement and feedback blew me away when I started at Radial, and it continues to surprise me every time a serious problem arises within the company. Even our most introverted employees have voiced their concerns with their job at many retro meetings. This piece is crucial in that everyone is involved, but better still, they are regularly listened to and action is taken to help them work through their problem. Nothing says “this company cares about you” like listening to an employee’s personal problems with their job and helping them resolve those problems. On top of that, by laying out problems in the open, I’ve found that retros have solved interpersonal problems in the company that I had previously presumed were unsolvable in a work environment. At my previous jobs, these sorts of problems would have guaranteed a festering, bitter resentment amongst team members every day they came to work, which would only end when someone left the team. At Radial, our team is made stronger through our differences and our brokenness. I’m also 100% sure it results in a much happier, more productive team.

Radial’s retro meetings aren’t perfect. I’ve found that our more-extroverted, more-socially-comfortable team members are reliably engaged in the meetings, while others are not. I sometimes worry that this is inadvertently muting some voices that should really be heard. Action items also have a habit of taking a long time to complete. We chalk this up to the team being very, very busy (which is certainly true right now), but it can occasionally feel like the initial feedback was effectively ignored because the action item took so long to get done that it had zero impact on the problem it was meant to resolve.

Hack Time: What I Was Doing All Along

I frequently start working at a company and get bored after two or three months when I’ve not only grasped the work, but effectively mastered it. There’s no further improvement to be made to my workflow, beyond subtle alterations based on company or customer needs.

Radial is by no means boring. There are always new clients, new technical challenges, and new things to learn. But it endeavors to build into the schedule “hack time,” eight hours of a given forty-hour work week where I can theoretically work on any personal project I desire.

I say that I was doing this all along because that’s effectively been my strategy with my career for many years. I worked at Simply Mac, but wrote opinion columns for the Collegian on the side to pursue my passion for writing. I worked at T-Mobile, but started learning to code at Bloc on the side. I’ve used my self-declared hack time to create things and learn things and grow as a person. Of all of my personality traits, I think this is the one I’m proudest of: I’ll put myself through the discomfort of a strange and foreign experience in order to expand my skills and understanding. Good things usually come of this.

Being able to bill these hours to Radial is a huge benefit for me. I’ve been working on building Novum Opus almost since I started at Radial, and have found a surprising level of support and engagement from my team members in my (complicated, arduous, confusing) process of trying to build a system that can solve the $1.5 trillion problem of student loan debt.

The major drawback here is that “eight hours” of hack time is something of a lie, at least right now. Retro meetings and one-on-ones are hours worked, but not billable to clients, meaning thirty-two hours need to be billed and a couple hours on top of that are already allocated to meetings. If we work on policy documentation, that too must fit within that eight hour window.

None of this stops me, to be sure; I regularly work over forty hours, much to my managers’ amusement. But someday, eight hours of hack time genuinely, reliably being allocated within a forty-hour Radial work week would be a great thing to see.

A… Win? Stand Ups and Sprint Reporting

Stand ups are a staple of development teams practicing any flavor of Agile methodology. The concept is that team members report what they did yesterday, what they’re doing today, and what problems are blocking them. At Radial, we do this on Slack Monday, Wednesday, and Friday, and do it in person on Tuesday and Thursday. Some members of the team (our Director of Engineering and self-proclaimed work group leads, like me) also report on overall project status in terms of hours and progress toward that sprint’s goals. For the uninitiated, sprints are two-week segments of time in which we determine what we’re going to deliver for a client, why we’re delivering it, and do our best to reliably deliver those things.

Overall, stand ups are… fine. I think it’s helpful for me personally to think about what I’m going to be doing that day before I start thrashing randomly at problems. I rarely read other team member’s stand ups, though. One reason is that they’re often uninformative; one might read “Y: FFL, T: FFL, I/O: No,” which tells me… nothing, except that the employee is working on a project with the initials “FFL” that day. Another reason is that they’re largely irrelevant to me unless they’re from someone I’m working with directly.

Sprint reporting is similar. I put a decent amount of effort into my sprint reports, much to the appreciation of clients and management, from all I can glean. Yet I find myself unlikely to read other people’s sprint reports closely for more or less the same reasons I cited about stand ups. Many sprint reports I have read feel half-hearted, or else as though they were dreaded by the employee who wrote it, making them difficult to read.

In short, reporting is valuable if done well. It’s nearly useless if it’s not. I think the key issues are as follows:

• The why of stand ups is not clear to everyone on the team, either because it’s never been conveyed or has been forgotten. On the one hand, there is an easily-resolved lack of clarity here: if management gets helpful stand ups, they can pitch in and solve problems proactively. if everyone knows this and values this, they’re far more likely to at least try and make their stand up informative. However, we’re so busy right now that there’s a valid argument to be made that the employee is not guaranteed help from management just because they put it in stand up. This is a dangerous precedent to set; I think it’s been a hugely positive thing amongst the development team to get help when they need it in the past, and it would be a bad thing to lose that.

• The why of sprint reporting is, I feel, misunderstood (as the guy who kind of started the idea). I send sprint reports because I know I can clearly explain the goals of a sprint and our progress toward those goals by writing them down. I like to write. It gives structure to my thoughts where the spoken word never could. I do it a lot, so I’m pretty decent at it, if I do say so myself. If other developer leads find it more burdensome to write down a sprint progress update than to just talk about it in a meeting, and the client finds progress reports within a meeting context satisfactory, a sprint report is of less than no value. The concern I saw when I started sending them was that clients were often wondering where their money went, we would say “look in the sprint tracker,” and the notes there didn’t connect the dots for them. I don’t think all clients need a sprint report from all developer leads, but I do think that a service as complex as ongoing software development requires some form of consistent client communication to be effective. After all, I’d need to write out a breakdown of people’s phone bills at T-Mobile for them to understand it, and that’s a far simpler concept to grasp than the concept of a software development sprint. If the client can translate project stories into colloquial terminology themselves, they don’t need a developer lead to do the translating; otherwise, that’s one of the main purposes of a developer lead, as far as I can tell.

• We’re very busy right now as a company. It’s easy to use that as a scapegoat for a lot of problems we’re encountering (not least because they were also problems when we were a lot less busy), but it surely plays some role in the challenge of making project reporting helpful.

Ideas Made Real

I can’t take credit for most of the things that make Radial what it is. The general structure of the company existed before I showed up. If I were ever to leave, it would continue functioning without me. While I’ve been at Radial, most of its operation has gone on without any input from me.

But coming from the world of entry-level jobs at enormous corporations, it has nevertheless been a tremendous honor and privilege to have contributed to the ideas and strategies that have helped scale Radial, which I feel is the story of Radial’s 2019. Here are a few things I’m particularly proud of, both because I contributed to them and because they were implemented successfully:

• When I started, I pushed pretty aggressively to have a salesperson on the team. I thought that could maybe be me, which turned out to be a poor scoping of how to solve Radial’s problems. Nevertheless, we now have a salesperson, a sales funnel, and more sales than we know what to do with, the opposite of our situation in 2018, because we as a company have taken sales more seriously since January. I can’t take the credit for the proper implementation of this idea, but I certainly feel I pushed our developer-focused team to recognize we need sales, and also need to appreciate getting them.

• As mentioned above, I think I can take quite a bit of credit for an improvement in overall client communication, both by encouraging developer leads to report on sprint progress to our clients at the end of each week and by setting a good precedent for project reporting expectations.

• I contributed pretty significantly to our team effort to redefine our company values.

• I understand how important it is for us to mess up, so we can know how to bounce back from it, learn from it, and get better. I also know that Radial figured some things about itself right before I started working there. But I also feel like the reasons cited above, and the positivity I attempt to bring to work with me whenever I can, have led us to several victories where our previous strategies would have failed us.

If I had all these same ideas at any other company I’ve worked for, they would have been at best completely ignored, at worst scoffed at because I didn’t have the job title to be discussing such things regardless of the quality of the idea.

Simultaneously, the way I work has fallen on its face pretty badly at Radial, more than once.

• At a retail store, if you’re overworked, it’s a short-term problem. Eventually the shift ends or a team member grabs the next customer, and now it’s no longer your problem. At Radial, projects are scoped to developer leads to a certain degree, but if you fail to reach out, you start to drown under the workload no matter how good a work ethic you have. One project I was leading had to be handed off because I failed, horribly, to pull in additional support when I sorely needed it.

• Because of my habit of leaving jobs early, I often find it easiest to just avoid someone who I’m struggling to see eye-to-eye with. After all, in most cases, I’ll be gone soon. Radial is not that way and is not going to be that way. If anything, I think this is the very worst time to ever leave Radial, because this company is going places, and I want to go to those places with it. This means that I’ve had to learn to face some of my nastier habits, such as discarding the opinions of others (and sometimes that person entirely) when I’ve made a snap judgment that they don’t deserve my respect.

In fairness on that last one, I think there are also a couple of times when Radial did not follow the path I thought we should follow, and we have been worse off for it. I’ve expressed my concern about some clients and personnel and found my opinion fell on deaf ears, only for it to come back to bite us because my instinct was right to begin with. Going forward, I hope to do a better job of articulating why I have reservations about an idea and where that reservation comes from, so it can be considered more critically by myself and others. I also hope to do a better job of reserving judgement so “my opinion being right” never becomes a self-fulfilling prophecy, which is to say that the initial distaste toward an idea or business strategy shouldn’t sour the idea before it was really given a chance.

Always Halfway Out the Door

I’ve gotten into a habit of leaving companies quickly. There’s always at least one “reason” to leave that I can come up with for any place that I work: this company will pay me better, this company has better benefits, I’m sick of this toxic environment, I’m sick of these customers, I’m sick of the idea of this job, the list goes on.

What I’m discovering is that I’ve built “leave as quickly as possible” into an instinctual habit because it has served me well in the past. My experience at Radial has taught me that I can remain this way, but I shouldn’t. I can let where I work be part of how I define myself, I can unironically say that my team at work is like a family to me, and I can stop for a moment and enjoy how far I’ve come since I learned what Ruby hashes were in 2016. “Settling” for something is often a sign of stability, not a sign that you’ve given up or stopped trying, and now might be a good time to dig in and explore my career more deeply rather than more broadly.

Radial comes with its flaws, like any company. But the empathy the team shows each other and the value the company places on its employees, their ideas, and their feelings makes it far greater than its problems, and it’s that above all else that has made it a second home for me.

This post was sponsored by Radial Development Group, but the opinions are my own.

Post number 61.

Technical Interview Question Answers: Array of Letters to Hash of Letter Counts, in Three Languages

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:

["s", "a", "b", "b", "h", "d", "e", "f", "o", "q", "r", "w", "s", "c", "u", "g", "a", "h", "h", "r"]

should return the following hash of key-value pairs:

 {"a"=>2, "b"=>2, "c"=>1, "d"=>1, "e"=>1, "f"=>1, "g"=>1, "h"=>3, "o"=>1, "q"=>1, "r"=>2, "s"=>2, "u"=>1, "w"=>1}

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:

letter_array = ["s", "a", "b", "b", "h", "d", "e", "f", "o", "q", "r", "w", "s", "c", "u", "g", "a", "h", "h", "r"]

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):

1  def count_and_sort_letters array
2      letter_counts = {}
3      array.each_with_object(letter_counts) do |letter, letter_counts|
4          if letter_counts[letter]
5              letter_counts[letter] += 1
6          else
7              letter_counts[letter] = 1
8          end
9      end
10     letter_counts.sort_by{|k, v| k}.to_h
11 end

Then call the method with the letter_array:

count_and_sort_letters letter_array

Great! So what am I doing here? Let’s break it down:

• 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.

The result is what we wanted: {"a"=>2, "b"=>2, "c"=>1, "d"=>1, "e"=>1, "f"=>1, "g"=>1, "h"=>3, "o"=>1, "q"=>1, "r"=>2, "s"=>2, "u"=>1, "w"=>1}

Some notes:

• 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.

Again, I defined the array we’re testing with:

const letterArray = ["s", "a", "b", "b", "h", "d", "e", "f", "o", "q", "r", "w", "s", "c", "u", "g", "a", "h", "h", "r"];

Then I wrote an arrow function that counts, then sorts, letterArray, before returning the counted and sorted object.

1  const countedAndSortedLetters = (array) => {
2    const unsortedCounts = {};
3    array.forEach((letter) => {
4      if (unsortedCounts[letter]) {
5        unsortedCounts[letter] += 1;
6      } else {
7        unsortedCounts[letter] = 1;
8      }
9    })
10   const sortedCounts = {};
11   Object.keys(unsortedCounts).sort().forEach((key) => {
12     sortedCounts[key] = unsortedCounts[key];
13   })
14   return sortedCounts;
15 }

I then call the arrow function to return the value in my console with:

console.log(countedAndSortedLetters(letterArray));

And get the result:

{ a: 2, b: 2, c: 1, d: 1, e: 1, f: 1, g: 1, h: 3, o: 1, q: 1, r: 2, s: 2, u: 1, w: 1 }

Let’s break this one down:

• 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.

1  import java.util.HashMap;
2  
3  public class Main{
4    public static void main(String []args){
5      String[] letterArray = new String[]{"s", "a", "b", "b", "h", "d", "e", "f", "o", "q", "r", "w", "s", "c", "u", "g", "a", "h", "h", "r"};
6      letterCounter(letterArray);
7    }
8    
9    private static void letterCounter(String[] letterArray) {
10     HashMap<String, Integer> letterCounts = new HashMap<>();
11     
12     for(int i=0; i < letterArray.length; i++) {
13       String letter = letterArray[i];
14       if  (letterCounts.containsKey(letter)) {
15         letterCounts.put(letter, letterCounts.get(letter) + 1);
16       } else {
17         letterCounts.put(letter, 1);
18       }
19     }
20     System.out.println(letterCounts);
21   }
22 }

The response is very similar to the JavaScript response:

{a=2, b=2, c=1, d=1, e=1, f=1, g=1, h=3, o=1, q=1, r=2, s=2, u=1, w=1}

Here’s what’s happening this time:

• 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!

Post number 60.

Lucrative Work, No Bachelor's Degree Required

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.

Help People Find a New Home

Real estate agents typically need a certification, but in my experience, full-time real estate agents are often paid more than the $58,000/year The Job Network claims. Northern Colorado real estate isn’t cheap, so I’m sure that’s a factor, but I’ve met real estate agents who say they pretty comfortably command six figure salaries.

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!

Post number 59.

Working at Radial: The Hiring Process

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.

Disclaimer: this post was written in affiliation with Radial Development Group.

Post number 58.