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.
As we go through this process as an institution, I’ve been a big cheerleader for openness, I’ve spoken to several individuals trying to convince them to open up, and as such I’ve been privileged to get a glimpse of the barriers standing between potential contributors and actual contribution. Turns out, when you ask a developer to come out of their little corner of the universe and start working within an open source community, the most common reaction is fear. We’re afraid that our code’s no good and that as soon as we publish it for others to see we’ll be revealed for frauds, that everyone will see that we actually don’t know what the hell we’re doing and that we don’t know the first thing about programming.
I think there are two factors that contribute to this attitude of fear. First, let’s talk about impostor syndrome. Many in our profession seem to suffer from something like impostor syndrome, and I personally think it’s because of the nature of the field we work in. Computers are weird and nobody really understands them, but web developers are expected to use them to build systems that support thousands of users and millions of dollars in business. The entire internet is held together with duct tape and good intentions and if anyone looks at it funny the whole thing will fall apart. This is the world web developers live in and are expected to excel in. Of course it’s terrifying, it’s not a solved problem and there are no best practices, really. The important realization is that you’re not the only one who doesn’t really know what they’re doing.
This leads to my second point: Education and the perils of working in a knowledge-based field. I think there are three kinds of knowledge, and I’ll quote:
there are things that we know that we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns, the ones we don’t know we don’t know.
– Donald Rumsfeld
OK, OK, there was a lot of laughing on the internet about this one, but the man has a point. There are three kinds of knowledge: Things we know, things we don’t know, and things we don’t know we don’t know.
Programming is a knowledge-based profession, and programmers are generally educated individuals, whether conventionally educated or autodidacts – usually a combination of both. Many people view education as something that decreases the things we don’t know and increases the things we know, but this often isn’t the case. Rather, education tends to show us a little about a lot of things, showing us all kinds of new things we never knew we didn’t know about.
In our specific case, software development is a huge, sprawling field and demands specialization as there’s simply too much for any one person to learn in a lifetime. Like education, specialization means that developers, and particularly less experienced ones, know a little bit about a lot of things, which means they have a good idea of how much they don’t know. Knowing that there’s a lot of things you don’t know about is the nature of the business, yet is the very thing that strikes fear in the heart and feeds into erroneous self-perceptions of fraud.
Software development is an extremely young profession that still has a lot of growing to do. It’s hard, it’s complicated, nobody’s terribly good at it, and nobody understands the whole picture, really. In my mind, the key to overcoming the fear of openness is to understand and embrace this idea. Of course your code is buggy and hacked together in places – debugging is hard, you’re working alone so QA is impossible, and time pressures force you to make compromises in quality, just like everyone else. Of course you don’t know everything, nobody does, and you won’t be exposed as a fraud if you can’t answer a question.
There is still a wealth of work to be done with documentation, tools, training, and onboarding new contributors. The more people that accept this idea, embrace the terrible, and open up, the more people we can get talking about what hurts and how to make it better.