28 Sep 2016
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)
27 Sep 2016
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
26 Sep 2016
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.
25 Sep 2016
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)
29 Jun 2016
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.
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.