Mod 4 was the culmination of the mods that came before it. I had some experience in web development before I came to Turing (although almost none in JS specifically). I could build a website but it was extremely difficult for me and took forever. So my top goal in choosing Turing was to be able to work significantly more quickly and confidently.
The projects in Mod 4 were proof that this goal has been reached. We began with Palette Picker. While it took me a day or so to get back into the jQuery groove (after several months in React), I quickly became comfortable with the task at hand. I had already written an app with a backend at the end of Mod 3, and so I wrote the majority of the backend for Palette Picker the night before Mod 4 started. As a result, the heavy stress of that first week was mitigated and I was able to simply tidy up the backend and build the jQuery frontend. It was pretty cool to be able to handle that project so quickly and just add on the few extra requirements.
It happened again on the day of the final exam, Garage Bin. It was intended to be a 10 hour marathon but again it required a backend that I was already comfortable building along with a jQuery frontend that I was comfortable with as well. Instead of it being a brutal 10 hour journey of misery, I was finished in about 7 hours, and then got to refactor a little bit and deploy without worry. I was amazed at how well Garage Bin turned out in such a short time. I completed all of the functionality, had time for testing and deployment, and turned in what I considered some of my best worok with time to spare.
And then came the capstone project. I decided to pair up with Hugh on a particularly ambitious project of building an app for a group of Pediatric Occupational Therapists. Their project requirements were huge and the project seemed almost impossible at first. But I had gotten comfortable with writing a lot of functionality very quickly along with testing and styling. We started early by building a portion of the backend in the BYOB project and then quickly adding to it after we turned it in. By the time the capstone project officially started, we already had over 200 items in our backend schema, and a good 20 completed frontend React/Redux components. The project still had a long way to go and grow, but because of the early start and hard work, we managed to pull off even our most ambitious targets. Even the nice-to-haves are now complete.
So that's a long way of saying that my first priority when coming to Turing of gaining speed and confidence in software development, has come about as planned.
This one is easy--it was House of Vars. House of Vars required us to jump in on an open source project, pull down the repo and get it working locally, find an issue we could address, work it out, and then make a PR with the updates. From the start, little seemed to go right. Our open source project was called Open Food Network. They have a cool product that uses old versions of everything because it was written over 3 years ago and the versions haven't been updated. As a result, the install process was very challenging.
I have a few important takeaways from House of Vars.
- Tread lightly when dealing with versioning issues. Versions should never be rolled back. It's possible to have multiple versions of Postgres and Ruby on your system. Also, when updating or changing a version of Node.js or Ruby, use a version manager...and only one version manager. There are many different ways to change a version--pick a good version manager (like NVM, RVM, or rbenv) and stick with it. Mixing version managers causes massive problems.
What happened to me was I got House of Vars to work, and in the process, caused every other app on my system to break. I had to get help to correct my mistakes. If I had asked a senior dev up front about versions and version managers, I would have done it right from the start and not made such a mess. Lesson learned.
- Open Food Network used preprocessors in many places. HTML was written in HAML, CSS in SASS, and JS in CoffeeScript. As a result, code was abstracted and difficult to debug or even find from the browser. It occurs to me that on an open source project, it might be sensible to avoid abstracting code any more than necessary since it makes it more difficult to work on. It'd be different when it's an inhouse app where employees can all get used to writing code a certain way--but if your goal is to get oursiders to help out, it should be a priority to make that easy to do.
If you ask most of cohortmates what the hardest project they did at Turing, they will probably say Palette Picker. Due to some backend experience in Mod 3 as well as a solid understanding of jQuery, I was able to get through that project relatively quickly. As a result, I had plenty of time to help others with the struggles they were having on that project. I spent many hours digging through code with classmates, at Turing and at home via Slack to try to get all of us through it. It was time well spent. I gained a better understanding of jQuery and Node.js, and I gained valuable experience looking at and debugging other people's code.
I've been a very hard worker from the day I first arrived at Turing. Mod 4 was no different. I was always there in the evenings, could be asked for help at any time, and chose to stay ahead on projects whenever possible.
I believe the results of my work ethic are obvious as my projects are consistently in a completed state. I've never turned in a project (in Mod 4 or anywhere at Turing) that I wouldn't consider complete. It always works smoothly, contains all functionality (usually with extras), is fully tested, has an easy-to-understand UI, works on mobile devices, and more. I never have and never will turn in work that is half-assed. I'm just not wired that way.
How did your Mod 4 experience with this part of the stack (e.g. front-end technologies for BE students/back-end technologies for FE students) impact what you wanted to be doing after Turing? How did it reframe what you learned in previous modules?
From the start I was most eager to be working with front end technologies. That hasn't changed. I still really enjoy the point of intersection between well-written code and a great idea. Those two things meet at the user I believe. And I will continue to build things for human beings. To me, writing code isn't an academic exercise. It's not done simply to see how clever we can be. Writing code is about building something for a user that makes life easier, more interesting, more exciting, and better. Front end feels like the front lines of that process to me.
With that in mind, the backend portions of Mod 4 were very helpful and interesting too. I enjoyed working with databases more than I thought I would, and enjoyed the reality that I could take an idea from inception through to production once I understood the backend.
I think what I've gained the greatest understanding of is how to work with others in a development environment. Since we're always working with others, it's important to write clean, understandable code, push small amounts of code regularly, and always be prepared to explain how something you wrote is working. I've learned to genuinely desire for teammates to understand how code is working as well as to ask appropriate questions about their code. Gaining a clear understanding of your codebase is critical to my growth as a developer as well as those around me. I look forward to working with others, particularly those who know a lot more about writing production code than I do.