What I do at work

This post is completely prompted by the fact that my job is hiring another developer, so for the impatient, go there and apply right now. All others that want to know what they are getting into should read further and see if it applies to them.

For the past 4.5 years I have been working as a developer for Wall to Wall studios. It is a pretty small firm, but with a broad set of skills. When I was first brought on we were just starting to get into the Content Management System game, partially because the size of client was increasing and partially because it was no longer economical for us to offer maintenance and update contracts for large sites. We have been through two and a half major iterations of our content management system since it was first built. All of them have been built on php, because we look for a large deployment base, but the systems have grown a number of support systems that are either shell scripts, or rake build files, or other programming languages, because we tend to grab whatever language glue is near at hand to build what we need.

Describing a typical day would not emcompass all of the types of work that gets done here, because we tend to move in larger cycles. The most constant part of the job is building html templates for our cms. I have gotten to the point on this job that I don’t really view building html templates as a fun thing anymore, it is just production work. Not to say that it doesn’t contain interest, just that it is the easiest, and most time consuming part. Occasionally a fun problem pops up in this phase, and I get to write a bit of javascript for some rediculous feature.

The second biggest part of the job is maintaining and upgrading the CMS. Our CMS is built on cakephp, but we have gone quite far beyond what cake supports at its core, and we encourage that sort of relationship to a framework. When we made the jump from treating cakephp as a framework, to treating it as a library, our job got a bunch more interesting. In fact, some parts of the cms have totally replaced cake core elements, for example, the view layer is now running on twig templates. As a developer here, you are also expected to be a UX engineer and interface designer, because the designers only work out what they want the output of your data to look like. All backend engineering and design decisions are left up to the developer building them. To me, designing the systems for collecting and manipulating data are just as much fun (read, even more difficult), if not more fun as designing the systems for collecting the data.

While I have been here, I have designed the backend for a calendar and event registration system, an extremely extensible slideshow system, and added a number of features to the core content system. In each of these cases, although I could seek input from my coworkers (and I did on a great number of occasions), the final design decisions were mine. In addition, the programming decisions were mine, so I could make as many crazy interesting polymorphic data decisions as I wanted, or make the data simple to make my life simple.

This creative agency extends to the process policy here. Between myself and the other developers, we have moved to a process that uses source control for everything, has a continous build server, automated testing, scripted deployment, pair programming, code reviews and bug tracking. None of these systems were in place or mandated by management, but we were given the space to make good decisions as we needed, and drop the ones that were slowing us down if we didn’t need them. We are also encouraged to do reasearch on new technolgies, which is nice and gives us an excuse everytime we are surfing reddit.

So, hopefully that helps, please apply!

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
powered by Jekyll with Barecity