20160926.plan

  • fallback to original, command-line passing behavior on non-windows platforms (chrome)
  • plumb field trial handle down to LaunchOnLauncherThread (chrome)
  • finish writing tests for content_main_runner and browser_child_process_host_impl (chrome)
  • add location data to juiceboxes (juicebox)

20160926.plan

  • avoid calling destructor by instantiating shared memory in gpu/renderer process instead of in the host (chrome)
  • fallback to original, command-line passing behavior on non-windows platforms (chrome)
  • add location data to juiceboxes (juicebox)

I haven’t touched the location stuff, probably because I don’t really have a need for it yet. I’ll probably do it at HW3 along with the mobile version. In other news, we saw a truly unparalleled level of shit-slinging at the presidential debate last night, and it makes me kinda sad that both sides will only come out of this more entrenched in their dogmatic belifs. That’s it bye

20160926.plan

  • figure out why windows handle is invalid (chrome)
    • this was because of a destructor closing the handle when the object owning the handle was going out of scope
  • avoid calling destructor by instantiating shared memory in gpu/renderer process instead of in the host (chrome)
  • add location data to juiceboxes (juicebox)

As an aside, I maintain that the best way to learn anything is just by doing it. I understand object lifetimes, smart pointers, and static member variables/methods way better now, having felt the pain firsthand of dealing with them. I don’t think I could truly understand these things if I read about them in a book, is what I’m saying.

20160925.plan

I’ve been inspired by John Carmack’s .plan files to start posting every day about what I’m working on. I realize no one gives a shit, but this should help keep me accountable. It’ll be like a daily virtual standup. I’ll figure out the format as I go.

  • fixed race condition causing incorrect end times (juicebox)
  • fix listeners box height when only one listener (juicebox)
  • add location data to juiceboxes (juicebox)
  • figure out why windows handle is invalid (chrome)

How To Be A Great Engineer

The myth of the 10x engineer is widely known in programming circles, and there are definitely people who seem to fit the description. Jeff Dean and John Carmack are some of the programmers I look up to as examples of 10x-ers, and there are also a few people I know personally that just seem to have crazy high output. How do you become like these people? Here are the qualities that I think make a great engineer.

  • Constant self-improvement
    • I once debugged a Rails app with someone on my Macbook Pro. He wasn’t familiar with OS X, but still tried to learn every keyboard shortcut to become more efficient. It doesn’t seem that big, but this was a revelation to me. I don’t think I would have ever thought of doing that. Imagine applying that mentality to everything you do. Skills and knowledge compound like interest, and it truly is worthwhile to stop to think about whether there’s a better of way of doing what you’re doing instead of mindlessly doing what you’ve always done because it’s easy and you’re used to it. Wow that was a long and complicated sentence but I’m glad you stuck through it.
  • Unstoppable drive
    • Great programmers don’t let anything stop them. Bug in the system library? Fix it. Some person or org blocking you? Find a workaround. Need to shave a giant fucking yak to finish the job? Just do it with the smallest amount of hassle and without any complaints. This is probably the most straightforward quality but also the hardest to achieve.
  • Deep empathy
    • Engineers don’t work in a vacuum, as much as I’d like to silo up and work on my magnum opus. You need to communicate with other people, whether it be about code, architecture, or product. In these situations, you want to be able to understand the other person’s concerns to know exactly what you should be working on, and why. I’ve definitely been caught in the pitfall of building things for the sake of building things, with the end result being lots of wasted work.
  • Sense of style
    • Good code is very ‘I know it when I see it’. There’s no objective metric that captures code quality, and it’s definitely not just about following PEP8. It’s all a tug-of-war between choosing the correct abstractions and finding flexibility. To write clean, elegant code, you absolutely need a sense of style. To this day, some of the nicest code I’ve seen has been written by Jae Wie, who has an habit of relentlessly destroying unnecessary code.

If you’re interested in this kind of stuff, you should probably read Khan Academy’s Engineering Principles and Career Development Guide. KA Engineering has a really high bar and it would probably be great working there (hint hint, any KA recruiters).

I’m probably missing some more qualities, and I’d love to hear your opinion on what makes a great engineer. Hacker News discussion here.