Studying cppreference

I have been writing programs in C++ for several years now, but there are many concepts that I don't know very well. My knowledge of the subject feels so shallow. I want to make a a concerted effort to fill in these holes. So, I'm going to commit to another goal.

I'm going to read each of the references documents in the Standard C++ reference, and then summarize them in my own words.

I like this commitment because it has a well defined ending. I think and hope it will be a worthwhile endeavor.

Update I have heard that the cpluscplus.com website may not be the best reference material to read. It seems like http://en.cppreference.com/w/ may be the more respected source. So, I'll base my studies off of cppreference instead.

See my reports below

• Approach for studying cppreference.com

Essential Fitness NYC

I went to go work out at Essential Fitness NYC. The trainer (Scott) was very kind and welcoming. I took the "Essential 7" class with two other students, who seem to be regulars at the facility. It was similar to personal training in that the trainer spent a lot of one-one-time with me. We did kettlebell swings, goblet squats, side steps with elastic bands, planks, and some stretching on rollers.

The objective for me to go to this class was to learn to improve my daily home workouts, and I did get some good pointers.

For kettlebell swings, I was instructed to plant my feet firmer into the ground, and to swing faster (my hip hinge should be faster). We also worked on my feet placement a bit (I was encouraged to try a more narrow stance). I'm sure there were a lot of pointers that Scott could have given to me, but he didn't want to overload me with too much information. The advice he gave made sense. If I get my base well grounded, it should help my swing.

For the goblet squat, the trainer gave me one good tip -- lower yourself slowly with control instead of just dropping. This makes squats harder, but probably more effective. I imagine I should do a similar thing for all exercises like push ups and pull ups.

Using the rollers was completely new to me. It seems like something I could get for my apartment, but I'll have to read more before I start shopping for one.

The most challenging thing for me was to get the breathing correct. I've seen and heard others do this coordinated breathing technique before, but I couldn't seem to get it right. I resorted to just taking regular breaths after I 'hissed' or breathed out. This will require more practice.

I think essentialfitnessnyc and Scott are great resources. Before I sign up again, I'd think I'd ask some questions to Scott to see if he thinks I might get more out of his other classes. I wish I could've had more time to work on other movements like the clean, snatch and so on ..., but it's probably the case that I have to learn to walk before I can run.

In my past, from programming to working out to learning anything, I've always favored just learning by myself. I think it was mainly because I was shy (and also broke/cheap). This year, I've forced myself to get some external help, which I hope will help me to improve faster and avoid mistakes. I'm not sure if I will go back to essentialfitnessnyc again, but I think it's good to continue to force myself to go out and get some external help from time to time.

Week 1 of Algorithms Part II. Graphs

I finished Algorithms 1 from Coursera a couple of weeks ago, and this week, I just finished the first weeek's work for Algorithms II from Coursera.

I tried to make the most of my time off between the two classes. I worked on an open source project, did some reading about building web applications and tried to study some other things. During this time off, I realized that I prefer structured classes. They help me to stay focused on the subject of study. With that said, I have to continue to push myself to focus on the material and my deep understanding of it, instead of allowing myself to be satisfied with simply getting the correct answers for the course.

I think some ways to improve my understanding will be to review and participate in the Coursera discussion forums. This gives me a chance to see how others (different from the course instructors) are thinking about the material. In the discussion forum, I can have the chance to approach things as a teacher, which will also help me to understand the material better.

So, onto my thoughts on week 1 of Algorithms 2.

This week, we went over undirected and directed graphs. Using breadth first and depth first searches, we were able to solve some possibly tricky problems like topological sort and finding strong components in directed graphs. The takeaway for me is to get very comfortable with depth and breadth first searches and to have a good mental image of what we get from each. With these two tools you can have a good chance of answering a question. Interestingly, it's a bit difficult to know at first glance how fast you might be able to solve a given problem. It's a lot less intuitive than guessing calculation times of sorting algorithms.

The lectures did an OK job of presenting the material. There were a few demos that you should watch (not just read through). The exercises were rather pain free. They asked you to trace through the steps of things like breadth first and depth first search.

The programming assignment, similar to ones in Algorithm I, asked us to work with existing implementations (this week, a directed graph) instead of writing an implementation on our own. I guess re-writing an implementation on my own can be part of my own self studying. The most time consuming part of this project was understanding the requirements (can there be multiple terms in a synset, is a word unique across synsets, etc ...) After I figured out what the requirements were, it was pretty straightforward to use the provided directed graph class to finish. I'm not sure if it really improved my understanding of Graphs, but at least it didn't take too much time.

On Knowing

A concept that I will like to internalize is the following:

Know everything about what you say you know. Know a little bit about everything else.

Here are some case studies where this concept comes in handy:

1. On prioritizing.
   You can devote more time and energy to learning the things you know very deeply. For other things, you can do more leisurely reading and learning.

2. On working on a project.
   For the parts you know how to build well, you will create a very high caliber product. For parts you don't know well, you will know enough to hire an expert or re-use an existing library that is proven to work well.

3. On interviews.
   People will often ask you what you know. If you say you know a certain thing, and then they find out that your knowledge in the subject is shallow, you look like a fool. For subjects that you say you don't know, having a general idea is usually sufficient to show that you aren't a one-trick pony. Having this mix of deep and shallow knowledge should prove to the interviewer that you are capable of learning any subject, as it is needed.

Bad interview

I found out about a new position at work and applied for it. I got an interview, but it did not go well.

I heard about the job on one day, did some light Q&A with the team members the next day and then had a technical interview the following day. I wasn't looking for a new job, so I didn't think a technical interview was on my horizon. The interviewer asked if I needed some time, but I thought waiting a day or two would just make me feel more anxious, so I said let's just do it immediately. That was a mistake. A little bit of review would have helped immensely.

The interviewer asked questions about basic things, like object construction and destruction, which I often take for granted when writing code. My focus is often on higher level details, like what would be the next best feature to develop for a client. Reminding myself of the basics would help me on interviews and would also help me write better code.

I also didn't have the right approach for answering questions. For questions that I knew the answer to, I didn't really explain things from first principles well. For questions that I didn't know the answer to, I just admitted I didn't know the answer. I think it would have been better to say something like,

"I don't remember the syntax and rules for this, but if it we assume it worked like this, then we could do this or that."

This would have let the interviewer know that I could think through problems and could move a problem along after googling for minor details. Instead, I allowed myself to get stuck in the mud too many times.

I think the final issue I had was that I simply got tired. I hadn't gone on an interview, or even taken a test, in years. The interview lasted about and 1.5 hours. After about an hour or so of talking, explaining, and thinking, I simply got tired. I felt like giving up on some questions a few times instead of digging deeper and deeper, even if I had more knowledge to share.

I doubt I got the job. That sucks, but that's completely my fault. I think with a little better preparation, I could've done a lot better.

I'm sad that I messed things up, and sad to have to continue on with my current job (I had already begun to daydream about moving on). The positive outcome is that I still have my current job, and learned (the hard way) how to do better on an interview.

Another opportunity will probably arise. I hope I turn this experience into a lesson that improves my interview skills for the next one.

First foray into open source with Proselint

For 2016, I challenged myself to contribute to 10 different open source projects on github.

I started looking for a project to work on by scanning through the list of trending github projects. I eventually decided to work on Proselint. The purpose of this project is to develop a tool that could analyze writing - it's a linter for prose.

I want to be a better writer, so a tool to improve my writing would be good to know about and to use. It would also allow me to 'dog-food' software. I like projects where I'm also the user.

Looking through the github page, there were a lot of existing small issues, many of which were tagged 'Easy'. I eventually chose to fix an issue where I would add a check that looks for paragraphs that start with the word 'But'. It seemed like a good balance of an easy problem that I could solve, but not a completely trivial code update.

I eventually made the code change, got my pull request accepted, and became an open source contributer. It was a really small update, but even still, I learned and was reminded of a number of things.

• pip is a really cool package management program. I should incorporate it into my projects more.
• regex is powerful. I shouldn't be afraid of it.
• nosetests is a great way to run tests. I should use this more.
• I need to figure out a good way to organize files/code better. Having a good structure makes things much easier to find and update.
• Normally, gvim is my go to text editor, but for this new project Atom with the vim plugin might be a better option. It's much easier to navigate across files and folders and it has some auto-complete to move things along.

This was my first open source contribution adventure, and it was fun, inspirational (for me), and educational. For my next projects, I will look for a variety of projects (different languages, different applications, etc ...). I think the variation will teach me a lot.

As they say, it's certainly better to give than to receive.

Feynman Method of Learning

I just read about the Feynman method for learning. The article describes it well, so you can read about it here. But in the spirit of the method, I'll try to describe it from memory now.

Start by writing the concept you want to learn at the top of the page.

Example: "How to learn with the Feynman method"
Why: I think this is important for getting you to focus on one concept instead of letting yourself get off tangent.

Describe the concept as if you are teaching it to a beginner.

This means describing the concept without using any subject specific jargon or relying on any other assumptions.

Why: This will expose holes in your understanding.

Go back to the source material.

After you discover holes in your understanding, go back to the source materials (books, lectures, mentors) and re-learn what you are unsure of.

Simplify

Describe the concept again using simpler words and analogies.

Why: This will ensure you have a deep understanding and you aren't accidentally, incorrectly assuming anything.

My takeaway

The methodology sounds good. I think the most important thing is being an active learner, instead of just being a passive observer.

Going open source

I have decided to commit to something new.

Before the year ends, I will contribute to 10 different open source projects. That's only about 1 project per month, but it's 10 more than I've ever done before.

I think it will be an interesting challenge. It will force me to be exposed to many new projects, and their unique coding/project styles. I'm sure this exposure will give me new ideas and make me a better developer.

Of course, the other possible benefit is that I'll be contributing to the open source world. Hopefully some good comes out of the that.

Updates
1. March 15 - Created a module for Proselint. See blogpost about it.
2.
3.
4.
5.
6.
7.
8.
9.
10.

Making peanut butter

I am trying to cook more. It's healthier, and it saves money.

For this winter, I made a few batches of chicken soup from scratch. I also learned to make some Kim chi jigae, which is the most common stew/soup in Korea. I'm pretty happy that I know hot to make these.

Today, I tried something else. I made 3 (small) jars of peanut butter. It's pretty simple to make. I did the following:

• peel the peanuts (this is the most time consuming part)
• roast the peanuts for 10 minutes at 350 degrees
• add a teaspoon of salt and honey
• blend until it is peanut butter

The hardest part of the process was that my blender kept getting clogged up. I had to do a lot of manual mixing to get the blender to work.

So, that's how this programmer spent part of his morning.

I am not sure if the effort is worth it, so I am not sure if I'll do it again. I wonder what I should try to make next.

How to Master Skills

Recently, I watched a youtube video from Tim Ferris on how to master any skill.

He describes his process via an acronym called DiSSS:

• Deconstruct (break the problem down)
• Select (think 80/20)
• Sequence (deviating from traditional order might be faster)
• Stakes (create incentives for success or failure)
• Simplify (less is more)

I had trouble remembering this acronym because there are too many 'S's. I thought of a better acronym that's easier for me to remember, which is DEQUE.

• Deconstruct. Same as before.
• Eighty/twenty. Replacing 'Select' with 'Eighty' gives me a nice vowel for my acronym.
• Queer. I could be wrong, but when Tim suggests learning things out of sequence, I think he's actually suggesting to us to not be afraid of learning things in a seemingly odd or 'queer' way.
• Uh-oh. Instead of 'Stakes', I think 'Uh-oh' captures the sentiment of "I need to learn this skill or else I'm screwed."
• Enough. I think 'Simplify' is fine, but using 'Enough' makes my acronym flow a little better (in my opinion).

Unfortunately, another acronym already exists for deque (double-ended queue), but I still find it easier to remember than DiSSS.

Whichever acronym you go with, the more important part is applying it to the skill you want to learn, and it hopefully helping you master it. That is still to be determined for me.

Week 6 of algorithms part 1. Hash table and final exam

The sixth and final week of my coursera algorithms course is done.

This week, we had lectures on hash tables, a set of exercises and a final exam. This was a little different from previous weeks where we would have a little bit more lecture material, two sets of exercises and a programming assignment.

The final exam had a lot of tricky questions, where the major obstacle was just reading the question correctly. I started it a few days ago, and didn't submit until today. Every day, after work, I read over the questions and answers to see if I might have been confused about anything.

I ended up getting an OK score, 9.13 out of 10. I can attempt it a couple of more times, but I don't think there's much point in trying to improve the score. It doesn't really mean anything, and I probably wouldn't learn much by doing it again.

It feels good to be done with this. It's great to finish anything, and this is something I wanted to try and finish years ago.

I signed up for part 2 of this course. After which, I hope to be well versed in all the basic data structures and algorithms that every software developer should know.

The next course starts in 2 weeks, so I'll have a little bit of a break, which is nice. Maybe I'll plan what I want to work on after part 2 of this is done - take another course? study some other way? reallocate time to something else?