General

(From left) John, Yulia, Neil, Tony, Mike, Michi, Becka, Natalie, Brian

We’ve updated our company photo!  Look forward to seeing it on Wired where we’ve been featured!

To learn more about our staff at Splurgy, check out our Company Profile page.

To get ahead in the tech startup world, it takes a lot more than just knowing how to code and gathering a group of particularly smart individuals. Particularly, having a firm understanding of how to monetize your business is not just a job for the only business-oriented guy you hired, because it entirely determines how your application is built. It makes sense when you think about it.  Obviously your startup has a lot more burden on finding customers than many larger companies, and needs to cater to your customers’ needs better than your competitors. But, when it comes down to action, the programmers will be programmers, and the business side does his own thing.

This is why, upon applying to grad school for computer science at USF, I specifically chose the entrepreneurial concentration, which requires MBA coursework to graduate. And, this is why I’m glad to be interning with Splurgy, where the engineers are involved in more ways than just coding. We’re presented with information about Splurgy as a whole, where we as a company are, and company goals. Engineers are encouraged to not only use business strategies to plan out the direction of the Splurgy application but also give input to the marketing and the business modeling aspects of the company.

This leads into another important characteristic of Splurgy, having all of the engineers staying in the engineering loop. Knowing what other engineers are working on has endless benefits – finding serious bugs in someone else’s project, continuing their work if they have an emergency, or even offering help if they’re stuck and have a deadline. Every little bit can help the company move forward.

From working at Splurgy over summer, I experienced how programming in a working environment has a completely different atmosphere compared to that of college. In college, you would first learn the necessary material before starting a code and the projects done are usually centered on the subject that the class is currently covering. That wasn’t the case when I started to program at Splurgy. Instead, I was given a goal first. From there, I had figure out what I needed to learn in order to achieve that goal. This process led to me to understand unexpected pieces of knowledge such as MySQL, something I hadn’t originally thought was needed for a Magento Extension.

Compared to what I learned during my freshman year during college, I felt as if I had learned more in the workplace. It was probably because, in the work atmosphere, the code you write is a significant contribution that affects the company. It’s a pretty big motivation to learn. I would savor every moment of my projects, spending more time on slowly thinking through each of the steps I went through. So far, I haven’t really gotten the same feeling of excitement when I’m working on a school project. Of course, I still try my best in every code I write, but when I think about how my peers are working on the same assignment and doing the same things as I am… it just doesn’t feel as special as it should be.

I feel fortunate to have experienced what it’s like to code in a work environment. Doing it this early is the best practice I could’ve possibly had. What I was taught is that I should aim exceed the expectations that has been set by the class and code as if what I’m doing is going to be looked at and used by someone else in the future. Working at Splurgy was valuable in showing me how my code is processed and used by others, which is a really rewarding feeling.

My first impression of Ruby on Rails is that it is a very seamless piece of work. When I say seamless, I mean that it is impressively easy and simple to setup and begin developing without any compromises while facilitating good habits.

The whole Ruby on Rails community revolves on the idea of good practices. The first Rails tutorial that I have ever read taught Test Driven Development, and it taught version control using git (http://ruby.railstutorial.org/). Surprisingly, Splurgy also uses TDD and uses git for Rails. I grew up on this idea of industry practices being the absolute best and that the only way  you can learn them is by working in industry. What was surprising to me was that I was able to learn what was being used in a company’s production setting from a tutorial. Of course, Splurgy had more things on top of what I learned from the tutorial, but it remains true that the ideas were consistent in the Rails community.

These are just methodologies and they can be applied to any other languages such as PHP, and they are, but it is inconsistent throughout the community. When I learned PHP, I was never taught to use version control nor did I use any development methodology because I never knew about them. When I started doing PHP work at Splurgy, I was surprised how much more tools I had to deal with such as PHP MD, PHP CS, Xdebug, and a few other things. As a beginner, every Rails related thing that I have come in contact with so far have consistently aligned ideas. They all have code coverage, and they all use version control.

My point is not that one is better than the other, but if I am taught to do things in a certain way from the beginning, I will continue that practice because that was the way I was taught. The Rails community does exactly that. These are good habits for all types of Engineers, and these habits make better programmers and lead to better applications.

Agent18, one of our beloved clients, sent us this assortment of iPhone 4/4S cases the other day. Since most of us here at Splurgy are iPhone users, these cases were claimed within seconds. I, of course, took the Woodgrain Slim Shield =). Thanks again Agent18, you guys rock!