Versions Compared

Old Version 74

changes.mady.by.user Nathan Wailes

Saved on

compared with

New Version 75

changes.mady.by.user Nathan Wailes

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of contents

...

Child pages (Children Display)

Related pages

...

...

  • Eat high-quality food.
    • This is just like when I was taking the LSAT: Protein (fish / chicken), carbs (broccoli / peas), and fat (cheese / almonds)
  • Alcohol
  • Caffeine
    • Chung is a big fan of espresso. I think Yang also drinks it.
    • John Collison (of Stripe)
      • "My attack on bugs and lameness in the app was fuelled by adrenaline and ridiculously strong coffee, tea and sugared Red Bull." (Source)

Lessons learned

USACO Puzzles

  • If you're having trouble with a certain task, see if you can break it into smaller pieces. This is one of the most useful things I've gotten practice with from these puzzles. It's kind of cliche advice, but if you're staring at something for half an hour and can't figure out how to get it working, you NEED to have the thought/motivation to try hard to break it up.
  • If you're having trouble with a certain task, see if you can describe / write out how you would do it in the real world, without a computer. This helped when I was trying to write a function that would convert from base 10 to another base. If you get too bogged down in how to execute things in the programming language it can make it harder to brainstorm.
  • Be OK with having your first version be ugly / sloppy. You can always go back over and smooth things over later. Trying to make everything perfect the first time around often makes it take LONGER to get to a great version.
  • Don't get too sucked into a particular way of doing things if it's hard to execute. Be willing to look for easier methods. On one puzzle I had the idea that I could use a fancy way of doing things, but it was so hard to figure out how to execute my idea that I burnt out and stopped working on the problems for a month or two.
  • It's extremely important to have a compiler set up so that you can quickly compile your code and see what happens. You should NOT try to figure out how to create the program without ever running your code. This held me up for literally 10 months with the USACO puzzles: I was having trouble learning all the C / C++ code necessary to do certain things so that I could create an entire program and hand it to the USACO website to compile, when I should have just been typing stuff up, handing it to my own compiler, and seeing what happened. I should have been starting with the most simple part of the puzzle and incrementally getting more complicated, just like that Stanford professor recommended in his Python class at Google.

Articles

People

  • Jesse Farmer

    • Quora - How do programmers code quickly?

      • They know how to use their keyboards to do work. Keyboards are way faster than mice once you know how to use them. They're also more amenable to muscle memory. Are you clicking around to open new files? When I'm coding I barely touch my mouse.

      • They are good typists. I probably type around 80 WPM on average and 100-120 WPM if I'm focusing on my typing, for example. Go practice! I like http://play.typeracer.com/ and https://typing.io/.

      • They know how to use their tools, especially on the command-line. Ctrl+R for reverse search, Ctrl+A/E for beginning/end of lines, <Tab> for autocompleting filenames, etc. These become muscle memory after a point.

      • They are very good at debugging and are likely to isolate, identify, and resolve a bug 100x quicker than a beginner. This isn't just because they "know more." Oftentimes they know just as much as you, but have a more disciplined approach to finding the source of unexpected problems.

      • They have a better sense of where to look for information and aren't afraid to navigate through manpages or even source code to understand how some other system is behaving. If I'm having trouble with a poorly-documented Ruby gem, for example, I'll often look at the gem's source code to see if I can make sense of what's going wrong. I'd say 90% of the time this is quicker than Google.

      • Regarding debugging, I wrote a blog post (Teaching Novice Programmers How to Debug Their Code) that outlines how to teach people to be better debuggers.

  • Notch
    • 2011.09.13 - Gun.io - What I learned from watching Notch code
      • Notch tests continuously, and he tests completely thoroughly, playing through the entire game every time he makes a change.
      • When building the engine, Notch wrote a function which would continuously pan the camera around and clip through the walls and keep the view on top, so he could make changes to the code and see the effects they made in real time. I’m used to testing by writing a function, building it, installing it on the device I’m testing on, and then seeing the result, which can take up to a minute at a time, so it’s easy to see how HotSwapping could save a lot of development time.
      • Notch's testing is mind-bogglingly thorough. 'Prelude of the Chambered' takes about 10-15 minutes to play through if you know what you're doing, and Notch played through the whole game every time he made a change. (...) the benefits in terms of user experience are obvious: More play-throughs mean more chances to spot bugs and inconsistencies.
    • 2011.09.15 - MrSpeaker.net - Code like you're Notch
      • Holy crap that guy knows his stuff.
      • For a time-based comp it's probably worth scaling back your ideas until you know exactly how you're going to do it.
      • The internet is, and distractions are, stupid. (...) Notch...worked eerily distraction-free. He went to Twitter only once (and that was to post an update on his progress). He played Doom for 15 minutes while he ate lunch. He went to sleep for 8 hours on Saturday night. I think he snuck in a toilet break at one stage - I'm not sure. Apart from that, he coded and he drew and he play-tested and THAT'S ALL.
      • Streamline your process. (...) I saw file dialogs maybe, a dozen times throughout the weekend. There was no export phase, no "are your sure?", no "save as interlaced?" - just one keyboard shortcut and the changes were ready to be loaded into the game. What I learnt: Ok, your tools aren't important - but they have to let you work extremely fast. Don't do something with 2 clicks that could be done with 1. Favour simplicity.
      • Have a plan. From the start his pacing was perfect: never rushing but never wasting time. When he finished one aspect of the game he moved straight on to the next. By the time the deadline arrived he was casually adding minor level tweaks. (...) What I learnt: Timing is everything. Spending time on fancy effects like dynamic lighting reduces time for the truly important aspects of play testing and level design. If you're ahead of schedule you can add some bells and whistles, but the clock is always ticking.
  • Tom Francis
    • Tom Francis playing Human Resource Machine
    • http://www.pentadact.com/2011-03-12-analysing-happiness/

      • Do what you want to be in the mood to do. You can also get stuff done that you don’t feel like doing, just by starting to do it. Your brain only resists up until the point you actually start the job, at which point it starts to focus on doing it. You do what you want to be in the mood to do, and soon you’re in the mood to do it. It sounds ridiculous, but it’s the single most useful piece of information I’ve discovered about the way my brain works in 29 years of having one.

...