DawsonBruce

The balance of rest is an important factor that I’ve understood the value of only later in my career. Pausing on a difficult engineering task at the end of the workday in favor of exercise or cooking dinner (or both) gives my mind and body time to reset it needs. Often answers or alternate approaches will materialize mid curl, crunch, or vegetable chop.

Huge fan of this tool for working on GUI implementations, ensuring the color choices and contrasts make sense for users that see GUIs differently than I do.

I use an M3 air for my personal machine which is used for c++ development and music production — it’s an excellent machine and I have yet to encounter a task that would require a MPB (at least for the type of work I am involved with).

IIRC, the US shot down some weather balloons in Jan-Feb 2023. Why not the same expediency with these drones?

Thanks for sharing this. I recently built something similar for a closed source project and am curious how I didn’t run across this library in my research.

Briefly: my implementation uses a templated RAII-style wrapper that persists objects in shared memory for as long as an instance of that object remains in scope. Once the last object goes out of scope, shared memory is freed. It works great so far. I’ll probably reference this library to compare implementations and see what I can learn. Thanks again.

I lost my father to Huntington’s Disease at a young age, and have had to live the 50% inheritance chance reality my entire life. I’ve never been tested for the disease, but I probably should be eventually. I really hope I don’t have it, and only time (or a test) will tell.

“Elastique” time stretch algorithm by zplane (0) seems to be a common choice by plug-in companies. Their C++ library is pretty straightforward to use, and most importantly it sounds good.

Generally speaking, phase vocoder (1) algorithms are what you’d want for developing your own pitch shifting algorithm.

[0]https://licensing.zplane.de/

[1]https://cmtext.indiana.edu/synthesis/chapter4_pv.php

The good documentation I’m envisioning refers to standardized comments throughout the codebase (we’re working with cpp, so doxygen in this case), with code examples within the header showing how the code should be used.

I’ve found there’s so many custom classes through my discovery if this codebase that it’s not quite clear how to use the classes or where to start, so having code examples along with comments describing their usage is pretty useful.

It’s also nice to utilize version control for the comments, which makes them easy to contribute to, as well as hopefully inspires others to contribute their own thorough comments when designing and contributing new classes to the codebase.

Documentation regarding process, coding guidelines, and the likes are better suited for a platform like confluence or some equivalent. We do that as well.

I’ve recently joined a team where the vast majority of the code used across different projects has been written by a lone developer. The code quality is quite good, however, nothing is documented thoroughly and it’s mostly understood by a single person.

We’ve started to code review all new code being merged to the the codebase, we’ve been pair programming occasionally, and I’ve also been writing documentation about how to use the code as I get a handle on it. It’s been helpful so far.

Please document your code. Please provide examples.

I watched the MIT 6.006 Introduction to Algorithms course (0) while studying leetcode a couple years ago. I’d watch the lecture, take notes, and then find some related leetcode questions and solve them. I found it considerably beneficial to do the two in tandem and made some pretty significant progress with my understanding of data structures and algorithms. Hope this helps.

[0] https://youtube.com/playlist?list=PLUl4u3cNGP61Oq3tWYp6V_F-5...

After being laid off from my previous employer of 7 years, I found a company to join in my domain that has weathered the storm for many decades and is well-established in the industry I’m in AND also has income via federal contracts from another department at the company. The company is still privately owned by the original owners, and it seems to be a sustainable company that will weather the coming economic storm. I’m really happy to have joined when I have, I think this is a company to spend some good years at, and there’s a number of employees that have been with the company for over a decade. Things are looking stable, and I suppose for now I am a lifer.

Agreed. Currently I am on a 3-month sabbatical after being laid off from my previous position of 7 years. While I could have opted for a longer duration, I’ve been happy with the time off thus far, and my efforts of saving and investing over the years has made finances a non-issue during this time.

I also set up my next gig in the weeks immediately following layoffs, which I’ll be starting in November, so I’m excited to know that there’s financial security at the end of this experience.

It’s been a much needed break.

It’s not that the funding changed people, rather those that built the company were either replaced, left, or laid off.

> Culture plays an important role in keeping the people, it's not always about the money.

Absolutely.

I was at my previous employer for seven years, mainly due to the fantastic culture.

In 2020 that company took a $45M series A investment that rotted the culture of the company from the inside out.

Today, the culture that remains at this company doesn’t reflect what kept me at the company, and most who were integral to the culture are no longer with the company.

It was good while it lasted.

The UIGEA (Unlawful Internet Gambling Enforcement Act) was passed in November of 2006, as part of the SAFE Port Act [0], which placed online poker into a legal grey area for most U.S. citizens. A lot of major poker sites withdrew from the U.S. market as a result.

The legality of both in-person and online poker varies from state to state.

[0]: https://www.beatthefish.com/us-poker-sites/uigea-unlawful-in...

I did this at my previous employer for seven years. My peers loved me, but I could tell the executives weren’t a fan of the outspokenness. Last week I was laid off, and while the company will never admit to it, I have a feeling that my willingness to use my voice over the years attributed in part to their decision.

I like making flashcards for myself for new topics that I study, in addition to notes. Of course bash as a whole will not fit on a flashcard, but breaking it into high-level topics. looking through the cards I’ve made helps when I feel the need to brush up on a topic in a general sense before diving deeper.

Despite all this, my brain is still Swiss-cheese.

While I have found using kanban with personal projects to be pretty beneficial for quantifying progress, there’s something that feels wrong about agile seven days a week between work and personal projects.

Dithering modulates the least significant bit of the audio signal, so at normal listening levels it should be inaudible. Of course, one can amplify the silence by 120dB or so and hear the noise.

Sources: http://www.dspguide.com/ch3/1.htm

https://www.bruce.audio/post/2022/05/26/dithering/

While its true that dithering changes the original signal, dithering is a necessarily evil that prevents quantization errors as a result of downsampling 24-bit+ source material due to CDs being 16-bit. It’s a choice between some barely audible noise, or some weird spectral artifacts..

Agreed, sharing a tech spec / architecture decision record outlining the system design and it’s benefits and consequences with the team you’re seeking feedback from is quite effective.

Not only does this remove another meeting from the calendar, but it also allows everyone to contribute asynchronously and requires explicit buy-in from each requested reviewer.

QBasic was my first programming language, which I was introduced to at about 13 years old. Today I am a senior engineer and the passion for programming all started back in that ugly blue screen around the turn of the century.

I was introduced to the programming language when I visited some family in the Midwest US. I had gone with my cousin to the home of a kid named “Robbie” that lived in a neighbor.

Robbie is what people today would call a, “script kiddie,” and he introduced me to a variety of his “hacking tools,” mIRC, and QBasic. I thought it was the coolest thing I had ever seen.

I spent the rest of my time during that trip in my aunts basement trying to write my own QBasic games and downloading other people’s QBasic projects and trying to modify them.

I began to attempt to write my own Zelda-esque game and was completely baffled by the concept of z-ordering and my giant green square of grass continues to cover my character and flash when I would make the character move around the screen.

It was all an absolutely mess, but it was my introduction to programming, and it changed my life forever. I was absolutely enamored with what I had discovered, and it was the beginning of a lifelong journey of exploration in technology.

Thanks Robbie, wherever you are.

> Their investigations reveal that the last certain evidence that Sheila was alive was in August 2019, when she paid her rent by debit card to Peabody for the last time.

How in the world did this individual remain deceased in their flat for two years when rent had gone unpaid for the entire duration? Baffling!

As someone that spends a lot of my work week reviewing code and documentation, here are some initial thoughts that come to mind:

1. break large feature branches into smaller PRs so they are more easily digestible by reviewers. If this is not feasible, at the very least, ensure each commit in the PR is concise and meaningful, so reviews can look at the PR commit-by-commit if needed.

2. have specific reviewers or "owners," for different areas of the codebase. Tossing a PR into the abyss without specific reviewers isn't a winning strategy for getting the desired feedback in a timely manner.

3. do not backtrack when requesting PR changes, meaning, each review should only review the code that has been implemented since the last review (don't retroactively ask for changes introduced in the original PR if it's the second or third time reviewing).

4. Code reviews should be celebrated at the team level; they shouldn't be seen as a net negative on one's velocity, rather, they're a net positive for the team's velocity.

5. Be proactive: be an active reviewer of your peers code and they'll feel a bit more urgency in assisting with your PR reviews as well.

My 2c,

Some dev on the internet who spends a lot of time reviewing code

Over the past year I’ve disabled all Slack notifications and the result is increased focus while I’m writing some code or an email. All the messages will be queued up regardless if I’m being notified (and disrupted) often. Perhaps give it a try!

Reader View on my phone usually does the trick, however, sites seem to be catching onto that.

> And, possibly just as importantly, you'll have time for gaming!

Facts. One of the main motivators for me to NEVER become a game devs is simply my love for gaming. Anything I’ve ever worked on professionally has become so demystified that the things I once loved become unappealing.

Same. I thought he was named, “Nice Linus,” or something.

I was promoted to senior engineer this year at my organization…

And what you’ve said is 100% true.

This amazing music technology podcast is ending after nine years. The host, Darwin Gross, is a really good guy and was recently diagnosed with kidney cancer and is undergoing treatment. Sharing here for exposure and wishing Darwin all the best.