Nice video! I've seen many of these in PRs I receive, but sadly have also been guilty of a few of them myself... Minor audio tip; you have some bump and pop going on with plosives, so add a high-pass or low shelving filter to roll off frequencies below 80-100Hz. It also helps reduce keyboard rumble when you're typing (though you don't have much of that).
@@MattStauffer It probably won't be audible on small speakers anyway. I saw your 'uses' list and saw you're using RX; I use that too because I have a noisy river outside my window! My favourite plugin for vocals is SSL's channel strip 2 (works better for me than their vocal strip plugin), which I run in Audio Hijack so that I get to do audio twiddling in front of apps like Zoom. I really need that as I use an Aston Element mic which has really excessive bottom end. Also, everyone really needs reverb, pitch shift, and bit crusher effects during calls, right?
@@marcusbointon9497 oh nice!! I only used the de reverb on this one. You’re definitely up on a significantly better game than me audio wise! I hadn’t ever thought about running stuff *for calls* dang lol
Nice to see you back on YT! Semi-related question, do you plan on doing a video on git workflows? Gitflow/ Github flow/ Trunk branching? I looked into it recently and now dont know what I prefer 😆 For small teams and web apps/ continuously delivered software, maybe feature branches are bad 👀
Thank you! Yes, I’ll definitely add that to the queue! Thanks! Short answer I think continuous delivery is great but small teams can sometimes struggle with using feature flags effectively. But if you can do it, go for it! Otherwise, short lived feature branches is the trick.
@@MattStauffer Your welcome! So, yeah we dont really use feature flags. Everyone gets everything when we deploy 😅 As you said, I imagine its hard to get right, especially with DB changes. I agree, short lived feature branches are a good goal!
Hi Matt, great video thanks! Do you at your company have pre-commit hooks, which start tests, linting and stuff like this before commit? Or does each developer need to call these commands itself before committing?
Thank you so much! We’re still working on this. Some teams use pre-commit hooks, but we try to make sure that everybody has GitHub Actions running all of our linters and tests so even if you don’t do it as a pre-commit hook, you’re still confident it’s going to get checked.
I came here out of frustration with my job. My prs go on for days, there are so many comments and so much small insignificant stuff that they complain about, like white space, not breaking out string constants, validation and error handling, I end up feeling really bad about It. I do lots of tests, but of course, they are not good if they are not testing for the correct behaviour.
Code formatting should be handled by the machine. Depending on the language, it can be meaningless to extract string constants from string literals. I wish my colleagues would complain about validation and error handling, because the result is that we don't have it whatsoever.
thanks for your video I have a question what will you do if you create a pull request with a lot of changing files? I myself sometimes create that kind of pull request. Or I have reviewed that pull request. To be honest, it is very difficult to review. What is your advice? Also, what will you do if you have to review a PR with not familiar technology or frame work? for i.e. I am backend engineer but I get some FE (Angular) pull request then I get many troubles to review that thank you
Nice video! I've seen many of these in PRs I receive, but sadly have also been guilty of a few of them myself...
Minor audio tip; you have some bump and pop going on with plosives, so add a high-pass or low shelving filter to roll off frequencies below 80-100Hz. It also helps reduce keyboard rumble when you're typing (though you don't have much of that).
Thanks so much! Sadly I only noticed the plosives after; usually I have good enough mic technique to avoid it. 🤦🏻♂️ I really appreciate you!
@@MattStauffer It probably won't be audible on small speakers anyway. I saw your 'uses' list and saw you're using RX; I use that too because I have a noisy river outside my window! My favourite plugin for vocals is SSL's channel strip 2 (works better for me than their vocal strip plugin), which I run in Audio Hijack so that I get to do audio twiddling in front of apps like Zoom. I really need that as I use an Aston Element mic which has really excessive bottom end. Also, everyone really needs reverb, pitch shift, and bit crusher effects during calls, right?
@@marcusbointon9497 oh nice!! I only used the de reverb on this one. You’re definitely up on a significantly better game than me audio wise! I hadn’t ever thought about running stuff *for calls* dang lol
Another amazing video, really appreciate your work!
Great video, Matt. Thank you.
Great video man so helpful 🙏
Nice to see you back on YT!
Semi-related question, do you plan on doing a video on git workflows? Gitflow/ Github flow/ Trunk branching?
I looked into it recently and now dont know what I prefer 😆 For small teams and web apps/ continuously delivered software, maybe feature branches are bad 👀
Thank you! Yes, I’ll definitely add that to the queue! Thanks! Short answer I think continuous delivery is great but small teams can sometimes struggle with using feature flags effectively. But if you can do it, go for it! Otherwise, short lived feature branches is the trick.
@@MattStauffer Your welcome!
So, yeah we dont really use feature flags. Everyone gets everything when we deploy 😅 As you said, I imagine its hard to get right, especially with DB changes.
I agree, short lived feature branches are a good goal!
Hi Matt, great video thanks!
Do you at your company have pre-commit hooks, which start tests, linting and stuff like this before commit?
Or does each developer need to call these commands itself before committing?
Thank you so much! We’re still working on this. Some teams use pre-commit hooks, but we try to make sure that everybody has GitHub Actions running all of our linters and tests so even if you don’t do it as a pre-commit hook, you’re still confident it’s going to get checked.
Thank you for this amazing content 😃👍🤗
I came here out of frustration with my job.
My prs go on for days, there are so many comments and so much small insignificant stuff that they complain about, like white space, not breaking out string constants, validation and error handling,
I end up feeling really bad about It.
I do lots of tests, but of course, they are not good if they are not testing for the correct behaviour.
Code formatting should be handled by the machine. Depending on the language, it can be meaningless to extract string constants from string literals.
I wish my colleagues would complain about validation and error handling, because the result is that we don't have it whatsoever.
thanks for your video
I have a question
what will you do if you create a pull request with a lot of changing files?
I myself sometimes create that kind of pull request. Or I have reviewed that pull request. To be honest, it is very difficult to review. What is your advice?
Also, what will you do if you have to review a PR with not familiar technology or frame work? for i.e. I am backend engineer but I get some FE (Angular) pull request then I get many troubles to review that
thank you