The Why

My current job had to be downsized, so I am now out of work. I need to find new work and I've decided to restart what I had been working on during the months leading up to my employment: front-end development. My reasons for picking this job are a few-fold. For one, after working for a translation start-up company, I realized that I need to find work in an area that won't be automated away into obscurity. The pay in translations is meager, although the job I had gave me enough to pay the bills. But I also had to deal with the constant stress of available work. We had weeks where no work was coming in, and meetings talking about poor business are never a fun conversation to have. So I need to find work in a field that will always be in demand so that my knowledge can serve as its own job security.

Secondly, I want to work a job that can easily translate into remote work. Given the instability of the economy, the pandemic, and all of the ills that have come from it, flexibility to work from home has almost become a requirement for me now. And having worked from home for the duration of my translation job, it has a lot of benefits that seem more relevant now than ever before. For one, I'm less beholden to fluctuating gas prices. Commuting to and from work is a stressful experience, and I don't live in a mixed-zoning area, where walking to work has legitimate health benefits.

Thirdly, software development happens to fit my interest niches. I like making things, seeing them on screen, as well as problem-solving. There's a certain kind of high a person gets when they resolve an issue they had been wrestling with, and the little feature they had been working on, actually works.

You'll notice that I have more secondary reasons to pursue this career path than primary ones. Yes, I'll enjoy this work more than other available career options, but at the end of the day, a job is a job. And I will inevitably have days where my work will feel more like work than having fun. And that's why these secondary factors become more important in my perspective.

The How

So now that I've decided upon this path, what does my roadmap look like? Before working in translations, I had been studying HTML, CSS, and Javascript. I plan on continuing that study, but with a different approach than I had in the past.

Prior to translating, I had been stuck in tutorial hell because I just didn't have the confidence or the direction on where to take that bulk of knowledge I had been studying. But this was dumb of me because I already had the tools from prior experience studying for the MCAT, possibly one of the hardest exams you could study for as an undergraduate student. The thing I have come to understand is that learning is most accelerated by doing. Not following, not listening, or watching. Doing. When it came to the MCAT, I made the most progress by dissecting test questions and actually taking the test under testing conditions. Studying the background information only provided me minimal help, and a large chunk of my studies was forgotten by the next day anyway. What stuck was when I struggled with a question for a while and had branching possibilities of solutions in my mind before seeing the actual solution itself. This accomplished building half of the needed bridge in my mind before connecting the rest from the solution. This almost always led to long-term retention because to some extent, I had participated in solving the problem. EVEN IF I WASN'T EVEN CLOSE. The simple act of engaging your brain in a creative way boosts your ability to remember that experience like an event in your life, like the first time you rode a bike, or when you went swimming during summer camp. Doing things becomes part of your story. Passively absorbing someone else's work, does not.

I believe this applies, not only in an academic setting but in all situations where learning is required. I learned how to drive better when I drove alone for the first time. I mastered the art of preparing seaweed soup when I did it without instructions. Cooking itself becomes a lot more enjoyable if you take instructions as general guidelines and you have room to experiment within the boundaries of those loose rules. They serve as the scaffolding and sandbox wherein I could play and experiment, but they should not comprise the entirety of my learning journey because no actual learning takes place when I'm being led by the hand and spoonfed.

So that's what doing looks like in other disciplines. How does that look in software development?

Projects

The heart of software development is actually making stuff. It's been a long time since I made anything so I intend to start things out by following a Youtube project on something simple like a landing page in order to re-familiarize myself with the syntax and general workflow. "But Roy..." you ask, "Didn't you just go on an epic tirade about how being spoonfed is completely antithetical to learning?"

That is correct. So instead of passively following instructions to complete my first project, I'm going to notate it with checklist objectives on the side. For example, if the instructor in this hypothetical video begins by setting up boilerplate information and importing the needed assets (like image files, .js files, .css files, etc.), then the first objective I'd write would say "Set up boilerplate information and import needed files" before continuing with the project. I'm going to try to not be too granular with every little thing the instructor does because the point is to learn how to make my own projects and google what I don't know. But by doing this, I am setting up prompts to follow as I attempt my own project right after (sans Youtube). One of the things that I felt that some online learning resources failed to do (such as freecodecamp, just as an example), was that they would teach you all of these disjointed coding concepts, but never connect them in the scope of a project. So treating these self-made prompts like coding challenges will be both useful when learning the syntax as independent concepts, but also will fit into the puzzle set that is the bigger picture of project-building.

Eventually, my goal is to be able to build my own projects from start to finish and add additional good practices and tools to my toolbox to better hone my craft.

Data Sets and Algorithms

This, from what I've researched on the topic, is an unfortunate nature of the beast. Countless software developers have said that these problems do not represent their job enough to be the requirement it has become in getting hired. That said, looking at the positive side of things, having this skill does prepare the developer to be better at solving problems. And while googling will always be a top skill for developers, knowing how to problem solve will be an equally critical skill because you'll inevitably run into instances where you're working with proprietary software and the documentation on it will be much more limited. This is why debugging your own projects is considered a very crucial part of the experience of this journey that many veteran developers advocate for. And I think taking on these problems can better prepare you to be in that mindset whenever you come across a seemingly impossible problem.

To that end, I'm going to commit to solving at least one to two leetcode problems per day. I'm not actually sure how difficult they'll be, but I figured I'd start with a modest number to set realistic expectations and scale upward as I get a better feel for it.

For anyone who has never learned software development before and wants to know where to begin, I do recommend freecodecamp to get a feel for the syntax, but don't spend too much time trying to learn everything. You'll never begin your first project that way. But rather learn the basics of returning commands and printing them to the console along with a few conditional "if, then" statements and "while" loops before starting your first project. I cannot stress this enough. The sooner you can get used to building projects, the faster you'll get comfortable with the actual job. I am only speaking this confidently because that has always been the case with all of my learning experiences in other disciplines, not to mention the countless testimonies of developers who now work in big companies like Google, Apple, and Netflix.

How and When to Apply

I need to find work soon-ish, so I am not going to waste too much time sending in my first application. After I have a couple of landing pages and an app under my belt, I plan to start applying for jobs. I understand that networking trounces online applications by an absurd amount, so I will be looking into connecting through Linkedin, Facebook, and Twitter, along with sending cold emails to recruiters instead of solely depending on job sites like indeed or zip recruiter.

I've been told that rejections will be a normal part of the process, so I'm going to try to mentally prepare for that inevitability. The thing is, I've been raised to deal with rejections very poorly. I grew up in a strict Asian household, and those who know me personally know that even a B+ was tantamount to career failure. This is a very toxic and unhelpful way to raise your children, and it makes them unable to cope and grow from failures. It's funny when we joke about it, but when it comes time for growth and change, you cannot raise your children to be ashamed of their mistakes or failures, nor be angry with them when they didn't achieve the scores you wanted (okay, mom?) So this will probably be the most difficult part of my journey as I try to interpret failures, not as a sign that this is an impossible career path for me, but rather as just a step toward further growth before achieving my goal.

So I hope you'll follow me on this journey as I work toward getting a job as a software developer. If I can help others in a similar journey, I think I will consider my mission at least partly successful. And thus begins my first step.

1. console.log("hello world.");