Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

Related pages


It's normal to feel overwhelmed by the size of the task in front of you

  • "98% of dev is just pretending you're not overwhelmed with the massive amount of work left to do" 



Don't overthink it!

  •  https://twitter.com/wspruijt/status/805041267394641923



Getting started

  •  

Getting through programmer's block

  • Figure out what's making you feel confused, and attack that issue
    • Examples
      • 2015.12.06 - I was procrastinating for hours, staring at my screen, and then eventually I realized that what was holding me back was that I didn't have a clear folder structure for organizing my code, and so I wasn't sure where I should be putting my code. After a few minutes clearing up what the folder structure should be I was back in business.

Misc Thoughts

  • I wonder if drinking may make someone perform better.
    • Explanation:
      • I was reading some of Mark Zuckerberg's blog posts while he was creating Face Mash and apparently he was drinking the entire time (Beck's).
        • The context in which he mentions drinking suggests he was using it to relieve anxiousness / stress:
          • 9:48pm. I’m a little intoxicated, not gonna lie.
            • Another article mentions that he'd had a fight earlier that day with his girlfriend.
          • It’s taking a few tries to compile the script…another Beck’s is in order.
            • Having the compilation take a few tries is something that causes stress.
      • At the same time I was trying to program but was getting extremely anxious because of the problems I was running into.
      • I wondered if drinking a beer might get me to relax, and when I had a drink I did feel better.
      • I'm not sure if it was just the placebo effect or not.

Stuff I Learn While Going Through the 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.
  • Libraries are exactly like toolboxes. Each toolbox contains a bunch of tools that you can use, and when you're tackling a particular task you need to think about which toolboxes you'll need to have with you to get that job done.
  • 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




Quora - How do programmers code quickly?
http://www.quora.com/How-do-programmers-code-quickly?share=1

Quote:
Jesse Farmer:
- 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.
  • No labels