Forem: Alan Lee

From Bootcamp to Software Engineer, Part II: Challenges.

Alan Lee — Tue, 05 Mar 2019 16:30:03 +0000

The goal of this series is to share my journey on how I went from a bootcamp student to senior software engineer. Finding a new job after graduation was one of the toughest and most rewarding experiences I've ever had. I'm hoping that those who read this series could learn from the things I did right and from my many mistakes.

Be Ambitious

In the previous blog post, I had mentioned the importance of learning and why it's a core fundamental requirement to becoming a software engineer. In order to fuel your motivation to learn, you have to be ambitious and you have to constantly challenge yourself. If done properly, you're going to excel quickly and succeed in the industry. If done improperly, you'll feel defeated and burn out. The goal of this section is to learn about the time I crashed and burned, and the times I actually did it right.

I've had a lot of ambitions of wanting to try or learn something new, but the way I went about it often left me defeated. I've always told myself that I wanted to good at Go, Rust, Server Side Rendering, Blogging, and etc.,. Usually these fantasies fell short of being an accomplishment because I wasn't prepared, focused, or shifted to the hottest new tech that someone else was learning. My goals and the time that I had allocated to achieving them were not reasonable. There were times I tried to bunch all of these goals together (this is a bad idea).

Don't go at it alone

Find a friend who has similar ambitions as you and challenge each other. Have the other person give you exercises or obstacles, review your PRs, or evaluate your ideas. Treat this person like a gym buddy, someone to spot you when you need an extra push or to give you motivation when you feel like slacking off.

I've had a lot of fun taking on challenges with someone else. Usually, you can make a game out of it by using small wagers like coffee. It deters you from cheating because if you cheat, you are the one losing out and the most you gain is a cup of coffee.

Here are some of my favorite challenges:

Contribute to Open Source

I received the challenge to contribute to open source from a close friend, who is CEO/CTO of a start up. Back when I was unemployed and I was struggling through interviews, my friend had advised me to contribute to open source projects. He noted it was a great way to work with other people, get feedback on how to improve your code/habits, and it gives you challenging tasks/projects that are not self-defined.

I spent a few weeks trying to find a project to work on, one that would be simple enough for a newbie to the open source community. I eventually landed on Professor-Redwood: Pokemon Go Discord Bot. I was a pretty avid Pokemon Go player at the time, and was really interested in working with bots. I reached out to the maintainers and they were happy to have me help out. It took a while to get started and I was really nervous about submitting my initial PRs, but after a few weeks I was making changes like clockwork.

I eventually began taking a lot of ownership over the project, and I was made one of the admins. I helped with some small infrastructure issues, migrated the bot to Google Cloud Platform, and reviewed a bunch of PRs by new developers that had joined in. Although I'm no longer an active maintainer, I always look back at this project as my foundation (I actually got another job at an early stage startup from this project).

1 week of Vim

This was probably the most challenging exercise that I had to overcome. Not only did I come from a breed of developers who learned from GUI based editors, I had also just bought a split keyboard, the ErgoDox EZ: An Incredible Mechanical Ergonomic Keyboard, which I would be using for the entirety of the week. The wager would be one week of coffee from the elusive starbucks reserve.

The reason why I had wanted to use vim was because I had read that a lot of engineers get a huge productivity boost from it. Also, whenever you are SSH'ing into a box, you can't just prop up sublime text or VS Code, you’re forced into vim or an equivalent anyway. A lot of GUI based editors got their inspirations for hot keys from editors like vim or emacs.

Coding with vim on a split, ergonomic keyboard had a huge learning curve. It instantly dropped my productivity for the projects I had been working on dramatically for the first two days. Like, 3 WPM productivity. However, once I felt familiar and comfortable, I felt like a rock star by the end of the week.

90 (Consecutive) Days Of Functional Programming

I am currently 1/3 of the way through this exercise. The idea came up when I had lost a bet back at GopherCon 2018, and I was told 90 consecutive days of Go with at least one relevant and meaningful commit, per day. With this challenge, it was extremely difficult because I tried my best to avoid using a computer during the weekends or vacations to clear my mind. I had tried to do this challenge five times, before giving up due to lack of ideas on projects.

The Go Programming Language had been a language that I had wanted to learn, even during the days I was at a bootcamp. It touts great performance by using a safe concurrency model, readability from an opinionated linter, and type safety. Additionally, it was a functional language as opposed to an Object Oriented Programming Language. Fundamentally, a lot of these concepts were different from Node.js. That was a lot of the draw for me, I wanted to expand my skill set with a different way on approaching problems.

With this challenge I set some core projects, all of which are small, manageable and extendable after they are completed. The toughest part of the challenge is a commit for 90 consecutive days, however this taught me to use my 90 days wisely. If I had been working on one project for a bit too long or if I was stuck, I'd shift priorities about learning a foreign Go concept for a day. As long as it had contributed to my goal, I'd do it.

Core Projects:

lambda functions to replace services (for work)
database utility tool (for work)
Go HTTP server
Form Scraper (for work)
Rebuild a previous Node.js project, the Go way

Side Projects:

Exercise and practice a Go fundamental concept (slices, channels, go routines)
Learning about profiling
Learning about debugging
Best Practices with Testing in Go

Having a task list of projects also helped. For each new project that I had started on, I listed out core fundamental features that satisfied the requirement. When I had a new idea for a feature, I would add it to a list for version 2, so I would not fall astray from completing my initial goals.

Pro-tip: Lambda functions are great for one off projects. If you've never heard for AWS Lambda, Google Cloud Functions, or serverless based technology, it's essentially meant to be a function that gets executed on invocation, but it does not stay online and idle waiting for your next call as opposed to a server. A container is spun up, your code is executed, and the container is destroyed. Serverless functions should be kept small, and should be used to accomplish one thing simply, reducing the run time and memory usage.

With this approach, I'm learning the language through practical use cases, and the repetition of doing it daily has made me familiar with the syntax and nuances that I've come across. Having myself do a commit everyday has kept me focused on the underlying goal, while giving me some leeway on working on other things.

The Challenge Framework

I developed a small framework for creating new challenges.

Simple
Complexity
Measurable
Time
Realistic

Here's some examples of those that fit the framework:

Answer 1 question a week on Stack Overflow
90 consecutive days of functional programming (1 commit a day)
Obtain an AWS Solutions Architect in 3 months time

Here's how the challenges in the example fit the framework. They are simple; I'm not mastering anything, but instead each of them have the verb of doing something. They offer a level of complexity, things that I'm not used to doing such as answering questions on Stack Overflow, or programming in Go. The goals are measurable by the number of things that I am achieving in a given timeframe. Finally, the goals are realistic enough to fit my current schedule. I know that these are things that I can commit to.

My framework isn't always perfect for everyone and everything. I try to use this as a general guideline on how to approach something rather than approaching things in absolutes. Figuring out how to challenge and motivate yourself is a challenge in itself.

Sounds Solid, But Ain't Got Time For That

Challenging yourself... sounds cliche right? It is, but there is a reason why I am talking about it. This is not a self help, motivation, or better yourself series. However, you should know that no one is going to push you or get you to the next level other than yourself. It does not matter whether you went to the top/highest rated bootcamp with a post-grad hire rate of 98%+ or received a Computer Science degree from a great university, you need drive to move to the next level.

If you don't enjoy being challenged then software engineering is not for you. This is the fight or flight scenario: You're going to be put in many situations where you're going to have to learn a new programming language, use an unfamiliar tool, switch to a different vendor (AWS to Google), work on a code base where styles/guidelines are different than what you're used to, or run into a complex product requirement due Monday. The best way to prepare yourself for those types of challenges is to training your “doing” muscles.

Conclusion

Challenging yourself trains and prepares you for challenges in the future. There will be a time in your new job or new career, where you will have to get yourself ready to learn the next thing. Do your best to manage expectations and develop a plan to set yourself up for success.

For my next post, I will actually go into some tips of highly effective new developers. Stay tuned.

From Bootcamp to Software Engineer, Part I: Learn.

Alan Lee — Wed, 27 Feb 2019 15:31:58 +0000

The goal of this series is to share my journey on how I went from a bootcamp student to senior software engineer. Finding a new job after graduation was one of the toughest and most rewarding experiences I’ve ever had. I’m hoping that this series could help others learn from the things I did right and from my many mistakes.

How To Learn

One of the first lessons that coding bootcamps teach you is how to learn. You go through a checklist of finding the appropriate material for your level of understanding (with the assumption that you don’t have a strong technical background), how to find help or the right resources, and how to constantly ingest information, new concepts, or solutions that come your way. The bootcamp taught that this is a fundamental skill that all engineers needed in order to be successful, because we are always learning.

Initially, I thought to myself that I had not forgotten how to learn. Working as a project manager or product manager, I learned new things everyday. Through repetition, I was able to train myself to make of habit of things. If a certain issue had occurred, I would do the following: evaluate the situation, attempt to remedy the issue as I had done previously, google it, or ask someone who is much smarter than myself. At the time, it sounded like this initial fundamental skill that my bootcamp was focusing on was something I had already mastered.

The Difference Between Learning & Understanding

As I was going through the curriculum, I was learning but I did not always understand the underlying concepts. For example, I learned that javascript had asynchronous characteristics but I did not understand what it was that allowed it to be asynchronous (i.e the event loop; the heap, queue and stack). During my studies in the course provided materials, these details were omitted and probably for good reasons. Coding Bootcamps are designed for non-technical people to get a general grasp of programming skills. None of the course content is tailored for an individual, but rather for many, many students. You’re not expected to understand how the event loop works, only that it exists and it makes JS awesome, because most jobs do not require you to. Your focus, initially, is not to worry about scalability or all the cogs that makes the machine work, but to build a minimal viable product that just works.

My mentors have stressed that I shouldn’t spend too much time on focusing on the how or why of things, but to get as much hands on coding exposure by working through projects. They had a fair point; if I jumped down a rabbit hole of understanding how the anatomy of the event loop, understanding how Node.js works with the V8 JavaScript engine in-depth, or other areas of focus, then I would not be able to get any of my projects done. However, they did not discourage my curiosity for learning or understanding the questions that I had but instead they asked me to progress through my challenges at hand and do the research on my own time.

So I did. Anytime I was not working through my challenges of building a http server and connecting it to a database, I would take the time to try and figure out how things worked. On my BART commute or during my breaks, I would read articles on Medium or Reddit to strengthen my knowledge of the domain that I was trying to grasp. If during my challenges/projects, I would come across a new concept, I would write a bunch of notes on the concept or add a TODO comment to come back to it later.

I would meetup my peers, during the week, where we’d help each other try and understand things that we’re interested or stuck on. People learn differently, and some concepts are easier to ingest than others, therefore it was great to gain perpsective on how others were able to understand something that you may not understand. These meetings were one of my favorite moments during my journey of going through the bootcamp curriculum because it taught me to learn and teach others.

Learning Better (and Efficiently)

Building a habit to explore my curiosity in tech helped me throughout my career. It allowed me to continue to stay hungry; interested in new and foreign things. I would experiment with new concepts, trends, and best practices every day. I’m a hands on learner; I use my portfolio projects like specimen for me to experiment on. It helped me take the idea of learning to the next level.

Whenever I came across something interesting that I wanted to try, I would do the following:

Draw a diagram of to make concept easier to understand
Map out how I am going to achieve the goal in a current project
Implement it in my current project as it’s own isolated function
Write Unit Tests for that function
Tweak the function to make sure that it satisfies all my cases
Documentation: Use JSDocs, write lots of comments, create markdown notes for a README, and/or saving snippets in Evernote/BoostNote

Pro-tip: If you see a solution from stack overflow or from a colleague/peer, but you don’t fully understand it, write a unit test for it and make sure to also have a debugger on so that you can step through the functions with breakpoints. You can choose to select and watch certain variables to see if your data mutates, or if a behavior working as intended. You will also make sure that the code you found works with what you’re trying to do. console.log, println, fmt.Println, or etc., does not always tell the other entire story.

Not only does doing these things help you learn and understand things in a better way, adding it to your workflow is a great skill that employers desire. It shows that you’re not a Full Stackoverflow Developer, that you go beyond copy and pasting or ingesting answers, and you actually know and understand what you are doing. I ended up making a list of things that I wanted to learn things daily by queueing them up in my bookmarks tab in Chrome, and I’d go through the list at the end of the week where I’d allocate time to experimentation or going in depth on things that piqued my interest.

Even after graduation and obtaining a new job, I still continue this practice regularly. The best way to fight imposter syndrome when getting a new job is to use your time to ramp up, wisely. Don’t stress about it because you’ve just developed a way to learn and understand anything and everything. Think of it as going from apprentice to master. One doesn’t simply master something just by learning, but by truly understanding something and really knowing the subject matter at a greater depth.

OK, Got it… What else?

Bootcamps have the stigma that they just ship out students that know the very basics of how to code and nothing more. They believe those graduates don't have the fundamentals from a computer science degree or their portfolio projects are not comparable to actual on the job experience. In the eyes of the industry for a bootcamp graduate, depending on your market and experience, you're usually a few steps behind those with a CS degree. This is definitely not always true.

What you learned and the entire experience you just went through is what you make of it. If you really want to stand out from the newly minted developer that just graduated from a bootcamp, then you have to be passionate about continuous learning. Often hiring managers will judge you on what you really know from the things that you’ve put on your resume. Remember anything you put on your resume is fair game for interview questions. So if you say that you are “advanced with Node.js”, I’m going to expect you to know how to use the built in debugger over console.log. This is not something that you should expect out of your bootcamp because their job is to get you started. Once you've gotten your feet off the ground, you need to take the next step forward to up your knowledge and game.

Side Note: You’re also better off learning about learning languages and their core fundamentals rather than focusing solely on mastering frameworks. In the JS ecosystem, new frameworks or libraries come out all the time, so it’s much more valuable that you understand the language.

Also, avoid listing a lot of items as skills on your resumes if you’ve only had minimal exposure to them. You can always add those skills that you’ve had minimal exposure to inside the bullet points of the job description, and explain how you used in a project. Anything you list under the skills section is fair game for deep dives or interrogation. I’ve interviewed many applicants and I generally derive questions from their skills; a fair amount of these applicants only used the underlying tech once or twice, but did not really know much about it.

On the Job Training

When I got my first job out of a bootcamp there was a lot of information you have to prepare yourself for to get ready. I was hit with having to figure out how to setup upstreams and a http proxy with NGINX on top of a node.js application, how to scale a node.js application, usage of different databases that I’ve never heard of, and many more. On top of stack and infrastructure, there’s also a bunch of tribal knowledge, such as why previous developers made a decision to do something over another, or the different quirks of authentication and session management that services have to go through. No one learns and understands that all on day one. The important thing is to not freak out, and have the perseverance and drive to digest all of this information at your own pace.

Conclusion

To be clear, I’m not advocating against attending coding bootcamps. I feel they do the perfect amount of getting you started, and having you continue on your own. At some point, you will have to leave the nest and continue learning on your own. During my job hunt, I figured out that to learn is to adapt. Going through job descriptions for the first time, you may not have learned how to scale Node.js applications, Dockerize applications, use NGINX, build microservices, or use AWS (not just S3 or lambda). I had to take the time to learn and understand it prior to applying for that job, just so that I’ll feel like I have the edge over my peers or the other 100s of candidates applying for that job or that I am adapting to become an ideal candidate.

I’ve always kept learning and trying to understand things as much as I can. I graduated from a bootcamp about two years ago and I’ve accomplished a lot. I’ve become a Engineering Team Lead for a Product (twice for two different companies), obtained a AWS Solutions Architect Certification, played a integral role for a company to migrate their on-premise infrastructure to AWS, and I am currently a Senior Software Engineer at Zendesk. I did not save this part for myself to brag about my accomplishments; a lot of my peers who did find great jobs or have greater accomplishments than mine, are always constantly learning, trying to understand, or experimenting with new things. I truly hope that your results will come out better than mine.

TL;DR: Keep learning and really understand your domain well. Work your way towards mastering the things you want to do good enough. Experiment with things and try to know the ins and outs of how things work. Take 5–10 minutes to read an article about your domain or try something new.