Skip to content

Instantly share code, notes, and snippets.

@lfender6445
lfender6445 / gist:9919357
Last active July 3, 2024 20:50
Pry Cheat Sheet

Pry Cheat Sheet

Command Line

  • pry -r ./config/app_init_file.rb - load your app into a pry session (look at the file loaded by config.ru)
  • pry -r ./config/environment.rb - load your rails into a pry session

Debugger

@swyxio
swyxio / 7rules-for-intemediate-developers-3.md
Last active October 28, 2021 19:29
Clone Open Source Apps

3. Clone Open Source Apps

You already know you should be making projects to learn things and potentially add to your portfolio. You've read your Malcolm Gladwell, you know that you need 10,000 hours of deliberate practice. Given you're just starting out, I have a slightly contentious suggestion for you: DON'T make anything new.

Your decision-making is a scarce resource. You start every day with a full tank, and as you make decisions through the day you gradually run low. We all know how good our late-late-night decisions are. Making a new app involves a thousand micro decisions - from what the app does, to how it should look, and everything in between. Decide now: Do you want to practice making technical decisions or product decisions?

Ok so you're coding. You know what involves making zero product decisions? Cloning things. Resist the urge to make your special snowflake (for now). Oh but then who would use yet another Hacker News clone? I've got news for you: No one was gonna use your thing anyway. You

4. Specialize in the New

You already know the value of a niche - you go up in market value the more specialized you are in anything. So what do you specialize in?

There are many schools of thought, including ones where you could be a generalist that doesn't specialize in anything. I find one rule to be simplest and most effective above all: Specialize in the New.

Didn't we just agree to avoid FOMO? Well yes, thats an important distinction - don't specialize in everything new. Specializing means you have to say no to a lot of things. Just pick something new that fascinates you, and hopefully many others as well. Since you're learning in public, you'll know when you hit on a real nerve. Budget in the idea that you'll fail a few times before you find Your Thing.

Then the other big objection: There are plenty of jobs/money/etc in (fill in the blank older technology) too! This is usually followed by some big numbers and anecdata. "My brother's cousin's roommate's friend took this COBOL job and now he's ear

@swyxio
swyxio / 1.md
Last active February 8, 2024 22:30
Learn In Public - 7 opinions for your tech career

2019 update: this essay has been updated on my personal site, together with a followup on how to get started

2020 update: I'm now writing a book with updated versions of all these essays and 35 other chapters!!!!

1. Learn in public

If there's a golden rule, it's this one, so I put it first. All the other rules are more or less elaborations of this rule #1.

You already know that you will never be done learning. But most people "learn in private", and lurk. They consume content without creating any themselves. Again, that's fine, but we're here to talk about being in the top quintile. What you do here is to have a habit of creating learning exhaust. Write blogs and tutorials and cheatsheets. Speak at meetups and conferences. Ask and answer things on Stackoverflow or Reddit. (Avoid the walled gardens like Slack and Discourse, they're not public). Make Youtube videos