Skip to content

Instantly share code, notes, and snippets.

@searls
Last active December 27, 2018 21:33
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save searls/62d9787f5f0484548086bd65fa87d119 to your computer and use it in GitHub Desktop.
Save searls/62d9787f5f0484548086bd65fa87d119 to your computer and use it in GitHub Desktop.
Winter 2019 Ruby talk proposal

The Selfish Programmer

Using Ruby at work is great… but sometimes it feels like a job!

This year, I rediscovered the joy of writing Ruby apps for nobody but myself—and you should, too! Solo development is a great way to learn skills, to find inspiration, and to distill what matters most about programming.

Building an entire app by yourself can be overwhelming, but this talk will make it easier. We'll start with a minimal toolset that one person can maintain. You'll learn how many "bad" coding practices can actually reduce complexity. You may be surprised how selfish coding can make you a better team member, too!

Details

The talk will follow a pretty straightforward outline:

  1. (~5 minutes) Introduce the main differences of writing an app for yourself versus building one as part of a team at work (i.e. the differences in priority lead to different tools/coding practices being used)
  2. (~5 minutes) Explain my particular problem learning Japanese and why—when I tried to start my own app—I was unprepared by 10 years of professional Ruby work to do everything myself
  3. (~25 minutes) Demo specific features of the app to explain challenges I faced, which led to counter-intuitive insights about how to best write code, speed up my feedback loops, and find shortcuts that you normally could never take at work (This will be the main body of the talk and probably cover 3-5 specific examples and lessons to learn)
  4. (~5 minutes) Draw from the main talk which lessons from individual can be applied to your team at work, too. (e.g. maybe Heroku is good enough over custom AWS, or that it's ok to have less automated testing, or to reduce an app's configurability)

I am very careful about structuring my talks to be engaging and informative, keeping people's attention while tying everything back to the main theme. I want people to walk away from this talk feeling empowered to use Ruby to solve their own problems, and with clear ideas of what their tools and code might look like to accomplish that.

Pitch

This topic is pertinent because nowadays, fewer people are exposed to Ruby as a way to code creatively than they used to be, and many of us may have lost sight of what was so great about keeping things simple and focused.

Over the last ten years as Ruby has gotten more mature and companies using Ruby have gotten larger and more complex, more developers are finding themselves in specialist roles (for example, working on a sub-team that writes specific services instead of full-stack application development) or using tools designed for huge companies (like AWS & Kubernetes) instead of tools that are easy for a single person to maintain.

I think this talk will be a lot of fun. I can't believe how much I learned about every stage of app development when I had nobody else to rely on, including how much I had to learn about changes to the Ruby language and gem ecosystem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment