DEV Community: Jacob Fromm

Things I'm Embarrassed I Don't Know, pt. 2

Jacob Fromm — Mon, 15 Mar 2021 01:56:45 +0000

(Last month, I wrote a post about package managers and how I was embarrassed I didn't know about them. This is part 2 of that series.)

Never before have software developers had to rely on their own personal computing devices for work. For developers who are either freelancers or just plain unemployed, using your personal laptop as your work device can be difficult with limited storage. Here's what I've done to make space.

Author's note: I'm working with a 2013 Macbook Pro with 16GB of RAM and a 500GB SSD running macOS Catalina v10.15.16. If you're not a Mac user, you can go ahead and stop reading now.

This helped me, so maybe it'll help you! I recently learned how to manage storage on my own device without downloading any pesky cleanup software.

Resources:

https://support.apple.com/en-us/HT206996

How I Job Search

Jacob Fromm — Mon, 08 Mar 2021 00:26:29 +0000

Yes, I'm unemployed. No, I don't think that makes me unqualified to write this post.

I completed Flatiron School's software engineering bootcamp in December, 2020, and on January 3, 2021, I officially declared my job search.

"Officially declared? Is that, like, a thing?"

Generally speaking, no. You can just, you know, search for a job. But Flatiron has a money back guarantee that requires its graduates to keep up with a certain amount of networking, coding, and blog posting each week. It's a lot of work, but it's keeping my nose to the grindstone and has undoubtedly helped me make more progress than I otherwise would have.

"But you said you're unemployed...so what does 'progress' mean?"

There's a whole bucket of idioms for what I mean by "progress," from "irons in the fire" to "points on the board." I'm talking about connections made, interviews conducted, code challenges completed. That sort of thing. There's no way around the brutality and demoralization of the job search; simply put, it sucks. But, in my experience, there are a few things that make this process a lot less of a bummer.

1. Figure out where you fit.

When I started Flatiron's bootcamp, all I knew was that I was training to be a full stack software engineer. What I know now is that

unless you're a senior engineer at a startup wearing a lot of hats, most dev jobs aren't really "full stack";
compared to other junior devs looking for jobs, my engineering skills and experience are paltry at best; and
I have a robust interpersonal skillset that has nothing to do with, but would be very valuable in, an engineering or tech-adjacent position.

If you're like me and you're finding yourself at the end of a bootcamp, struggling (and probably failing) to keep your head above water psychologically, try to remember that you were a whole talented-ass person before you made this transition. You weren't doing eight hours of heads-down coding before, and you might not even enjoy that now. There's a whole ecosystem of jobs out there for people whose engineering skills are a (valuable) subset of their larger skillset; it would behoove you to be open to them.

2. It's a numbers game (sort of), and you've got to get yourself out there.

This one might be sort of obvious, but despite how overwhelmingly depressing the nameless, faceless application submission process is, you've just got to do it. Here's how I've streamlined that process:

I only apply to jobs I want, even just a little bit. There's no point in feeling the sting of a rejection from a job you didn't even care about.
Most of the time, I don't write cover letters. This might be controversial, but if there's a substantial chance my resume isn't even going to be looked at, I'm certainly not going to spend hours perfecting a cover letter.
For jobs I do want, I write a passionate and personal cover letter. I don't believe in templates; I think there's an unavoidably impersonal, copy-and-paste quality to those cover letters. But then again, I've got an English degree, so writing a good cover letter is something that's in my wheelhouse.

3. The job posting is just a starting point. You've got to build relationships.

This is really the crux of my job search process, and I think it's what's gotten me in front of interviewers more than anything else. When I see a job posted at a company I'd like to work for, the first thing I do is apply on the company website. Only after I've applied does the work really start.

Once my application is in, I reach out to everyone who's remotely related to that position. In general, I try to focus on

people who'd be on my team, and
potential supervisors.

This is something I learned from my past life as a comedian: you simply have to show up. No matter how many tapes I sent to producers, I was much more likely to be booked if I knew the person booking the show. I'd go hang out, meet the people involved in the production, and follow the show online. More importantly, I'd come back. And that, more than anything, was what got me booked. You just have to show up.

I don't mean that showing up is all you have to do, but it's the baseline. Unless your skills and experiences make you the undeniably perfect person for the position, you're not going to be considered unless the right people know you and like you. It's a fact of life, and it's a fact of the job search.

I start by contacting people I have any connection with: maybe we went to the same bootcamp, or the same college, or know the same person. I spend a lot of time looking through LinkedIn profiles for anything to which I can relate or connect. Because in-person networking events aren't happening right now, this is how I'm building relationships.

And I say "building relationships," not "making connections," because more often than not, I keep in touch! For example, if I meet someone who refers me to someone who reaches out with some sort of opportunity, you can bet I'm letting that someone know! If someone helps me, I keep them updated with my progress. I think this is an essential step in the job search, but it's one many people have a hard time with. It's easy to feel like you're bothering someone, or to feel guilty asking them for help. But you just have to get over that, because it's damn-near impossible to get a junior dev job on the quality of your resume alone.

4. I don't actually know what I'm talking about!

This could all be totally wrong. Like I said, I don't have a job. But I've got an internship, and I'm interviewing, and I'm doing code challenges, and I know a ton of people at a bunch of companies I never thought I'd know. And that's pretty cool to me.

"I Know This is Crazy, but I Think the Tests Might Be Wrong"

Jacob Fromm — Sun, 07 Mar 2021 23:32:37 +0000

I recently received a coding challenge from a company I'd love to work for. I wanted to share the experience here because I think it might be valuable for other junior devs and bootcamp grads in the early stages of their job search.

I had been told that the challenge would test my Ruby skills, and that once I received it, I would have five days to complete it. Once I started, however, the assessment was supposed to take about forty-five minutes—fifteen for the first section, and thirty for the second section.

In preparation for the assessment, I opened up some old Rails projects, took Ruby and Rails assessments on teamtreehouse.com, and completed LinkedIn's Ruby on Rails skills assessment. On the day I had decided to complete the challenge, I was feeling prepared but anxious.

For the first section, I had the opportunity to choose which language I wanted to code in. I chose Javascript because I knew the second section was in Ruby and I wanted to demonstrate competency in a variety of languages. I completed the first section, but the time it took me to finish was considerably longer than was estimated. Because of that, I was even more anxious going into the second section than the first: even if my code was right, I didn't want to be seen as a slow and inefficient developer.

The instructions for the Section 2 presented a challenging but not impossible task. Given the input of a hash, I was tasked with sorting the hash such that the keys were sorted by length and their values sorted alphabetically and / or numerically. Unfortunately, I didn't save the actual instructions, so the above description is paraphrasing, but given the following input: {"category_names"=>["Sports", "Music", "Food"], "user_ids"=>[562, 332, 555, 311, 987], :videos=>["/videos/987569", "/videos/43222", "/videos/54322"]},
the expected output should be:
{ :videos =>["/videos/43222", "/videos/54322", "/videos/987569"], "user_ids"=> [311, 332, 555, 562, 987], "category_names"=>["Food", "Music", "Sports"] }

I tested my code in repl.it using the given input until I received the expected output. My solution looked like this:

def sort_hash(hsh)
      sorted_hsh = hsh.sort_by {|k, v| k.length}.to_h
      sorted_hsh.map {|k, v| [k, v.sort]}.to_h
end

First, we sort the input hash, hsh, by the length of its keys using hsh.sort_by. We then convert that result back into a hash, since Hash.sorty_by returns an array of arrays (AoA).

Next, we map through sorted_hsh and sort each value on our way through. Finally, we transform the array returned by the Hash.map function into a hash. It's a simple solution that could probably be refactored and may not account for edge cases, but it does work. That is, given the example input, it returned the desired output as defined in the instructions.

I was excited to see my code producing the correct result in repl.it, but when I went back to the assessment to run my code through the assessment's tests, the tests failed! I was confused, disappointed, and very stressed. I told myself to take a breath and read the error messages, and when I did, I found a bit of a head-scratcher: as far as I could tell, the expected output (according to the tests) was identical to the example input.

To test my theory, I commented out my code and ran the function with only one line of code: return hsh. Sure enough, the tests passed. As far as I could tell, my hypothesis was confirmed, and two things were true: my code was right and the tests were wrong.

"I Know This is Crazy, but I Think the Tests Might Be Wrong"

Jacob Fromm — Sun, 28 Feb 2021 23:11:06 +0000

I tested my code in repl.it using the given input until I received the expected output. My solution looked like this:

def sort_hash(hsh)
      sorted_hsh = hsh.sort_by {|k, v| k.length}.to_h
      sorted_hsh.map {|k, v| [k, v.sort]}.to_h
end

First, we sort the input hash, hsh, by the length of its keys using hsh.sort_by. We then convert that result back into a hash, since Hash.sorty_by returns an array of arrays (AoA).

As my heart pumped with anxiety and sweat dampened my shirt collar, I took screenshots of my code, the instructions, and the error messages, and explained my thinking. I included edited versions of those notes to both the recruiter I'd been in touch with, as well as a senior engineer with whom I'd had an informational interview a few weeks prior. I did my best to humbly but confidently explain what I thought had happened, and in both messages, I said something like, "I know it's audacious for a junior developer to say this, but I think the tests might be written incorrectly."

I figured that one of two things would happen: either I'd never hear from them again, or I'd get the job. I haven't gotten the job, but I'm happy to report that I am in fact moving forward in the interview process! I still don't know if the assessment was one big trick question or if the tests were simply written incorrectly, but I'm glad I trusted my gut.

It gave me an opportunity to demonstrate my ability to communicate, to raise questions respectfully, and to provide further context into my thought process. In other words, if I had to do it all over again, I would do everything same except for one thing: I would relax!

Freelance Fears of a Junior Dev

Jacob Fromm — Mon, 22 Feb 2021 02:30:11 +0000

I was excited, if a little apprehensive, when E. asked me to build him a website. A close friend of my girlfriend's, E. was the most stylish person I knew. He was a multitalented artist with an innate sense of impeccable design that some people are just lucky enough to be born with.

He needed a web site that served not only as a portfolio, but also as a portal through which his supporters could donate to his current projects.

And he needed it done in a week.

I had a few reasons to be nervous about taking the job:

I knew he knew my design instincts weren't as, let's say, intuitive as his. I'm a photographer, and I have opinions about what looks nice and what doesn't, but I was worried that what I designed for him just wouldn't cut it.
I also knew he also knew that I had recently graduated from a coding bootcamp and that this would be my first freelance project. (What he may not have known, I now realize, is that the skills taught in coding bootcamps aren't necessarily the same as a self-taught developer. If the organic autodidactic path to software development typically goes through HTML, CSS, and JavaScript, with a nice holiday in Wordpress, and then on to brighter and more code-heavy pastures, my bootcamp was a bullet-train to database design and refactoring for Redux. As I've written about previously, there are some gaps in the bootcamp skillset that E. probably wasn't aware of.)
Inexperienced as I was, it was difficult to settle on a rate that was fair to everyone. We didn't really discuss a budget, and of course I was going to be charging him less than a client off the street, but I also didn't want to insult the both of us with a laughably low rate. But then, like I said, I didn't have a sense of his web-design budget.

I was worried that, should anything go wrong, a professional disagreement could put a strain on our friendship.

Despite my reservations, I accepted the gig. I find fulfillment in solving problems and being of service, so I was happy for the opportunity to help my friend. E. had a lot of visually stunning images for me to work with, so I was excited about the idea of adding a beautiful project to my portfolio. And as a job-seeking bootcamp grad, I was eager to get more experience under my belt.

E. came over (we're in a covid pod) and showed me a Squarespace site he had quickly mocked up. He told me that he'd found the platform to be a bit much, and with no web design experience of his own, he wanted to bring a--and I can't stress enough how difficult it is for me to use this word--professional into the mix.

I asked him what design elements on the Squarespace site were intentional and which were sort of boilerplate / accidental Squarespace designs. He told me what he liked, what he didn't like, and what was important to him in terms of design and functionality. I thought we both came away from the meeting with a sense of mutual understanding, which made it all the more painful when he asked me, less than a week later, to disconnect his domain from the site I had built so he could move forward with the original Squarespace version. He disliked what I'd done so much that he was willing to go back to square(space) one (sorry) rather than continue to work with me. I was crushed.

Now that I have some distance from the situation, here's what I've learned:

Mistakes Were Made

Yeah, no duh. A lot of these might be obvious, but they weren't to me at the time, and it's important to admit when you fucked up.

Here's what I did wrong with E.:

We didn't discuss budget.
- This one's gotta be top of the list. Never again will I agree to a rate without knowing what that money means to my client, no matter what the "going rate" is.
1a. I shouldn't have charged by the hour. As a junior developer, it takes me longer than more experienced engineers to complete a project, especially when there are new technologies involved. My client shouldn't have to pay for my inexperience.
I researched poorly.
- If I had really thought about it, I could've guessed that the most complex part of the build would be processing donations. I should've researched presented him with a list of options based on what mountain climbers would call the "crux," or most challenging part, of the project.
- This resulted in an unpleasant surprise for my client when I told him, uncomfortably close to the deadline, that despite having paid me to build his site, he'd still have to pay up to $30/month (depending on the platform and implementation) to process donations.
I prioritized the wrong things.
- E. had told me that his priorities were
  1. design: interactive javascript / moving images
  2. functionality: as previously stated, processing money
- Despite those instructions, I focused on setting up a robust CMS; I implemented interactive scrolling but very built very little interactivity into the imagery; and I left the donations feature to the end of the design process.
In short, I didn't prioritize the client's needs.

Lessons Were Learned

Here's what I'm going to different moving forward:

Obviously: *always* **always** ***ALWAYS*** discuss budget before taking a project.
Until I learn to work more quickly, I'm going to charge a daily rate instead of an hourly one. If I'm going to go down a rabbit hole learning some new frontend framework or markup syntax, that shouldn't come out of the client's pocket.
Measure twice, cut once. I've never been good at this, but now that other people's time, money, and intellectual property / branding are on the line, it's important that I approach each project with a 360° view of what the project needs to be completed.
Approach each project as a person, not just a web developer. If I had really thought about it, I mean *really* thought about it (and, you know, learned about it), I **absolutely** would've told E., "I think you should just go with Squarespace. I'd be happy to help." Maybe I would've charged a consulting fee, or accepted something other than cash in exchange for helping a friend. Who knows. But approaching problems holistically, with the client's priorities at mind, is a big goal of mine going forward.

In the end, I made a donation to E.'s project——something I was going to do anyway, and not in the form of a full refund, but enough to say, "Hey buddy, I'm sorry I fucked up. I appreciate you paying me for my time and my work, but this was my bad." And the thing is, I was happy with the site I built! It was responsive, it looked great, and the CMS functionality was really exciting. It just wasn't what the client needed.

Luckily I've got another freelance gig on the horizon, a project on which I look forward to implementing these new insights. When it's done, it'll be up on my website. I'm still a job-seeking bootcamp grad, but a little less green than I was when I graduated.

Finding the Solutions

Jacob Fromm — Sun, 14 Feb 2021 19:38:59 +0000

As bootcamps flood the market with junior devs from a wide variety of backgrounds, many recent grads find themselves feeling unqualified for dev jobs. Is solutions engineering the answer?

I'm a job-seeking bootcamp graduate with a completely tech-irrelevant background. I'm thirty. I'm worried I'm in over my head.

My story is similar to many others who, motivated by covid--either in the form of a wake-up call or an economic necessity--turned to coding bootcamps in pursuit of a stable future. Bootcamps in the time of covid (what a phrase) represent a reprieve from the vertigo-inducing uncertainty of These Unprecedented Times™ with a one-two punch of intensely-focused work (productivity! routine!) and entrée into a growing and respected field insulated from the worst economic impacts of covid. (stability! security!) It's a no-brainer.

One of the reasons I was so drawn to software engineering was the professional importance of hard skills. That, and the relative accessibility of those skills: if I had the time (read: financial safety net), I could achieve something my liberal arts-educated-ass was desperate to do: put some hard skills on the resume.

Backstory: for five years, right up until covid descended upon New York City, I was pursuing a standup comedy career. I did all the side hustles: dog walking, production assisting, barista-ing. I decided to quit comedy just a few days before getting a text from my dad imploring my girlfriend and me to flee the city. I wound up home in Pennsylvania with no idea what I was going to do and a patchwork of professional experiences that wasn't exactly pointing in any sort of career-ward direction. I was tired of trying to convince people that I was valuable. I wanted to show them a list of my skills and prove I was.

Nine months later, on December 4, 2020, I graduated from Flatiron School's software engineering program with a Certificate of Completion, a slew of projects built and several deployed, and a brand-new set of skills. I'm having conversations I never would've been able to have, solving problems I wouldn't even know where to begin to start, and thinking in ways I couldn't possibly imagine if I hadn't done a coding bootcamp. I've got an internship and even a couple freelance clients! But as I trudge through LinkedIn, Indeed, and All the Job Sites looking for a full-time job as a software engineer, I'm starting to realize that from the perspective of a hiring manager, I've actually transformed my resumé into software-engineer-with-less-experience-than-like-every-other-software-engineer. My coding skills make me better; they don't make me different. They won't make me stand out to a recruiter.

I'm starting to realize, ironically, that what does make me different are all the skills, experiences, and qualities I already had. And the more time I spend poring over developer-related jobs, the more postings I see for a type of role that actually sounds like me--not just my most recently-acquired skillset. And most of those jobs have the word "solutions" in the title.

As a former comedian, I've spent a lot of time considering the perspectives of others. Comics have to understand how the audience thinks to make them laugh; you can't land a punchline if you're not on the same page as the audience. So I think I'd be good at understanding translating client needs and to engineering deliverables.

As a former production assistant and tour manager, I have a wealth of experience solving problems for others. Whether it's getting a caramel macchiato for a stressed-out producer or finding a replacement synthesizer at the last minute before showtime, I get a real thrill out of making things happen for others. If that's the core M.O. of a solutions engineer, count me in!

I realize this is starting to sound like a cover letter, but if you're a junior dev reading this, you probably relate to the relief that I feel reading a job description under the Software Engineering umbrella for which I'm not only really qualified, but also genuinely excited!

I think that's the sordid truth about a lot of bootcamp graduates: they they don't necessarily care how much time they spend coding, really.

Listen, I love to code. I really do. I wouldn't have done a whole-ass bootcamp if I didn't. And it's not like I didn't, ya know, ask myself these questions before committing to this path. But if the knock on solutions engineering is that you don't spend all your time coding, well--fine. I spent the thirty years of my life not spending all my time coding. I'd love a job that was half coding and half interpersonal communication, even if it's just emailing.

And I never would have known about this position, nor be remotely qualified for it, if I hadn't gone through Flatiron's software engineering bootcamp in the first place! So as rough as the job search can be, and as deep as I sink into Dunning-Kruger's Pit of Despair, I'm actually feeling quite hopeful. Because up until recently, I didn't even know that there was a position in my newly chosen field that really felt like me. And now that I do, it's just a matter of finding one.

Things I'm Embarrassed I Don't Know, pt. 1

Jacob Fromm — Mon, 08 Feb 2021 02:23:27 +0000

I'm a HUGE dumbass. I know a lot of developers probably feel this way; there's an ever-expanding universe of frameworks, languages, and libraries to learn; there's always someone better or more accomplished (often two completely different things) to compare yourself to; and if you're always learning, you're often swimming in confusion. But I really am (a dumbass, that is). I'm lucky to have a supportive community in which I'm comfortable being vulnerable and asking pretty dumb questions, but there are some topics that are just too embarrassing for me to ask even my closest coder friends. So I decided to start a series of Things I'm Embarrassed I Don't Know.

In this series, I'll be writing about topics I feel like I should've known by now. The, "how did I complete project X if I don't know convention Y?" type of things. I don't want to lose the respect of my peers, but strangers on the internet? Who cares! So, without further ado:

Things I'm Embarrassed I Don't Know

Part 1: Package Managers (npm vs. yarn)

Why I'm embarrassed to ask
I've used package managers in just about every project I've ever built, so you'd think I might have an opinion about which one to use. To me, building front ends and not understanding package managers feels like a cook not knowing how to peel garlic.

The Facts

npm

released in 2010
stands for "node package manager"
automatically installed when you download Node.js

yarn

released by Facebook in 2016
developed to address npm's shortcomings (at release time)
Yarn 2, released in January 2020, received widespread criticism from the dev community

The Differences

Yarn is slightly faster than npm, partially due to installing multiple packages at once, as opposed to npm's one-at-a-time approach to installs.
Yarn's terminal output is less verbose than npm's.
In the past year, npm has been downloaded over 600,000 times more than Yarn.
However, Yarn is much more popular than npm on Github

npm

yarn

The Similarities

Both package managers install packages into the node_modules folder (with the exception of Yarn 2)
Both provide package.json files. According to White Source Software: > This file keeps all the relevant metadata associated with the project. It assists in managing the project’s dependencies version, scripts, and more.
Both provide lock files (package-lock.json and yarn-lock.json, respectively). As defined by White Source Software: > The lock file ensures the same file structure in node_modules is maintained across all environments. This provides determinism, supports collaboration with other developers, and prevents code breakages from installing new or incompatible dependencies.
Yarn recently added a new feature to make it easy for users to transition from npm to Yarn.
npm 7, available now, allows for easier handling of yarn.lock files
Recent updates have brought npm's performance and security in line with Yarn's. #### The Upshot
These two package managers are quite similar, but pick one. Don't use them together. Although, with the latest updates, you probably could.
In general, both npm and Yarn manage packages——the dependencies and plugins you use in a software engineering project.
Don't let anyone make you feel dumb for using one over the other. For most devs, it's just a matter of personal choice.

Resources

https://www.whitesourcesoftware.com/free-developer-tools/blog/npm-vs-yarn-which-should-you-choose/

"Well, You LOOK Like a Coder!"

Jacob Fromm — Mon, 01 Feb 2021 01:32:20 +0000

This is the first thing my friend Anthony* told me when I joined our scheduled Zoom call. He was sitting in his sunny Bay Area home, and I was in Brooklyn, standing on an ergonomic mat, my notebook open upon my homemade standing desk, staring into a new webcam perched on my wall-mounted second monitor. Anthony may have been referring to my home office setup—did I mention the whiteboard to my left?—or my shaggy appearance and hoodie; regardless, I was buoyed by his observation. Because while I may look like a coder, I sure didn't feel like one.

"Oh no, not another blog about imposter syndrome!"

Yeah, well, when you live most of your life with a millennial's cursory knowledge of computer science, then spend four-to-six months working your butt off in an coding bootcamp and come out the other end digging through hundreds of job postings for "entry level" positions requiring three-plus years of experience, it's a syndrome you're likely to develop!

While you're in the midst of a grueling bootcamp, you only have time to focus on the task at hand. Although projects often lead to a substantial amount of independent learning, most of your time is spent learning what's assigned. In the first couple months after leaving graduating, you start gathering data. Who's hiring? What are they hiring for? What skills do candidates for those positions need to have if they want to be successful? In other words, you start getting a sense of how huge the software engineering world really is; you start to know how much you don't know. And it's at that point that you're expected to throw yourself into the ego-destroying machine that is the Big Bad Job Search.

Essentially, you're trying to pitch your commercial value from the pit of Dunning-Kruger's Valley of Despair:

"Why should you hire me? Great question!"

For those of us (bootcamp-trained junior devs) coming from non-traditional backgrounds, it's certainly satisfying to submit applications peppered with technical skills and projects, but let's not kid ourselves—these experiences don't stack up against engineers with real career experience. And that's ok! You're a lot more than those slightly-better-than-beginner dev skills you were so proud of just a few months ago, presenting your final bootcamp project on the cusp of graduation.

*"My guess is, junior developers are a dime a dozen." *
My dad blessed me with his version of a compliment with that sentence over the phone the other night. He meant that while I now have skills that make me better, they don't make me—in a sea of other junior devs—different. The good thing (and the point, really) is the things that do make me different were—major cliché alert—inside me all along.

As a developer, sure, you might not be the belle of the ball. But companies don't hire developers. (I mean, they do—at least I hope they do! Ahh! Panic!) Companies hire people. And you're a people! And I'd bet that, if you're still reading this article, you're a curious, hard-working, talented people—all the more so since you did that bootcamp. So keep going! You can't be an imposter when you're being yourself. You can be a stressed-out, inexperienced, bug-prone junior developer for sure. But not an imposter.

*name changed