Reflection on General Assembly's WDI Program

01 February 2014

So, life after college General Assembly's Web Development Immersive program. It's a heart breaker in the sense that I've learned so much but yet so little.

Things that I wish I covered/focused on
Tests Tests Tests. During the three months I hardly focused on testing. Rspec was something that was slightly covered. However, in the workforce, tests are extremely important. I can actually remember my instructor mentioning before every project: "You guys should really write some tests!" However, my classmates and I were already stressed at internalizing the rudimentary principles of Ruby and Rails. So, naturally, we would all get caught up in coding out our apps and we'd almost never get to write tests for it. If I did manage to have some time to waste, I would slap on some Rspec to test out my models (but that wasn't real test driven development).

Things don't really work like that in the workforce. Test driven development ("TDD") is extremely important.

No good company will ever launch an app without any test coverage. There are many reasons why people would argue that TDD is fantastical. However, the one thing that I will stress here is scalability. The larger you grow in terms of users using your app, you will most likely be changing and evolving your app. Apps, programs, software, or whatever shit out there, can be thought as living entities. They will need to either grow, if successful, or flourish, if unsuccessful. Tests can be incredibly important because whenever you update your code things will break and you can use it to target portions of your code and know what to fix.

Git/Github branching, rebasing, fetching, pulling, and branching again! One of the things that my cohort struggled on was using Git. The concept of having repositories, on let's just say Github, and pushing to this repository, or folder/thing, was so foreign. Everybody was kind of against it because we all just thought: "Hey, I'll just make a copy of my folder will all my updates and archive it", or: "Hey, I'll just airdrop my work to you!" After copying folders and airdroping documents to each other one person would be assigned with to push to the master repository. Nobody wanted to deal with the steps of creating a branch, rebasing, pull, rebase, merge, push, and etc. Again, in the workforce, Git is wildly utilized.

Haml and Coffeescript. Haml is actually easy to pick up, but I thought to myself: "Why? There's no need to learn HAML, HTML is just dandy." CoffeeScript on the other hand, I stayed clear of this because I was still trying to learn JavaScript. Long story short, programmers like short hand.

Are programmers lazy? I say they are efficient!

Programmers will find ways to type less. However, this of course, does not apply to everything. In some cases, solving something iteratively may be longer but more efficient in terms of BigO than solving something recursively. But, I feel that in general programmers will end up coding in shorthand.

Those are my thoughts so far. There's just so much to learn and so little time! One can't possibly learn everything in 3 months because 1) there's just so many abstract concepts to learn and 2) things are always evolving (a new thing today can be obsolete in 4 months).  While there's so much to learn, I loved participating in General Assembly's Web Development Immersive program because it paved the way for my learning. I came out of the program wanting to learn more, and I can say that I am indeed still learning. A few weeks after finishing the program I received the opportunity to intern at a great start up and there's so much that I've never seen before! After the first 3-4 days I've covered Cucumber + Selenium testing (behavior driven development), Haml, and I'm swimming deep in Rails.