DEV Community: Russ

My First 3 Months At A Startup

Russ — Mon, 30 Nov 2020 19:28:17 +0000

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.

My experience of being in a Chingu voyage

Russ — Fri, 20 Mar 2020 20:11:39 +0000

What is Chingu.io
Why I decided to go on a voyage
My review of Chingu.io
My role in the voyage
The voyage
Conclusion

What is Chingu.io

Chingu.io is a global collaboration platform that connects motivated learners who have shared goals to learn, help, and build together. It offers you the opportunity to go on a remote 6-week Voyage where you will build a project in a remote team and level-up with the technical and soft skills required in a professional software job.

Why I decided to go on a voyage

The one question that I kept seeing come up on my interviews was "Do you have any group experience?". After speaking with some friends and doing some research online I settled on Chingu.io as the place where I would like to gain my group experience. It used to be free but they now charge $30 (6 lattes) for the experience which I was ok with.

My review of Chingu.io

Chance McAllister and Jim Medlock did an awesome job of setting it up and running the program. The documentation they put together for everyone is very detailed. I personally didn't find anything lacking and was able to locate everything I needed.

I think the first thing that immediately got my attention was this image about defining an MVP. I've always heard people talk about it and read about it but this visual representation just made it click in my mind.

Some of the detailed documentation that they have put together have titles such as:

Git - Defining a Workflow
Git - Branches
Git - Commits
Git - Pull Requests

and many more that are helpful for developers at the early stages of their careers.

My role in the voyage

I ended up being the project manager for this project because I had the "most experience" in a full-stack environment. I didn't want to be a project manager because I knew I greatly lacked in that area but agreed to step up to the plate. I know I wasn't the best project manager because I have never been in a managing position but in the future, I believe I could do much better if such an opportunity arises. There is so much you could do when you have a full-time job, have to review code, and also write your own code. It was definitely an experience I believe everyone should have just so they could see some of the things a project manager goes through.

The voyage

Demo
Github

Week One
We were immediately at a disadvantage because we had our first meeting at the end of the first week due to differences in our schedules. After going back and forth attempting to find a project we could all get behind one of our members suggested a live chat app. Cloning Slack was brought up and we stuck with it and ran. We also agreed that we could probably not accomplish a full clone of Slack but we were there for the experience

We decided to use the MERN stack to attempt to clone Slack. When setting up the project I decided to have two separate repo's, one for the frontend and one for the backend, and immediately got asked by the group members why I was setting it up that way and I said that is the way I was used to. After some discussion, I decided we needed a vote on this, and the majority of the team choose to go with a mono-repo. I wasn't familiar with how mono-repo's worked but since the group members had the experience I figured I would ask them questions when the time comes for deploying the mono-repo on Heroku. I did some research and found out that Google is known for using mono-repos, so I told myself if Google does it I might as well learn it also.

I personally preferred working on the backend but two members wanted to get more experience with MongoDB so I decided to step back and let them take care of it and jump in whenever they needed help and focus on the frontend (I, unfortunately, didn't touch much of the frontend due to a number of reasons)

Weeks Two-Four
After breaking down Slack into different MVP's that we could target, I decided to target this for the scooter portion of the MVP

A user can signup
A user can Create/Read/Update/Delete a comment
A user can update their name public name
A user can see other public comments
A user can see when a comment was posted

It was a good first goal and it took us a little bit of time to get up and running. I setup up the MongoDB server and got it all hooked properly so that everyone could have access to the database and delete users when they need to through Compass (GUI for MongoDB). I also set up the authentication on the backend and while setting it up I realized that I was passing through sensitive information into the JWT payload and had to dial it down to only include just the necessary things to verify the user. I also realized that re-reading the documentation on how to use Passport.js on the authentication can help you save like 30 minutes because it defaults to look for a username in the body and I was attempting to pass through the user email for logging in.

While everyone was committing files to the dev branch I noticed that everyone had their own styles and that we need to clean up the files and keep them consistent and that the tests weren't passing when people pushed changes. I first used Husky to set up Prettier in a pre-commit hook to clean up the files so that things were consistent. Since this was a mono-repo I had to use Lerna to run Husky pre-push hook to run tests on both the frontend and the backend, this was a bit more of a struggle for me but I was able to figure it out.

We were able to accomplish the first goal and I'm really proud of the team that we were able to make so much progress.

Week Five
Since we were able to accomplish our first goal we decided to target our second goal.

A user can send, Create/Read/Update/Delete a private message
A user can start a thread on a comment
A user can view channel details
A user can create a new channel
A user can view how many members a channel has

We had also voted to remove the pre-push hook because of merge conflicts. I had the pre-push set up like this: git fetch && git rebase origin/dev && lerna run test. I believe the reason we had so many merge conflicts was that we had multiple people working on the same files. After removing it I noticed that some things were being removed because we were no longer merging things that I'll have to go back and clean up at a later date.

About at this time, we also decided to incorporate socket.io so that all users would get real-time updates to new comments being created, edited, or deleted. I'm thankful that one of the teammates decided to dive into this make all work beautifully at such short notice.

With a time crunch on our hands, we decided not to implement private messages but leave that for the future.

Week Six
It was during this week that I was moving cross country and wasn't able to help the team that much on the project. I'm really thankful that the rest of the team was able to get so much done while I was moving.

After having settled down I was able to work on deploying the app on Heroku. There were somethings that had to be corrected in order for the app to run in production and had to change the name of a file that worked in a local environment but not in production.

Conclusion

The painful part
There was no testing. Before this project, I got into a good pattern of doing TDD and this was a hard thing to let go of but I'm really hoping I can add tests in the future and get back into TDD.

Overall Experience
The Slack Clone we created is not complete but for a 6-week effort, I am really proud of the team. I know some of us will continue working on bugs and new features when we have free time to make it even better. We were able to make so much progress as a team and were able to help each other out whenever we got stuck. Some members of the teams had job interviews and the other team members were there to morally support them if things didn't go well after the interview.

It was a really good experience to work in a remote team and to gain this experience of working in an agile environment. I'm thankful that the group stuck together till the very end and the friendships that we created. If anyone wants group experience I highly recommend that they signup for a Chingu.io voyage.

Reflection As A Project Manager
I have a lot of work to do in this field and have seen how much I need to grow as a developer to make big decisions on what technology to use in the app and to know specific reasons as to why we are going to be doing things one way over another. I didn't realize that I would be doing less coding and a lot more code review.

How was your first experience with working on your first group project? Please share your experience in the comment section

My experience with a coding bootcamp

Russ — Sat, 01 Feb 2020 06:58:42 +0000

Why I became a developer
What is a bootcamp
Why did I chose a coding bootcamp
How I chose a coding bootcamp
The structure of the coding bootcamp I chose
Mistakes that I made while going through the curriculum
My review of my bootcamp
What I'm thankful for
What I would have done differently

Why I became a developer

When I was in middle school and high school I had the opportunity to mess around with a robot and really fell in love with the coding side of things. I enjoyed telling the robot what to do and immediately seeing the results on how clear your instructions were to the robot. In high school, I was in a technical academy and decided to pursue Mechanical Engineering but the prerequisites were just so mundane that I would just lose interest in the courses. I wasn't driven by A's and 4.0 GPA's, I wanted to get involved immediately and ended up leaving that for some other work-related courses.

At one of my jobs, I had a coworker that went through a bootcamp and had suggested it but I dismissed it and didn't think much of at that time. My HR manager suggested at one point that I should look into it but I also dismissed it. After leaving that job I really started thinking about what I enjoyed a lot and realized it was coding was similiar to robotics and decided to jump into and remembered my co-worker and HR manager had suggested I look into a bootcamp

What is a bootcamp

A coding bootcamp is an innovative new form of short-term, intensive, and often immersive education designed to provide aspiring tech professionals the technical skills they need to start careers in software engineering and other tech fields.

Why did I chose a coding bootcamp

I'm a hands-on learner and that is the best way that I retain information.
Coding bootcamp's are a lot shorter than a 4 year CS degree
Companies like Google and Apple are no longer requiring a college degree to get a job I didn't see any reason why I should go through a 4-year school to break into coding.

I had the time and some money saved up to focus on the bootcamp so I pulled the plug and jumped in.

How I chose a coding bootcamp

My priorities were price, location, and online reviews. I looked at some of the local bootcamps that were offered to me but the thought of paying for parking every day in downtown for 4-6 months for 8 hours just scared me away (looking back I could have parked further out and used public transportation to get to the location). So after figuring out that I didn't like the idea of spending so much money for parking I decided to go for an online bootcamp.

The structure of the coding bootcamp I chose

For 6 months I would work solo through the curriculum and would meet with a mentor twice a week for a 1-hour session to discuss my progress and if I had any questions. After completing the course I worked with a career coach that guided me through revisions of my resume and helped me respond to emails from companies if I wasn't certain about my response.

Mistakes that I made while going through the curriculum

I graduated at the wrong time
I didn't request a different mentor sooner. I need someone that would have kept me on track better and push me to get more done with the amount of time I had on my hands
I got too attached to my personal projects and tried making them as perfect as possible before submitting them and not just making them barely pass the requirements so that I could move on with the curriculum
I asked too many people that same question and got different opinions which left me in the same spot that I started

My review of my bootcamp

Some of the mentors were there for the money or weren't cut out to be mentors. Other mentors weren't as familiar with the MERN stack and would give you answers from StackOverflow that you have already tried.
Mistakes in the curriculum weren't corrected at all it seemed like. I would ask myself "How many other students noticed this mistake and reported it and why is it still here, it's an easy fix".

What I'm thankful for

The mentors that really loved their jobs as developers and as mentors and weren't there just for the money
The student's that I met along the way and was able to become friends with and still stay in touch with even though we never officially met besides in online sessions
That I was introduced to meetup's and was able to meet other developers in my city, I didn't know what meetups were before this

What I would have done differently

I think I would have potentially selected one of the local bootcamps and would have figured out the parking situation downtown. I believe a bootcamp that has you work in a group on client projects would have helped me gain actual-world experience sooner. I might have chosen a bootcamp like Epicodus where students finish their studies with a five-week internship.
If I were to take my bootcamp again I think I would have gone the group route that way I could get that experience of working in a group.
I would aim for graduation in mid-late December. I graduated in May right before everyone goes on vacation during the summer and then you have a little bit of a hiring season in the fall before the holidays and few posts during the holidays.

Please share your experience in the comment section

Bootcamp grad? What is your experience with the bootcamp that you went through?
Hire a bootcamp grad? Did you notice any differences between bootcamps and what do you think a bootcamp could do differently?

My 2020 New Years Resolutions As A Dev

Russ — Wed, 01 Jan 2020 11:48:20 +0000

Why?

After watching Veritasium's new video about Why Most Resolutions Fail & How To Succeed I decided to make some New Years resolutions for the first time. The reasons are:

Making smaller goals is easier to hit consistently. Getting 1% better a day doesn't require that much effort and the effects will compound over time.
Once the habit sticks I could make it more ambitious.
I'm 42% more likely to achieve them if I write them down.
I'm 10 times more likely to stick with a New Years' resolution 6 months later.
It's a new decade.

My Resolutions

Learn 5 new technical terms every week.
- Why? I've always struggled to learn new words and remember them if I don't use them, so I want to make an emphasis on learning and retaining new technical terms.
Answer at least one question every 2 weeks on a Question/Answer site like Stack Overflow or Slack group.
- Why? Help me become better at answering questions and being able to explain my answers.
Do 1 coding challenge a week.
- Why? I find that I forget things if I don't practice them. This will help me retain things better.
Exercise/Stretch for 5 minutes every day.
- Why? I don't exercise much these days but I am concerned for my physical health in the long run so I'm hoping to start a good long term habit.
Write 1 blog post a month.
- Why? I want to look back in the future and see the progress that I've made as a developer and a blogger.

Your Resolutions

If you made a New Years' resolution to help you grow as a dev in 2020, it would be awesome if you share it in the comment section and maybe motivate someone to make a New Years' resolution of their own.

My Experience With Test Driven Development (TDD)

Russ — Sun, 29 Dec 2019 02:29:49 +0000

What is Test Driven Development (TDD)?

TDD is a software development approach in which a test is written before writing the code. Once the new code passes the test, it is refactored to an acceptable standard. TDD ensures that the source code is thoroughly unit tested and leads to modularized, flexible and extensible code. It focuses on writing only the code necessary to pass tests, making the design simple and clear.

Unlce Bob has three rules for TDD:

You are not allowed to write any production code unless it is to make a failing unit test pass.
You are not allowed to write any more of a unit test than is sufficient to fail, and compilation failures are failures.
You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

My Experience

What I'm Working On

I'm refactoring a project of mine to use SQL instead of NoSQL and I was going to do certain things a little differently so I decided to rewrite my whole backend.

First Thoughts

I was completely lost about where I needed to start because I was thinking "how could I reference something that doesn't exist?" but then I'm like "oh duh the test will fail so then I would need to create all those files to make the test pass".

How I Immediately Broke The Rules

I started by forking a boilerplate that I had created and created the basic files .env, error-handler.js, logger.js, validate-bearer-token.js and set up the test file. Looking back now I think I immediately broke rule #1 because I wasn't trying to pass any test and later on I corrected this by not creating files until I had a test asking for that file.

The next thing I proceeded to do was create my SQL files and get my schema's defined and add the correct npm packages to make my database connection work. I decided to define my schema before writing my test for it because I need to see what query strings I would be writing and have it all defined in one place so that I wouldn't be going back and forth on my tests. I believe this breaks rule #1 as well.

My First Test

My first test was simple and I was able to make it pass very easily. I was testing that my empty database responded with an empty array.

My Second Test

My second test would insert data into the database and it would respond with all the data that was just inserted. The test immediately failed because of a schema design flaw from my end. I had circular references in my tables. In the business table, I had this column: address_id UUID REFERENCES address(business_id) NOT NULL UNIQUE and in the address table I had this column business_id UUID PRIMARY KEY REFERENCES business(business_id) NOT NULL. This would require that both tables be created at the same time to even make the insertion possible.

I was thinking that my second test should be just as easy to make it pass but it showed me that I couldn't even design my schema correctly and I spent a lot of time rewriting and rethinking the design of my schema. It showed I still had a lot to learn about SQL schema design and I was able to learn a lot about schema design from the dev community on slack.

The Tests After

After I had defined my schema correctly, writing the tests after seemed so much easier and required less research on how to set things up correctly.

Conclusion

I believe using TDD would have saved me a lot of time by not doing a lot of manual testing each time I made a change to my schema or code. The test will do the comparing for you and immediately tells you why it's failing.

Using the TDD approach allowed me to dictate how I wanted to see the response from the server and then writing and rewriting the code to make it pass. It showed me the areas that I was shallow on as a developer and it made me go out and learn more about that particular subject just so I could make my test pass.

TDD will immediately show you how well you know what the response should look like from the server. Still being an entry-level developer it has shown me that I still have a lot to learn about how Postgres responds and how it inserts data. Sometimes I had to console.log responses just so I could write the tests and know what to anticipate from the server.

I see the TDD approach very beneficial to helping entry-level developers become better developers and will make my best effort to continue using TDD in my projects.

HELP WANTED: I'm not much of a writer so if you know of good articles that helped you become a better blogger on dev.to please do share them with me in the comment section.

My first Coderetreat experience

Russ — Sun, 17 Nov 2019 22:34:11 +0000

What Is Coderetreat?

Coderetreat is a day-long, intensive practice event, focusing on the fundamentals of software development and design. By providing developers the opportunity to take part in focused practice, away from the pressures of 'getting things done'.

The Task

We were to build an implementation of Conway's Game of Life with an emphasis on unit testing and Test-Driven Development (TDD).

The Event

When we got started we broke up into pairs (pair programming) where we would switch off between driver (the person behind the keyboard) and navigator (the person who dictates which way we go) for 45-minute sessions.

First Session
We attempted to start by creating a grid with known cells so we could test it and the session ended before we could get anywhere. We knew the first session was a throwaway because we would be figuring how the game worked, the rules, and where to start. My partner was at the event for the first time as well, so we spent a lot of time spinning our wheels trying to figure out what we needed to do.

Second Session
In this session, the rules were switched up and one person would write a test and the second person would write the method and then switch roles. This time I paired up with someone who has come to the event before and he wrote a test to check if a cell is alive. I was like "Wait, what? Don't we need a grid first to test it against?". The discussion started from there and I was like "Oh we are creating an infinite grid where we are tracking only the live cells and we don't care about the dead cells", I had my mind blown by how over complex I was making it in the first session. I then proceeded to write the method that would satisfy that test and some other things before the session came to an end.

Third Session
The third session was about mob programming where you had a driver and a navigator (every two minutes the roles would switch and we would go through most of the group this way), the navigator could communicate with the rest of the mob about what to write next and the driver could only take instructions from the navigator. A majority of the group voted to do it in JavaScript (JS) and we had some none JS programmers and the navigator would have to talk with the mob about what to do. The interesting part about it was each person had a different approach and they could just undo what the last person did because they would do it their way. It was a very interesting experience for sure and encourages you to communicate better.

Conclusion

Test-Driven Development (TDD) seemed so odd to me and I was so lost as to why we would even write the test before writing the method. It was tough to break my habit of writing a method first, then write a test for it, and seeing the test pass. I can see why the TDD approach is a good habit to pick up. It helps you write shorter code that would pass the test and your methods would only do one thing that way you could test it and know if you break your method in a future refactoring. I'm going to try and implement TDD in my next project to see where it would take me and if I approach projects differently in the future.

DEV Community: Russ

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 experience of being in a Chingu voyage

Table Of Contents

What is Chingu.io

Why I decided to go on a voyage

My review of Chingu.io

My role in the voyage

The voyage

Conclusion

My experience with a coding bootcamp

Table Of Contents

Why I became a developer

What is a bootcamp

Why did I chose a coding bootcamp

How I chose a coding bootcamp

The structure of the coding bootcamp I chose

Mistakes that I made while going through the curriculum

My review of my bootcamp

What I'm thankful for

What I would have done differently

My 2020 New Years Resolutions As A Dev

Why?

My Resolutions

Your Resolutions

My Experience With Test Driven Development (TDD)

What is Test Driven Development (TDD)?

My Experience

Conclusion

My first Coderetreat experience

What Is Coderetreat?

The Task

The Event

Conclusion