My manager, an enthusiastic programmer, is full of good energy to program. But he has a ... habit were he will be negligent in meetings if he can't understand the issue or argument. As a result, he screws up a couple of things.
For example:
When we were talking about the design process for REST web services, I suggested that we write down the specification of REST web services first and then start implementing.
He insisted that if we could use JAX-RS to implement the reusable component, then documentation for the specification would not be a priority. I said that reusable components would be a problem if we changed the specification of REST web service and tried to upgrade the systems which uses these components. He didn't understand or care what I was talking about.
After the JAX-RS API was released and used in other projects, he realized that something was wrong in design of the Java classes. He wanted to change the Java interface of the client API (annotated with JAX-RS) but didn't know how to upgrade systems that used it, so he decided to write a whole new API. The new API was a disaster because of lack of documentation and building with his intuition. Finally, the API of REST web service he finished did not correspond with the specification of REST web service on the server.
We modified our projects to use the new API. Our projects broke, we found the problems and he fixed them; end of story.
This may be a problem of communication (always communication), but he doesn't care about technical things that he is not familiar with - yet he used to write code intuitively.
Should I keep convincing him of better practices I am experienced with or just do my work? This is not an isolated incident.