Ask HN: How do you deal with a boss who is stuck in the past?
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?
15 comments
A significant portion of the application has already been coded by my boss ... his many years of C experience ... I am continually refactoring his code ...
Several responses come to mind here:
1. Unless you're working for a very unusual startup, your time would be better spent writing new code rather than refactoring existing code.
2. You speak of experience as though it's a bad thing. It's possible that your boss knows what he's doing.
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.
How the the HN community deal with these situations?
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. :-)
Several responses come to mind here:
1. Unless you're working for a very unusual startup, your time would be better spent writing new code rather than refactoring existing code.
2. You speak of experience as though it's a bad thing. It's possible that your boss knows what he's doing.
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.
How the the HN community deal with these situations?
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 strongly disagree with your point #1.
I understand you want to emphasize business value and short-term returns but barring refactoring is taking it too far. Smart refactoring will pay off immediately by giving you faster turnaround for new features. And fast turnaround is a startup's edge.
I don't refactor for refactoring's sake but I do refactor every time I would benefit right away from the change. It also makes programming more interesting. Once lousy code is refactored, I can go back to solving the right problems and stop fighting with it.
I understand you want to emphasize business value and short-term returns but barring refactoring is taking it too far. Smart refactoring will pay off immediately by giving you faster turnaround for new features. And fast turnaround is a startup's edge.
I don't refactor for refactoring's sake but I do refactor every time I would benefit right away from the change. It also makes programming more interesting. Once lousy code is refactored, I can go back to solving the right problems and stop fighting with it.
I agree with cperciva's point.
There have been times I've been tempted to refactor something at Justin.TV, but most of the time it would be wasted effort:
- Sometimes you refactor a feature only to discover people aren't using it very much, and you should just scrap it.
- Other times you arrive at beautiful code and then find it needs to be discarded and completely rewritten in order to scale. If your traffic is growing exponentially, you'll find this happening a lot, no matter how hard you try to avoid it. Figuring out in advance what bottlenecks you're going to hit is often very difficult.
I think the right approach is to just write the best code you can up-front, and live with the mistakes you make. They're minor in comparison to all the other challenges a startup faces.
There have been times I've been tempted to refactor something at Justin.TV, but most of the time it would be wasted effort:
- Sometimes you refactor a feature only to discover people aren't using it very much, and you should just scrap it.
- Other times you arrive at beautiful code and then find it needs to be discarded and completely rewritten in order to scale. If your traffic is growing exponentially, you'll find this happening a lot, no matter how hard you try to avoid it. Figuring out in advance what bottlenecks you're going to hit is often very difficult.
I think the right approach is to just write the best code you can up-front, and live with the mistakes you make. They're minor in comparison to all the other challenges a startup faces.
I also agree.
If his employer coded the first iteration, he may have a better understanding of the problem space and not care if unimportant parts of the back end are sloppy. Or he may need to maintain and debug it himself, in which case refactoring is hurting the business and possibly introducing new bugs.
Those are all perfectly good reasons for development to happen HIS way. I would be really irritated if I hired someone to HELP me they started refactoring stuff instead of following my lead on what are priorities and teaching me in areas where they felt I was weak.
It sounds as if the latent issues here are power and compensation. If it is really about design approaches, try to make the system more modular and take care of building one of the modules from scratch yourself. Your employer is more likely to hand down additional responsibility once you've proven your approach in a restricted area.
If his employer coded the first iteration, he may have a better understanding of the problem space and not care if unimportant parts of the back end are sloppy. Or he may need to maintain and debug it himself, in which case refactoring is hurting the business and possibly introducing new bugs.
Those are all perfectly good reasons for development to happen HIS way. I would be really irritated if I hired someone to HELP me they started refactoring stuff instead of following my lead on what are priorities and teaching me in areas where they felt I was weak.
It sounds as if the latent issues here are power and compensation. If it is really about design approaches, try to make the system more modular and take care of building one of the modules from scratch yourself. Your employer is more likely to hand down additional responsibility once you've proven your approach in a restricted area.
1. Unless refactoring existing code makes new code easier to write, or fixes existing but broken functionality. The design of least resistance may not be obvious the first time a section of code is written, and patching around the design is bound to result in less rapid progress on features than just refactoring immediately to save time and pain later. Not all time spent writing new code is time well spent, unless there is a line-of-code performance metric that needs to be gamed in order to appear productive.
2. Experience can be a bad thing, depending on how one relies on it. It depends on whether tone relies on rote memorization and verbatim application of things learned by experience, or whether one spends time analyzing what one has learned to understand when what was learned is applicable. It is quite possible that BigCanOfTuna's complaint is legit, that his boss writes code that requires a lot of additional work and attention. Or it could be he is refactoring because of trivial stylistic things, or just to refactor. I don't know, but I'd like to give him the benefit of the doubt until he provides reason for me to believe he's just wasting time and trying to get his boss's hackles up.
3. And ultimately, you sometimes have to ask whether loyalty to your boss or the success of the company is more important, because these are not always mutually achievable goals. I may be reading too much into this, but you seem to be advocating a monochromatic, obey or leave, line of thinking.
At BigCo, it wouldn't be disastrous if you followed bad direction from a boss. You would be trading an insignificant amount of financial damage for political stability and security. I would still have a hard time doing this and would probably be quite demoralized at an employer that demanded it, but I can at least understand others aligning their priorities this way.
At a startup, unwavering loyalty to one's boss can potentially do much more damage, and deciding between financial success and political security isn't so easy, when forced to pick one or the other. The decision can become even harder when one has bought into the vision of the company, and doesn't view what they do as just a job to pay the bills; they might not be prepared to leave just to avoid a struggle. This may sound hopelessly idealistic; so be it.
Ultimately I don't know what BigCanOfTuna's workplace and boss are like, what his priorities and goals are, and whether his complaints are legit. I do think he deserves more than a cursory dismissal as just another whiny kid who has to get his way.
2. Experience can be a bad thing, depending on how one relies on it. It depends on whether tone relies on rote memorization and verbatim application of things learned by experience, or whether one spends time analyzing what one has learned to understand when what was learned is applicable. It is quite possible that BigCanOfTuna's complaint is legit, that his boss writes code that requires a lot of additional work and attention. Or it could be he is refactoring because of trivial stylistic things, or just to refactor. I don't know, but I'd like to give him the benefit of the doubt until he provides reason for me to believe he's just wasting time and trying to get his boss's hackles up.
3. And ultimately, you sometimes have to ask whether loyalty to your boss or the success of the company is more important, because these are not always mutually achievable goals. I may be reading too much into this, but you seem to be advocating a monochromatic, obey or leave, line of thinking.
At BigCo, it wouldn't be disastrous if you followed bad direction from a boss. You would be trading an insignificant amount of financial damage for political stability and security. I would still have a hard time doing this and would probably be quite demoralized at an employer that demanded it, but I can at least understand others aligning their priorities this way.
At a startup, unwavering loyalty to one's boss can potentially do much more damage, and deciding between financial success and political security isn't so easy, when forced to pick one or the other. The decision can become even harder when one has bought into the vision of the company, and doesn't view what they do as just a job to pay the bills; they might not be prepared to leave just to avoid a struggle. This may sound hopelessly idealistic; so be it.
Ultimately I don't know what BigCanOfTuna's workplace and boss are like, what his priorities and goals are, and whether his complaints are legit. I do think he deserves more than a cursory dismissal as just another whiny kid who has to get his way.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I'd like to hear your boss' point of view before jumping to judgement.
... and I think you could probably do with hearing his point of view too.
... and I think you could probably do with hearing his point of view too.
Can you give some examples of patterns that show up in your bosses code that you disagree with? Let us judge them too.
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.
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.
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.
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.
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.
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.
[deleted]
How about recommendation #7 of http://paulgraham.com/head.html ?
That's my favorite solution. I don't really care if someone else is writing code that makes me vomit as long as the interface I have to it is good enough and that it works reliably.
You will if you ever need to maintain or expand it for any reason, and the person you might otherwise call on to do so is unavailable.
[deleted]
We're talking about startups here. If that unavailable person is your co-founder you're probably screwed anyway.
That could be even worse, even if your co-founder is still available. What if your co-founder is stuck on a difficult problem, and needs a second set of eyes on the code to help him out? If he has been writing vomit-code the whole time, will you be able to help?
The point behind tip #7 was to advocate having a single person in charge of editing a component, to avoid two people making changes to the design and confusing one another. The point wasn't to suggest a total lack of caring about the other developer's work.
This smells very much of political fence building, and an overly zealous drive to strictly segment responsibility.
The point behind tip #7 was to advocate having a single person in charge of editing a component, to avoid two people making changes to the design and confusing one another. The point wasn't to suggest a total lack of caring about the other developer's work.
This smells very much of political fence building, and an overly zealous drive to strictly segment responsibility.
I think the core idea of #7 is to give a vast amount of freedom to each person in their work so they can let their brain run wild on the problem without restriction. Even if that's not what PG meant, it certainly is what I mean.
I think the other great benefit is that each person can afford to become an expert in their areas, rather than each person becoming merely competent at everything. I think 3 people who are each experts at 3 different things is more powerful than 3 people who are merely competent at the same 9 things.
I think the other great benefit is that each person can afford to become an expert in their areas, rather than each person becoming merely competent at everything. I think 3 people who are each experts at 3 different things is more powerful than 3 people who are merely competent at the same 9 things.
No problem with the idea of letting peoples' brains run wild on a problem. I suspect you and I could debate for some time about your latter point; I'd worry about things ranging from bus factors to developers who become expert in some set of things later being confined to those areas of expertise to avoid stretching their knowledge portfolio to thin, whatever that means. Maybe it is worthy of it's own conversation somewhere; maybe such a conversation already happened that I could get more insight from.
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.
Let him run/test the web app or QUIT
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.
Option-2: QUIT. There's no way you can work with these guys if you can't convince them.
I would suggest choosing the first option. Means a lot professionally.
Let him run/test the web app or QUIT
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.
Option-2: QUIT. There's no way you can work with these guys if you can't convince them.
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:
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?
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?
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 did stand your ground?
Lots of questions, but narrowing down what is important to you will help me and others give you better advice.
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?
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?
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 did stand your ground?
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.
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.
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
[deleted]
I wonder if there are two programmers in the world who can agree on the best way to solve a problem.
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.
I've been the in the same situation(s), and I just left when I couldn't handle it anymore.
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.
Someone who picked Rails doesn't sound like he's that far in the past, so yeah, maybe helping him try and get it, and compromising on when to nitpick and when not to in order to keep productivity high. Best of all, show him some rewritten code that's dramatically shorter and explain that this will make both further work maintenance easier and cheaper.