scottious

I don't really think so. The stuff that's covered in the first half of this article is certainly very math-y, but you can be a great musician and not know this stuff. I really think all you need to know is basic arithmetic and the absolute basics of modular arithmetic (akin to learning how 12 o'clock + 1 hour = 1 o'clock, not 13 o'clock).

Becoming a great musician is more about developing your ear, technique, repertoire, etc. It's more similar to learning a foreign language than learning math, in my opinion.

> I'd like to ask you for advice on how to make the most out of the time during my studies

Go to professor's office hours. I was always so shocked when I showed up to office hours and I was the only one there almost every time. You can literally have 1-on-1 time with an expert and nobody takes advantage of it.

Another advantage of office hours is that you don't want to look like you're unprepared, so preparing some questions to ask is actually really good practice to hone in on what your gaps in knowledge are.

Withdrawal symptoms usually last a few weeks for me. Head over to reddit.com/r/leaves if you need support for quitting.

I've struggled with this a lot over the years. I'll quit for 6 months, get rid of all my paraphernalia then find myself starting up again. I keep telling myself that I'll use it more responsibly this time, but then I end up doing it every day.

"hey welcome to your first day at Amazon! We're so excited to have you. Here's your desk, and here's your PIP. Oh yeah, here's your computer too"

sure, but all of that is a cost which you don't have to pay with a monolith. Versioning APIs and having to constantly think about backwards compatibility with independently moving services is not trivial.

Sometimes the cost is worth it. Most of the time it's not

or even worse: the teams DO have full control over their stack and now you have dozens or more different technology stacks at the company and expertise isn't shared between them

There are plenty of monoliths that scale in terms of number of contributors and organizational changes. For example, the Linux kernel. I've worked on massive monoliths that were 20 years old and changed hands and org structures tons of times and nobody ever thought "this needs to be microservices!"

Microservices are not the only way to modularize code.

Also, there is TONS of bike-shedding with regard to HTTP. Which HTTP method do you use? How do you structure your paths? What does the body of the request look like? How to we translate failures into the various HTTP error codes? Do you send a 200 or a 201 status for this particular request? I could go on and on... Even among well established HTTP APIs, there are differences.

> Letting [technology choices] drift on a per team basis is kind of nice to allow experimentation with different technologies without having to get the whole org onboard.

This is very much a double edged sword. I've seen this happen and people just tend to avoid services in languages/frameworks that they don't know. And even if they don't avoid them, they are less productive in them. We have a critical services written in Rust and one guy at the company knows Rust. We have 2 services written in a particular Java reactive framework which only a few people know how to use. Any newcomers to these services have to spend a lot of time learning a new thing.

I feel like the author is really saying "don't over-engineer". At no point does he say create code that does not work. The closest he says is that ALL systems will fail and that he'd rather fail with throw away code than some overly abstracted, lovingly hand crafted pile of code.

The point the author is trying to make is that trying to build a perfectly designed cathedral of code can often be counter productive.

> A lot of senior experienced people will talk about all the “shoulds” your code should be like. They are usually describing some far distance promised land that they have never visited either.

Oh how I can relate do this. I've seen so much guilt and inaction from developers who are paralyzed by "should". They so badly don't want to be a "bad engineer" that they'll over-engineer just about everything and end up causing a lot of problems.

24fps is definitely not just a low-budget option. People with very expensive cameras capable of shooting 60fps without any issues at all are still CHOOSING 24fps.

The debate about 24fps vs higher frame rates is nuanced. It's about trade-offs and style choices. Here's an example of a videos discussing 24fps vs higher frame rates:

https://www.youtube.com/watch?v=WIo7jwsYbxc https://www.youtube.com/watch?v=e6HZPmSlS5c

A single team can break down their domain into sensible layers and abstractions within a monolith.

Similarly, A microservices/SOA architecture can fail to break down their domain into good boundaries and abstractions. I've seen this happen a lot.

It's a lot harder to fix bad microservices than to fix a bad monolith

The insidious thing about over engineering is that it's usually committed by very experienced engineers. Experienced engineers rarely under-engineer, that tends to be fixed very early in one's career.

As we get more competent and read more books, we have the tendency to get enamored by new fancy abstractions. We get too clever and then we get in our own way.

Best real-world example: I inherited a project that was an giant "microservice" with 50-ish endpoints, and a Mongo database and dozens of collections. After probably 3 months of wrestling with this thing I had a realization: "this whole thing can be just a simple command line tool and one collection in Mongo". That reduced the code by almost half and it became so much easier to work with. It's frustrating that it could have just started this way.

Sometimes if you try this you enrage the person on the other end so much that they LITERALLY stop what they're doing to SCREAM at the top of their lungs. After their voice is hoarse they go right back to the vicious attacks. I'm not sure this advice works when used on people with Narcissistic Personality Disorder or Borderline Personality Disorder.

I was being berated unfairly, verbally abused, accused of things that didn't happen, and gaslit. Instead of defending myself I actually tried the approach laid out in this article: "SHUT UP when you aren’t sure what to say". I wasn't about to defend myself when everything I do is suddenly on trial for some reason.

> OMG, in the recitals there was one lady who just had to play every note correctly, no matter how many times she had to try. She stopped at every mistake and "corrected" it, until you wanted to scream at her.

oh man, that is frustrating! Somebody once said that a good musician will make their mistakes sound musical. Thinking that you must stop to correct a mistake is a fundamental misunderstanding about how music is perceived. I don't blame her though, I was once like this too. I think this is the default behavior for many adult beginners especially.

Getting a teacher will without a doubt help with both of those things. Learning to play the piano is like trying to summit Mt. Everest while blindfolded. Technically speaking, you can do it alone but it's orders of magnitude easier with somebody guiding you. Sometimes all it takes is a nudge in the right direction. Other times they need to tell you specifically how to execute or understand an idea.

I envy the fact that you can read music so well! I'm the opposite of you: I play by ear and I am mediocre at reading music.

I started piano lessons 9 years ago when I was 27. I had a background in marching band where we were not allowed to carry sheet music with us on the field for 4 years in college

I think that experience with marching band really forced me to develop my ear and learn to memorize music. Also I was terrible at reading music so I used my ear (which also wasn't that good) to fill in the gaps.

Eventually I became proficient enough at this that I could just listen to the other saxophone players and play what they were playing. I didn't know anything about keys, chords, intervals, or anything. I just played what I heard because I had no other choice.

Perhaps putting yourself in similar situations would be helpful. For example, I'm now a keyboard player in a band and I have to be able to learn a song that I've never heard at a moment's notice. That kind of pressure would force anybody to develop their ear because sheet music is just not as useful in that kind of setting.

> I have heard team leads say "this python code is bad because it uses no classes"

And they'll say it's "best practice".

"best practice" has basically come to mean "whatever that particular developer knows/likes"

> I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all.

I've been a developer for 15 years... anybody else feel like the further they get into their career, the more they want to keep their opinions to themselves?

I feel like as a junior dev I had way stronger opinions and I was a lot more vocal about them. Now, I still have opinions, but I've learned that nobody gives a damn about my opinions so I just keep them to myself.

You're lucky. I deactivated back in January and I think I did a "log in with facebook" button once and now facebook seems to have re-activated my account implicitly.

Also they send me click-baity emails like "John Doe has posted a status update!"

Heck, they've even started TEXTING me to lure me back.

I'm dreading having to log back in to try to figure out how to get them to stop trying to contact me.

yeah -- your app is coupled to those services. I've definitely written code before that depended on a third party API only to have that API break on me.

Granted, this is not something to worry about with S3 or SQS.

> If we go with your definition then my app is a monolith with S3 and SQS

okay sure, I agree that calling your app a monolith with S3 and SQS is ridiculous.

The point is that we all may think that we're writing another S3 or SQS when we write our own micro-services. However, in practice maintaining a stable, backwards compatible, public API like that is quite costly and we usually end up re-implementing function calls as HTTP requests and then calling it "loosely coupled".

> I think this is too strong of a definition because then everything is a monolith.

Yes... exactly. More things are monoliths than we want to admit.

> We need a definition of what it means for two services to communicate while being “uncoupled”

Take a dead simple example: an application server that talks to an in-house video encoding micro-service

Even if that video encoding service only has a single really well designed endpoint, there's STILL coupling between the application server and the video encoding service.

Just because we've replaced a method call with an HTTP request doesn't mean things aren't coupled anymore.

Sure -- you may be able to deploy certain changes to your video encoding service without changing your application service. However, you need to be keenly aware of what changes are compatible with existing application servers and which are not and that adds complexity and cognitive load. Maybe it's worth it in some cases. In many cases, it's not.

I find a lot of people create micro-services when a simple library would suffice. An "authentication" micro-service might make sense in some contexts, but in almost every real-world situation I've been in, this would be better as a library.

Couldn't have said it better myself.

Sometimes you gain real benefits from this approach (e.g. maybe a component needs to be scaled independently), but I find that very commonly, people write tightly coupled micro-services and end up with a distributed monolith.

> I’ve noticed that faced with a “new tab” I’ll often just hit the f key and hit enter without thinking about it

OMG I'm so glad I'm not the only one. I deactivated it over 6 months ago and I STILL have this impulse from time to time.

Yup. I usually really like NPR but I had to stop once I read that. Why'd they have to say they were a Libra? They could have just said "I was born to find balance". ugh.

Counterpoint: perhaps putting a name and numbers to these tax loopholes will make them less abstract for people.

For example, knowing that the richest man in the world avoided paying $x billion in taxes using a loophole could insight change better than a theoretical story about how somebody could use these loopholes.

That being said, I'm still not sure if leaks like this are a good idea or bad idea. Just playing devil's advocate a bit.

Totally agree, especially about Maven/Gradle. I'd also like to point out that the popular Spring Framework is just... annoying. It's full of magic. You have to know the right incantations to get anything done. Somehow there is too much documentation and not enough at the same time.

I've never seen a Java program in my entire career that was actually fast and not a huge pain to work with. I'm working on a new one right now and the prototype/skeleton literally does just basic CRUD operations and the CI/CD pipeline takes 7 minutes.

Golang was a breath of fresh air for me.

> It also often makes the difference (given equal visuals) between great amateur and pro in e.g. the YouTube scene.

Good audio and good lighting can really make all the difference. It pains me because it's actually a very cheap problem to solve. Lighting, an audio interface, and a decent mic could cost no more than a few hundred dollars for a starter pack.

I'm on conference calls all the time where people have overhead lighting that makes them look like a sith lord and their mic is trash and picks up way too much room sounds and echos. It makes them look and sound bad. People notice that stuff.

I'm a musician but I honestly don't really understand this thing. I even tried playing around with one for a while. It just didn't click at all. You could have convinced me that it was a children's toy and I probably would have believed you.

Obviously I'm missing something. I've seen some YouTube tutorials but they all seem to produce the same kind of music and honestly I don't find it super impressive.

Maybe it'll click one day

> After I finished school, as a software engineer I bought a home and a car (by taking a loan) and effectively I had negative wealth.

I mean, sure... but your wealth was only negative for a VERY short period of time. Your car still had value and you could close that gap in probably a few months and be net-worth positive.

I think there are way more people who are paycheck-to-paycheck at best. The average credit card debt in the USA is thousands of dollars. I don't think that's because people are just stupid with money, I think a lot of that comes out of necessity because they can't keep their head above water.