1

I'm a senior developer/consultant/freelancer, and I find that most positions entail being hired to "level up" the team. (A recent manager used this exact phrase.) But of course, a team of people isn't always so eager to change, or improve their poor development skills.

E.g., I was just assigned a project with a code base that has,

  • no bug tracking database,
  • 90 abandoned branches in the repo,
  • over 100 irrelevant files in the root directory (outdated mockups, excel files, random scripts, you name it),
  • the programming language version has been unmaintained for a year, getting no bug fixes or security updates,
  • > 100 dependencies on libs, many abandoned,
  • little to no tests,
  • no refactoring or cleanup of code ever done,
  • manual hacking of the database schema periodically necessary.

And so I'm frequently in the position of getting push back from the colleagues on technical issues — the person(s) responsible for the code's sorry state. They always use the right buzzwords (which is how I got suckered into the job, usually) but then rationalize why now is not the right time e.g. to start using automated acceptance tests. ("We can test the new UI manually.")

I see the behavior time and time again: cringe-worthy statements that "well, [buzzword] is the right thing to do here" matched with self-conscious strongly worded assertions that [buzzword] will never work, or not work now, or is just a fad.

For example, in the above situation, I mentioned the value of enabling us to use TDD. The colleague responsible for the repo's condition pushed back and said that he prefers BDD, but we don't have time for it. Makes me want to kill somebody.

It's pretty upsetting to me, giving me anxiety and anger. E.g., I don't want to be fired, but I also don't want to give in and act unprofessionally.

I have the recurring problem of not knowing how to respond to co-workers via email and IM. I often feel the need to have my girlfriend give me advice on how to reply, and even tell me what to say.

Thanks for any ideas.

Improve this question
9
  • 1
    Write up a proposal and send it to your manager and once he's given the green-light, send it to your juniors and enforce it (then bring up any issues in scrum (assuming you're working agile)). IF your manager doesn't give the green light then talk to him/her in person and fight your battle with reasons why you want/need to change. The snr dev should take this initative IMO. Sometimes the snr dev has the sole responsibility to push live, so you could get everyone to write documentation and do the required testing before you even consider going live.
    – hd.
    May 21, 2015 at 7:38
  • 1
    How are most of these communications happening right now? For example, e-mail is good for a lot of things, but I've never found it good for arguments. If "push back" happens in an email thread then you should switch to a better communication channel.
    – Brandin
    May 21, 2015 at 7:57
  • @Brandin we're 100% remote. Me, one dev, one manager, and then some others I don't interact with too much. The team uses Skype, Email, and newly Slack.
    – senior-dev
    May 21, 2015 at 7:59
  • 2
    @senior-dev Back-and-forth via email has a tendency to devolve pretty fast. I think both sides feel an urge to reply back without thinking too much because it's so easy. Arrange a telephone call, you need to catch them at the right moment but it can be 10x better to resolve such situations, or if not resolve at least to bring some mutual understanding.
    – Brandin
    May 21, 2015 at 8:07
  • 2
    Remote teams suffer from this much more than co-located ones, because it's so much easier for awkward juniors to resist change and awkward managers to duck responsibility, when there's little or no direct communication. Treat "100% remote" as a big red flag when looking for your next position. For now, I agree with @hd; and if your manager doesn't back you up after reasoned discussion then at least start passive work towards another job.
    – Julia Hayward
    May 21, 2015 at 9:41

1 Answer 1

Reset to default
5

I assume you have the formal authority to ask/tell people what to do and to make decisions about priorities.

You can start with specific requests to your colleagues about the low-friction issues: "Mike, I think we should clean up that repository - can you weed out the abandoned branches this week?". Maybe sit down to make a small 'how to' plan (if necessary, otherwise rely on and acknowledge their expertise), then let him do it.
Do not get into discussions about the why. You want it done for reason X.

Avoid presenting it as "something is wrong", just "I want to make our work better/easier".

If your choices pay off you will gain credibility, and you can take on more complicated changes.

As suggested in the comments: For somewhat bigger changes (e.g. writing tests) back up your requests with data ('too many regression bugs') and with manager approval. This adds external authority/credibility to your own.
But keep framing the changes as an 'us' thing that will benefit all.

For the real big changes (switching to TDD!) that require completely different ways of working you cannot do this other then getting team and management to all agree. You need team willingness to make an attack plan. I'm not going to speculate here, because I think for changes on this scale you should write a new specific question.

Now if in all this you push peoples' red buttons (e.g. a colleague constantly interprets "I (=you) want to make our work better/easier" as "I (=him) did something wrong earlier") this becomes a different issue. You will be the initial person who has to deal with this (even if it is not in your formal work description) because the colleague addresses you. How you handle that is not easy to just generically write here.
Growth in your job comes with new responsibilities and requires new skills. Try to distinguish the skills that you are missing (you already found the one "not knowing how to respond to co-workers via email and IM" and got as comments "avoid that, talk personally") and see where/how you can develop there (a course/training maybe, read some books, asks questions here on or [Programmers.se]?)

And note that judging from your text ("cringe-worthy statements", "self-conscious strongly worded assertions", "is just a fad") there definitely are some red buttons getting pushed with you. You should investigate what is happening there (with you), otherwise you will respond emotionally and add fuel to the fire.
It helps (is faster) to not do that alone. Do you have a coach/mentor? Is there some training you can follow?

-- Added 23 May (ref)

I know of one training course (The Landmark Forum) that specifically addresses those personal reactions, and since participating in it, that helps me quickly distinguish my own buttons (and deal with them).

Improve this answer
3
  • 1
    Thanks! Yes, I was referring to my own red buttons. :-)
    – senior-dev
    May 21, 2015 at 9:01
  • And actually, no, I don't have formal authority over the other developer.
    – senior-dev
    May 21, 2015 at 9:36
  • 8
    @senior-dev you really need to try to avoid assignments where you have responsibility for improving other people's work practices but not the authority to tell them what they need to be doing.
    – Carson63000
    May 21, 2015 at 9:41

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