5

I am working in a small software company. We are quite small with only 3-4 full time developers. I started working there as a student assistant roughly 8 years ago and started working full time after finishing my masters in computer science.

My colleagues and me have more than once proposed various policies on how we think we could enhance the development process (e.g. code style, code reviews, etc.). We have discussed these proposals in the team and came to an agreement. Also our boss who also does development from time to time had agreed on it and introduced it as official company policy. However, he then quite often ignores these policies. E.g. commits code without code review that more than once caused a build break. When asked about it he either says it is not a big deal and does not take the complaint serious or he gets offended (we have a quite familiar atmosphere at the company).

This bothers me a lot because I don't think that is how software development should work and I also find it disrespectful. After all, however, he is the boss. Furthermore it looks like that I am the only one who really finds this annoying. From time to time also my colleagues complain about him but they seldom talk to him about it. So it might look like for him that I am the only one complaining. I also think that it is not possible to convince my colleagues to talk to him about it, since for them it seems to be not such a big deal.

What could I do about? Is it my boss who behaves wrong or am I too picky?

Improve this question
2
  • 5
    You're not being too picky. I've seen this kind of thing happen repeatedly at small software shops. If your boss, who is also a software developer, isn't on board to strengthen the development process, it's really never going to happen. You can try speaking to him again, and again he'll either accept what you have to say or get upset. Either way, even if he accepts what you have to say, he'll probably keep on doing the same thing. So I'd suggest you look for a new position elsewhere. Now you actually have an idea of what to screen for when you're interviewing for a position at another company.
    – Stephan Branczyk
    Apr 15, 2016 at 9:12
  • 1 word for ya: Gated Checkins.
    – Grimm The Opiner
    Jun 26, 2017 at 16:09

3 Answers 3

Reset to default
6

Try to look at the problem differently.

1: You lack code review in some places. 2: You know that someone breaks your builds by ignoring code quality.

In my team we have set up automatic builds, and started testing a lot more. This gives us the visual green feedback "All tests passed", and red when someone messed up. This solves 1. in most cases, because everyone wants to solve the failed tests.

For 2. you can start automatically rejecting commits that break a build. If this is a problem for the boss, you have arguments of saved money on development speed, and more stable services for your users.

If you have implemented these steps, and you still fail, there are lots of other jobs for you out there. Don't spend your energy where your voice doesn't matter.

Improve this answer
3
  • Your mitigation for 2. or similar techniques have already been proposed. My boss and also my colleagues don't like any tool support that forces them to do/not do certain things. They argue e.g. that sometimes you need to push broken code to get things done fast.
    – sigy
    Apr 15, 2016 at 10:48
  • 1
    The need to push broken code into production heavily depends on how critical your system is. The system I'm currently working on handles 4 searches a second, and if that breaks the business looses a considerably amount of revenue. That aside I think that pushing broken code to production intentionally is really bad in itself. The pure concept of broken should remove all doubt that that code needs to go into production. I think this hints at bigger underlying issues at your workplace.
    – Magnus Kirø
    Apr 15, 2016 at 11:11
  • We don't do continuous delivery. However, I get your point. And I agree.
    – sigy
    Apr 15, 2016 at 11:32
3

You're not being too picky, you're in the right, but he is the boss. You developers bear the brunt of the work, but bottom line is his if there's problems. So you do what you can to mitigate against it, you reiterate the importance. And when he disregards it, you fix it. That's your job.

The bosses job is to ensure you get paid each payday.

Improve this answer
2
  • Additional problem is, that I am the project manager of the current project he works in. If the project does not get delivered on time I will not get a bonus payment which would otherwise boost my annual salary by ~12%
    – sigy
    Apr 15, 2016 at 9:59
  • 2
    Then you should be extra vigilant, that's a BIG bonus. Have backups and all the rest, anything breaks fix it immediately. Clean up his code whenever necessary or get someone else to do it. Normal stuff to ensure a project meets deadlines satisfactorily.
    – Kilisi ♦
    Apr 15, 2016 at 10:02
0

Approach the boss with the problem and state that you are trying to fix it and need more information. Ask lots of questions so that you can understand his motivation for writing the code, even if you know how to fix it. You may learn a thing or two about why he did it that way. And then fix the bug. And then document it on your weekly report.

If the boss actually cares about team performance, he'll realize that his process violations are causing you to spend extra time fixing his bugs instead of getting your own work done, and it is causing him to waste his time explaining his code to you so that you can fix his bug. At that point he'll likely either code less, or follow the process better.

If he doesn't care about team performance, then at least you are making some progress fixing his stuff instead of no progress because of broken builds.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .