Thank you! I want to ::sniff:: thank my coach, the whole team ::sniff::, and especially my mom for helping make this happen! ::sniff:: Love you mom!

Here’s a version for my fellow gluten-free peeps:

Honestly, this is why I tell developers that work with/for me to build in logging, day one. Not only will you always have clarity in every environment, but you won’t run into cases where adding logging later makes races/deadlocks “go away mysteriously.” A lot of the time, attaching a debugger to stuff in production isn’t going to fly, so “printf debugging” like this is truly your best bet.

To do this right, look into logging modules/libraries that support filtering, lazy evaluation, contexts, and JSON output for perfect SEIM compatibility (enterprise stuff like Splunk or ELK).

Heisenbugs are the worst. My condolences for being tasked with diagnosing one.

Last time I did anything on the job with C++ was about 8 years ago. Here’s what I learned. It may still be relevant.

• C++14 was alright, but still wasn’t everything you need. The language has improved a lot since, so take this with a grain of salt. We had to use Boost to really make the most of things and avoid stupid memory management problems through use of smart (ref-counted) pointers. The overhead was worth it.
• C++ relies heavily on idioms for good code quality that can only be learned from a book and/or the community. “RAII” is a good example here. The language itself is simply too flexible and low-level to force that kind of behavior on you. To make matters worse, idiomatic practices wind up adding substantial weight to manual code review, since there’s no other way to enforce them or check for their absence.
• I wound up writing a post-processor to make sense of template errors since it had a habit of completely exploding any template use to the fullest possible expression expansion; it was like typedefs didn’t exist. My tool replaced common patterns with expressions that more closely resembled our sourcecode¹. This helped a lot with understanding what was actually going wrong. At the same time, it was ridiculous that was even necessary.
• A style guides are a hard must with C++. The language spec is so mindbogglingly huge that no two “C++ programmers” possess the same experience with the language. Yes, their skillsets will overlap, but the non-overlapping areas can be quite large and have profound ramifications on coding preferences. This is why my team got into serious disagreements with style and approach without one: there was no tie-breaker to end disagreement. We eventually adopted one after a lot of lost effort and hurt feelings.
• Coding C++ is less like having a conversation with the target CPU and more like a conversation with the compiler. Templates, const, constexpr, inline, volatile, are all about steering the compiler to generate the code you want. As a consequence, you spend a lot more of your time troubleshooting code generation and compilation errors than with other languages.
• At some point you will need valgrind or at least a really good IDE that’s dialed in for your process and target platform. Letting the rest of the team get away without these tools will negatively impact the team’s ability to fix serious problems.
• C++ assumes that CPU performance and memory management are your biggest problems. You absolutely have to be aware of stack allocation, heap allocation, copies, copy-free, references, pointers, and v-tables, which are needed to navigate the nuances of code generation and how it impacts run-time and memory.
• Multithreading in C++14 was made approachable through Boost and some primitives built on top of pthreads. Deadlocks and races were a programmer problem; the language has nothing to help you here. My recommendation: take a page from Go’s book. Use a really good threadsafe mutable queue, copy (no references/pointers) everything into it, and use it for moving mutable state between threads until performance benchmarks tell you to do otherwise.
• Test-driven design and DevOps best-practice is needed to make any C++ project of scale manageable. I cannot stress this enough. Use every automated quality gate you can to catch errors before live/integration testing, as using valgrind and other in-situ tools can be painful (if not impossible).

1 - I borrowed this idea from working on J2EE apps, of all places, where stack traces get so huge/deep that there are plugins designed to filter out method calls (sometimes, entire libraries) that are just noise. The idea of post-processing errors just kind of stuck after that - it’s just more data, after all.

“this is as far as you can go if you don’t want to get involved in management”

Yes. That exactly. This typically comes with a nice perk: Principals are supposed to have the same clout as lower-level managers. Which is to say they usually report to Directors or even the CTO in some organizations.

Another one is “Independent Contributor” which is similar but, as the name would suggest, is very self sufficient and does not work on (or for) a team. They’re basically one-man engineering shops and are expected to perform well everywhere in the company’s tech and talent stacks. As a result, ICs are very rare.

The other pivot point is The Pragmatic Programmer, which is totally understandable.

That book does a good job of grounding the reader through examples and parables from everywhere else but IT. By the end, you realize that good software engineering makes the best of general problem-solving skills, rather than some magical skillset peculiar to computing. You wind up reaching a place where you can begin to solve nearly any problem through use of the same principles. So @codex here, perhaps effortlessly, went on to management instead.

Same. Let’s rock.

https://www.youtube.com/watch?v=TrqQxl5o3eg

Printed on the bomb:

| In case of accidental detonation: have a nice day. Thanks for reading.

I’ve tried to enjoy IPAs, really. I’m not discounting the role of interesting terpenes and flavonoids here, but the raw in-your-face excessive bitterness of IPA-level hops pushes all that great stuff so far from the stage of my experience, that it’s all left waiting in the lobby to get seated. For me, it’s like someone mixed LaCroix, light beer, and a drop of dish soap in a glass. Every time.

I actually tried to use marketplace a few weeks ago. It was an unmitigated disaster. People either didn’t respond, had stale posts for items, or couldn’t get their act together to have a conversation (even with 12 hours between messages) about how to get shit out of their house. I have never yearned for old-fashioned yard sales so much.

Estimate for CD lifespans was in the 100 year range, but the only way to really put that to the test is to try them in 100 years.

FWIW, I have some CDs that are pushing 40+ years at this point. They work fine, scratches and all.

In my experience, CDRs and other record-able media can’t handle a single summer in a hot car. Mistakes were made. If you have your hands on anything like that, I agree: focus there first for your data hoarding activities.

I completely understand the sentiment here, but I have to respectfully disagree with part of your argument.

The internet itself is this fundamentally ephemeral, thing. Our relationship to it, as a medium, has persisted for decades at this point and may continue to do so for a long time. At the same time, it lives and dies by the whims of corporations and millions of other users, and so it’s trajectory is largely beyond the control of any one individual. It’s like this by design: properties like distributed control, flexible routing, easy duplication/destruction of data, give it resilience but also make it temporary. This also makes it a volatile place to keep things permanently, which is a real problem for a lot of different mediums.

With that in mind, there exists a lot of media today that has no non-digital equivalent. So, having a local data cache you control - DVD, BluRay, forvever moving data between online services, even a personal NAS - is the only hedge you can get for the net’s volatility. And even then, that medium has a service life.

So I don’t think it’s a shame, per se, that things are like this now. Rather, it always has been. It’s never been easier to consume (and pirate) media online, but the underlying rules have not changed.

Thanks. I knew I was in for a wild ride when a co-worker quoted MIB:

The company keeps us on Centaurian time, standard thirty-seven hour day. Give it a few months. You’ll get used to it… or you’ll have a psychotic episode.

Management was very accommodating in making the switch back to 2nd shift. I noped outta there and went on to much greener pastures soon thereafter.

The kind of customer you interface with at 1AM is absolutely NOT going to take “we can’t solve this now; I’ll make sure a supervisor or manager contacts you during the day” as an answer. You typically get quite the earful for something 1st or 2nd shift never has to worry about. After this happens a few times, it more or less eradicates any perks of working this shift.

Don’t forget that night shift customer-facing jobs also have to deal with the night creatures that are said customers.

Things get real weird from 11PM-3AM. These people didn’t need IT support, they needed a psychiatric counseling hotline.

For me, my body literally couldn’t take the constant “biological darkness” (no UV). After three weeks, I experienced moderate dysphoria, anhedonia, and could no longer achieve restful sleep. Perhaps more-so than the average person, I am a slave to my circadian rhythms and absolutely depend on a normal clock to function.

I agree, but I feel like having the toaster itself catch fire could have been mitigated somehow.

I’m actually kind of amazed that the failure mode for “toaster used sideways” is that it just catches fire. That’s one hell of a design flaw.

This is basically how Ixion went. The game didn’t need a soundtrack to go this hard, but it absolutely put it over the top.

They are. This is the equivalent of a 19th century steel tycoon buying up newspapers all across the country. It’s an investment.