This started out as a way to jot down thoughts on areas that seem interesting but underappreciated. Since then, this site has grown to the point where it gets millions of hits a month and I see that it's commonly cited by professors in their courses and on stackoverflow. That's flattering, but more than anything else, I view that as a sign there's a desperate shortage of understandable explanation of technical topics.

• Teach Debugging

  I understand now why half the class struggled with the earlier assignments. Without an explanation of how to systematically approach problems, anyone who didn't intuitively grasp the correct solution was in for a semester of frustration. People who were, like me, above average but not great, skated through most of the class and either got lucky or wasted a huge chunk of time on the final project. I've even seen people talented enough to breeze through the entire degree without ever running into a problem too big to intuitively understand; those people have a very bad time when they run into a 10 million line codebase in the real world. The more talented the engineer, the more likely they are to hit a debugging wall outside of school.

In this blog, I write my thoughts and experience on Frontend development. Subscribe if you are interested in knowing more about JavaScript language analysis, clean code practices, and efficient system design.

• this keyword in JavaScript
  one of the best explanations of 'this' in JavaScript

Who are you, anyway? A great question! I write well and prolifically, generally on the intersection of marketing and engineering. I’m not the best marketer or engineer in the world, but I’m a better engineer than almost all marketers and a better marketer than almost all engineers. Tactically abusing this combination prints money in a very intellectually interesting way; this site is mostly war stories from doing that. You can read my brief bio for the highlights.

• Kalzumeus Salary Negotiation

  Salary Negotiation Instrumentally probably the most useful thing I have ever written. Salary negotiation advice, originally written for engineers in a good market but I’m told broadly applicable. According to reports from people this is responsible for $X million a year in raises or better starting offers. Personal favorite.

• Kalzumeus Don't Call Yourself A Programmer

  Don’t Call Yourself A Programmer, And Other Career Advice. Career advice for engineers, but widely applicable, or so I’m told. Personal favorite.

• Chip Huyen, Confession of a so-called AI expert

  Of course, I have improved over the last two years. But I’d be foolish to think that the change in recruiters’ attitude is due solely to my improvement. Many of my friends, who are way smarter than me and can unceremoniously kick my fuzzy ass in anything CS-related, struggle to find a decent job just because their resumes lack trending keywords. Yet many others, who barely understand basic concepts of machine learning, swim in job offers just because they’ve completed courses with fancy sounding names. It’s a phenomenon that Richard Socher, the dishevelled 30-something (or 20-something?) lecturer who just sold his company for several hundred millions yet still biked to campus, mentioned in his class: “Companies keep asking my students to drop out to work for them.”

get a referral
2 steps to get a job
1, get an interview...somehow
2, do well on the interview
39:40, it took 5 times of him applying to the Big 4 to get hired, and this was him going in and interviewering and being told he was not good enough
you don't have to put down how many times you failed, on your resume

The more interesting surprise was in how many hours each stage actually took. The main stages of my initial project plan were basically...

The reader should understand a test without seeing any code outside of the test function.

The secret:
Documentation needs to include and be structured around its four different functions: tutorials, how-to guides, explanation and technical reference. Each of them requires a distinct mode of writing. People working with software need these four different kinds of documentation at different times, in different circumstances - so software usually needs them all.

So Dean, working with fellow standout programmer Sanjay Ghemawat and others, did what he had done in high school with Epi Info: found software solutions to what seemed like hardware problems. Ghemawat helped lead a team that built the Google File System, which allowed for huge files to be efficiently distributed across thousands of cheap servers. Then Dean and Ghemawat developed a programming tool called MapReduce that allowed developers to efficiently process gargantuan data sets with those machines working in parallel. Much as a compiler allows a programmer to write code without worrying about the nitty-gritty of how the CPU will process it, MapReduce allowed Google’s developers to tweak the search algorithm or add new computations without having to worry about how to parallelize the operation or handle equipment failures.