With immersive programs, comprehensive training and career support, coding bootcamps provide the perfect launchpad for your journey into the tech industry.

With immersive programs, comprehensive training and career support, coding bootcamps provide the perfect launchpad for your journey into the tech industry.

Learning to code can be tough, especially when you start making projects! Here I will give you all the advice I can think of that I learned from my time in the Flatiron fullstack software engineering program.

Tip #1: READ YOUR ERROR MESSAGES!

I've had a few friends from the program ask me for help, and the conversation usually goes something like this:

They show that their app isnt working. They go between the browser and vscode erratically telling me that it isnt working. I tell them to open the console in the browser. They see the errors and just say that they dont understand why the code isnt working. I end up going through the error messages and read it with them. They usually havent read any of them.

If "map isn't defined" that probably means that your data changed types or your data isnt updating when you think it is. I then go through the flow of data with them to see when it is supposed to update and we console.log and use debugger until we can see where the data is causing issues.

The error codes can seem overwhelming but they usually give you a very good idea of what is going wrong with your code and are necessary for efficiently writing your code.

Tip #2: Don't be afraid to refactor!

Sometimes you're hours into a project and you have an idea of how you think it should work. Everything has been good until, uh oh, you can't figure out for the life of you how you are supposed to make this next feature work! You spend hours trying different things and end up with over 100 new lines of code trying to keep as much of your app the same as you can. I'm here to tell you, its ok to change your code!

Make that component you know you need, create that serializer, adjust your app's main component! I promise you that the "tedious" refactoring you know you must do is going to work a lot faster than the spaghetti you're making to try and work around your problems (I am speaking from experience, wasting your time is much more frustrating than refactoring I promise.)

Tip #3: Learn how to Google!

Some people are of the opinion that the only good code is code made without any reference, please listen to me when I say that they are wrong. If you're having an issue, chances are that hundreds if not thousands of others have ran into the same issue. The best way to find answers to your questions is knowing how to ask them. If you're having an issue with state in react, start with the error code! If that doesn't help, something like "State not updating after async call in functional component react js" will help you a lot more than "State won't update. Be sure to include the language you are having issues with as well! Many languages are similar in execution but the way you fix issues can be wildly different. Make sure that the answer deals with the version of the language you are using as well. There can be major differences between the different versions and this will affect how you must approach the problem.

I've been a part of the flatiron school fullstack software engineering program since early february. It's hard to believe how far I've come, from barely knowing how to program a calculator that works in the console with python to writing fullstack applications in react and rails with full crud functionality and front to backend communication.

As I work on my final project, I'd like to reminisce on the program as a whole and give my thoughts on each phase.

Phase 1, we were learning vanilla javascript and would simulate a backend with JSON server. This phase was me putting my feet in the water and learning what I would have to later in the program. This was the only phase I had to retake the coding challenge, and at the time it was almost overwhelming. The constant cycle of learn, code, learn, code, was very new to me. I passed the retake of the code challenge and completed my first project. This phase was probably the second hardest, because I was acclimating to the program and needed time to get used to the fast and constant pace of it.

Phase 2, we had finished with vanilla JS and immediately threw ourselves headfirst into react JS. Although it was just as fast paced as phase 1, I found that react was a lot easier to grasp than vanilla JS because of how much more efficient and organized it was. The second code challenge was by far the easiest, I had felt unstoppable. My project had been developed with no major hitches, in my head I had crushed react and would continue to crush the rest of the program. Little did I knew i was due for a humbling in phase 3.

Phase 3 had us switch gears completely. We were no longer working on the frontend, we were learning Ruby, SQL, and Sinatra. Pivoting from the now familiar land of javascript and frontend to the completely new backend world with new languages was the hardest transition by far. Up until the code challenge I had to continue studying. I remember the panic attacks from the stress I was putting myself under. I was worried I wouldn't do well on the code challenge and that I would waste the money I spent getting into the program. Literally the night before the code challenge, something clicked in my head. It all started to make sense and I ended up doing great on the code challenge. The project went well too, I got even more experience with the way the backend and the frontend communicate. I worked on the backend as much as I could on that project because I knew how much it would help me in phase 4.

Phase 4, we piggy-backed off of sinatra into Rails. As far as the learning and code challenge went, This was a close #2 for the easiest of the phases. Rails just makes a backend so simple yet it is so robust, I don't feel like I am trading simplicity with configuration control at all with it, sort of a best of both worlds relationship with Rails. As I said, this phase would have been the easiest if not for, the project. During this project I ended up having to do a lot of troubleshooting between the front and backend. While it was stressful at the time, it was a great learning experience. All of that troubleshooting helped tremendously in phase 5.

Phase 5 is just 3 weeks of project basically. Working on my first project completely on my own has been an absolute treat. I feel like all the stress I've been through has well prepared me for this. I've been experimenting with new things in this project, and I feel comfortable enough with the frontend and the backend to do so confidently. My troubleshooting skills have gotten much better now, I'm not scared to write code anymore. I am still working on my final project but I am super proud of what I've done. I've gone from a man who couldn't do more than basic math and console logs to a man that I feel would be a genuine asset to a team.

As I complete my final project I have been looking forward to the opportunities I've worked to get. I can't wait to see my hard work pay off and I'll be sure to keep yall in the loop!

Till next time,

Oh man, what a week. Going into the week I assumed that my group would finish much faster, especially since there were 3 to our group instead of 2. One thing I came to learn, however, is that the distribution of work matters infinitely more than the amount of people. I ended up having my hand in many more places in the project than I meant to originally because of how I separated our work.

The first task I gave myself was making a basic skeleton of our website, it seemed easy enough to make one quickly and it was. A couple of hours and I told the team that we could start dividing the work. Our initial plan was much smaller than what we ended up doing, so as we continued with the project, when a new idea would come up I would volunteer to implement at least the basic functionality and let them tweak it as they pleased. That ended up meaning, consequently, that I added the favoriting function, commenting, basic display cards, and a carousel of images along with the skeleton website I had built originally.

My eagarness to make our project more robust was leaving my partners with idle hands a few times, though. They would be waiting for me to implement a feature before they could try to adapt or style it. This led to us working until the very last minute! 1:30 central time was when it was time to show our project and we were making changes until 1:30!

Although I respect everyone in this cohort, I find that I am more willing to do things myself than to trust others to get things done. My teammates proved, though, that when put to the task they can perform. One of them made our database completely from scratch and about 70% of the styling! The other teammate was able to go through my code with little issue and tune most of the things I started to make them much more appealing. Going through someone else's code and refactoring is a tough job for anyone, so I have to show that some respect.

Day 30, blog 3

thanks to howlongagogo.com for doing that math

It has been almost a month since my first blog and allow me to say ‘it has been busy and fun-filled,’ because it totally has. I am still lacking confidence in some aspects of JS, especially my accuracy in syntax, but i have really gotten to understand concepts well so far. Granted it is due to trial and error. I have come to accept that while messing up code is super aggravating I learn the satellite topics around the code in question very well. For example I learned arrow functions by rewriting it over and over while breaking something else. 

One of my least favorite things so far is knowing the code works but not having it exactly as a test wants it. But my favorite thing is the opportunity that presents me. I can write, rewrite, rearrange, rethink, and reconfigure everything to try getting things to pass. And when that doesn’t work, I can ask for help from the Flatiron TC staff. They are like a good spot at the gym, they help you get past that struggle but don’t lift the weight off you. 

One taught me about the snippets tool in console. I am still practicing with it but it is honestly a game changer. For one, it is free. For another, it provides a play-by-play of your code as it runs, using ‘debugger’ as a reserved word. My explanation is not doing it justice, I admit, but it is fantastic. Thank you TC Tomas. At that, dear reader, I will leave you. I need more tea.