This past Sunday, an 18-year-old who intends on starting at UNT next Fall and majoring in Computer Science explained to me the difference between a computer scientist and a programmer.

As he explained it, computer scientists are people who conceptualize software and programmers are the people who merely carry out the plan that the computer scientists made.

This kid went on to describe computer scientists as the people who do the thinking and the programmers as “dime a dozen.”

But, that’s not right…

The more the kid spoke, the more irritated I became because I do not perceive my role as a programmer to be one where I simply follow instructions without thought.

So, while I was initially very irritated, I later realized that:

  1. Automattic is my first job out of University. So, perhaps my perception is skewed
  2. This kid likely has no experience and is making assumptions

Thinking some more, it seemed like the best way to move forward would be to simply explain what I do as a programmer.

So, what do I do at Automattic?

Code Wrangler job description
This is the Automattic Code Wrangler job description as of December 21st, 2016.

My title at Automattic is Code Wrangler. But, that title is merely the default title for developers at Automattic and doesn’t mean much since all Automatticians can choose any title they like. 😂

Further, Code Wrangler is a very generic job title at Automattic, so what I do can be very different from what a Code Wrangler working on another product does.

That being said, I’d still like to share the things that I do as a Code Wrangler (aka software developer) at Automattic.

Maker of things

As a Code Wrangler, bringing things to life with code, or fixing broken things, is my “bread and butter”.

I spend a majority of my time on the front-end building interactive UIs with JavaScript, HTML, CSS, PHP, etc., which you can see from the images I share in this post.

But, thanks to being on team Poseidon (the Jetpack platform team), I also get to do other interesting things, such as:

  • Writing a script to loop through all Jetpack sites and backfill missing data
  • Somewhat fix a several years old bug that is lovingly called an Identity Crisis
  • Add CLI commands to Jetpack’s sync functionality

And while I spend a majority of my time actually working with code, I do spend significant amounts of time doing other things.

Manager of things

Account management section of
Allen Snook, Kevin Conboy, and I were the main people behind getting the account management section into the newer JavaScript based version of nicknamed Calypso. You can find more information here.

At Automattic, we don’t really hire for typical project manager roles, at least to my knowledge.

Because of this, I’ve had the opportunity to take on the role of a project manager for several of the projects that I’ve worked on.

I like to get shit done, and I will gladly do whatever is necessary to push a project to the finish line.

This means that I am often involved in much of the planning for the projects I work on, which can include diagramming, white-boarding, creating and assigning tasks, discussing designs, etc.

Maybe I’m good at managing things. Maybe I’m just opinionated and don’t mind sharing those opinions. ¯(ツ)

Breaker of things

Jetpack Secure Sign On
Earlier this year, I refreshed the Secure Sign On module with design input from Michael Arestad. We were able to spruce the design up, but I also fixed many flow issues and bugs.

At Automattic, we have the “Flow” team whose job I understand to be:

  • Manually testing Automattic’s products
  • Implementing automated functional testing of Automattic’s products
  • Working with other teams at Automattic to improve testing processes
  • Generally being awesome 😄

While I am not on this team, testing is definitely one of the things I like most about my job, even though testing isn’t mentioned anywhere in the Code Wrangler job description.

I often find myself asking things such as:

  • I wonder what happens if I rotate the screen here?
  • Does this input have validation?
  • What does the mobile layout look like here?
  • What’s a flow that wasn’t thought about?
  • How do things look in Internet Explorer?

I don’t have a strict testing list, other than the fact that I try and test Internet Explorer every Friday. Yet, I am often able to find bugs in new software as well as regressions in older software.

The thought I’d like to leave you with for this section is that testers are necessary to make sure that we have considered as many things as possible before our users unwittingly become our testers. Sure, some planning ahead can help reduce issues, but no one person can catch them all.


User Management Section of
This is the user management section of, a project which I had the honor of leading. I worked with Miguel Lezama, Rocco Tripaldi, Rick Banister, and Kevin Conboy to bring this together.

I have the honor to work with amazing designers such as Rick Banister, Michael Arestad, Jeff Golenski, and many others.

And I’ll be the first to tell you that I’m definitely not a designer in the same way that they are designers. They’re all badasses.

But, one of the things I learned early on, is that as a developer, I can play a vital role in the design of a project

For example, if I am a developer on a project, and I am delivered a design, should I simply implement that design? I’m not so sure about that. invite users form
This is the form to invite users to a site. Worked on by myself, Miguel Lezama, Rocco Tripaldi, and Rick Banister.

On one hand, the designers have likely delivered what the ideal flow should be. But, have the designs taken in to account technical limitations? What about business limitations? If the designers only delivered mobile designs, what does this thing look like on desktops? Vice versa?

As the person who will implement a design, it’s my job to provide feedback to designers so that, together, we can can deliver the best product possible in the shortest timeframe possible.

I didn’t always understand my role to be like this. The first project I led, the user management section of (pictured at the top of this section), went very differently actually. At the beginning of the project, Rocco Tripaldi and I were given designs, and we immediately set out to make those designs a reality.

Jetpack Sync Panel
This is the Jetpack sync panel that is displayed within This allows the user to trigger a full sync of their site and watch the progress.

After Rocco and I spent several weeks quietly working towards implementing the design, we finally came to the conclusion that the design was not then possible without some significant changes to how we stored data, so we decided to tweak the design a bit to be compatible with how we then stored data.

This was an expensive (to the company) lesson for me. Had I provided some feedback with the issues I was running into earlier, we could have made the decision to change sooner and potentially saved a month or more of developer time (two developers times 1-3 weeks).

In my experience, the best work that I’ve done has been a result of great communication and collaboration between development and design.

What do you do as a software developer?

One of the things that I became interested in after talking to this kid was the fact that software developers likely work very differently at different companies.

So, how do you work? Do you wear different hats, or do you tend to just do programming? Feel free to leave a comment or link back to this post.

Interested in wrangling code with me?

Automattic is always hiring, so if you found this post interesting, check out our open positions.

This picture was taken by Jeff Golenski at the 2015 Automattic Grand Meetup in Park City

3 thoughts on “What I do as a software developer at Automattic

  1. I have had his conversations before. I think the only people who talk about computer scientists and programmers not being the same it’s just people who are in college and need to feel that those years are not wasted time (I was one of them … And I don’t think those were pretty valuable years, but at the same times some of the best software architects / engineers / builders / whatever I know lack any formal education in this field ).

    Anyway, I subscribe this theory… We are not scientist or engineers, we are gardeners:

Leave a Reply