People are the problem
How developers need to spend more time developing themselves
The startup community’s concern with software development is highly ironic. We spend hours, days, week, months, and sometimes years writing code that, once written, will act exactly as we prescribed. There may be bugs, it may not scale, but it’s actions are finite. It will only do what we have written.
So, to combat the writing of bad code, we spend just as much time trying to write better code. We go to conferences, we read books, we take classes, we write open source, and dozens of other practices but the end result is the same: the code will only do what we have written.
We need to rethink the way we approach creating software. Writing good code, nay great code, is a worthy endeavor but, at the end of the day, we still have a huge problem and we talk very little about it. The hardest part of software is the people.
Coding is ultimately a craft. It’s something that can be learned, taught, improved upon, and put into action. But people… people are a lot harder to deal with. We have emotions. The same input doesn’t give the same output. Our needs change. Depending on who you’re surrounded by, your output can change dramatically.
I think that’s why talking about a lot of coding practices, technical theory, or the new hot library for asynchronous this-and-that is pretty unappealing to me. These are all areas that, given time and effort, can be satisfyingly conquered. However, the ones writing that code, the people, are evolving and ever changing. They aren’t statically typed.
Corporate culture usually states that “people are our biggest asset”. While I wish that they actually believed that, I do think it’s entirely true. We focus too much on the output of our craft and too little on the person creating that output. Are their needs met? Are they happy? Are they looking for a greater challenge? What are they worried about? Do they need something they don’t have? When was the last time they took a vacation?
Startup culture tends to gloss over this by giving people “candy”. They give things like XBoxes in break rooms, kegs on tap, cleaning services, and other perks. All of these help people in some way. But, in many startups, it ends here. We pass out all these “good things” and assume people can synthesize them into everything they need.
I propose we try tackling people head on. Let’s figure out how to help cure “impostor syndrome”, how to guide people to what they really would rather be working on, and how to help people grow as an individual. These types of improvements create exponential rewards for our crafts whether that be programming, designing, or operating.
I don’t have to give up our endeavor to write the best code of our lives. I just have to acknowledge that writing really good code doesn’t make me a happier, fulfilled person. Who on your team would you rather have spearhead a new project?
The challenge here is that “person growth” is highly subjective. Giving a talk on “person growth” would be considered soft compared to a technical dive on some cold, hard code. A “person growth” talk/class/event would be much more of an exploration in which we might not have a destination. That’s a good thing. Why do we have to pretend to only have answers where sometimes a difficult question is just as good?
I spend a lot of my day working on software that tries, in a small way, to help facilitate my co-worker’s happiness but I definitely don’t have all the answers. We need to work together, put our concerns and issues in the open, and tackle ourselves.
