On Courage (and Throwing Away Code)

Malina Tran
Tech and the City
Published in
4 min readJan 13, 2017

When I tell people about certain life decisions — to move to New York City, to physically challenge myself (e.g. running marathons in high school, playing rugby*, teaching myself to swim), to switch into a software development career — the response always warrants some kind of awe.

Some might call it “brave” or “courageous.”

But I’m not special and neither of my decisions or achievement. Off the top of my head, I can name friends who have ran seven marathons by age 17, moved out of the country, and pursued an artistic albeit creative career instead of a stable career. And I don’t do these things for accolades or any external validation. Heck, most of the time I’m doing it because, in the short-term, I am transgressing self-imposed boundaries that have been comfortable to me. And the act itself provides this fulfilling sense of being alive, however uncomfortably so. They were itches that I merely scratched.

This is why I’d like to dedicate this post to courage.

Being a developer was a decision informed by a need for intellectual stimulation. In the process, it has not been exactly a walk through the park. It has, at times, been filled with self-doubt and mental fatigue. This is perhaps why I enjoyed reading the values and principles set forth in Kent Beck’s “Extreme Programming Explained.” I was reminded by the many ways in which we exercise small acts of courage in our daily lives. While I haven’t completed the book, what I do like is the amount of self-introspection that Beck introduces to us readers and fellow developers. To date, I’ve read a handful of software-related books during the course of my apprenticeship. These books encourage us to write our code a certain way to achieve robust and extensible software, and of course, it all makes sense.

But Beck introduces four values — communication, simplicity, feedback, and courage. As a values-driven person, I approach decisions based on my somewhat unique set of values (e.g. is it healthy? Is it good for society, including more vulnerable communities? Is it safe for the environment?). In this way, writing code should also be based on shared values among developers. And in order to achieve and hold true to those values, we should act on certain principles.

I don’t think it is common for people to perceive developers as “courageous.” So, what is courage in this context? Beck mentions an incident in which a team of developers, upon realizing a flaw in the architecture, actively work to address and amend it. He also talks about throwing away one’s code, which I have come to terms with doing. This past week, for my hosted tic-tac-toe game, I had two stories related to customizing the game: 1) the user can select a marker of her choice and 2) the user can choose whether or not to go first. For both of the stories, I wanted to figure out what was the best way to achieve that. During the times when I didn’t have a working solution or the approach didn’t seem to work out, I went back to the drawing board. I am not afraid to git checkout -- . anymore. Sure, you may put so much effort in writing code and testing that code. But it’s surprising how much doing something wrong can help clear up your thinking. In fact, it’s pretty damn liberating to say, “I have tried this and it’s not working. Let’s move on.”

And because our principles comprise overlapping values, I often look toward simplicity (another value that Beck discusses). What is the simplest way to implement this? What is the bTest way to accomplish this, that would work for today’s purpose? Let’s remember that simple is not easy, as both Beck and Clojure creator Rich Hickey have mentioned.

With this in mind, I worked out a solution that works and eliminated extraneous code. It’s not perfect by any means, but it’s progress.

I think this book raises awareness about humanity within software development. In some ways, extreme programming is a misnomer. Its name suggests that it is somehow about “radical” action (e.g. pair programming, short iterations, quick feedback loop). Rather, I think it is about being thoughtful, collaborative human beings working together to make good software for the world.

*This was for a very short period during my freshman year in college.

--

--