I’ve learned a lot the hard way (pain) and the easy way (patterns).

Below is a collection of 12 principles I keep coming back to. Take what’s helpful. Ignore the rest.

1. Expect Everyone to Act In Their Own Self Interest and You'll Rarely Be Surprised
2. Once Something Is Agreed, Paper it Immediately
3. Don't Deviate Far From Standard Terms
4. Be A Good Steward of Capital
5. Beware The Most Dangerous Person in the Room
6. Improve Health to Improve Productivity
7. What Product-Market Fit Feels Like
8. (How to) Hire Extraordinary Employees
9. Avoid Complexity
10. There Can Only Be One (Founder & CEO)
11. Know Your Odds of Success. Be Good Enough To Succeed
12. The Central Limit Theorem of Advice

1. Expect Everyone to Act In Their Own Self Interest and You'll Rarely Be Surprised

A nicer way to say this is: “show me the incentive and I’ll show you the outcome.”

People aren’t evil. They’re incentivized. And incentives beat values more often than we’d like to admit, especially when money, ego, status, or job security are involved.

Don’t rely on other people to be saints.

Instead:

• Assume self-interest. If someone benefits from doing something that disadvantages you, expect them to consider doing it.
• Design for it. Make it in peoples’ best interest to do what you want, and not in their best interest to do what you don’t want.

This applies everywhere, including:

A) Employees / ESOPs

Retain and motivate employees by structuring comp and equity such that staying and performing is rational (i.e. better than what is available to them elsewhere). Don’t rely on loyalty. Loyalty can be fragile when rent is due.

B) Customers / Vendor Risk

No one gets fired for buying from Salesforce. People do get fired (or look dumb) for betting their roadmap on a startup that disappears in 18 months.

If you’re early-stage, you’re selling against risk, not just features. You can reduce that risk by:

• selling to smaller / risk-tolerant customers first,
• selling something low-effort to adopt (i.e. low switching cost), or
• building something new (i.e. not available elsewhere) or 10x better so that the buyer can justify the risk.

C) Investors / Partners / Advisors

Always ask: what do they want? How does my success (or failure) affect them? Once you see their incentive clearly, advice becomes easier to evaluate.

2. Once Something Is Agreed, Paper it Immediately

I’ve regretted not doing this more than once; I was slower than I should have been to learn this lesson.

A surprising number of people will change spoken commitments after the fact - sometimes without highlighting changes. Putting something in writing doesn’t “ruin the vibe.” If they’re serious about their verbal commitment, nothing changes.

Paper it. Immediately. And validate all details are as agreed.

3. Don't Deviate Far From Standard Terms

Weird terms create weird problems later.

If your salaries, equity grants, board rights, valuation, customer contracts, or investor terms are too far from normal ranges, future employees / customers / investors will ask: “why is this weird?”

Find out what typical bounds look like. Pick a sensible spot in that range. Save your novelty for your product / solution.

4. Be A Good Steward of Capital

Won’t someone think of the shareholders?

If you raised money, that’s shareholder money, not your money. Treat it with respect. Protect it. Try to grow it. Cut waste aggressively.

You should be proud to show investors each line item on your income statement:

• “Look what we built.”
• “Look how little we spent doing it.”
• “Look how capital-efficient we were.”

Keep offices austere. Revisit spend constantly. If you’re technical, find technical deals: negotiate vendors, use spot instances where possible (often 70% savings), avoid shiny tooling that doesn’t move the needle, etc.

We wouldn't have survived long enough to build a successful product (Hivemind was our fourth product) if we weren't so careful with our finances.

In startups, survival is compounding. The longer you survive, the longer you have to find product-market fit, and the more likely you are to produce returns for shareholders. It's all about the shareholders.

5. Beware The Most Dangerous Person in the Room

Watch out for people in (senior) roles who don't deserve them on paper. They have the most to lose.

My experience has been they (by necessity) prioritize politics, posturing, and narrative management over outcomes. Expect them to behave accordingly.

You can sometimes spot them by:

• unimpressive schooling / grades in fields where it matters,
• unimpressive experience,
• exaggerated achievements,
• shallow understanding of (and network in) the problem space,
• a pattern of conflict (e.g. public lawsuits, accusations),
• etc.

Avoid working with them if possible, despite charisma and assurances. Remember: where there’s smoke, there’s fire.

EDIT: I've since learned that some psychologists think there are two main leadership strategies: A) dominance and B) prestige / accomplishment. Try to seek out leaders who lead by prestige / accomplishment – you'll learn more from them (and probably like them more).

6. Improve Health to Improve Productivity

The healthier you are, the higher your average speed. Being healthy isn’t just self-care; it’s throughput. As such:

• sleep +8 hours whenever possible,
• do cardio and lift weights - a little goes a long way, and
• work <=60 hours a week (hands on keyboard).

As a former investment banking analyst, I can confidently say the following about +60 hour work weeks:

• outside of doing god's work (i.e. rearranging logos in PowerPoint at 4 AM for a 9 AM meeting), they are not needed / productive,
• your health (and output) will slowly degrade, and
• your marginal hourly productivity will become negative. You aren't well enough rested to be clever.

Every successful founder I know doesn't sustainably work more than 60 hours a week (hands on keyboard).

Work (sustainably) hard. Exercise. Rest.

It's a marathon, not a sprint.

7. What Product-Market Fit (PMF) Feels Like

Product-market fit is not a dashboard metric. It’s a feeling. It’s the moment selling flips from actively pushing your product to having it pulled from you.

• You don't sell the product, you describe it / demo it. Buyers want it based on that alone.
• Buyers don't need to be educated. They are aware they have the problem you are solving and are actively trying to solve it.
• Buyers want to talk to you. Most schedule additional calls. Inbound interest picks up substantially.

To find PMF, find a painful, resourced problem.

The best problems are:

• common in a specific niche,
• valuable to solve,
• known by customers; budget exists to solve it, and
• currently solved badly.

Solve that. Sell that.

Listen to problems. Ignore proposed solutions.

Customers are excellent at describing their problems but (often) bad at designing solutions.

As the old adage goes: to travel large distances quickly, people will ask for a faster horse, but what they need is a car.

You can only do one thing well.

That doesn’t mean only try one thing. Try many things quickly. But once something hits (you'll feel the pull), focus on that.

8. (How to) Hire Extraordinary Employees

I have a lot to say about identifying and hiring top talent... BUT I think one heuristic that captures 80% of what is important is: extraordinary people do extraordinary things.

When looking to hire extraordinary employees, look for people with extraordinary accomplishments or achievements. That could be academic, athletic, or professional. Often achievement is not isolated, but repeated, and easy to identify.

Don't expect people without extraordinary achievements to do extraordinary things. While there are (many) exceptions, if they haven't produced extraordinary achievements by the time you are interviewing them, why would they start now? Answer: they probably won't.

With the above in mind, a few other things to be mindful of when hiring:

• Do you like them? You'll be spending +40 hours a week, every week, with them.
• Do they want the job you are hiring for? If they don't, save the time you'll spend convincing / motivating them and find someone who does.
• Do they have the right attitude and aptitude? Everything else can be taught.

9. Avoid Complexity

You can only load so much context into a brain (or LLM, it turns out).

Complexity is a tax:

• harder to understand,
• harder to debug,
• harder to onboard,
• harder to improve, and
• easier to break.

Simple is clever. Clever scales.

10. There Can Only Be One (Founder & CEO)

Elon, Gates, Zuck, etc. With very few exceptions, successful companies (and governments) have one person at the top.

Co-founders are great; they work hard for less cash (and more equity), provide continuity should other co-founders burn out, etc.

But decision-making authority and clarity matter. If you have co-founders, decide who has final say. They become your company's benevolent dictator - the CEO. They become accountable for all top level decisions. They also become the shareholders' one throat to choke.

11. Know Your Odds of Success. Be Good Enough To Succeed

In university level calculus - before grade inflation, smh at you Gen Z - perhaps 50% of the class would fail the final. No one, and I mean no one, thought any of the top math students would be among the 50% that failed. And they never were. They were consistently at the top.

Startups are similar. Maybe 10% succeed. And it’s often the top 10% of founders (and teams) that do.

Anecdotally, all of the most impressive entrepreneurs I know (who were also top decile in academics and work ethic) have succeeded. More or less everyone else failed, perhaps predictably.

Further, in business, like in Catan, they are many winning strategies. The best strategy for you depends on i) what you're top 10% at executing and ii) how the board is set.

The uncomfortable takeaway: avoid games you are unlikely to win. Be honest about what you’re top-tier at, and choose a game where that actually matters.

Two more practical angles below.

A) Know What Success Requires: My Experience Biking Across the Country

When I biked across the country, I did napkin math on what success demanded: km/day, watts/hr, calories consumed, changes in wind resistance and power requirements due to elevation and headwinds (I went Toronto to Vancouver, into the wind), etc.

I did the math on what was needed. Then I trained until my fitness could meet or exceed that.

Companies are multivariate (i.e. many things matter), but the principle holds. Identify the 5-20 variables that actually determine your outcome (ROI, distribution, conversion, retention, product milestones, iteration velocity, hiring, etc.), measure them, then make sure you meet or exceed what's needed.

Easy in theory, hard in practice. But a helpful exercise nevertheless.

B) Persistence Increases Odds of Success

“Never give up” is not a strategy. But persistence plus learning is powerful. Survival buys you attempts. Attempts buy you luck. Luck buys you outcomes.

12. The Central Limit Theorem of Advice

Repeated advice is good advice.

Everyone is searching for the secret insight they’re missing. In practice, you’ve probably already heard the advice you need - multiple times.

Pay attention to what you hear most often. That’s the signal.

Consider the above an n=1 sample from an infinite number of viewpoints on principles for your career / business.

Take what’s helpful. Ignore the rest.

Remember: these thoughts are worth what you paid for them ;)

From August 7 to 28 (2021), I biked 4,447km from Toronto to Vancouver to raise money for The Canadian Cancer Society and The Jonny Kellock Foundation. The journey was in memory of all Canadian cancer victims, like my dear friend Jonny Kellock.

This article includes:

1. Ride itinerary (with links to Strava activities)
2. Where I shared updates
3. A note / thank you from me (written after the final ride)

Ride Itinerary

Ride 1 (Aug 7): Toronto > Tobermory (338km)

Ride 2: Tobermory > Ferry to South Baymouth > Thessalon (264km)

Ride 3: Thessalon > Michipicoten (303km)

Ride 4: Michipicoten > Terrace Bay (259km)

Ride 5: Terrace Bay > Thunder Bay (201km)

Day off 1 (Aug 12): in Thunder Bay

Rides 1 to 5: 1,365km

Ride 6: Thunder Bay > Ignace (237km)

Ride 7: Ignace > Kenora (242km)

Ride 8: Kenora > Elie | part A and part B (257km)

Ride 9: Elie > Virden (240km)

Ride 10: Virden > Regina (280km)

Day off 2 (Aug 18): in Regina

Rides 6 to 10: 1,256km

Ride 11: Regina > Swift Current (245km)

Ride 12: Swift Current > Medicine Hat (221km)

Ride 13: Medicine Hat > Strathmore | part A and part B (246km)

Ride 14: Strathmore > Banff (186km)

Day off 3 (Aug 23): in Banff

Rides 11 to 14: 898km

Ride 15: Banff > Rogers Pass (232km)

Ride 16: Rogers Pass > Shuswap (210km; forest fire smoke ended ride a little early)

Ride 17: Kamloops > Boston Bar and forest fire make-up laps (258km)

Ride 18 (Aug 27): Boston Bar > Vancouver (227km)

Rides 15 to 18: 927km

Where I Shared Updates

• Strava: for activity stats from daily rides
• Instagram: for pictures and videos from daily rides

A Note / Thank You From Me

We made it! Toronto to Vancouver. 4,447 kilometres cycled over 3 weeks.

I cannot think of a more intense way to celebrate Jonny, and explore the mountains he loved to surround himself with, than this journey.

Jonny was an adventurous, accomplished (yet humble), hard-working, and light-hearted person. I miss having him around, cracking jokes, and sharing a laugh. I know many of you do too.

To everyone who donated in his memory, joined me for part of the ride, provided encouragement, and shared the journey: thank you, thank you, thank you. As of today, over $29,000 has been donated to the Jonny Kellock Foundation and the Canadian Cancer Society.

A special thanks to 1) my fiancé Jacqueline, 2) the Kellock family, and 3) the Jonny Kellock Foundation. Your encouragement, advice, and assistance made the Journey For Jonny possible. Without you, it would not have been.

Thank you all <3

This article contains a list of the top 50 YC software startups (sourced from the October 2019 YC Top Companies page). It also contains aggregated statistics for valuations and back-end programming languages used.

Values in this article are sourced, but I cannot guarantee their accuracy.

Find me on Twitter @charlieinthe6. View article comments on HackerNews.

Table of Contents:

1. Top 50 Software Startups
2. Aggregated Stats

1. Top 50 Software Startups:

Notes:

• Ginkgo Bioworks, Boom Supersonic, Grin, Memebox, Helion Energy, North, RelativitySpace, and The Athletic were excluded from the below list; I didn't feel they were primarily software businesses. Feel free to disagree with my judgement.
• Values current as of August 15, 2020.
• If one language was the primary language used to build the initial product, one language is listed above. If it was not clear which language was primary, multiple languages are listed above.
• If I couldn't find which language was used to build the startup initially, I referenced the oldest job posting I could find.
• Valuations are approximate and predominantly sourced from recent articles online. Where I couldn't find an indication of value, ~$150M is assumed; startups listed above were all worth +$150M as of October 2019, as per the YC Top Companies page.
• "Y" and "N" values in the "DataSci / LowLv" column describe a startup's primary product (i.e. ML startups would have a "Y" for DataSci). It was included to provide additional colour on why initial back-end language(s) may have been used / selected. The values in this column are based entirely on my own judgement. Feel free to disagree with them or ignore them.
• Ruby and ruby on rails was a popular choice for YC startups around 2010 - 2012. Anecdotally, ~40% of YC startups used ruby during its peak popularity.

2. Aggregated Stats:

Startups with one (initial) primary back-end language:

Startups with multiple (initial) primary back-end languages:

Note: "Startups with multiple (initial) primary back-end languages" table doesn't add to 100% because multiple languages were used for startups.

All startups:

Note: "All startups" table doesn't add to 100% because multiple languages were used for some startups.

I recently started a podcast with my friend Tom Zaragoza called the DEVpreneur. It's a podcast about working on a software / SaaS business as a software developer.

Below I'll explain both how and why you should host your own podcast, as well as potential drawbacks of doing so.

Table of contents:

1. How to host your own podcast
2. Why you should host your own podcast
3. Drawbacks of hosting your own podcast
4. Ending thoughts

How to host your own podcast

In order to host your own podcast, you need to do three things:

i. Add a valid RSS feed to your website
ii. Add the media (e.g. mp3) file to your website
iii. Add the RSS feed to various podcast platforms

Add a valid RSS feed to your website

If your website isn't built using something like WordPress (i.e. you coded it yourself), or you simply want to build an RSS feed for your podcast manually, then you need to create of a valid RSS feed. Apple provides a sample RSS feed as well as documentation on different required RSS feed fields to help you create your own feed.

The XML / RSS feed for the DEVpreneur podcast looks like this.

After you've created your own feed, you can validate it using the Podbase podcast validator. Remember that as you add new episodes to your podcast, you will have to update your feed (or write code that updates your feed for you automatically).

Add the media (e.g. mp3) file to your website

The RSS feed you add to your website must contain URLs that link podcast episodes to their associated media (e.g. mp3) files. As such, you need to upload media files to a publicly accessible location.

You have many choices for where you host your media files. For DEVpreneur, we host the files on charliereese.ca (the same server that hosts our RSS feed) under the /podcasts route (e.g. https://charliereese.ca/podcasts/ep_01.mp3). You could, however, use one of the many cloud storage providers - as long as the file has a publicly accessible route.

Add the RSS feed to various podcast platforms

After you finish creating a podcast RSS feed and have hosted your media file(s) in a publicly accessible place, it's time to add your podcast's RSS feed to various platforms so that it can be found by future listeners!

Which platforms you add your podcast to is a matter of preference, but you may want to check out the following to get started!

Podcast platforms:

• Apple Podcasts
• Google Podcasts
• Stitcher
• TuneIn
• Blubrry
• Spotify

Why you should host your own podcast

At this point you might be thinking, why go through the above trouble to host my podcast when I can pay a nominal fee to have a hosting provider (like Transistor.fm) do it for me? That's a fair question, and there is one reason (other than nerd clout) why you may wish to do so: control.

You retain full control / customization of your RSS feed if you host your own podcast; it's easy to add specific XML tags to your RSS feed if you host it yourself - it may not be possible if you use a hosting provider.

Drawbacks of hosting your own podcast

Hosting your podcast isn't without drawbacks, however.

Every time someone downloads your podcast, a large media file has to be sent from your server (or cloud file storage provider). This could cause problems if you're expecting a very large audience to build over a short period of time, or if you have little bandwidth on the server hosting it.

Further, hosting your own RSS feed and media files will almost certainly take more time to set up initially than using a podcast hosting provider, and your feed may also be more brittle / error prone as a result.

Ending thoughts

While hosting your own podcast is both relatively simple and beneficial, it may not be worth it if you're concerned about setup time, stability, or bandwidth.

Do you host your own podcast RSS feed, or are you planning to? Why or why not? Let me know @charlieinthe6!

Knowledge Gained / Discoveries:

1. How to Start a VM for Ruby on Rails Core Development
2. Jumping Into the Console to Explore Changes
3. Rails is Comprised of a Collection of Standalone Gems
4. Learning How to Contribute to Rails is Easy
5. Running Tests for Rails is Easy
6. Ruby Has Great Introspection Methods

1. How to Start a VM for Ruby on Rails Core Development

After perusing Alex Kitchen's rails blog post and using instructions in this repository, it was simple to get a VM up and running using the latest release of rails.

This allows you to run tests / explore new features, patch bugs and issue pull requests (if you want to be a rails contributor), as well as alter code to see the impact.

2. Jumping Into the Console to Explore Changes

After using instructions in this repository to set up a rails development box, you can easily drop into irb (with local rails repos loaded) using the console tool that ships with rails available at rails/tools/console.

This allows you to easily experiment with any modification you make.

Want to know where a method on an object is defined? Try [OBJECT].method(:method_a).source_location or [CLASS].instance_method(:method_a).source_location in irb and find out!

If you are looking for where a ruby builtin method is defined, you'll have to check the C source code; look for the right C file (they're organized by class) and find the rb_define_method for the method.

3. Rails is Comprised of a Collection of Standalone Gems

Rails is comprised of a series of (mostly) standalone gems. Other than Action Mailer / Mailbox, Active Job, Action Cable, Active Storage, and Action Text, and Railties, the gems can be used outside of rails and replaced with different gems inside of rails.

As of 6.0, rails is comprised of the following core gems:

• Action Pack: routing and controllers
• Action View: view template lookup and rendering
• Active Model: non-Active Record (DB) model interfaces
• Active Record: connects and associates models with DB
• Active Support: collection of utility classes and standard library extensions
• Railties: glues frameworks together, handles rails initialization / bootstrapping process, manages rails CLI, provides generators core

And supplementary gems:

• Action Cable: WebSockets integration / support
• Action Mailbox: routes incoming emails to controller-like mailboxes for processing
• Action Mailer: email delivery
• Action Text: rich text content and editing
• Active Job: queueing framework for delayed jobs
• Active Storage: easily upload, reference, and associate files in cloud storage

4. Learning How to Contribute to Rails is Easy

Rails encourages everyone to contribute to Ruby on Rails! It's easy to learn how to contribute to rails by reading their guide.

If you contribute, your name gets put on this sweet list of rails contributors!

5. Running Tests for Rails is Easy

After using instructions in this repository to set up a rails development box, running tests is simple.

With the dev box running, running tests is simple:

# All tests (be prepared to wait):
cd rails
bundle exec rake test

# Component tests:
cd railties
bundle exec rake test

# Directory within component tests:
cd railties
TEST_DIR=generators bundle exec rake test

# Specific file tests:
cd actionview
bundle exec ruby -w -Itest test/template/form_helper_test.rb

# Single test:
cd actionmailer
bundle exec ruby -w -Itest test/mail_layout_test.rb -n test_explicit_class_layout

For more tips and tricks (e.g. testing with a specific seed or DB), check out the rails testing documentation.

6. Ruby Has Great Introspection Methods

Not sure what class an object is, or what parent classes / modules it has?

object_a.class.name
object_a.ancestors

Not sure if an object is an instance of a certain class?

object_a.instance_of?(ClassA)

Not sure what methods an object / class has?

ClassA.methods
ClassA.instance_methods

Not sure if a method is available to a given object?

object_a.respond_to?(:method_a)

Want to see the instance variables of an object?

object_a.instance_variables

Other Takeaways

• Checking out the *.gemspec in the root folder of a gem quickly shows you its dependencies
• There is a great guide explaining how rails autoloading / reloading works. Check out rails/activesupport/lib/active_support/dependencies/autoload.rb to see the code
• In the first level of rails gems (e.g. Active Record), the lib directory contains a file with the name of the module (e.g. active_record.rb), which configures how the gem is loaded when it’s started up
• Some gems have a rails/generators directory which holds the generators pertaining to the gem (e.g. rails g model)
• git log -S --reverse --patch --pickaxe-all; A way to search commits in reverse order with all code changes

I was at a bar with an old group of friends over the holidays. While we were waiting in line, one of them mentioned that he heard about a Twitter-bot that replied to tweets containing Biggie Smalls lyrics with other Biggie Smalls lyrics.

I thought the idea was hilarious, and after one or five beers decided it was something I had to build. However, I wanted to do things a little differently:

1. I rep the 6 I am from Toronto, so the Twitter-bot would be for Drake - a.k.a the DrizzyBot
2. The DrizzyBot would reply to tweets containing Drake lyrics with the next line of the song
3. The DrizzyBot would run at regular intervals with no human interaction
4. The DrizzyBot would not be flagged as spam by Twitter's (admittedly fairly impressive) spam filters

After a day of programming, tinkering, and giggling, the DrizzyBot was born.

Technical Requirements to Build the DrizzyBot

The following languages / software / packages are needed to build and run the DrizzyBot:

1. Ruby (at least version 2.1)
2. The (ruby) twitter gem

$ gem install twitter    

1. Git
2. OPTIONAL: a linux environment for scheduling recurring cron jobs; I use a (perpetually running) Raspberry Pi that my brother bought me for Christmas - thanks Tom!

Building the DrizzyBot

A. Initial Set Up

• Create and save bot.rb file in root directory (I called my root directory twitter_bot)
• In bot.rb file, require Twitter gem and standard library (Date) class we will be using:

require 'twitter'
require 'date'

B. Create a Twitter Application

• Create a twitter application here
• Record your:

1. Consumer key
2. Consumer secret
3. Access token (generate first in Keys and Access Tokens)
4. Access token secret (generate first in Keys and Access Tokens)

C. Create a File Containing Passwords

• Create and save passwords file in root directory
• Create a .gitignore file in root directory and add the passwords file to it:

# passwords
.passwords

• In .passwords file, create constant variables for passwords (containing keys from step B.):

CONSUMER_KEY        = "consumer_key123456abcdef"
CONSUMER_SECRET     = "consumer_secret123456abcdef"
ACCESS_TOKEN        = "access_token123456abcdef"
ACCESS_TOKEN_SECRET = "access_token_secret123456abcdef"

D. Create DrizzyBot Class

• In bot.rb file, require .passwords file and write initialize method:

require 'twitter'
require 'date'

# load passwords from dotfile here

class DrizzyBot
  def initialize
    @client = Twitter::REST::Client.new do |config|
      config.consumer_key        = CONSUMER_KEY
      config.consumer_secret     = CONSUMER_SECRET
      config.access_token        = ACCESS_TOKEN
      config.access_token_secret = ACCESS_TOKEN_SECRET
    end
  end
end

E. Copy and Paste Lyrics to Various Drake Songs

• Create lyrics.yaml file in root directory
• Download song lyrics in the following format (album, song, lyric; please excuse syntax highlighting):

thank_me_later:
    over:
     - Bottles on me
     - Long as someone drink it
     - Never drop the ball
     - F!ck y'all thinking?
     - Making sure the young money ship is never sinking
     - Bout to set it off in this bitch Jada Pinkett
     - I shouldn't have drove
     - Tell me how I'm getting home

• Create lyrics.rb file in root directory
• In lyrics.rb file, load lyrics.yaml file:

require 'yaml'
lyrics = YAML.load_file(File.join(__dir__, './lyrics.yaml'))
ALBUMS = lyrics

• In bot.rb file, import ALBUMS constant by requiring lyrics.rb file:

require 'twitter'
require 'date'
require_relative 'lyrics'

# load passwords from dotfile here

class DrizzyBot
  def initialize
    @client = Twitter::REST::Client.new do |config|
      config.consumer_key        = CONSUMER_KEY
      config.consumer_secret     = CONSUMER_SECRET
      config.access_token        = ACCESS_TOKEN
      config.access_token_secret = ACCESS_TOKEN_SECRET
    end
  end
end

F. Write DrizzyBot Rap Logic

1. Add method to (like and) reply to tweets containing (case insensitive) lyrics from a specified album and song with the next line of the song: see reply_to_tweets(album, song)

• Must create method that finds matching tweets (contains lyrics without matching next phrase of song): see find_tweets(phrase, next_phrase)
• Must create method that finds the most popular tweet, as replying to too many tweets will flag us as a bot: see most_popular_tweet(phrase, next_phrase)
• Must create method that likes tweet and generates reply with the next phrase of the song, the song name, and the album name: see reply_to_matching_tweets(phrase, next_phrase, album, song)

2. Add method to tweet random lyrics to circumvent being identified as a bot (only replying to tweets will flag you, as will tweeting the same content consecutively): see tweet_phrase_from_song(album, song)

After adding the above logic, your bot.rb file will look like this:

require 'twitter'
require 'date'
require_relative 'lyrics'

# load passwords from dotfile here

class DrizzyBot
  def initialize
    @client = Twitter::REST::Client.new do |config|
      config.consumer_key        = CONSUMER_KEY
      config.consumer_secret     = CONSUMER_SECRET
      config.access_token        = ACCESS_TOKEN
      config.access_token_secret = ACCESS_TOKEN_SECRET
    end
  end

  def reply_to_tweets(album, song)
    phrase_arr = ALBUMS[album][song]

    phrase_arr[0...-1].each_with_index do |phrase, idx| # can't reply to last phrase with next phrase
      reply_to_matching_tweets(phrase, phrase_arr[idx + 1], album, song)
    end
  end

  def tweet_phrase_from_song(album, song)
    phrase_arr = ALBUMS[album][song]
    phrase = phrase_arr.sample

    puts "DrizzyBot tweeted: #{phrase} ##{album} ##{song}"

    @client.update("#{phrase} ##{album} ##{song}")
  end

  private

  def find_tweets(phrase, next_phrase)
    tweets = @client.search(phrase, {result_type: 'recent'}).take(500) # limits to 500
  
    tweets.select do |tweet|
      today = Date.today === Date.parse(tweet.created_at.to_s)

      tweet.full_text.match(/#{phrase}/i) && 
      !tweet.full_text.match(/#{next_phrase}/i) &&
      today
    end
  end

  def most_popular_tweet(phrase, next_phrase)
    tweets = find_tweets(phrase, next_phrase)

    if tweets.empty?
      false
    else
      tweets.sort! do |a, b|
        b.favorite_count <=> a.favorite_count
      end
      
      tweets.first
    end
  end

  def reply_to_matching_tweets(phrase, next_phrase, album, song)
    tweet = most_popular_tweet(phrase, next_phrase)

    if tweet && !tweet.user.screen_name.match(/The110God/i) # tweet exists and isn't my account
      screen_name = '@' + tweet.user.screen_name
      album = album.gsub('_', '')
      song = song.gsub('_', '')

      puts "Favorited then tweeted at: #{screen_name}"

      @client.favorite(tweet)
      @client.update("#{screen_name} #{next_phrase} ##{song} ##{album} #drizzybot", 
                    in_reply_to_status_id: tweet.id)
      
      sleep(rand(300) + 180) # add 3 - 8 minute gap between tweets
    end
  end
end

G. Create DrizzyBot Object and Prepare it to Tweet

At the bottom of your bot.rb file (after the last 'end'), instantiate a DrizzyBot object and instruct it to (1) reply to tweets and (2) tweet random lyrics from a given album / song (song must be in lyrics.yaml file):

drizzy_bot = DrizzyBot.new
drizzy_bot.reply_to_tweets('views', 'one_dance') # 1
drizzy_bot.tweet_phrase_from_song('views', 'one_dance') # 2

H. Execute bot.rb File

From your terminal, change into your root directory and type:

$ ruby bot.rb

And that's it! Your very own DrizzyBot.

I. OPTIONAL: Set up Crontab

If you want to have your Twitter-bot send tweets without having to lift a finger, and you have a linux environment on your computer, open your crontab:

$ crontab -e

And add the following code to execute your Twitter-bot every day at 12:01 pm (your file paths will differ; please excuse the syntax highlighting):

1 12 * * * cd /home/pi/programming/twitter_bot && ruby bot.rb

Now you have a DrizzyBot that lives on its own!