My First 3 Months At A Startup

Table Of Contents

• My Background
• How I Got The Job
• What I Currently Do
• Stressful 1st Month
• Productive 2nd Month
• Frustrating 3rd Month
• Life During Those 3 Months
• What I'm Looking Forward To

---

My Background

I don't have a CS degree and went the boot camp route of learning programming (think of it as a technical training program). My experience was more in being a full-stack developer in the MERN/PERN stack. I go into depth about my experience with a boot camp in this post.

How I Got The Job

I want to say I got the job by pure coincidence. The CEO of my company and my friend were mutual friends. My friend brought it up at one point that he might be looking to hire someone onto the team and so that is how we connected and eventually sat down for a coffee and had a formal introduction.

We kept communicating back and forth for a couple of months and to be honest I really didn't think it would pan out with gaps in our communication. I later found out that the CEO was going through a tough time of his own and it all makes sense now looking back.

What I Currently Do

At the moment I use Chef and Ansible to write "scripts" to harden Linux based machines to meet certain benchmarks that are hosted on AWS(Amazon Web Services) and Chef InSpec tests to make sure everything was hardened correctly. It is definitely not something I learned to do while in school but I was able to learn on the go and increase my productivity.

Stressful 1st Month

I wanted to get up to speed ASAP that when I first started I jumped right into writing Ansible playbooks. I started by making a copy of a playbook for a different OS and started adjustment to it to make it meet my needs for the controls outlined in the benchmark.

I immediately started making the following mistakes:

• Didn't read the Ansible Docs nor read the benchmark diligently.
• Didn't question why things were written a certain way in the playbook and let them slide.
• Read-only the audit and remediation from the benchmark and not the description that came before it.
• Didn't understand how certain things worked but kept working on the stuff I understood.

The first month was focused on working in Ansible and writing tests for those controls. Towards the end, I started understanding more and more of what was going on and started asking questions that either provided an explanation or resulted in something getting corrected because it wasn't written correctly. I was able to learn more about Linux based OS' and a little bit about running commands in the terminal.

Productive 2nd Month

Halfway through the 2nd month, I was able to finish up the playbooks for Ansible. At this point I was a lot more comfortable with using Ansible, I had managed to read a lot more of the documentation as I progressed from problem to problem which forced me to find solutions using Ansible.

After finishing up with writing the playbooks to harden OS' I then hopped on cleaning up a script we used to create AWS AMI images. We had three different scripts that were targeting three different kinds of images and I noticed that there were inconsistencies in multiple areas across the 3 files where things were supposed to be consistent. Basically, the scripts didn't follow the DRY principle. We were manually copying things from that script and pasting it into the VM one at a time. This was time-consuming and susceptible to introducing errors because of the potential for copy and paste errors. Someone eventually mentioned that we could theoretically refactor the scripts into an Ansible playbook and we could use prompts to ask different questions depending on what kind of image we wanted to create.

Having refactored the scripts and automated it as much as we possibly could, I was very happy and excited that I no longer had to manually copy and paste all that stuff. Towards the end of the 3rd month, we add a few more things to that playbook and we were able to keep it to one prompt and everything else was automated. The automation of the scripts helped speed things up so much I was able to have 9 different terminals open and running the same script on 9 different VM's at once and I only had one prompt per VM and I didn't have to worry about making mistakes with copy and paste along with selecting incorrect files. I was so overjoyed to have gotten it to that point.

Frustrating 3rd Month

After I had finished everything with Ansible I moved on to creating Chef Cookbooks. My first gripe with Chef was their way of naming products. The search engines search for the stuff you don't need when you have to use the words chef, cookbook, or recipe in your search query. This time around I sat down and read the whole documentation for Chef Cookbook. I think that reading docs beforehand actually helped me to an extent. I learn best when I do things hands-on but if I read something somewhere and I have an issue later I can recall that it's possible I just can't remember how it's done.

Setting Up A Chef Server
The first frustration I had was with setting everything up to make Chef communicate with the client. I initially struggled to manually set up the Chef Server using AWS VM's to connect to the Nodes(system that we would harden). I wasn't able to make it work and then decided to use AWS OpsWorks to connect to it and it worked immediately. Of course, that is the case when you pay for someone's services. While going through this struggle of setting up the server so I can execute the Cookbooks, buried in the documentation I discovered that I could have avoided setting up a Chef server by using chef-run to execute the cookbook.

Editing Files With Chef
While writing cookbooks I think I was spoiled by first starting with Ansible(I do appreciate how neat cookbooks look). It seemed so simple and I had everything I needed to write the controls. In Chef, there was no resource to edit the contents of a file and I had to resort to using either block of ruby code or grep/sed commands. This was actually a good learning experience because I had to look into other solutions for this particular issue and I was able to learn more about the grep and sed command-line utilities and how powerful they are.

First Month Mistakes Catching Up
By the third month, I had read enough of the benchmark that I knew that I needed to read the descriptions to see what they were trying to accomplish, this is where the pressure of getting up to speed the first month came back to bite me. I had missed so many critical details and I had this same problem across the board for all of the OS' that I had written playbooks and cookbooks for that I had to go back and correct my old work. While going back and reviewing things I realized that we needed to mount a partition.

This is where I discovered that method of mounting a new partition is different from OS to OS and version to version. This required me to mount a partition with all the required options and mount partitions with default options and then add options to them if they don't have the required options. I would then proceed to reboot the OS to make sure my changes still existed after a reboot. This required a lot of testing and patience to figure out what worked and what didn't work for each OS that the company supported. I found out that in CentOS 8 that if you mount the tmp improperly it'll consume about 0.5-0.75GB (I would launch the instance with about 1GB of RAM) of RAM and not release it to be used for something else. This confused me so much because after a reboot and attempting to run a test I couldn't log into an instance and I was left wondering if I had somehow messed with the keys that I wasn't able to log back into the instance.

Peer Reviews
Through this whole process, I and my coworker started peer reviewing each other PR's to help catch mistakes and ask each other why we used one approach over another. Through this process, I found out that I was a bigger stickler to consistency than I had really anticipated. This drove me nuts and I'm still learning how to let things go if the code works correctly.

Life During Those 3 Months

Work-Life Balance
Well, right now that doesn't exist at all for me. I've been putting in a lot more hours than is required of me at work and at the moment I'm ok with that. At the moment I'm not concerned about the number of hours that I've been putting in at work but I'm starting to think about my mental health a bit more. I want to reduce the chances of burning out at work. This will have a big impact on my performance and personal life as well. I burnt out about a year back as well and I just had no desire to code nor be involved in the coding community. It was a tough patch but I was able to get myself up and get back on track.

Tutoring
During this time I also begin tutoring someone who was going for his CS degree. I actually enjoy this because it forces me to think of creative explanations for different methods and how certain code works. This was a test for me as well to see if I can apply my JavaScript knowledge to Java. This was a bit frustrating sometimes because I'm not used to declaring variable types. I also wasn't familiar with Java array and object methods which were frustrating at moments.

New Year Resolutions
Towards the end of the 3rd month, I decided to review my simple New Year resolutions that I had made for myself as a developer and I realized that I couldn't even hold myself to those simple resolutions which would have helped improve me in multiple ways. Pretty disappointed in myself that I couldn't even do those simple things.

What I'm Looking Forward To

• At work, we'll be starting a new project soon and I'll be back on working in the backend using Node and am stoked to be developing apps once more.
• The company has office space now and I'm looking forward to working somedays from the office to break up my remote life a little bit.
• Focusing on my mental and physical health more
• Doing some of my New Years Resolutions
• Being hired on as a full-time employee.