
Hello those who still read forums.
I have recently graduated from a college and started working as a junior dev (trying to consume as much knowledge from senior colleagues as I can now) and it seems that the real world is kind of a different story compared to the college practice.
In the college...
I have recently graduated from a college and started working as a junior dev (trying to consume as much knowledge from senior colleagues as I can now) and it seems that the real world is kind of a different story compared to the college practice.
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..
I think I was kind of a good at listening for the lectures, but I now am doubting about, whether it was worth learning stuff at all lol since it's so controversial out there. 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 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).
Ironically, this is similar advjce for tech leads coming into a new company, under ant why things are the way they are, ask questions, respect what came before.
Unless they chose PHP, you never have to respect anyone who chose PHP (joking…sort of)
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!I searched for the paper about the monkey experiment a few years ago. I came to the conclusion that it was false, myth. Anybody got a trustworthy reference?
I don't know of an actual paper either. It's rather just a really good anecdote that illustrates the point.
The first time I heard this was actually just in person from a trainer at work. He told this over like 10 minutes or even more as an engaging story. The monkeys went "Uuuuh banana!" each time. Until they didn't ;) That's essentially how it stuck in my mind. Through the Uuuuh banana! exclamation.
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.
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.