This is the story of how I became a software developer.
At first, I wasn't
I was an English major. Well, before that I was studying Biblical Literature. And before that I was studying Music. And finally before that I was studying English.
Twice in that list I say I study English. I started off that way and ended that way in 2012 when I found myself in attendance of the Broadening Participation in Computing at Mississippi State University. Yes, I declared English as my major two different times. The first was at a bible college that doesn't exist anymore. The second was after the school shut down. Life is great when it makes no sense.
I was studying Spanish to satisfy the basic requirements for an English degree when I met Daniel. Daniel introduced me to the BPC program because he had experienced it himself. He highly recommended it, and so I applied. I went to my favorite teacher at Hinds CC, Mrs Kathy Smith, and asked her to recommend me for the program. She agreed to show me the kindness of providing me a letter which acknowledged an ability to critically analyze a story and understand the differing motivations possible to explain the author's intent.
That's a skill I've found quite handy in reading code written by my coworkers. Does it sound complicated? It's really not. There are a million little things developers try to understand — and they all tend to bubble up in design patterns. Systems of design are intentional. The care put into them requires your attention if you plan on being able to improve them.
The rest of my college career was designed by people who generally understood that designing systems requires intention. My process for selecting to pursue a Bachelors of Science degree in Software Engineering at Mississippi State University was aided by a well-designed flow of balancing conversations about the pros and cons of other comparable programs; I am grateful for the counsel of many community members who gave me advice and impacted my life. Seeing the unique benefits offered at MSU, I decided that Starkville would be my home for a while.
1.5 years later, I was ready for Senior Design
The project was simple. Build a website to manage a library of audiobooks.
The project was not simple. The website's main audience was going to be people who could not see. What happened next has shaped how I understand my job, and I couldn't be more grateful for its impact.
Our team was large for my taste. 9 people total. But it seemed like everyone else understood we had too many people to form a single, cohesive group that could last an entire semester. We selected a project manager. He broke us up into 3 teams with separate concerns. There was even further fragmentation as one person took it upon himself to completely own all database components and he created a single way to write all our business logic in PHP. We self-selected our sub-teams: backend devs writing PHP, frontend devs writing HTML, JS, and CSS using Bootstrap, and an integration team which handled reviewing and handling the logistics that tied the two together. I joined the integration team.
9 people seemed perfect, now. We had stuff figured out. We knew what we were doing.
Except for all the mistakes
We did some things well but there were plenty of little things I'd change now that would have saved time back then. C'est la vie.
We poorly practiced trunk-based-development. Since everyone's concerns were primarily structured the same way using the Model-View-Controller paradigm, I ended up benefitting by getting a little exposure to a lot of different ways of thinking. This came in handy when comparing the mistakes I made in my team to the mistakes made in the other teams.
Frontend designers think differently when they have to spend time working with their users. That's where the requirements are gathered, really. Accessibility means your users are able to use your software. It can offer long periods of uncertainty in whether your work will be ultimately meaningful. Not every idea we have can survive forever, especially when there is a disparity between the users and the designers.
Our meeting notes included phrases like, "This doesn't make sense to me!" There was no note afterward indicating this had changed for the author. The difficulty arose from a misunderstanding between the author, her colleague, and two of the clients. There is still so much I have to learn about creating inclusive technology experiences when writing new software, but this project was where I first considered what truly accessible software means.
Backend designers are typically focused on analytics. This has been where I've found myself professionally. Learning from frontend designers became normal. Writing code that could be consumed by the frontend designers made it so that I was interested in listening to their complaints. If I could make it easier for them to work with us, I'd need information on their roadblocks. That meant errors.
Some of those errors were mine. Some of those errors belonged to others. All the errors were rooted in not understanding something. Maybe the software didn't 'understand' some input or the person who wrote it made a mistake or the actor tried to make the software do something it couldn't. Perhaps the software was configured incorrectly or something happened to the network. It is possible that some of my colleagues even went through breakups that affected their emotional states while writing their code, leading them to make assumptions just because they weren't interested in their work. All of these things were questions I ended up having while learning how to work with two separate groups that weren't always talking to each other.
Recognizing that this happens often in life shifted how I processed my own failures over time. Sometimes the failures ended up leaving some shame for changing my mind so often. The times I felt some grief at the different lives I might have lived if I had continued on in English or Music were met with meaningful friendships that have become pillars. Accessibility all starts with feeling empathy for the person who reads what you write, whether by being the actor or reviewing the design.
Top comments (0)