azov

Yes, but “if you can” does a lot of heavy lifting here. In most cases you can’t, and this is when Rust’s ? is used.

I believe they have Adobe + Da Vinci plugins for film & video (and maybe a standalone app as well. At least they used to when I played with the beta, but it may be plugin-only now, I’m not sure).

As far as I remember, they try to do some physically accurate emulation as well. The founder is a big fan of film photography and also runs some interesting gigs (like, repackaging cinema film for use in still cameras) - also blogs about color and film photography.

Having code reviews is an incredibly low bar. The very fact that you offer this as an evidence might be the reason people make those assumptions.

"A feature not making it into a sprint" is your problem. You will get in trouble for that, it will make you look bad in front of your boss, etc. "Not following best practices" is not your problem. If the code turns into a mess, it's not you who will have to deal with the consequences, at least not you directly. As a manager you will demand that your senior developers fix that (while still shipping features, of course). After all, that's what expected of senior developers. So, the incentives for you and for your senior engineers are not aligned.

Of course I don't know if that's even remotely close to your reasoning. I don't know you or your project or your priorities, I have no idea what "best practices" we're talking about and how reasonable it is to follow or not follow them in a given situation. I might be totally wrong, you may have all the right reasons to be mad about those reviews. But the comment makes it sound like your senior engineers are idiots who block PRs for no reason, and that can't be good for your team.

PS. But, titles aside, do we actually want to do teaching during code reviews? There are many activities when teaching and doing are better kept separate (like, you don't want to teach your partner how to dance while you're dancing). Do code reviews fall into this category? Should we consider them a doing phase or a teaching phase?..

Who are those people dangerous enough to never be allowed on a plane (despite being searched, xrayed, water bottles and corkscrews taken away from them), yet not dangerous enough to roam free everywhere else?

  "On their face, the benefits of using exceptions outweigh the costs, especially 
  in new projects. However, for existing code, the introduction of exceptions has 
  implications on all dependent code. If exceptions can be propagated beyond a
  new project, it also becomes problematic to integrate the new project into
  existing exception-free code. Because most existing C++ code at Google is not 
  prepared to deal with exceptions, it is comparatively difficult to adopt new 
  code that generates exceptions." (https://google.github.io/styleguide/cppguide.html#Exceptions)

But, sadly, countless companies parroted this section of Google's style guide for all the wrong reasons (mostly just cargo culting Google) leading to unfortunate fragmentation of error handling in the C++ library ecosystem.

[1] https://en.wikipedia.org/wiki/FireChat

Well, yes, they do. They also make your database slower. This doesn't mean they are overrated - this means they are tradeoffs. Like everything engineering.

With DB normal forms you buy integrity (i.e. keeping the data consistent as it changes) and you pay with performance and schema complexity. Usually this is a sensible tradeoff because integrity is more important. But, for example, if your data never changes - you will be paying for nothing. Or, perhaps, you can't afford the performance price and you have some other way to ensure integrity. Then you de-normalize.

DRY is similar. As mentioned in the sibling thread, it's not about mechanically avoiding repeated code - just like normal forms are not about never having the same value in two different rows. It's about maintining logical integrity of your code as it changes. PI=3.14159265359? Probably safe to copy around. An implementation of some use case? Probably not.

I'd say following DRY/STEP principle is a sensible default. If a reviewer asks you why your code is not DRY - you should be able to articulate a reason.

With robotaxi you get a driver that:

  - never gets tired
  - never gets distracted
  - never gets drunk
  - never gets upset
  - never falls asleep 
  - has reaction time in milliseconds
  - ...

The way you think of dogs is probably not very different from the way many people think of computers.

Well, this can be done. Lots of software was written before code reviews or source control existed. But I’m not longing for that time.

First amendment refers to the government not precluding your speech. "Free speech" is a much broader concept.

Did the author even try his own trick?.. Switching to Russian keyboard the way he describes will not change the UI language or menu options, it only applies to the text you type.