[Hello! I'm a mod here - I've done some minor edits to your text to fit HN's conventions (e.g. no need to sign your posts with your username), and I added "Ask HN" to the title since that's the convention for text posts - see https://news.ycombinator.com/ask in the top tab.

Welcome to HN and if you run into any problems or have questions, you can always email us at hn@ycombinator.com. Same invitation goes to everybody of course!]

You’re going to see a lot of shitty code and practices that result in millions or more revenue.

I’d suggest you maintain your knowledge and build upon it for how to build systems that scale both organizationally and from a performance pov.

That way, you can identify which parts can be made better in the existing system without breaking it.

Ultimately, the customer really doesn’t care about the internals as long as whatever they’re using solves their immediate problem. They hold the ultimate card because they will just switch to another service provider if they’re cheaper, even if their product is worse.

So don’t become jaded. Become an expert in systems engineering and work on making things better. When you have a chance to work on a green field project, apply your knowledge there and make a foundation that will outlast your commits.

But realize that the business might toss your perfect shiny approach into the bin if it doesn’t translate into $. Don’t take it personally. Optimize for the best solution given the $ and time constraints.

For example, adding better test coverage might help reduce issues that result in headaches and lost productivity, or worse down times. Or adding a better interface to a poorly written implementation so you’re not tossing out everything just reducing the surface area for problems.

Good luck! It’s cool that you care, you’ll have fun.

Best think of "best practices" as a recommendation, maybe a strong recommendation. But the answer is rarely "yes" or "no" and often "it depends".

You should always be in a position to question your seniors, so be curious (and patient) as to why they believe their solution is sound.

You can study anything from accounting to zookeeping in college, and the real world will fall far short of the ideals ("best practices") you were taught.

What matter is that you learned a good amount of the reasoning behind those college ideals, and the real-world downsides to expect when they aren't met. Because in the real world, "how close to ideal is this solution?" is just another metric to be considered, in your searches for the least-bad real world solutions.

Think of all the lessons you have learned in life, and think of all the ways in which you haven't followed them to a tee. Now multiple that by the size of your organization. Don't overstress over things like this, it will waste your time and energy. Learn what you can improve and make attempts at what is unknown to you. Try continuously.

So different colleges have different courses, and focus on different things. So what I say next is very much YMMV.

Back when I did college there was a disconnect between what students thought college was for, and what colleges thought college was for. This was ultimately addressed in 2nd year, but it took me decades to really understand it.

As students we went to college thinking we were being taught skills to prepare us for getting jobs. Which given the endless "you need to go to college to get a decent job" mantra seems reasonable.

My college however believed that job skills are basically easily assimilated and can be quickly learned after you get the job. What makes it possible to learn fast are solid foundational skills and understandings.

For example a chef is better off learning the science of food, and honing knife skills. Once hired they can learn French recipes or Italian recipes or whatever.

In our case the complaint was about language; we learned in C and C++, with forays into assembler and Scheme. Job postings were for Cobol and Java (this was the 90s).

To show us language was irrelevant we did 10 assignments in 10 days. The same problem 10 times over, but in a different language every day. And this is pre www, so harder than it would be now. But still, turns out, really easy.

Now sure, good theory doesn't always make it into the real world in a perfect state. But I continue to be amazed at how much the fundamentals matter. 35 years later and I still ground my work in solid theory. And I notice a lot those around MD who are lacking that theory.

So, I'd say yes, lean into the theory. Yes the real world is messy, but knowing best practices, and encouraging their use always pays off in the long term.

I'll counterpoint that though that juniors always want huge sweeping changes to make it conform to their newly minted theory. Don't be that guy. It's OK to spend some time first getting to know your work system. Then you can enquire about past decisions made, and choices made. Then suggest small (and later larger) improvements.

Good luck, and have fun.

There is no the right way to building a software. Anything more complex than a hello world. And if project is large enough (google scale) - no single person really groks it fully and arrogant enough to claim knowing how it should be done.

All these clean architecture, design patterns are myths, wishful thinking, marketing memes, or someone’s successful experience overgeneralized and cargo culted at best.

There couldn’t be anything less meaningful than “best practice” idea. It encourages dangerous illusion of shared understanding. Ive seen projects bestpracticed to death.

Best from who’s point? Best for what goal? Best in what context, for what kind of team? How the bad-good scale is defined?

All you can do is patiently learn on a case by case basis, slowly building up your own intuition and style of work (ideally raising awareness the limitations of your own experience and preferences at the same time).

So basically yes, throw out all hi level theoretical concepts to trash (they have already served their purpose) and approach new projects from ground principles.

And from the fact that your craft is not the goal but only means to an end, to serve business, users, customers.

> I am, of course, in no position to question senior dev, but what do you guys think - is it really normal that all the college so called "best practices" go straight to the trash bin or am I just misunderstanding the real-work-like context?

The first thing you should do is to absolutely question your team if you think their ideas aren't good and have better suggestions.

Also stop looking at titles. They are entirely made up and meaningless in this industry. You can leave the company, found a startup as 'Founder/CEO', sell it and make yourself CEO of Product/VP or President of new company and framing that as 'career growth'.

Lastly, in a world where we have 'vibe-coders', 'AI builders' openly admitting that they have not written a single line of code before and are shipping products like sandcastles into production instead of a production-grade secure fortress, the latter being robust against security threats, made out of 'best practices' and stands the test of time and the former crumbles the moment you touch it or leave it.

I think you would want to know how to build secure software with best practices so that almost no-one can attack your software and is even also willing to pay for it.