My First Post as a Full-time Developer
For the last two weeks I've been working as a full-time web developer. Four months after graduating Firehose, the efforts I've put into becoming a developer have finally paid off. During this time, I've applied to 58 job postings and went to 8 face-to-face interviews, and this has been the first job offer. I was hired as a PHP developer. This was very unexpected and incredibly lucky, to say the least, since PHP was not one of the languages I knew well, and said so at the interview. This turned out not to be a problem because they were not looking for someone who already knows PHP. Instead, they were looking for someone experienced in web development using any other MVC framework, who could be trained to use a PHP framework. (I'm guessing its more cost-efficient to hire an entry-level developer and train them, instead of hiring someone more experienced at a higher salary.) My Firehose experience with Rails was a good fit. Another helpful factor was that I did know the fundamentals of PHP. This was something I picked up while working on an open-source application that was meant to help refugees in Europe find housing. Shortly after that, the group I was working with (Prosper, led by the Firehose grad John Ellison) changed direction and the PHP application that I started working on was set aside. But, the knowledge of PHP stayed. These two factors resulted in an an interview, which led to a job offer.
I am now a trainee at the web development group of Columbia College, where I'm learning PHP and Symfony, a PHP-based framework. PHP is a unique language because it was designed specifically for web development. It has features for accessing a database and for interacting with a server, so that, unlike with Ruby, a framework is not strictly necessary for making web applications in PHP. But, it helps a lot. Just like Rails, Symfony is based on a MVC architecture, which made the general layout very familiar. But as they say, the devil is in the details. The number of details that need to be understood and managed in Symfony is way higher than in Rails. The Rails philosophy of convention-over-configuration means that the developer doesn't need to worry much about configuring the different components of Rails to interact correctly with each other. They just work. Symfony, on the other hand, is configuration-over-convention, which means that a lot of the details that are managed automatically by Rails need to be specified by the developer. The advantage of the Symfony philosophy is that each application can be configured to have only the components it needs to do its job, leading to small and efficient applications. For example, Symfony has a component that allows the developer to make console apps that interact with the user only through the command line. Such apps can be converted to browser apps with a reasonably small amount of effort. My first project involves just such a conversion.
To use an analogy, after starting to use Symfony I felt like a person who was used to taking pictures with a point-and-shoot camera and then suddenly switched to an all-manual professional-grade camera. The professional camera has much stronger capabilities, but first one needs to learn to use it. I am still at a stage where I'm just trying to use Symfony to replicate what I know how to easily do in Rails. Hopefully, it won't be much longer before I feel like I know what I'm doing with Symfony.
Let me know what you think of this article on twitter @YuryVoloshin or leave a comment below!