Tag Archives: Culture

Going Remote – Day 0

This post is the first in a planned series about my experiences moving from a traditional Nine to Five office job to a remote job with a distributed team. Disclaimer: These articles are intended to provide my personal perspective on transitioning to what very well could be the future for tech workers and are not endorsed by, nor reflective of the opinions of my employer.

Well, this is it. I’ve been interested in the idea of remote work and distributed teams for a long time now, and ever since I read The Year Without Pants last year I’ve been hooked. I saw what companies like Automattic and Lullabot have been doing – hiring talented programmers wherever they may be and trusting them to get things done without constant oversight – and it made so much sense to me that I had to pursue that kind of working life, if only to try it on for size. Finally, after taking my time and slowly searching out a new job over the last several months, I’m starting my first full-time, 100% remote job tomorrow.

Continue reading →

Fear of Becoming Open

The University of Oregon’s developer community is interesting. I’d say unique, but from speaking to developers at other universities, I’m under the impression that our situation is fairly common at large institutions. With 25,000-ish students and hundreds of schools and departments supporting them, there comes a few thousand websites to provide information about enrollment, financial aid, majors, classes, housing, dining, activities, events, and on and on and on. Typically, developers are hired in far-fetched corners of the institution and charged with one area’s concerns. Thusly, to support a thousand sites, we wind up with a few hundred developers, ranging from $10/hr students to $100k/year professionals supporting this odd, cobbled-together infrastructure.

I’ve written about this problem elsewhere, and rather than re-hashing it I’d like to look at some interesting ideas that come up as we head down the road to recovery. Eventually, all these programmers start talking to each other and realize that they’re all working on essentially the same problem. As we begin to collaborate organically, realizing that we have common problems and coming together to find common solutions, we start to emulate open source software communities, and we run into one of the biggest problems in OSS: encouraging contribution and eliminating barriers to first commit.

Continue reading →

Understanding Institutional Scope

Working at a large, distributed institution like a public university is interesting. The University of Oregon is home to some 20,000+ undergraduate students, not to mention grad students, faculty, staff, and so on. As you might imagine, an institution this large has a similarly large web presence, with literally thousands of pages covering colleges, departments, classes, programs, organizations, etc.

For example: at Oregon, we have a few key pages: The homepage, pages for the individual colleges (Arts and Sciences, Architecture, Law, Business, etc.), athletics, and so on. However, this is only the tip of the iceberg. Departments, professors, student groups, classes, campus initiatives, and on and on and on all need sites. I’ve un-scientifically estimated the total number of sites deployed at Oregon at a (very) rough ballpark of ten thousand.

To create this mammoth web presence, we’ve taken what seems to be a typical approach for universities: hire dozens of web developers and hope everything turns out ok. Enrollment hires a developer to make enrollment sites, the business college hires someone to make their site, some student makes the computer science page, some contractor makes the site for the music school, and the physics department is still sporting that site a professor made back in the early 90’s. Universities are full of smart people and were early adopters of the internet, so back when this whole web thing was getting started and the concept of an IT department hadn’t really been invented yet, it made sense to grab the nearest nerd and put them to work. Today, this model’s still around, but it doesn’t make sense any more.

Continue reading →

Developers are designers, designers are developers

I’m going to open with a question: What’s the difference between a designer and a developer?

If you’ve been working in the web for a long time, I’m going to guess at your answer: Designers are responsible for making a website look good, developers are responsible for making it work. This is how it’s been for ages, especially in the dark times before front-end engineers and UX developers or UI designers or whatever we’re calling them this week.

Historically, this is how we’ve done web development: A designer’s job has been to make something that looks nice, throw it over the wall, and let the nerds worry about how to make it a functional thing. The nerds take whatever the designer made and chop it up into something that resembles a website. Compromises have to be made – design elements are impractical or impossible, so they’re modified or left out entirely. The designers resent the nerds for ruining their design, the nerds resent the designers for being too old-fashioned to get this whole “internet” thing, the project managers don’t understand why everyone’s being so difficult, and the content managers don’t understand what all the arguing’s about and why it’s taking so long to make a website for their softball team. Nobody’s happy with this approach.

Continue reading →