The basic pattern is...

1) just shut up and listen and do everything their way for the first 3-6 months, bite your tongue questions about _why_ it's like that, or improvements, just learn _how_ they do it now first. then, after that, suggest your improvements once you have built up some credibility/rapport.

2) chesterton's fence - understand why things are done wrong first, then you will be able to make positive improvements. if you skip that stage, you're likely to just run into the same problems that lead to the original "wrong" choices (again).

Lots of good advice in this thread. Some minor points:

- What you learned in college was not a waste.

- When it comes to software development, everything is controversial to someone. And ever-changing.

- You need to spend a good 12-18 months acquiring situational awareness. It's pretty common in life to attain a level and discover you "know nothing" and have it feel like you're starting over from scratch. It's just an illusion, but it's also kind of true. Eg. You get your blue belt in Brazilian Jui Jujitsu, and realize there's a whole other Jedi level you weren't aware of.

- Regardless, trust in your abilities, master the fundamentals, listen to mentors, and ride the wave.

- The progress graph is not a flat line upwards. There's peaks and valleys, but as long as it trends up, you're doing good.

College-taught "best practices" and especially "software development patterns" can pretty much go straight into the trash bin when you start your real software development job. They're not inherently bad, they're just usually not relevant inside the context of whatever applications you end up working on after college. If you try to fit whatever you're doing at work into the patterns you learned in school, it will probably not be helpful. If you do find a chance to apply a pattern you learned in college to something you're doing at work, that's great, but don't try to force it when it's not fitting. It's more important to match the existing patterns inside the software project you're working on than to apply best practices and patterns you learned in school.

From the company’s perspective, your goal is to build the minimal thing that does the job to make money. Minimal can definitely include well-designed if you can clearly articulate why it will be more and reliable will help you move faster in the future. There is a constant tension between business need and building good software. Typically, engineers are the champion of good software. This can be a healthy relationship as the real world has constraints on your time. You learn to make trade offs as you go, even if they are wrong.

I like to think of learning to write software as learning to cook. You start by learning some basic skills (e.g. chopping, frying, seasoning) and you practice them through recipes. But as you really learn and become more of a chef, these are just skill sets and experiences you pull on to make the right thing in the right moment. Just as a good chef can make an amazing meal with minimal ingredients and time, good software engineers can make useful and reliable software that makes appropriate trade offs.

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.

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.

In college you're pretty much always working in a greenfield (everything is new and you don't have to worry about any legacy). In a job, you'll almost always be in a brownfield (you have to work within the existing systems and legacy to make things work).

There could have been decisions made 30 years ago when the compute landscape looked very different that are still impacting decisions today. Many times you might think something is stupid, and the person telling you about it probably thinks it's stupid too, but it's what needs to happen to keep things working without upending the whole company. The person you can both yell at about it is probably retired or dead, and likely made the right decision at the time, given what they were working with at the time.

Even with projects I've had that are relatively greenfield, eventually they have to meet the existing infrastructure. When that happens, my perfect little applications has to get hacked to bits to cover various edge cases due to a company acquisition or some section of the environment that is non-standard for whatever reason. I find this part of the job quite painful, but it's necessary for the tools to actually work.

We've brought in some vendors from time to time who are supposed to write some code for us. They follow best practices and do everything by the book. There stuff doesn't work. We end up having to throw all of it out and re-write it the second they leave. Production code is much more ugly than anyone wants it to be.

Be very careful who you learn from. There are a lot of pretenders out there and doing what they do will steer you very wrong.

I have been in corporate software for nearly 20 years. During my time there have been three completely unrelated paths: career elevation, technical brilliance, and finally seeking employment. I cannot say if this will hold true into the future, but it has been true for a long time.

First, know what you want and that will tell you who to follow. So, let's talk about this.

If you want to ascend in your career you need to focus on mastery of only two things: soft skills and conscientiousness (awareness). Career elevation ultimately means some combination of management people and/or projects. You actually have to care about the people you are managing or you can be a complete dick if you are an outsider who knows the right people at the proper levels. You also need to be masterful at management of multiple work streams, calendars, and event timelines impacting multiple teams. Imagine being in three unrelated conversations simultaneously all day long and still knowing the technical details about what is happening better than the people on each of those multiple chats/calls without exhaustion.

Technical brilliance comes from building ambitious things. If you aren't constantly building new and ever more challenging things at work then you need to be doing it outside of work. This typically has a negative impact on career progression unless you are willing to get a PhD and make a career out of research like Roy Fielding. It has a negative impact on career progression because demands a tremendous amount of time practicing on things that are not directly tied to the key goals of your employer's business goals.

Then finally there are people whose only goal is seeking employment or raises from jumping between employers. This is counter productive to both career elevation and technical skill growth, but can be good if you are a future founder and are trying to build out personal relationships. I have always thought of these people as trend followers and bottom feeders from a technical skill perspective.

all these thing are.. directions. Stuff that has emerged with practicing, empirical, not a stone-cut rules. Each may apply in 99% of cases but not at all in the other 1%.. different 1% for each one. Like, you hold a knife by the handle, not by the blade. But If the handle of a knife breaks-off, you can work with the blade alone - except very-very carefully AND you better know what you're doing.

And rules depend on values anyway. So be ware (become aware) of what the values are, in the specific spot of time and space (and organisation). And learn how to make rules out of them. (universe does not obey "laws" of physics. "laws" of physics describe universe)

Software is knowledge medium. (kind-a self-) executable one. fast-changeable. So far it needs people to (self-)change. So it is also a communication medium.. between people in space/time.. with all the trickery it entails. And ever since it existed, progressively more levels of it are generated by machines. But it's people who cause anything.

you think this all sound too philosophical? you're right, because it is. Philosophy is the most base science there is..

yeah, and beware of the possible mild shizophreny when trying to be n concepts /persons at the same time. Might be difficult to explain to others.

but do not be afraid. and. last but not least :).. have fun

p.s. see me site for more on these topics

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.

Almost certainly these people know way way more than you and a lot of knowledge is tacit knowledge and cant be explained easily.

Also don't trust anything from college that are not hard provable facts. Just don’t. Trying to learn "best practices" in college is total BS.

For example, I was already quite experienced when I worked with a specific really good older engineer. I knew he was very good but I thought he was wrong about some things and I was right. We had some debates. I kept thinking about those things for years. Now I know he was right about all those things. Yeah, he was right about everything I remember disagreeing with at the time. Took me years to figure it out.

So here is an advice to my younger self: Shut up and put in the thousands and thousands of hours first.

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.

The college knowledge isn't wasted - you just need to reframe how you use it.

Best practices like clean architecture exist to solve specific problems: making code easier to test, change, and reason about at scale. The key insight is understanding which problems they solve and when those problems actually matter.

A domain layer that depends on infrastructure might be "wrong" by the textbook, but if it's a small internal tool with 3 users and a 2-year expected lifespan, the coupling probably doesn't matter. The cost of the "correct" abstraction exceeds the benefit.

What I'd suggest: when you see code that violates a pattern you learned, ask yourself "what problem would the 'correct' approach solve here, and does that problem actually exist in this context?" Sometimes the answer is "yes, and this code will bite us later." Often it's "no, the simpler approach is fine for this use case."

The ability to make that judgment - knowing when to apply rigor and when simplicity wins - is what separates effective senior devs from people who cargo-cult patterns regardless of context.

> 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.

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 matters 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.

undefined

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.

[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!]