I'm working for a small startup that has chosen Rails as its development platform. A significant portion of the application has already been coded by my boss and he continues to participate in development. The problem though, is that while he means well, his many years of C experience and his lack of web application development is causing me some serious pain. I am continually refactoring his code and trying, to the best of my ability, to help him understand basic principles of Ruby style, web design patterns, and basic OOP. It's getting to the point where he is becoming very defensive about his code. How the the HN community deal with these situations?
<i>A significant portion of the application has already been coded by my boss</i> ... <i>his many years of C experience</i> ... <i>I am continually refactoring his code</i> ...<p>Several responses come to mind here:<p>1. Unless you're working for a very unusual startup, your time would be better spent writing new code rather than refactoring existing code.<p>2. You speak of experience as though it's a bad thing. It's possible that your boss knows what he's doing.<p>3. Ultimately, he's the boss. If you don't like his code and he doesn't like your suggestions, either quit or be fired.<p><i>How the the HN community deal with these situations?</i><p>I think the usual solution here is to quit and start our own companies where we don't have to put up with a boss we don't like. :-)
I'm not trying to be rude, but some of tension in this situation seems to be caused by a clash of egos as much as by any technical deficiency.<p>In my current employment, there are many procedural deficiencies as well as technical weaknesses. But one thing that really is done right is that every piece of code that is merged into the source base is peer reviewed before it is committed. I'm a strong technical member of the team, and when I started I thought quite a bit of myself. Even so, I wrote things which were potentially confusing to my teammates. Not confusing because they are incapable of understanding, but just not having the sort of clarity which would make later maintenance easier for whoever would be tasked with it.<p>When I got some hard questions in code reviews I felt a bit defensive at first, but once I swallowed my pride (tastes like crow!) and realized that I really am working with talented teammates who want us all to succeed, something clicked. I was teaching others new techniques and idioms, and they were teaching me about teamwork and the importance of writing for other humans as well as myself and the computer. I do sometimes end up doing major structural refactoring of existing code, but there's always both a good business and technical reason for it. I will say that I put in my own taste and style, but there's nothing wrong with that so long as everyone can understand it.<p>In your situation, try hard to focus on the human element here instead of just the technical element. Have some respect for the people you work with - you should all be bringing a variety of experiences and knowledge to the table. I find it hard to believe that your boss is just trapped in the past and can't understand modern web programming. The fact that he chose Ruby and Rails for this effort indicates to me that he really is open to new ideas and opportunities. Hey, it's not CGI! You certainly have an opportunity to teach here, but you also might have an opportunity to learn something. Try to sit down and have an ego-free conversation about what's going on and see if you can find a deeper reason. Especially in a small startup, resentment and defensiveness can only undermine your collective ability to succeed. You need every strength that you can call upon in such an environment.
First, you need to be nicer. Calling him "stuck in the past" and saying he doesn't get "basic principles" or "basic OOP" is needlessly insulting.<p>Second, stop blaming him. You're working for him, so obviously he has done some things right and deserves some respect. If you understand something he doesn't, it's your responsibility to explain and educate. If he is "very defensive" then perhaps you are bringing issues up in too confrontational a way.<p>Finally, be patient. Find some code that could be improved with better adherence to Ruby style, work up a changelist that cleans it up, and politely send it to your boss suggesting that you think this style has advantages, would he mind if you fixed it up? Show him how your style has advantages, point by point, and over time you will earn respect.
Can you give some examples of patterns that show up in your bosses code that you disagree with? Let us judge them too.<p>How many other developers are on this team with you and your boss? Maybe you can get them to stand up and say something too.<p>Maybe you can get together with your team and do peer reviews once a week. Try reaching out to your boss about a function/module you have written that you know needs improvement and seek his opinions on what could be done. You have to start thinking of him as a peer who is trying to help create a successful business and not as an antagonist to beautiful code.<p>Your code might be pretty, but if beautifying code takes the place of bug fixing and adding features needed to sell a product or service, it doesn't matter.
I've dealt with such a guy during a freelance project. Heck my situation was worse. The boss and his whole team of 6 members were like an expired drug who couldn't even read the docs of a framework or language and would get excited and choose a framework in an (unstable) ver 0.1 for production env. Everytime I had to tell/explain the right way of doing things I had to explain to boss+6 guys. So I hit upon two options.<p>Let him run/test the web app or QUIT<p>Option-1: LET HIM RUN/test the webapp. When errors pop he'll surely come to you. Then explain the right way to him and don't tell him anything more than what he needs to know about the error. This is peaceful and will make your boss more happy that he has a guy who's capable of doing stuff. Days later you'll be called the hero who could do things the right way (yeah like Hancock coming thru the door and not breaking a wall to get in). I chose this. So now whenever there's anything wrong they call me for help even to this day long after the project is over.<p>Option-2: QUIT. There's no way you can work with these guys if you can't convince them.<p>I would suggest choosing the first option. Means a lot professionally.
I'd have to understand more about your situation to really give any sort of advice. A few questions come to mind:<p>1. Do you believe what the startup is doing is worthwhile? How much of what keeps you there is just a need for a job, and how much is due to you wanting this job in particular?<p>2. Does his code function correctly? Is it overly fragile? Has it proved to be a maintainability problem in the past? Have others complained about your boss's coding style and defensiveness? If so, what action have they taken?<p>3. Have others commented on how you approach your boss in these instances? Do you seem overly abrasive? Do you stand your ground when he disagrees, or do you give in as soon as he does? If the latter, do you think you would face severe consequences if you <i>did</i> stand your ground?<p>Lots of questions, but narrowing down what is important to you will help me and others give you better advice.
1. Make a best effort to reach a mutual understanding. Don't assume you are right; question both sides.<p>2. (Prepare to) Move on. If your boss is truly holding things back, staying will increase your frustration while limiting your development. Been there, done that.
Whenever there is an argument over whether something should be refactored, dont call a meeting(if it happens now). Just email with pros and cons(to as much detail as possible in a digestable way). Its easier to get lost in a conversation, but with email I feel its easier to convince and once pros and cons are listed for each of them, there is really a no need for argument. Usually something will come out as an obvious solution. Just my 2c
There is more than one way to do it. Design patterns, basic principles of style, all of these are only soft recommendations, don't mistify them. Try to cope with the existing code, probably you will learn from the old fart.
Have you spoken to him about it? Explain to him how your time and in turn your startup's money both of which are precious at this point are being wasted. If he still didn't get you are in the wrong boat my friend, quit.