Yep, just like learning anything the intro level summaries don't reflect reality they just help you get your head around new things.
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
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).
1. also helps you after the first 3-6 months. As in, you can't change the entire code base (if reasonably large). Not even with AI helping you with the tedious bits. Consistency is something that does have value, even if it's not global and even if the consistent thing is not how you would've done/called it. The more consistency you can get, the better, because it helps tremendously. Both you and also an AI. If things are named consistently it doesn't matter whether you call a potato a potato or a potahto. It just matters that you don't call it an orange half the time.
We have a relatively good code base in this regard for example. To find things, I literally just hit the shortcut to open file/class by name, start typing the camel case for what I need and I'm usually there. Like, if I need to know what exactly we do for writing the potahto to the database, I type PoRep and I'll probably see the PotatoRepositoryImpl and I'm where I need to be. Of course not everything is roses. I might want to know what the service layer for the potahto does and start typing PotSer and I find nothing, because half the domain objects call the service layer a service and the other half calls it manager. That's OK. That's called "local consistency" and it happens as a code base grows and ages and different people with different opinions build in it and don't know enough about the magic of consistency and think they know better but can't or don't want to change the existing code base. As long as it doesn't get out of hand, it's not a big deal and you can slowly converge.
2. This is such a big one, thank you! Too many people don't believe in Chesterton's fence. They know so much better! Rewrite everything! And it is OK and good to question why the fence is there! Nothing is worse than "we do it this way because we've always done it that way!".
But also, if you never question the fence's existence, you're stuck forever. This is an anecdote I found very good in this regard.
A group of scientists places five monkeys in a room with a ladder and a banana on top. When one monkey tries to reach the banana, all are sprayed with cold water. Eventually, all of them stop attempting to climb. The scientists then place a new monkey who knows nothing of the water incident. When the new monkey sees the banana and tries to climb, the others prevent them from reaching it. Nobody gets sprayed any longer. The scientists slowly replace any of the original monkeys that were actually sprayed with water with new ones. Eventually there are no monkeys left that experienced the spraying. Yet no monkey ever even tries to get the banana any more.
So, do challenge Chesterston's fence's existence! Try to find one of the monkeys that actually got sprayed with water, so that you may understand why the fence was there. Or in other words ask the other monkeys why the eff you can't go for the banana. And if nobody can tell you other than "coz we've never done it like that", then try it. For all you know, the pesky scientist with the hose is long gone!
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.
> I am, of course, in no position to question senior dev
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.
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.
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.
When college taught you x,y,z best practices I take it they also defended them with the reasons why right? Why not to cross layers, why x pattern works for y problem. It's good to have confidence in those patterns, especially if you understand them and you must take ownership of your opinion of them. But now other people are going to have their own opinions and you're going to need to parse why they came to those conclusions and a lot of it will boil down to "this was how it was done before and it worked." At this point you might not have the power to override their decisions without making things difficult for you, so just try to follow suit.
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 decision has trade-offs. The best design is often the simplest, which can mean combining layers/responsibility in small or throw away projects.
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.
Think of the college experience as “that’s the way things are done here”. Then park it. It’s much more important to learn “that’s the way things are done here” including boring things like naming conventions or what the social/political landscape looks like to get code into production. If it’s a big place with formal practices and dedicated test teams or it’s a small place where you have to DIY those things. I would avoid as much as possible the crusty, grumbly devs who have been there forever and do nothing but complain, they’ll only hurt your career (I’ve been one of those people and was useless to everyone).
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.
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.
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.
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.
> In the college we've been taught about design patterns and all these responsibilities like domain, application, infrastructure, UI. Domain should never depend on infrastructure or application layer and so on. But the projects I got have domain that depend on infrastructure and another one where application has a reference directly to infrastructure and been told that this is correct implementation... doh..
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.
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.
Thanks!
People who've seen C and C++... I bet seen a lot :D
Some of my older colleague (not to offend anyone with larger bag of experience) have once told me that the real challenge is not the software - it's people. That kind'a stuck on me. I wish to really understand that one day.
Everything is ultimately an organizational challenge. Even something like Linux which is cool and Linus is a beast, but what is most impressive is how thousands of people can contribute to it. And there are so many flavors.
Knowing how to program has always been the lowest bar. And nobody cares about what programming languages you know because with experience and especially with AI, anyone decently good can pick up a new language or tool in days, if not hours.
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
The only way to learn real software engineering is on the job. It is not theory but practice. Assume you know nothing, and humble yourself to learn. It will take many years!
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.
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.
Quick answer: the code tends to mirror the way the project is run.
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.
> 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.
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!]
Yep, just like learning anything the intro level summaries don't reflect reality they just help you get your head around new things.
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
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).
1. also helps you after the first 3-6 months. As in, you can't change the entire code base (if reasonably large). Not even with AI helping you with the tedious bits. Consistency is something that does have value, even if it's not global and even if the consistent thing is not how you would've done/called it. The more consistency you can get, the better, because it helps tremendously. Both you and also an AI. If things are named consistently it doesn't matter whether you call a potato a potato or a potahto. It just matters that you don't call it an orange half the time.
We have a relatively good code base in this regard for example. To find things, I literally just hit the shortcut to open file/class by name, start typing the camel case for what I need and I'm usually there. Like, if I need to know what exactly we do for writing the potahto to the database, I type PoRep and I'll probably see the PotatoRepositoryImpl and I'm where I need to be. Of course not everything is roses. I might want to know what the service layer for the potahto does and start typing PotSer and I find nothing, because half the domain objects call the service layer a service and the other half calls it manager. That's OK. That's called "local consistency" and it happens as a code base grows and ages and different people with different opinions build in it and don't know enough about the magic of consistency and think they know better but can't or don't want to change the existing code base. As long as it doesn't get out of hand, it's not a big deal and you can slowly converge.
2. This is such a big one, thank you! Too many people don't believe in Chesterton's fence. They know so much better! Rewrite everything! And it is OK and good to question why the fence is there! Nothing is worse than "we do it this way because we've always done it that way!".
But also, if you never question the fence's existence, you're stuck forever. This is an anecdote I found very good in this regard.
So, do challenge Chesterston's fence's existence! Try to find one of the monkeys that actually got sprayed with water, so that you may understand why the fence was there. Or in other words ask the other monkeys why the eff you can't go for the banana. And if nobody can tell you other than "coz we've never done it like that", then try it. For all you know, the pesky scientist with the hose is long gone!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.
> I am, of course, in no position to question senior dev
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.
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.
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.
When college taught you x,y,z best practices I take it they also defended them with the reasons why right? Why not to cross layers, why x pattern works for y problem. It's good to have confidence in those patterns, especially if you understand them and you must take ownership of your opinion of them. But now other people are going to have their own opinions and you're going to need to parse why they came to those conclusions and a lot of it will boil down to "this was how it was done before and it worked." At this point you might not have the power to override their decisions without making things difficult for you, so just try to follow suit.
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 decision has trade-offs. The best design is often the simplest, which can mean combining layers/responsibility in small or throw away projects.
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.
Think of the college experience as “that’s the way things are done here”. Then park it. It’s much more important to learn “that’s the way things are done here” including boring things like naming conventions or what the social/political landscape looks like to get code into production. If it’s a big place with formal practices and dedicated test teams or it’s a small place where you have to DIY those things. I would avoid as much as possible the crusty, grumbly devs who have been there forever and do nothing but complain, they’ll only hurt your career (I’ve been one of those people and was useless to everyone).
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.
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.
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.
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.
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.
> In the college we've been taught about design patterns and all these responsibilities like domain, application, infrastructure, UI. Domain should never depend on infrastructure or application layer and so on. But the projects I got have domain that depend on infrastructure and another one where application has a reference directly to infrastructure and been told that this is correct implementation... doh..
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.
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.
Thanks! People who've seen C and C++... I bet seen a lot :D Some of my older colleague (not to offend anyone with larger bag of experience) have once told me that the real challenge is not the software - it's people. That kind'a stuck on me. I wish to really understand that one day.
Everything is ultimately an organizational challenge. Even something like Linux which is cool and Linus is a beast, but what is most impressive is how thousands of people can contribute to it. And there are so many flavors.
Knowing how to program has always been the lowest bar. And nobody cares about what programming languages you know because with experience and especially with AI, anyone decently good can pick up a new language or tool in days, if not hours.
We teach software engineering like it's a craft. And some of it is. But 95% of it is not. 95% of it is in service of making money.
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.
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
The only way to learn real software engineering is on the job. It is not theory but practice. Assume you know nothing, and humble yourself to learn. It will take many years!
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.
Build stuff faster than you can worry about it.
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.
Quick answer: the code tends to mirror the way the project is run.
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.
> 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.
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!]
Thanks, dang!