Yes, but “Proto Indo-European” doesn’t exactly roll off the tongue. /s
Yes, but “Proto Indo-European” doesn’t exactly roll off the tongue. /s
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.
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.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.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.
Oh no, I have to press up
200+ times if we’re counting all the detritus and failure in my command history.
There is an advantage to this approach though: fewer errors. You’re plucking a known working command from a list instead of manually typing a (possibly) broken version of it. Worse yet is when it’s a command where typematic mistakes cause unintended side effects like data loss. So, mashing up
100 times can be pretty smart, especially if you’re not a great typist.
Upvoted for the dancing and singing emoticon. Nice art.
This man is a menace and must be stopped.
Eh, I’m used to it.
This is fine.
Good fences make good neighbors.
Corollary: server-side commit hooks make good teammates.
Oh. That’s good.
NPM ruin dev
is a new advanced feature that endorses opinionated “extreme programming” techniques. First it gets to work rebuilding node_modules, but with all the least compatible module versions in order to accelerate testing. It also minifies your .js code in place, to save you some CPU cycles later. Lastly, it squashes your entire git history on all branches, to save space.
I totally get that: use the right tools and you’ll be okay. This applies to many technologies in this space.
With respect, I still take this advice like hearing “look out for rattlesnakes if you’re hiking there.” It might be safer to just hike where there are no rattlesnakes, instead.
I swear, overcoming fixed functional-ness is like a superpower when you can apply it.
I once shared a small office with a co-worker. I had the idea to move the desks away from the walls and place them back-to-back, diagonally, in the middle of the room. Other co-workers scoffed and remarked at how dumb and unconventional this looked. Then I explained that we each now had nearly full privacy from each other, much more personal space in our respective corners, no more glare from the window, and nobody could sneak up on us from the door anymore. Things got pretty quiet after that.
Useful? Not exactly. But you’d never look lazy or idle, that’s for sure.
/me goes back to get second folding chair.
Pascal went to military school.
I’m not in love with the idea, but a language that cuts out the BS has a sudden appeal when on a group/team project.
Java itself is kind of blissful in how restricted and straightforward it is.
Java programs, however, tend to be very large and sprawling code-bases built on even bigger mountains of shared libraries. This is a product of the language’s simplicity, the design decisions present in the standard library, and how the Java community chooses to solve problems as a group (e.g. “dependency injection”). This presents a big learning challenge to people encountering Java projects on the job: there’s a huge amount of stuff to take in. Were Java a spoken language it would be as if everyone talked in a highly formal and elaborate prose all the time.
People tend to conflate these two learning tasks (language vs practice), lumping it all together as “Java is complicated.”
$0.02: Java is the only technology stack where I have encountered a logging plugin designed to filter out common libraries in stack traces. The call depth on J2EE architecture is so incredibly deep at times, this is almost essential to make sense of errors in any reasonable amount of time. JavaScript, Python, PHP, Go, Rust, ASP, C++, C#, every other language and framework I have used professionally has had a much shallower call stack by comparison. IMO, this is a direct consequence of the sheer volume of code present in professional Java solutions, and the complexity that Java engineers must learn to handle.
Some articles showing the knock-on effects of this phenomenon: