As an inexperienced software developer I am familiar with and have come to love the peer review process. Whenever I ask a senior developer (not my boss but still senior) about some small point of the system design somehow it becomes a debate where Im being forced to design my code by committee. How can I manage this?
Let me set the sceen: I have never done any substantial system/software design before due to the fact that all the projects I have worked on haven't been at that stage. Therefore it is pretty fair to say that Im a design novice. I have however written code from other peoples designs so I know what I like to see and What I don't. Coupled with the fact that I know my own coding style so I know roughly how I would tackle any given situation. Given that myself and my colegue have almost exactly the opposite oppinions on software development we are almost constantly arguing about it. There are valid occasions where I might have over looked some point and the comments that are made are valid.
How can I manage the situation to allow my software designs to take shape the way I envisage them yet still have meaninful insights into the pitfalls of my design from onlookers?
Edit:
From the responses given so far and upon reflection, I think that there might be a personality clash between myself and the other developer. If this is the case I can't really sit back and let it sort itself out. I know in this situation its as much my fault as it is his, so any advice on things I can do to help lessen the impact would be gratefully received.
-
I've always found that just going through the different design ideas and listing the pros and cons of each generally flushes out the better design. Remember that it isn't a competition, if you're both working for the same company then the goal is to produce the best software you can, not to spend lots of time debating optimal design details.
From tloach -
The reality is as the junior developer your word isn't going to carry as much weight as your seniors. You are a tool of the overall project.
However, if you feel your coding habit/strategy/solution is better, put a well thought-out proposal together and present it to your boss. Be technically and mentally prepared to defend your point. If it doesn't work, just keep on coding and try not to let it bother you.
From JTA -
Form your views before going to a senior member to ask for advice. Layout what you think will work and ask specific questions. Try to go through as many alternatives as you can think of so when you are challenged you've already come up with a response.
-
Your choices that I see are:
not ask for help - then you don't get the good points of things you have overlooked
live with the situation as it is - you get the good but get beaten down by the bad
attempt to separate design approval from fault checking
The only way to achieve the goals you want is to arrive at an agreement with the senior developer. If he is obstinate and refuses to help without bashing your design, it is hopeless with him.
But in any case it will require some small confrontation up front to explain the type of help you are looking for.
From Carlton Jenke -
A good developer is always willing to improve on what he previously might have thought as being a nice methodology or pattern. The discussion should be about which is the best way to do things when an alternative comes up. Experience will often show when it comes to created a scalable solution, or when a perfect solution isn't necessary due to the type of task.
Junior developers often bring new technologies to the table, and they can do a good job listing the pros and cons.
Senior developers will always carry more weight, and as a sign of respect you should acquiesce to their knowledge, at least when the battle isn't worth fighting ;)
In addition, sometimes it is better to just do (i.e., code) something than talk about it, to prove your point.
TK : Normally I try to narrow down the agreement to a smaller more precise statement e.g. So X will do Y in Z. By my senior collegue keeps trying to use it as an excuse to broaden the topic and mould the design into his way of thinking.JeeBee : There's more than one way to crack an egg, and some of them are equally good - so it's good to be consistent across a codebase if it is done in a similar way there as well.From JeeBee -
Are there just two developers in this shop? If not, why not present your design to the group instead of Mr. X? I'm not suggesting that you use that as a design by committee opportunity, but instead show your design, why it is the best design you have arrived at and ask if there are legitimate concerns with your particular design. If there are, take that input and resolve them.
Sure, there are multiple ways to solve problems but if your way doesn't have any significant problems with it, I can't imagine that any reasonable individual would balk at it.
Unless this is a personality issue - I've worked with some donkeys in my time and it wouldn't matter how much experience I had, they'd have issues with something. Make sure it isn't one of those situations.
As a junior dev, it isn't uncommon to have senior devs questioning 'solutions' to problems - this is generally a good thing, particularly when everyone leaves his ego at the door. You aren't trying to out-develop each other, at least you shouldn't be.
Again, this totally depends upon the shop you work in and the team dynamics.
TK : This is true, I can go to my boss (im in a 3 man team) but hes often busy doing managementy type activities. Unfortunatly I believe that there might be a bit of a personality clash and Im not too big to admit that at least 1/2 of that is my fault! I think I might try to include my boss from now on!itsmatt : Personality issues are typically the biggest problem to overcome in the workplace, particularly with folks who have strongly held ideas. Definitely can't hurt to include the boss. Best of luck!From itsmatt -
From your description and your comments to some responses, it sounds like the problem isn't so much "design by committee" as it is "design by the other guy." If you were part of a larger team, you'd both have other people who could help review your code to avoid possible conflicts during a group review. (Of course, if the other people end up taking sides, you'd be no better off than you are now.)
In your situation, it might not be a bad idea to see what suggestions your boss might have. I wouldn't recommend saying "Hey, X and I don't seem to get along, we fight about everything. What should I do?" Chances are he's already aware that you two have had disagreements, and he might feel that you should be able to resolve this yourselves. (I found myself in this position once, and as it happened, my boss did feel that way. Unfortunately, we could not, and I have to admit that I did not handle the situation well at all ... fortunately for me, the root cause was that the other guy had no clue what he was doing and eventually left the company once his ignorance was exposed.)
You might try to find out what it is about the other guy's style that your boss likes and why he likes it. That might make the situation a little better, and introduce you to other coding practices as a bonus.
If your boss doesn't like the other guy's style, then this could be an opportunity to reinforce that. Let your boss lead you to those conclusions: when your boss points out something he doesn't like, ask him why, and see if the way you do it is what the boss likes. Let the boss work those issues out with the other developer.
Now, if the boss likes what the other guy does and not what you do, and his way of coding isn't a way that you'd like to work, well ... there are always places to work where that would not be the case. :)
From Dave DuPlantis
0 comments:
Post a Comment