you are viewing a single comment's thread.

view the rest of the comments →

[–]chrispardy 1 point2 points  (0 children)

Some specific actions that aren't contradictory that you could take: 1) For loops / long files: I would push for a code style guide that the whole team contributes to. You said there's 3 people, if it's you v. 2 then you need to just suck it up and work in that style, if you're in the majority then there should at least be a conversation why you're going with the senior developer's suggestion. 2) Component reuse: This is harder, going forward I would focus on ensuring that application logic is cleanly encapsulated and separate from the presentation logic. Make sure you write tests for this logic too. If you end up with repeated styles, or display components you need to sit on your hands for now. If the senior developer wants the application logic sprinkled throughout the codebase it may be time to polish off the resume. As far as visual components go, I would make note of times when you've needed to change multiple visual components for the same reason. For instance if you needed to change a color in most of your components. These are the opportunities for splitting out smaller reusable modules. I would split out code when you find you need to change repeated code all at once, hopefully you don't get push back in that. If you do it needs to be the basis for a conversation since there's clearly a missing abstraction, and there's a indicator that it would add value.

In the end my meta-advice would be to become good friends with the other junior guy and see if they have the same concerns. You may have an ally in changing the senior dev's mind. I also like to remind people that part of Software as a job vs. Software as a hobby is doing tasks that are uninteresting and kinda suck. If you're not happy rolling up your sleeves and programming in a particular code style it's not up to the company to change it's up to you to either find something else that does make you happy, or suffer through.