
Ask HN: How do you deal with a boss who is stuck in the past? - BigCanOfTuna
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?
======
cperciva
_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. :-)

~~~
matstc
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.

~~~
abstractbill
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.

~~~
trevelyan
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.

------
LogicHoleFlaw
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.

------
lacker
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.

------
Angostura
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.

------
zackola
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.

------
CatDancer
How about recommendation #7 of <http://paulgraham.com/head.html> ?

~~~
staunch
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.

~~~
azanar
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.

~~~
staunch
We're talking about startups here. If that unavailable person is your co-
founder you're probably screwed anyway.

~~~
azanar
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.

~~~
staunch
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.

~~~
azanar
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.

------
SingAlong
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.

------
azanar
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.

------
pasbesoin
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.

------
bigbang
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

------
Tichy
I wonder if there are two programmers in the world who can agree on the best
way to solve a problem.

------
babo
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.

------
jcapote
I've been the in the same situation(s), and I just left when I couldn't handle
it anymore.

------
sarvesh
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.

~~~
davidw
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.

