pysthlm talk about dedication, inspiration and routine
CSS JavaScript F#
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
css
js
lib
plugin
README.md
index.html

README.md

It can't be that hard, right?

A talk about dedication, inspiration and routine

Given at #pysthlm meetup #17: Wednesday, May 7, 2014


Hi! My name is Lowe, and I am a developer at Spotify. For a long while, I've been very interested in what makes us want to develop things and how we can use that to become better developers. To this end, I have been experimenting a lot over the last year, and now I want to share the observations I've had.

I want to talk about three topics, and all of them will somehow relate to the innuendo-laden question "It can't be that hard, right?". The three topics are:

  • Dedication
  • Inspiration
  • Routine

In the context of this talk, these three all relate. More importantly, I believe that dedication is a goal that you can reach with a combination of inspiration and routine. All three lead to the other in some way.

Dedication

So, what do I mean when I talk about "dedication"? To me, it's about the dedication to always want to become a better developer and to always strive to evolve your skills. And why would one want that? It could be many things, but my personal favorite is probably a certain feeling that you might actually recognize. Sometimes when you find a new brilliant tool, or something you just wrote just fucking works exactly the way you planned it (or better), you get this very nice feeling that I think only developers can understand, and you just tilt your head back and go "oh, that is soooo beautiful". You might know this feeling or something like it, right? It's like a beautiful little storm of endorphins, and they come from what is actually pretty small things.

It's also a lot of fun to be good at stuff, especially when that "stuff" is about creating more stuff. Developing is a form of creativity, and human beings as ourselves get a special sort of satisfaction when creating things. However, to create something, you need some inspiration.

Inspiration

So, where do we get inspiration? We developers create things for different reasons. Sometimes it's for our daily work, and when it's that, the inspiration is usually focused around solutions to a problem you're hired to solve at work. And, sometimes it's because you had a very great idea for something you've been thinking about on your free time and you just want to scratch that creative little itch. When this happens, it's usually just out of nowhere, and probably at a time where you are not even remotely close to a computer.

Inspiration can happen in many ways, and it's probably different for each and every one of us. I'll get back to the how later in this talk, because I want to talk about the title phrase of this talk: "It can't be that hard, right?". When inspired, it's very easy to say that, and if you do say this to someone without any hints of sarcasm, you'll usually met with disbelief and a reply in the lines of "eh, hells yes it can".

Developers create things. Creators overall, not just developers, usually develop an abstract skill of thinking. This form of thinking allows one to go from a view of a problem to a suggested solution very quickly. Or, in the case of art forms like painting, go from nothing to vision of creation equally quickly. When one quickly goes from the very beginning of a workflow to a vision of the finished creation, it's very simple to underestimate the length of the road between start and finish.

So, in a sense, I agree with the disbeliever saying "yes, it can be that hard". After a couple of years of being a developer, I've realized that the road to the finish can be very long, if not infinite. I mean, how many of us have actually been literally done with a project? To add to this, that road is not only paved with good intentions; it's also paved with unforeseen errors during development as well as lots and lots of Exceptions. Therefore, I think that the "It can't be that hard" mindset can be seen as a form of naivety.

To relate back to actual naivety in my younger days, I did something of the sorts during math classes. I took pretty much every math class possible up until the end of high school, and all my math teachers concluded that I only had one real issue as a math student; Whenever I saw a problem or an equation, I solved it all in my head and just stated the solution. My teachers then tried to explain that I needed to state all my steps so that they could follow my train of thought and that the steps are even more important than the answer. As the rebellious little shit I was (and to some extent still am <3) I answered with "Well, I got the solution. Why would you need anything else?" and then reluctantly did all the steps needed.

I have since realized that my approach was poor and naive, and I am thankful for the fact that my teachers were adamant to tell me that my workflow was bad. Still, this naivety stuck with me, and when I started to develop software, I was back at square one again. Explaining and communicating the steps are as important as ever then, but I still missed out on it.

But, I also defend this Developer Naïveté. It's not all bad. To the contrary, I find it really useful! Based on my own experiences and my half decade of working with developers, I've observed that we reach really intense levels of productivity when we have the creative sparks generated by this naivety. So, while I agree that it is bad to disregard the amount of work needed to go from problem to solution, I think it is worse to undoubtedly quench these sparks and disregard them as naive. Getting the inspired person to explain and communicate the steps needed for this idea to happen is still important!

Instead of that, I'd recommend recognizing this and embracing the possibility that letting the developer work on her ideas for a while might give a boost in productivity. There is still some chances that the idea actually is genuinely naive and troublesome, but I've seen and experienced too much instant dismissal that I can't help but be worried. Getting these sparks dismissed enough times, the developer will eventually stop having them and might lose the connection to one of the most valuable feelings about being a developer; the feeling of creativity.

However, this kind of dismissal can also have the complete opposite effect. I overheard a conversation from one of the tech leads at Spotify saying "Well, whatever you do, do not build a new build system. That would be the absolute worst thing to do at any given time at all!". So, naturally, I went home and started to build a new build system, because you can't tell me what I can't do!

In all seriousness though, the point I am trying to get across is that it is important to recognize when someone is inspired and is presenting an idea, and try to help that person by discussing that idea. Not with dismissal, but with an open mind and with constructive criticism.

So, that's about keeping and defending inspiration. I said I would get back to the part about getting inspiration; so, where do you actually get it from? This segues nicely into...

Routine

Last October I read [a blog post about 177 days of GitHub][177]. It outlines the idea that you should strive to contribute something to an Open Source project every day. It doesn't need to be much, just 20 minutes of writing a small patch or reporting an issue will count. The goal of this idea is to get into the habit of contributing every day and keeping that up by developing the mindset of not wanting to break the chain.

This really piqued my interest, so I set out to do it. It can't be that hard, right? When I started, I was notoriously bad at habits and actually getting shit done, so I thought that maybe I could change that whilst getting a chance to give back to the beautiful world of Open Source Software. And I did. I even got to the point where I myself could write a blog post called "177 days of GitHub", where I boasted about how well I had done. I did almost 900 commits and contributed to 11 projects that were not my own. Even more importantly, I started 7 new ones of my own.

After a while of doing the contributions, I started to feel very inspired. Because I was exercising my mind in contributing to non-work things every day, my creative muscles started to flex a bit. Not only did I start new projects, but I also felt like doing things I had never done before. So, I tried golang, which by the by is an awesome language that actually deserves at least part of the hype it is getting. I also got this fix idea to try network programming for some reason. I had no idea of how to do any kind of that, but I wanted to make some kind of Celery-like thing, but with no central broker. As an aside, if you ever feel that normal programming isn't infuriating enough, try network programming. Network code always finds a way to die in the most inexplicable ways, and after a while it feels like it's literally just mocking you. No matter really, but what happened was that I was actually feeling a positive effect from doing this contribution; I was getting more inspired than ever before.

Unfortunately, irony was abound! Just two days after being glad for passing 177 days and excited to make it through a full year of contributions to Github, I failed. I missed my 24 hour window because of reasons, and my streak was broken. This was a harder hit than I thought, and I was actually very sad about my failure. I took a month of vacation from the hard routine, and then I had a little retrospective of how I'd done. I celebrated all the good things I just mentioned, but I also realized that I was starting more than I finished. I mean, many moons and 200 commits later, my network project still kinda can't send messages properly. Only one of the projects that I started ever really made it out from the dreaded beta land, so when I restarted my spree about a month ago, I tried to make sure to stop starting stuff and start finishing them.

And this segues beautifully back into...

Conclusion

...dedication. After kind of completing my initial contribution experiment, I found new ways to improve myself as a developer and as a person. I will strive to continuously do so, and I hope that I have inspired you in some way to do something like it. Be inspired to do something, create a routine to do it, and be dedicated enough to keep doing it. And most importantly, remember to develop because it's so much fun! It literally isn't that hard.

I conclude this talk with a quote from my favorite TV dad: "Success is 1% inspiration, 98% perspiration, and 2% attention to detail."

  • Phil Dunphy, Modern Family

Any questions? Because of the nature of this talk, I would like to hold an Open Space about this topic later on this evening.

Thank you.