The biggest challenge when onboarding remotely was getting a feel for the culture. Without this, you have to play it safe and act conservatively (i.e. maximally professionally), however it can be draining to always be so buttoned-up.
The two things that helped me feel more comfortable were:
1. Seeing “micro unprofessionalisms” during zoom calls.
One colleague had a large drawing of “No Face” from Spirited Away on his wall.
Another’s cat jumped onto the desk, and then a baby ran into the room.
Another just had a mess in the background.
All of these show humanity and personality. They let the new team member know that the tone is relaxed and that there’s no need to stress over behaving perfectly “professionally”.
2. Getting hints from coworkers about work norms.
I have a coworker that’s brutally productive. But one day he said, “I’m going to be out for a few hours this afternoon to get my trombone fixed.”
It’s easy to overlook such a remark if you’re been on the team a while. But for a new joiner, even small comments like this provide valuable insight into what is and isn’t acceptable on their new team.
To make your new team member’s remote onboarding experience more comfortable, be intentional about showing humanity — visibly display things that are unique to you (and un-blur your background). Also, remember that your team’s culture exists, must be learned, and can be proactively communicated.
LLDB supports custom scripts (“variable formatters”) to pretty print C++ data structures. For example,
std::vector is typically implemented as a struct with three pointers: begin, end, and capacity. But if you wanted to print out a
std::vector variable during a debugging session, printing out these three pointers isn’t likely to be helpful. What you actually want is to print the contents of the vector. Pretty printer scripts allow for doing this for your own data structures.
Here are a few tips to supplement the official documentation. Sudara also has a great post on the topic.
I get asked why I’m into C++ and not Rust.
Above all, it’s pragmatic. C++ is simply what’s used for the work I aspire to do, and I don’t have time for both.
Beyond that, I still think there’s at least one reason to learn C++ today: out of respect for where it’s gotten us. A lot of lessons to learn from something that powers the world, flaws and all.
And when you do learn Rust, you’ll understand it better. The C++ context will give you a deeper & more intuitive appreciation for why it’s like it is.
Rust wouldn’t be what it is without C++. 🤝
An obscure quirk of the /proc/*/mem pseudofile is its “punch through” semantics. Writes performed through this file will succeed even if the destination virtual memory is marked unwritable. In fact, this behavior is intentional and actively used by projects such as the Julia JIT compiler and rr debugger.
This behavior raises some questions: Is privileged code subject to virtual memory permissions? In general, to what degree can the hardware inhibit kernel memory access?
By exploring these questions, this article will shed light on the nuanced relationship between an operating system and the hardware it runs on. We’ll examine the constraints the CPU can impose on the kernel, and how the kernel can bypass these constraints.
In addition to the well-known
-Wall, clang offers another interesting warning flag:
-Weverything. While it sounds like a “strictly better” option (the more warnings, the better?) it’s not.
This topic is already well covered by Arthur O’Dwyer’s blog post and the clang documentation.
Arthur makes a strong case against use of this flag. The clang docs generally agree, though offering a slightly more lenient position:
If you do use
-Weverything then we advise that you address all new compiler diagnostics as they get added to Clang, either by fixing everything they find or explicitly disabling that diagnostic with its corresponding Wno- option.
But what I have not seen clearly expressed is how use of
-Weverything is a tradeoff.
If you’re already a 10x engineer, you probably won’t need this article. But for the rest of us, this is what I wish I knew about clang-format as an inexperienced C++ programmer: how to only format the changes in your pull request.
You may have already heard of clang-format. It auto-formats source files for languages including C and C++. You can aim it at a source file and format the entire thing using
clang-format -i file.cpp.
If you’re contributing to a project that is already 100% clang-format clean, then this workflow works fine. But you’ll occasionally encounter a project that is not quite 100% formatted, such as LLVM, osquery, or Electron.
For these projects, the “format entire files” workflow doesn’t work because you’ll incidentally format parts of the files that are unrelated to your contribution. This will add noise to your diff and make it harder for your reviewers.
In this case, you need a way to surgically format only the lines changed in your contribution. To do this, you can use the clang-format git extension. This article will cover the basics of git-clang-format, including a practical workflow that allows for messy development, and formatting at the end.