Coding bootcamps give some of the most relevant training needed to be job ready. The standups, collaboration, and describing issues is accurate to the work environment at my current developer job.

Working together

I've been fortunate to get along with everyone I worked with, but I would also want to see if I could handle someone has a bad attitude, is hostile or lazy. Group learning is one of the best parts about learning at App Academy. It was such a joy working with others at this coding bootcamp, both of the group projects I have done here have everyone pulling their weight. It could just be the nature of App Academy due to their tough selection process. Everyone who joins App Academy wants to learn and work with others since we would do pair programming or group work most of the time. The most hostile we would act towards each other was when we tried to convice each other that the site we picked was the best choice which was all fun and games.

Before we begin working we start off by selecting a high quality website to clone as a team as it is much better for learning than creating one of our own because. We at least know that the designs and functionality have been tried and tested. The amount of benefits for having good communication within a team is insurmountable. It helps with group cohesion, entice us to meet our goal, debugging, and much more.

Splitting up the workload

App Academy has found it better for us to get to experience full-stack development, rather than splitting each team member to do a specific thing, just as front-end, back-end or design only. At this stage in our software developer journey, we got to become a balanced engineer to get the big picture, and specialize after getting several years of experience.

Do not separate the workload into front-end and back-end! We're full-stack developers, not half stack.

• my App Academy instructors, 2020

GitHub was where we did all of our management because of how much tools it had. We would create our wireframes, page design, documentation etc and os them the GitHub wiki. Another useful tool we used was GitHub projects where we could create Kanban boards, create issues and tasks that we could link to pull requests. If there were problems that need to be addressed before a merge, we would fix the code and get it reviewed by our instructors. In our feature packet we have to write out all of our MPVs and get a timeframe of when we are going to complete them. This really made it easier to get our work done on time, and if I was feeling behind, I would finish it up while I was out of class.

Communication

We would stand-up with our instructors 3 times a day, one at the beginning, one in the middle, and one at the end of the day. We would discuss what we have done, what we want to achieve before the end of the day, any blockers preventing me from progressing, and at the end of the day, what we plan to do at night for our project. We also speak amongst ourselves during class and on Slack when we’re not on Zoom.

Communicating built my confidence and skill to estimate my ability

Having us state what we have done and our plans for the day, coaxes us to achieve those goals. For the most part, I was able to complete what I said I was going to do because I set my daily goals realistic and achievable. Even procrastinators will do their work when there are goals (deadlines) due soon. If the goals are too far-fetched, I would get into a downward spiral and get the illusion of continually falling behind every second I think about it, getting me to unhealthy work habits, missing sleep, meals, social interactions etc. Keeping my goals reasonable is great for my mental well-being since I get a shot of dopamine for every objective I complete, no matter how small.

Getting help

Asking for questions involving bugs is an art in itself and an important communication skill we learned. Programmers don’t just simply ask someone to fix something, code can be resolved quicker if there is a lot of context. I think the process was that we had to describe the problem, find out where this error is happening, what we have tried, and quite possibly, what we think we need to do. If it’s not bug related, we could ask for suggestions without context.

I have also been on the giving side when it comes to helping. I am pretty grateful that I came from a Game Art and Design background because it made it easier for me to design pages. App Academy does not teach us much about the principles of design so almost all of my colleagues would have trouble with making a page look pretty with CSS. They told me that they learned a lot when I was teaching them compared to googling. I would say that we learn well when we communicate with each other, not from lectures or finding the answer through search results.

Architecture and clean code

Setting up the project, controlling data flows and keeping code DRY/ clean can speed up the development cycle the larger the project becomes. It's less stressful to just change a variable on one config file than searching for every instance of it and get exposed to code that belongs to someone else that was hardcoded that way for a reason. To keep our secret information hidden such as API keys, tokens, or important info needed for deployment such as URLs, names, ports, etc... we would put but those variables in an env file.

I think making the code elegant and easier to understand increases the longevity of a project.

You can become a super genius by having a diet of stolen copy-pasta I didn't write and spaghetti in every line of code. My code far is too advanced for your simple brain to wrap your head around it.

• says a narcissistic job seeker who failed every tech interview miserably and brags about his 800 line "Hello World" console log with 10 async callbacks that he can't even explain or understand for himself.

File structure

Routes were organized the same way our file systems or URLs are where we nest folders the deep we go. The first project we created had the back-end and front-end routed on the same server since our project was small and takes less setup to deploy.

/client
/config
/db
/routes
    │
    │
    └ /api
    │   |
    │   └ /route1.js
    │   └ /route2.js
    │   └ /route3.js
    │
    └ index.js

As we moved forward, we haven't went back to putting the front-end and back-end on the same server and have been keeping them separated. Later we learned about how we could use virtual machines to help us deploy our project and used Docker to deploy our apps. This service can containers so that can be delivered anywhere with uniform requirements no matter what what our computer environment is like.

Database

Before we created the database, we planned out our models by drawing schemas, and relationships. We also did some brainstorming on how the user can interact with the database to get, post, patch, delete entries and use it to display them on the screen. It's one of the model view controller or view-model method of designing software. Object relational mappings helped us a lot with creating and keeping our database models, migration and seeded organized which made it easier to test out the backend locally or live with ease.

Middleware

It is important to keep our site from thieves forging an authenticated user's request. There were also some problems with cross-origin resource sharing since our front-end and back-end became separate and most browsers have it disabled by default. Fortunately, the way we have our routes organized, we can easily protect them from CSRF attacks and allow CORS by using middleware on our main app file.

app.use(cors({ origin: true }));
app.use(
  csurf({
    cookie: {
      secure: process.env.NODE_ENV === "production",
      sameSite: process.env.NODE_ENV === "production",
      httpOnly: true,
    },
  })
);

Controlling the flow of data

Our state was managed through a library called Redux which makes state management easier by separating them with actions, reducers and stores. The actions are pure functions that will return the same results if the same parameters are passed in, the reducers if the case matches the action type then does it accordingly, and the store is where the state is well, stored. Redux connect is one of those methods that confused me for a long time but now I know that higher order functions which is a function that returns another function, I just have to learn how to use it properly.

Using Redux really tests how much I understand about keeping clean, and DRY. I still don't fully understand how to use this technology but I definitely want to learn it more since it would level up my architecting skills.

Conclusion

App Academy knows that building full-stack applications is tough but rewarding. If there is only user auth, and one feature from the MVPs, then that’s how the majority of projects turn out. The styling of the page doesn’t even have to match the original source. It is expected that nobody gets 100% completion on their project, since the ones we were cloning took seasoned professionals developers with a high budget.

The reason to aim for completeness is simply because of that. These projects are going to be used for our portfolio projects. App Academy’s purpose is to get us employed, which I used to think was optional. Grades mean nothing, what matters is that our work looks great and we can impress potential employers. It’s quite amazing at how much we are able to do with the knowledge gained from coding bootcamps.