2

I'm a lead software developer in a new project and I have a luxury of writing something from scratch. I started with prototyping an application that slowly turns out into a bigger product. I'm an engineer and I don't have any direct reports and I like it this way.

One thing that I'm still struggling (and after years of experience I learned more about this personal flaw) is influencing others. Somehow even if I propose something good apparently I'm doing it in a wrong way, so sometimes people don't listen and it is painful for me to see things are turning out to be much worse than I thought. To give a simple example I had a hard time convincing one engineer to reduce code duplication by introducing a common module. Another time it was trying to persuade my colleague to use dependency inversion-of-control container instead of all-singleton business logic.

In my early years as an engineer I attributed those failures to other people's personalities but after seeing this pattern repeating over and over again in different circumstances with different people I come to believe that problem is actually in me and I need to change something in myself to be more persuasive. I hope that I'm not the only one who had to overcome this personal flaw and I wonder what is the good strategy of approaching this. I think I'm oftentimes seen as being maybe overly reclusive, but somehow I feel that it'd be very inefficient if not hopeless to rebuild myself into more extrovert nature, anyhow it'd be very unnatural to me.

I see that some people - and Linus is a great example - developed a very straight-to-the-point way of influencing architecture and good coding style but this approach is unlikely to flourish in the world of commercial software development, not in the big companies at the very least.

If somebody overcame this flaw in the past, I'd be glad to hear your story.

closed as too broad by gnat, scaaahu, dwizum, carrdelling, Snow Apr 19 '18 at 7:06

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    Linus Torvalds should not be used as a good example of how to influence people. The exact opposite in fact. – Philip Kendall Apr 18 '18 at 5:38
  • @PhilipKendall : isn't inspiring a way to influence people? ;) – OldPadawan Apr 18 '18 at 6:44
5

I’m a software developer and I relate to your struggle.

At my current position, I feel I’ve really begun to learn for the first time how to be persuasive with my opinions about architecture. (Partly from the example of some other great developers around me.) Here’s what I’ve learned:

1. Approach it as a fallible human.

Try your hardest not to sound like you think you have all the answers. For example, preface (even strong) opinions with “I could be wrong, but I think...” or a similar phrase.

2. Always explain your reasoning in concrete terms... and emphasize the benefits!

For example, trying to convince that coworker about inversion of control over singletons? After perhaps explaining what inversion of control is, you might say, “One of the key benefits is how this class can be tested much more thoroughly. This will make the code way less bug prone.”

And then go even more into specifics about how it will benefit that particular bit of code: “For example, see how this line does an HTTP requests? We can’t even test it or else our test suite will be making live requests. But with inversion of control we mock out the class that does the HTTP request, like this...”

3. Recognize that most architectural decisions involve a tradeoff.

Everyone has preferences and opinions. One of the beautiful things about programming is that it’s not an exact science.

Your opinion might be wiser... in some scenarios. Or it might not. Instead of looking at architectural matters as “the right choice” versus “everything else”, compare options and identify the tradeoffs.

Recognize some similar code patterns? You might argue that a reusable, abstract version of the code should be extracted so that you only have to maintain one copy. (The DRY principle.) That is, until later on when you realize different scenarios require making the “DRY” code so complex it becomes a maintenance nightmare.

Once you start to recognize tradeoffs, your conversations can stop being about what’s right and what’s wrong, and more about which side of the tradeoff makes the most sense in the given context. E.g. “We could de-duplicate all of this code, and it will be less code to maintain. But time hasn’t told yet whether each case might require specialization. What do you think the chances are we’ll need slightly different versions of this code for each scenario in the future?”

4. Let peers influence you.

Can’t convince your peers to take your opinions seriously? Do you ever take theirs seriously? I’ve learned that letting others be “wrong” and going with it helps build a culture where they become more willing to listen to you.

Plus, if they really were wrong in the first place, time will reveal that. (Perhaps with a little help from you refactoring their flawed code and kindly explaining how your refactor improves the code.)

Like any relationship, if you want to influence you have to build rapport with the other person and allow there to be some give and take.

2

I think Paul Statezny already gave a very good Answer. I´ll try to add some of my experiences.

Key is, even if you become the best influencer ever, people will not always follow your suggestions - else it would not be called influence but control.

If you realize that and step back a little you´ll see that it is often more effective to just offer your solutions as alternative approach, and let the other party decide to use them or not. This may be painful to watch, but people sometimes have to make their own errors. In time they will realize that your offers are worth considering and even actively come to you for advice.

Then, you´ll ask here how to deal with those constant interruptions and how to get people thinking for themselves ;)

I highly recommend you to read up a little bit on this topic. The best book for me is still "Peopleware" by Tom de Marco and Timothy Lister. Or more general purpose "How to make Friends and Influence People" by Dale Carnegie

  • Thanks, this is the second time I hear advice to read "Peopleware". I'll give it a try. – Alex Apr 19 '18 at 14:41
  • @Alex: That book is not entirely on topic, as it comes from a management-perspective but then most of the management-problems are essentially how to make people do things. A good read, also for those being manged, nonetheless. – Daniel Apr 19 '18 at 14:45
1

Do they really not care, or not understand that clean code make things easier for everyone? Or could it be an ego thing, they feel that you're intruding on their task and bossing them around?

For the "not caring, not understanding" part, you really need to reach a consensus. Try to arrange a meeting about this, not as you telling them how to do it, but as peers discussing best practices. Ideally prepare some concrete examples where bad code has caused problems in this company, but avoid any impression of finger-pointing. The goal is to get everyone to agree that good code quality helps everyone and is something worth making an effort for.

Then, propose that code reviews should become a standard part of your workflow, ideally using a code review tool. The important part here is that everyone's code gets reviewed, including yours, and everyone does reviews, not just you.

1

I already have the technical lead once, and let's say it straightly, some developers totally don't give a damn about doing anything else that just "makje it work" on their computers. So what I did was simple :

  • For people want to be involved in the design : involve them in the process. Make sure they have understood the design before submitting it.
  • For others : first, try to see if you can give them interest in proper design. If they don't show any interest in it, you may not involve them, forcing may just backfire by even less motivation. Just create tasks in your tools and affect them to it, that task may be purely technical (create a "common module"). As developers, their jobs is to do the tasks they're assigned, if they don't and they won't listen, get management involved. But that requires management to follow.

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