On "you don't need a CS degree" True, for simple things. But there's a difference between a website and a bank management system—both in complexity and importance. You may not need a degree, but you need enough education to shoulder your responsibilities.

Learning new things always gives me a dose of humility and empathy. Humility because I may have to start from the very basics. Empathy as I look at people struggling to learn something I already know.

If you don't understand what that code is doing, you shouldn't copy-paste it from StackOverflow.

Every line of code is the result of the accumulation of previous decisions and not simply the result of how good a programmer is. In this sense, like in a game of chess, it's possible that we end up driving ourselves into a corner where there are no good options left.

The goal is not to have small functions, but to have code that's easy to reason about. Not the same thing.

Clean code has nothing to do with writing documentation or not. Documentation tells you the why of the design decisions. Code can never tell that story.

You'll know you're doing software engineering when your primary concern is maintenance and not just making it work.

If you're competent, you don't need to be afraid of losing your job. You can easily find another one.

A codebase quality sets the standards for its programmers. A developer working in a messy codebase tends to be more careless. It's the broken window theory at play. In that sense, when we're sloppy, we're influencing our colleagues to also be that way.

Testing every single function in your code is a good way to waste your time and increase maintenance costs. Instead, define the interface of the module you'll be testing and only test against it You'll need fewer tests, less time, and your tests will be more resilient to change

Your career is as dependent on your soft skills as it is on your hard skills. Maybe even more. Take time to improve them.

Sometimes I come across the idea that TDD takes care of design concerns. I don't think it does. I find TDD can give some insights, but without design skills, it's hard to recognize them or know if they are any good. Learning design != learning TDD

We tend to overcomplicate by using too much tech (libs, frameworks, etc). And we tend to oversimplify when implementing business behaviors (e.g., overlook corner-cases). Simplicity is a great principle, but it's important to know where to pursue it.

Before coding a feature, write a list of likely changes. Design your software to make those changes easy. This simple habit will make your app 10x easier to maintain.

Your environment shapes you. Use that to your advantage.