Skip to content

Latest commit

 

History

History
executable file
·
181 lines (110 loc) · 5.73 KB

w1_d3_rtfm_finding_things_out.md

File metadata and controls

executable file
·
181 lines (110 loc) · 5.73 KB
Raw

RTFM - Finding Stuff Out

##Opening

Pop Quiz
  • Hands up if there's a subject you know really well
  • Keep your hand up if you know everything about the subject...
  • Really... everything... You wrote the book? phew you can take a break
  • Everyone else...

It's a common phrase that it takes 10,000 hours to achieve mastery.

image

WDI is 60 days, 10 hours a day... 600 hours


##We do: How to get answers?

Let's think of some ways that we can think of solving our problems:

A problem:

You're working on a photo-sharing social networking app, and you want to only allow png, and jpg files to be uploaded, but you don't know how to do this.

How would you go about getting answers?

Write answers on the board

Two broad groups of answers:

  1. Where someone else is giving us the information
  2. Where we're looking for it ourselves
Answers might include
  • Ask co-workers
  • Ask the community (on the internet)
  • Look up documentation ('man')
  • "Google" - look on the internet

The difference in these answers seems to be that one type is focused on relying on others... the other is finding for ourselves

So, let's learn how to fish, so we can feed ourselves...

What's the cost of asking others?

Programmers don't work in a vacuum - we generally have colleagues around.

But unless they're working on the same topic, it costs them time to get out of one train of thought, and onto the other, and then back again. (15 minutes to get "into" something).

Unfortunately, the more you ask someone, the less inclined they get to provide an answer.

RTFM - Read the F'ing Manual

STFW - Search the F'ing Web

Two phrases that might get directed at you if you ask colleagues too often.


##I Do: How to solve our own problems

"There are three great virtues of a programmer; Laziness, Impatience and Hubris" - Larry Wall (creator of Perl)

(Hubris means extreme pride or self-confidence)

A good programmer is a lazy programmer

Lazy programmers help you by...

  • Writing reusable software for common tasks
  • Writing clear code, documentation and tutorials so they don't get bothered with questions
  • Answering questions in public forums so they only need answering once

Help yourself by being Lazy & Impatient

  • Instructors aren't always going to be here
  • Are we the first person to have this problem?
  • Don't reinvent the wheel
  • search for existing solutions online
  • Read the docs - common use-cases and gotchas are usually covered
  • Read the source - good code can be almost self-documenting
  • Still stuck? Ask someone else to solve the problem

Google is your friend

"Let me Google that for you..."

Google is usually the fastest route to your solution - skip this stage at your peril! Or you'll most likely get these aggressive responses: RTFM, STFW... ... or the more passive-aggresive type: "How do I reverse an array in Ruby?" :-)

Keyword choice is key.

Google-fu

  • use standard terms
  • include error message (in quotes)
  • include language
  • include library if you know it
  • include version numbers if necessary

So: 'rails api array last item' might be a good search term if you need to get the last item from an array in Ruby.

Common Ruby on Rails resources

Part of this course is learning how to solve your own problems

  • practice finding things
  • ask peers and instructors for keyword advice

##You do: Find out about Fossil

A colleague comes up to you and says:

"Whoa, I've been playing with this awesome app called 'fossil' as an alternative to git."

Go find out about it on the web...

Answer

The answer


##I Do: How to ask for help

If searching for yourself doesn't get you what you need, you may have to ask a question. There are two types of ways how to ask a question:

FAST ways to get answers - interact live with fellow programmers

  • ask an instructor - special case!
  • ask a colleague
  • use private chat room (e.g. Slack)
  • use public chat room for tool/language (e.g. IRC)

SLOW ways to get answers - post request and wait for response on...

  • Q&A site
  • group
  • forum
  • issue tracker

Whoever you ask, ask smart questions. (Homework)

  • Describe the symptoms of your problem or bug carefully and clearly.
  • Describe the environment in which it occurs (machine, OS, application, whatever). Provide your vendor's distribution and release level (e.g.: “Fedora Core 7”, “Slackware 9.1”, etc.).
  • Describe the research you did to try and understand the problem before you asked the question.
  • Describe the diagnostic steps you took to try and pin down the problem yourself before you asked the question.
  • Describe any possibly relevant recent changes in your computer or software configuration.
  • If at all possible, provide a way to reproduce the problem in a controlled environment.

##I Do: Give back When you do have a problem, would it be good to leave the answer for the next guy?

  • Where can you do this? blog it, or write about it, or contribute to the community
  • Register on Stackoverflow

Closing: Reassurance!

For the duration of this course... of course the instructor team is there to answer your questions; we won't tell you bluntly to RT*M

But we would love to see you starting to put the research in to solving your own problems, because in most cases...

The answer's out there!