Here are my slides and a paraphrased summary of some of the things that I talked about at DjangoCon EU 2013. You can find the full slides on SpeakerDeck and there’s even a video of the talk on YouTube.
Originally this talk was called, “How to build the tools that developers want to use.” I later cancelled the talk to focus on something slightly different instead. While working on that original talk, I came up with a number of pointers about how to make great software that people want to use again and again.
This got me to thinking about why I was coming up with these specific suggestions, because while I definitely agreed with them in certain contexts, I didn’t think they were universally useful or true. So, I got to thinking about how I made decisions and came up with something that was a little more fundamental to my identity as a developer, entrepreneur, and artist, an idea I call “Principle Philosophy.”
The first thing to note is that I’m not talking about your school principal; instead, I’m talking about the other kind of principles. The ones that help us make decisions on a day-to-day basis. The guidelines that we use when we’re making choices.
I want to combine the principles I use with this idea of philosophy, which is just a way of thinking about, discussing, and studying ideas in an intellectual manner.
When we take those two ideas and combine them, we end up with “Principle Philosophy,” which is just a way of thinking about and discussing the rules that dictate our behaviors - our principles. Specifically, I want to look at the principles that I’ve picked up over the years that have made me a better developer, entrepreneur and artist. And, I want to share them with you in the hope that they will help you as well.
So, let’s take a step back and talk about who I am. Just to avoid any confusion, I am going to say at the outset that, despite the handsome resemblance, I am not Ryan Golsing. I’m actually Swift, a developer evangelist over at SendGrid. If you’ve never heard of SendGrid, we’re an API company that makes it super simple to send and receive emails. I’m also one of the founders of Hacker League, which is a platform for people who organize and attend hackathons.
These roles are developer and startup facing, giving me the the privilege of being able to help them a lot. Specifically, I have the opportunity to help them succeed and get better at what they do. I find that very rewarding, which I trace back to some of the principles my parents taught me when I was growing up.
I was my parent’s first child and one of the first things they did was to identify a good success metric. How do we know we’ve done a good job raising our son? The answer, they decided, was that they wanted me to be a “Good Person,” by which they meant they wanted me to be a successful, contributing member of society who worked hard and did the right thing.
So, they found themselves asking, “How can we raise our son to be a good person?” The answer that they came up with goes back to those principles that we talked about a little earlier.
If you lay out a strong foundation for somebody that’s based on good, reliable rules and they don’t do anything to violate those principles, then they’ll do well in life. That makes sense, right?
So they were teaching me things like:
- Always do my best
- Don’t be a quitter
- Help those less fortunate
- Don’t steal
The list goes on, but I knew that as long as I stuck to the rules on the list, then I would end up as a “good” person.
And, this all makes senses. However, I think that the way that we go about approaching these things and thinking about them is total bullshit. I’ll tell you why.
It’s because the rules as given are very black and white concepts. Either I’m stealing or I’m not, either I’m doing my best or I’m not. However, most situations that you encounter on a day-to-day basis don’t actually fit into this black and white, boolean way of thinking.
The truth is that life is more like gray and gray. We end up using tools like pro / con checklists to decide which side of that black and white line something falls on, but it’s very rare that something falls cleanly on one side or another.
Up to this point, I don’t think that any of this should be terribly surprising to anyone, because we make these decisions on a daily basis. But, I think something that’s a lot more interesting is how we go about answering this next question.
How can I be a good programmer? When we think about the ways that programmers make decisions, we consider them to be logical and methodical people.
After all, they deal with things like code or math all day. These things are built in steps and are either right or wrong (read: black and white). That’s a little scary, considering that we just talked about how bad black and white paradigms are for gray inputs.
But, being logical, methodical people, programmers must have a better system for deciding what’s good and bad, right?
The truth is we don’t. We go around saying things like:
- Don’t repeat yourself in code
- Write tests
- Open Source your tools
- Blah, blah, blah
These are the the same old black and white rules that we’ve been having problems with on a day-to-day basis and we expect them to handle our super gray inputs.
The even sillier thing is that we get so passionate about these things, that we go on the Internet and yell at each other because we don’t agree with the way that other people interpret these principles. People fight over principles like “ruby is better than python” or “you shouldn’t write unit test,” all of which are absolutely absurd. We all know that applying these gray inputs to black and white functions is a craps shoot.
We seem to still think that we have a decision making function that looks some thing like this. We get a thing. We take a look at the thing. If the thing is good we, do it and if it’s not, we don’t. But, guess what? It doesn’t actually work like that.
The questions I would raise next are, “How do we know what’s good?” and “how do we know what’s worth doing?”. And it’s really hard to answer those without talking about this guy.
Immanuel Kant. If you don’t know him, he’s a German philosopher who lived during the Enlightment. He’s widely considered to be the Godfather of modern philosophy, because it’s difficult to have a philosophical discussion without bringing up either arguments he made or arguments others made that were influenced by him.
He had a number of arguments that are still relevant today, especially in regard to morality and how that functions with our ability to reason. These next few slides are a summary of some of those arguments and my interpretation of them.
The first thing Kant wanted to know was why we have the ability to reason. Why do we have this gift of being able to think logically about things? This question is incredibly relevant to our earlier discussion of programmers.
A lot of people would say that our ability to reason must be meant to be used for our own happiness, but Kant disagreed. If life was about going around being happy then we would just follow our instincts. The choices become pretty obvious when all you’re thinking about is yourself all the time. But, the truth is, we do things all the time that are not in our own best interests. Kant argued that since this is true, reason must be around for some other purpose.
He theorized that our reasoning must be around for us to be good. That the fact that we’re capable of reason, means that we must be capable of moral, good decisions. This brings us back to the original question that I posed and fits with my parents model and the principles that they were trying to instill in me.
How do we actually know if something is good? Kant had this three-pronged argument. This is a really condensed version of these three points, so I highly recommend you read the full thing yourself if you want to get a deeper view.
The first prong was this idea of duty. Duty is some kind of moral or legal obligation that you have to fulfill. Kant said that good things always come from our pursuit of duty, that as you’re pursuing these moral obligations, good things will come naturally.
But, not all things we do from duty are necessarily good. An example of this might be something like open source. If you’re open sourcing code because you feel some kind of obligation to pay back the developers who open sources before you, you’re doing it from duty but it wouldn’t be a fit for Kant’s definition of good will. On the contrary, open sourcing code because you intrinsically feel it’s the right thing to do would fit that definition.
The next thing Kant got into was that the morality of an action should be separate from the goal or the actual outcome of that action. It has to come from the underlying principles that you build on - “the principle of the will” as he called it. You can do things that are good that have a bad result; things that are the right thing to do, but just happen to have a crappy outcome. And that doesn’t make the decision to act bad or anything, it just means it had a bad outcome.
The third thing was the idea of universal lawfulness. This is the idea that you shouldn’t do something unless you’re okay with literally everyone else in the world being able to do that thing too. So, we don’t steal because then there would be no sense of ownership, as everyone would just steal from each other. Likewise, maybe tests are universally acceptable, because it would be okay for everyone to rigidly test everything unconditionally (just an example).
I think all of these rules provide a pretty good foundation for how we decide if things are good or bad, right or wrong, and I agree with everything that Kant has said so far. But, the part where we start to differ is here:
The idea of priori vs posteriori knowledge. Kant said that the things that we do that are good must come from priori knowledge, which is knowledge that we just naturally have; our gut moral feelings. Alternatively, our posteriori knowledge comes from our experiences and is based on our subjective knowledge and therefore, Kant argued, cannot be moral.
I totally disagree with this, because I think it’s impossible for us to totally separate out our decisions from our past experiences and yet I think I make plenty of good, moral choices daily while relying on those experiences. In fact, our principles are directly tied to our experiences as many of them develop directly out of things we’ve gone through.
I think Gandhi actually summed that up really nicely in this quote.
“A man is the sum of his actions, of what he has done, of what he can do, nothing else.”
What he’s getting at here is how impossible it is to separate ourselves from our past experiences. So I want to take this, and revisit that really naive function that we defined before.
It probably looks something a little more like this in reality. We look at more than just some arbitrary boolean when we make decisions. We actually calculate a value based on our past experiences and their outcomes. If we don’t have anything in our experiences that would fit the specific case, then we weigh the good against the bad and make a decision based on that.
Essentially we boil down to the sum of our experiences; we are this value. The best thing that we can possibly do for ourselves, therefore, is optimize our experiences so that this expression evaluates to be as large as possible; we need the biggest pool of things to draw on when we’re making decisions.
There’s two ways we can go about doing this. The first way is through our first-hand experiences, which are the things that we’re doing every day. These are the choices we make and the results of those choices are evaluated in our own subjective context.
The second way is the reason that things like conferences and networking events are so important: your network experience. These are the experiences that your friends, mentors, family, peers have been through and share with you. These let us expand our foundation of experiences to draw from at an exponential rate.
Everything looks different from the outside. Unless you’ve gone through something or know someone who’s gone through something, it can be hard to make the right decision. So the knowledge that you get from your network and the knowledge that you get from making choices every day is super important. Without it, we can’t possibly find the answer to questions like, “Am I a good programmer or person?”
Up to this point, we’ve talked a lot about the theory about how we make decisions; about what makes something good and bad; about how important principles are for building up a foundation; about how important the experiences that we go through are. But, now I want to get more into the practice. I want to tell you a story about an experience that I got a ton of value from and how it made me a better programmer, entrepreneur, and artist. I hope this helps you, too.
This story is actually about Little League. If you’re not familiar with Little League, it’s a suburban American tradition where little kids get together on Saturdays and play baseball. Parents come to watch them play and cheer for their kids' teams.
I played in my town’s Little League from the first day I was eligible until the last day I was eligible, but it wasn’t because I was great at baseball. It was actually quite the opposite case. I was horrible at baseball. I could barely catch the ball, I definitely couldn’t throw it, and sometimes while swinging the bat, I would accidentally let go and it would hit people.
Overall, it was a really horrible experience and I hated it. I wasn’t motivated to even try, because I was so bad. I really wanted to quit. One day, I approached my parents and said, “Mom, Dad, I know you think it’s a good idea for me to play Little League because I’m meeting people and doing something athletic. But, the truth is, I hate it and don’t want to do it anymore. I quit.”
My parents looked at me and said, “Hang on, we need a minute to talk about this”. They went outside, chatted for a few minutes and then came back to pass their ruling. They looked at me and said something to the effect of “No, you’re not quitting. We aren’t raising a quitter for a son.”
Instead of motivating me to go out and give Little League a second try, this actually made me even more unmotivated to try to find value in baseball. So rather than sitting the bench or half-assingly playing right field, I would do things like laying down in the grass instead. Then, at least, the coach would pull me out and send me on my way home early.
My teammates became increasingly hostile towards me, because they could tell I wasn’t even trying to play anymore. Effectively, I accomplished the complete opposite of what my parents were trying to get me to do. I had quit without actually quitting.
My parents saw what was going on and tried to figure out a way to motivate me and get me to find some value from the whole experience. What they came up with was a monetary incentive. They promised me $100 if I could ever manage to hit a home run. At the time, that was a lot of money to me, especially considering I wasn’t actually doing any serious manual labor to earn it.
I got it in my head that I wanted this $100 more than anything. Things started to change. I would go to baseball games and actually try to hit the ball. Don’t get me wrong, I didn’t get better over night. It was a very rocky road along the way and I still sucked at baseball, but I managed to slowly improve, inch by inch. I managed to hit the ball a few times and everyone was more supportive now that I was actually trying.
Fast forward to some time near the end of my Little League career. It wasn’t the last game. It wasn’t the bottom of the 9th. The bases weren’t loaded. There was nothing dramatic about this day except that I only had a few chances left to hit that home run. I get up to bat this particular day. The pitcher throws the ball. I close my eyes and swing the bat as hard as I possibly can.
Crack. I make contact and the ball goes flying. I look up and the ball is sailing towards that fence. Closer and closer every second, I can feel that it’s going to go over.
But it doesn’t. It falls just short of the fence. No home run once again.
I look up and at this moment realize that the entire time this was happening, I never started running. All these people, my parents, my coach, my teamates, are behind me screaming at the top of their lungs, wanting me to run. Go! Go! Go! I start running.
Needless to say, I was out before I even hit first base.
The sad ending to this story is that I never actually hit that home run. I never accomplished that goal, but I certainly learned a lot from that whole experience. In hindsight, I think the thing that was so important to me wasn’t necessarily the money that my parents had promised me. Instead it was that I wanted to make them happy, or proud, or show them that I could do it.
I want to examine some of the other things I learned from that experience and talk about how they made me a better programmer, entrepreneur, and artist. Hopefully, this will help you learn to examine some of your own experiences and principles too.
The first thing that I learned was to always “swing for the fences”. And I know that’s kind of a cliche when you’re talking about baseball. Ha. But seriously, I think having a broad vision is super important for equipping yourself for major success down the road.
There are several reasons for this, but mainly it prevents burnout and enables you to take bigger risks. I also think people tend to understand big goals more easily than little ones, so they’re certainly easier to share with other people.
As a developer, this has been instrumental to the way that I do my job. Developers have this tendency to stick with what they know. If you’re a Django dev and every day all you do is write Django apps, well there isn’t much of a chance that one day you’ll wake up and decide to write your next production app in Rails or Node.js. Having a large goal enables you to take dramatic, deviating risks because you have a lot of ground to cover anyway.
I have a good example of this. At the time, I was working at Crowdtap as a Rails developer. We had this monolithic test suite that would take three hours to run. So every day, we would push branches to CI and then three hours later they’d come back red, at which point we’d have to stop what we were doing and fix them. Not very productive.
So one day, the CTO comes to me and asks me to work on cutting down the time it takes to run the suite. I set a large goal for myself. I wanted to cut the time in half. To get there, I could have done the obvious things like moving to a faster box, caching, cutting down database calls, etc. But, since I had such a large goal, I went for something totally radical in Node.js and managed to cut out 25 minutes from the build (details, slides). It wasn’t the hour and a half I wanted, but it was probably more than I would have gotten playing close to the vest.
The next thing I want to talk about is about having small goals to build up to your big ones. I never consciously planned this out while I was playing baseball, but between where I started and that attempted home run, there was a lot of ground for me to cover. I made a ton of incremental steps that helped me get to where I ended up, and the same has held true for my software engineering career.
I maintain a library called Breakfast Serial, which helps programmers talk to Arduinos using Python. It gives them a set of simple, high level objects to work with so they can build things quickly and iterate. My big goal for the library is to be the best library out there for Arduino and Python, but I can’t just do that over night. To get there, I’ve been setting and completing small goals of adding individual components to the library. First it was LEDs, then buttons, then sensors, and so on. Small steps forward.
Another lesson I learned, is that it’s totally fine to be bad at things. You don’t have to be good at everything you do and, in fact, being bad can help you gain a new perspective on things. People at the top don’t usually start from the bottom, so you can end up with the upper hand because you think of things differently.
Hacker League has been a great example of that for me. When I started Hacker League, I had actually never even won a hackathon. I had a history riddled with failure and disappointment. A year and a half later, we’ve run over 300 events including big names like Tech Crunch Disrupt and Evernote’s DevCup.
Being at the bottom gave me the insight to focus on things that were more important than sponsorship and who won because I learned their value first hand, and we ended up better off for it.
This is a quote that most people attribute to Mark Twain, but I’m pretty sure that’s not true.
“Quitting is easy. I’ve done it thousands of times.”
Usually it’s used in reference to smoking, drinking, or gambling, but what I really want to talk about here is that quitting can be the easy way out. My parents were absolutely right about this and it’s been instrumental to my personal development that they didn’t let me quit.
One of the hardest things when you’re building tools for other people to use is when no one ends up using them. I maintain a number of repositories that almost nobody, including myself, uses any more. And that’s hard, right? Why would you want to work on something that nobody is using when the easy thing to do would be not work on them? If someone submits a bug, it’s just one person, so what does it matter?
Persistence is really the key for success. And I don’t mean to say that you can’t ever quit anything, I just mean that you should give a valiant effort before you can legitimately stop something. Just like when I was playing baseball and not trying, things got a lot better once I started to put real effort into it. The same is also true for software engineering.
The end might not be anywhere in sight, and you might never hit that home run, but giving something a shot and refusing to give up on it can be the difference between mediocrity and success.
There are way more examples in the video of this talk, so if you’re interested I highly recommend checking that out.
We’ve talked about a lot of things, here. How we make choices, how we decide what’s good, how our experiences and principles help us do those things as well as examples of some of this in action. Where do we go from here?
Back to our original question: “How can I be a good X?”. These kinds of questions are fundamentally flawed. We know that everyone has a different foundation and pool of experience to draw from. We know that one size doesn’t fit all when it comes to making the right choice. We know that experiences and principles are relative to ourselves even though we may share them with other people. So, I think we need to start asking better questions.
We should start asking ourselves things like, “How can I can be a better programmer, entrepreneur, or artist?” And all we have to do is optimize the materials that we rely on to make decisions.
I want to leave you with some action items, I realize that these are pretty general, but just think about them the next time you’re making a decision or you’re criticizing someone else’s decisions.
- Build a strong foundation of principles
- Remember, one size doesn’t fit all
- Learn from and share your experiences
- Build a great network
- Ask the right questions
Even when things are totally unrelated to programming, your experiences and the principles that you’re building from those experiences helps to shape that part of your life and your decisions. Those experiences will help you become a better programmer, entrepreneur, artist, or whatever you may be.
Special thanks to the Noun Project for all the awesome images. You guys rock.
Comments and discussion on Hacker News.
P.S. My name is Swift. I'm a former developer evangelist at SendGrid and one of the founders of Hacker League. I also tweet as @SwiftAlphaOne. Follow me there for more of my thoughts and maybe a laugh or two.
Tweet Vote on HN