| ▲ | sublinear a day ago | |
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. | ||