4

I work in a small company with 4 other developers. Essentially all projects are solo projects.

Our manager has a strong sales background, but can write "hello worlds".
He knows words like server, front end, back end, database.
He tells us what client has requested and it is our job to make it happen.
We report back to him about what tasks we did and how long we spent on them.

To my understanding my manager understands documentation as following:

  1. Most likely it is a wiki or a pdf, but it can be a issue description etc. It is something that can be read.
  2. Intent of documentation is to make developer's work easier. To enable them to produce business value faster.

He doesn't grasp how one can spend time on class/method names, version control, automation etc.

I see that he significantly underestimates value that clean code, automated tests and CI/CD pipelines can be for other developer. (Although as I mentioned that we have solo-projects, but we are in pain when we need to take over other projects).

So instead of reporting that I have spent a 2 days for refactoring and getting "customer didn't pay for that" look, I just tell him that I wrote documentation for a 2 days.

Is it unprofessional to keep details for myself that would otherwise put me into same battle all over again?

I wouldn't mind to share details if he asks and I will take responsibility for all the work that I have done.

  • "So instead of reporting that I have spent a 2 days for refactoring and getting "customer didn't pay for that" look, I just tell him that I wrote documentation for a 2 days." There's the risk of him finding out and blowing up "bigly" about the perceived accumulated violation of trust. – pmf Feb 2 '18 at 9:42
  • 1
    I'd refactor only on paid projects, then. If the accounting part needs a maintenance paid by a customer, then it's time to refactor it to make the maintenance easier. And the refactoring paid by the customer - he indirectly gets the benefits, after all. But refactoring 2 days outside any budget? Nah, too tough to hide. – gazzz0x2z Feb 2 '18 at 10:00
  • 12
    Yes it is unprofessional to lie to your manager. – paparazzo Feb 2 '18 at 13:37
  • 2
    Sorry if you don't see it as a lie. I bet your boss would. – paparazzo Feb 2 '18 at 14:01
  • 2
    And there is a worry about refactoring outside of process. Were code changes code reviewed, did QA sign off on them/ What steps were taken to make sure the refactoring did not change how something worked? Did you run a full set of regression tests? I would be extremely displeased if someone was making unauthorized changes to the code base. – HLGEM Feb 2 '18 at 16:43
6

I'm not sure I'd call it unprofessional because you're trying to do work you feel is necessary but in the long term it would be best for all of the developers to work on getting your manager to understand the business benefits of maintainable code.

In the short term, if you feel you have to hide it then I don't think the documentation is a good place. The documentation is more understandable by your manager than your code and if you take a long time on "documentation" it's just going to reflect poorly on you and there's also the problem if he finds out. It would be better to account for the refactoring and testing effort as part of the development of the features. Your client and manager expect quality software and this is all part of delivering that, it's not a separate task.

  • 1
    Indeed if you do not have a manager who can understand the technical aspect, you need to try to understand the business aspect. From a business point of view, working on something that already work seems extremely pointless. Even automated testing seems pointless. I mean if it work, it works right? Why spend days writing extra stuff. So tell him, from a business point of view, why you do this stuff. (speeding up development times, reduce bug and possible downtime and/or financial/reputation damage, etc). But also realize that the business aspect might sometimes trump the technical aspect. – Jeroen Feb 2 '18 at 15:18
  • +1 just include testing etc. in your definition of done of a given task. – mxyzplk Feb 3 '18 at 22:07
2

Yes it is unprofessional to lie to your managers.

You and your team have to schedule a meeting with your manager and explain him very clearly the benefits of having clean code and using tools like version control or continuous integration. You must talk about money because this is his language. Don't try to begin a technical speech with him, he speaks only in terms of time saved (less work) and efficiency (more work in less time). If you can convince him, it will be rewarding for both your team and management.

0

It is unprofessional to lie to your manager.

If you don't consider this lying, then I'd add that withholding information on what you have been doing for other 2 days is more important than a detail and is almost as bad as lying.

Your manager should always understand what it is you are working on at all times.

If you feel that refactoring is necessary, then it is your job to explain what it is and what it entails. His job is then to decide if you should be working on it or not.

0

Yes, it is unprofessional because there are several assumptions in your statement, that can only be verified by openly talking about the subject.

  1. You assume that your managers is underestimating the value of clean code.
  2. You assume that you have so much insight into your company that you can determine what is a good use of your time.
  3. You assume that the work you do will actually provide a benefit to the company.

Should you be wrong about any of these assumptions, any resulting backlash will be solely your fault.

Should you be right in your assumptions, doing work in secret still will backfire. Either you reveal what you have done and loose the trust of your manager, or you don't reveal what you have done, and you reinforce your managers assumption that his way of doing things is the right way.

If you really feel strongly about the issue, officially raise your concerns with your manager. Make a powerpoint, get some references, show steps that can be taken (and what effect these will have moneywise), and most of all, be prepared to repeat all of the above for as long as it takes to convince people.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.