10 Things I Learned During Hack Reactor — You Won’t Believe #1
I’ve written about my Hack Reactor experience here and here. Both those were while I was in the program. This post serves more as a retrospective now that I’m a few months out.
I think the best way to lay it out a is a top 10 list and hopefully get some clickbait action going. It’s also some good advice for anyone looking to do Hack Reactor.
10. Google is your friend
The internet is such an awesome resource, but it is also hard to navigate. Google really has done a fantastic job in organizing that data on the premise you learn to ask the right question. Learning to ask the right question becomes a super important skill.
My advice for anyone considering to pick up software engineering, start practicing your Google-Fu.
9. Dev Environments Continue To Be A Thing
I think it was in week 2 I encountered my first real struggle with a dev environment issue. It was relate to pathing in MacOS and installing via brew. It was my first time encounter this issue and I really had no concept about bash profile, pathing, etc. However after going through once, I ended up being and old hand when I had to go through similar experience setting up new environments.
The same goes for port in use. The first time I came across it I didn’t know what was going, but now it’s second nature.
Even if you are thinking that you can abstract all this with Docker containers, that’s far from true. You will also need to know how you manage/set up containers on your local, and there can/will be issues that arise when doing that.
8. Be Comfortable Being Uncomfortable
One of the recurring themes at Hack Reactor was your growth as a software engineer is directly proportional to your ability to be comfortable being uncomfortable.
This is a honestly a pretty big life lesson if you haven’t picked it up yet, but it equally applies to your software engineer growth. But the experiences that push you the hardest end up being the ones that grow you the most.
7. Make Sure You’re Doing This Because You Like It
Don’t do Hack Reactor (or any bootcamp) because you were lured in by my advertisement on how much you will make afterwards. That’s not to say they are inaccurate, but if you are doing this for the money then you are probably going to hate it. There are ways to earn more money if you are willing to pursue something you are willing to hate.
Software engineering is a trade, and it should be treated as such. Only pursue it if you like the the actual work, otherwise you will be in for a long grueling haul.
6. Async Javascript, Event Loop
One of the crazier intricacies of Javascript is it’s nonblocking thus async by nature behavior. I wrote about this in an earlier post, but it still remains one of the most valuable things I learned.
I’m by no means an expert on the topic, but being able to understand the core concepts has helped me reason out a lot of problems in real world software development.
5. Closure, IIFE
Here we have another technical concept making this top ten list. But really understanding closure/scope and how to use immediately invoked function executions to create closures is super important.
After basic syntax and looping, I feel that this is probably the second most important thing to know. If anything, knowing and understanding closures is kind of a requirement to work with asynchronous behavior in my opinion. It provides the framework in thinking about separation of concerns.
4. Reading Documentation
While Google is your friend, documentation is the source of truth. Not just truth, ideally detailed truth. It’s easy to pull up Google and throw in your question. Honestly, that will get you there 95% of the time. But the 5% where Google doesn’t cut it, you’ll have to do some more leg work.
Looking at the documentation is a great start. Documentation will lay out function signatures and optional arguments that an unlock great new ways to use the function. Examples are also often included. Moreover, sometimes looking over the documentation will introduce you to an API or method you didn’t know was available to you.
The big caveat here is that sometimes documentation sucks. Depending on the library or package you are using, the quality of the documentation may vary.
3. Never Give Up, Never Surrender
Related to #8, but the difference here is the result. With Software Engineering the thing to realize is there is always a way. If some cases, the solution may be convoluted, but there is always a way. However for more cases the solution is just something pretty doable you just haven’t uncovered.
Once you accept this, it means as long as you keep at it you will solve your problem.
I would like to point out one thing though. This is more of a lesson learned outside of Hack Reactor, but if you feel you really have hit a point where there is no solution, you’re requirements may be too specific. Take a step back, see if you can solve the same or similar problem in a different construct. It may be possible to move your problem across constructs to solve and then bring back.
Ironically this is a lesson I should have learned as a Mathematics major, but when I was learning it I was too focus on my use case of that concept.
2. Other People
Let’s be real, if you are reading this you probably are not a 10x programmer. You will need the help of people around you, whether it be for code review, debugging, explaining things, or just splitting work. Other people are a super valuable resource you cannot forgo, this was especially true in Hack Reactor. We were expected to consume so much knowledge in a short period of time.
For me it was super important to hear how other people thought about things I found confusing. If I had tried to grind my way through the understanding it probably would have taken twice as long for certain concepts.
This need becomes even more apparent towards the end when you start the job hunt, but more on that for another time.
1. Reach and Apply For Everything
The outcomes phase of Hack Reactor was a pretty eye opening experience for me. There’s a number of “secret sauce” items (not that secret, but still saucy) that I won’t get into, but the biggest thing I took away was a “Why not apply attitude.”
After my traditional undergrad education, I went on a job search. It took a while, but I landed a job through a connection. That led to other jobs, and other jobs, but all through connections. I never really had to go out into the wild and search for a job.
Not the case this time around. The biggest thing I learned is you should just apply to everything. It’s a pretty small investment on your part (once you’ve got the routine going) and you never know what the upside could be.
You know what you do know though? The upside for not applying is nothing.
Conclusion
There was so much more domain and life things I got from Hack Reactor. I’m not going to say you need to do it now, but if you are serious about looking for a change, especially in career and maybe how you approach things, I’d strongly recommend looking into it.
Had fun reading this? Found it useful? Recommend or share on Facebook/Twitter! Check out more posts on Always Be Coding.
