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

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

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.

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.

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.

Don't assume senior devs know necessarily better. There's a wide range of abilities in our profession!

That being said software engineering is made of trade offs and your colleagues may be aware of the issues you mention. Maybe this was decided on purpose based on constraints at the time, or maybe it was a bad design, but it's now costly to fix.

In any case, you should probably not question them and re-assess the case when you have more experience and seniority in the company.

It's still very important to know the best practices, but it doesn't mean they have to be followed blindly in all situations.

In a world where everyone is doing stupid, insane things all the time, learning stuff the right way is rebellion. You know things most of your colleagues don't know. And that may be a threat to them, or maybe they'll ignore it. But you know what? You don't have to do what they do. When it's your turn to make something, you get to use your knowledge, skills, expertise, to make it the way you want & were taught. You get to influence the world through an experience uniquely your own. Build the world you want.

> am I just misunderstanding the real-work-like context?

You're just young, and don't know yet that adults, experienced people, etc are not necessarily doing things better or the right way. Most adults and organizations are idiots, lazy, selfish, with many competing interests and priorities. The real-world designs reflect that. Best practices really are best, but people don't like doing things best, they like doing things easiest.

The skill you're going to learn now is how to navigate a world that's held together by duct tape, and that nobody wants you to fix. The "soft skills" will help you navigate this world, and if you want, enable you to improve or change things. Start with the things that you have control over. Over time as you get bolder, try with things you don't have control over.

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.

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.

For now you need to build and ship whatever lets you keep your job and income going, but keep studying to understand how things should be despite what work will have you do. Keep deepening your understanding of SWE and form opinions on them for when its your turn to make decisions.

Every place does things differently and the best way to be productive is to follow along. It might be wrong or weird but chalk it up to experience, likely things are that way for a good reason.

The step above that is to make the simplest design that is extendable.

Often newbies doing "Best practice" results in more code that is overly complex, it splits understanding across too many functions and tries to create too many "reusable" functions that often mean the architecture is often extendable in useless ways but harder to extend when you actually need to do it.

You can usually notice when interacting with these battle scarred pieces of code, if the author is still there there is usually a story for why things are the way they are.

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.

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.

You might be working at a place with guilds.

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.

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.

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

Try to understand the quality of the software in your org as a function how likely it is to increase the amount of money the company makes.

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.

In the real work experience every project, team, and company are a little bit unique in how they respond to the requirements and politics of the moment. Everyone is trying to get something done and how purely it follows some pattern or rule is only relevant as far as it helps get the work done.

What you learned wasnt useless - it was probably very helpful for understanding or at least getting exposed to lots of concepts that you'll need. However, just like the joke about physicists and their spherical cows, the perfect algorithms and architecture rules from school aren't even close to the whole story in the trenches.

A non-engineering anecdote - had a math professor tasked with determining a fit line for and integration of a bunch of sensor data (needed the total area under the curve, classic math test problem). College me imagined trying to craft bespoke integratable functions and maybe some multi part fitting optimization but I knew my little list of memorized formulas couldn't touch this real life data so I was looking forward to the veteran approach. Math guy printed it, eyeballed to fill in the gaps with a pen, cut it out, and weighed it against a sample of "1x1" unit squares of the paper.

I was flabbergasted but the dude was so obviously right -- one off task, collected data with no clear pattern, didn't need crazy precision. The "obvious" answer took far less time than anything I had in mind and was plenty good enough for the problem at hand.

tl;dr - what you learned so far wasn't wasted it was simply the very beginning of filling up your mental toolbox

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.

This is so interesting, we were never taught about any of these things. I think there was one course titled "software engineering" (as part of a 4-year degree) that may have mentioned something similar at one point. But that's about it.

Which country did you study in? It's quite fascinating to me as it's such a surprise that there are places where these kind of "design patterns" are a core part of the degree.

> is it really normal that all the college so called "best practices" go

Most of them yes, because for most of them the answer is "it depends". And if we're going to be technical (and come on, this is computing so we should be) - then really the answer is "it depends" for every single one of them. There is not a single design pattern that applies to all coding domains. Not even "always give your variables descriptive names", and that's probably the one with the highest % of coverage.

Read on if you want my elaboration and advice.

The good thing about being a junior dev is that your decisions don't have much impact yet and nobody trusts you anyway.

The bad thing is that people trust experience way too much and will eventually start to dump more work on you and not question you. That's when the real struggle begins. This struggle doesn't stop until you retire. It's the precious nature of limited time and attention.

Other people's struggles have produced the strange code you're looking at right now. Your gut is right. Don't trust that code, but also know that your time is limited and you need to stay focused on your assigned tasks.

Stay curious and take mental note, but never make a move until you know you can without consequence. You have other stuff to do. Eventually bugs will be found or new features will be assigned to you. Only then do you have sufficient information to act. The description of the bug or feature tells you more than the code ever did. Code just tells you how. Bugs and requirements will tell you what it does and why.

So now here's my advice.

Teamwork is hard work and people can develop antisocial behavior that causes dysfunction and ultimately bad code. Nobody ever truly has the full picture or full authority. Don't trust anyone who claims to regardless of titles or years of experience. On the opposite end, some people seek solitary refuge in their work but doing the same will hold you back too. Avoid staying siloed amongst the devs, and run from the places that force you to. Don't buy into hype and always do the minimum that works. Good code is less code, but expect to write more. Your education is valuable, and your eyes don't deceive you. Don't let people get to you and it will be fine.

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