I agree with the article’s ideas, but certain things about the execution bother me.

1. calculate_order_total_for_customer. I’d just call it calculate_order_total. It’s clear than any order will have a customer, it’s in the type signature.
2. is_user_eligible_for_discount. I’d call it user_is_eligible_for_discount. Because inevitably that function is getting called in an if statement, and you’d rather it read closer to proper English: if user_is_eligible_for_discount: ....
3. “Designing for Tomorrow”. I agree that dependency injection is a valuable technique, but it’s not always strictly necessary and they seem to say you might as well always do it just in case. That’s counter to YAGNI. Make sure you have an immediate use case, or let future you do it if you end up needing it. It’s not hard to refactor something to inject a dependency.

Agreed with pretty much everything here. My notes:

1. Read about software patterns - the gang of 4 book and Fowlers book are classics. This will help you read and understand legacy code, and write your own code with understandable structures and naming conventions.
2. All skill learning inevitably comes with making mistakes that you regret later, and which will make you look dumb. Embrace it. If you have to think too hard to come up with a clever name for a variable, give it a stupid long name - the dev 5 years later working on your code would much rather have a variable with a name so long it runs off the page, but actually describes its purpose accurately, than a short named variable that is “clever”. If you or someone else thinks of a better name later, renaming variables is trivial. Interpreting variable purpose from an unclear name is not. Similarly, make your methods short - really, really short. If you have 10 lines of code and put them each in their own method, great! Maybe it isnt the fastest code to read - but readable method names will make it obvious what each line does, and combining independent methods together is far easier than breaking one massive method into chunks.
3. TDD (or BDD) is awesome for turning most of the things listed here into habits. It also, ime, makes boring enterprise software development far more enjoyable, since you start by making a long checklist of itty bitty tasks, and then get to check a new one off every 5 or 10 minutes, knowing that the task is done.
4. The best way to learn how to write better code is pair programming with a more senior developer. Often employers will refuse to budget time for this since “how can we justify paying two developers to write the code one developer could?” The fact is, developing like this typically decreases development time as juniors’ code ends up more readable and with fewer bugs, reducing time spend on fixing bugs later - the most time-intensive part of any software project. If managers still won’t budge - fuck 'em. Do it anyway. Getting someone to critique your code in real time - even for just 30 minutes per day - will rapidly improve your skills.