13

This topic relates to web development / software engineering; however the question can be related to other fields of expertise involving a more junior employee being more technically skilled than a senior with more experience.

I work in a team where the absolute extent of object oriented programming used is inheritence. Procedural code is placed in class methods. There is little to no typehinting in method signatures, no namespaces or interfaces - (I know, right)? - This has lead to legacy code that is hard to maintain and very difficult for new staff (juniors) to pick up and work on. Only the person who wrote it knows really how it works.

In a technical meeting on a new project, I anticipate any discussion on good OO practices (design patterns, etc.) will most likely be met with "it's too complex". Too complex being 5 classes or more.

I am polite, calm, respectful and honest, and so is the senior developer - he's a friend. As a result, he honestly believes that anything above inheritance in programming is "too complex" and I honestly believe it isn't - having written code in the past that 'just worked' as it was fully unit tested by myself and worked flawlessly on release-day, and the senior's code required a few fixes.

How can I put forward a good object oriented solution that is architecturally sound and 'makes sense' in this meeting but avoid the "it's too complicated" issue (when it really isn't, it's just he is used to coding in procedural style). I have the greatest respect for my senior, but I want to avoid the terrible, procedural code (in classes) that our legacy application now has.

How can a more junior person, with much less experience, but significantly more drive (having learned these concepts and put them into practice on multiple occasions), convince a senior that this way is the best way, with adequate respect and tact?

Improve this question
6
  • 3
    One note that may help: maybe they feel threatened by these changes (which would make you the "senior" in this particular aspect). Maybe remarking (in a subtle way) that they will still be the senior programmers (because they know of other programming issues which are unrelated/ortogonal to OOP)... and that once they get together to use OOP, they will easily catch your same level of ability so at least it won't be a disavantage.
    – SJuan76
    Jul 6, 2014 at 23:46
  • 11
    There are good programmers, and there are "clever" programmers. The combination of "clever" and OOP can be absolutely lethal (ever tried fixing C++ code that was so clever that it compiled on one C++ compiler but not on another? ) And there are many good reasons not to change a large codebase. Number one reason is the cost / benefit ratio.
    – gnasher729
    Jul 7, 2014 at 1:35
  • 2
    Have a look at this blog post
    – DJClayworth
    Jul 7, 2014 at 20:14
  • 2
    Reminder: There's nothing magic about OOP, any more than there was about Structured Programming before it. It's a good tool, but for the most part it's a formalism of best practices that can be applied in any language... and like those best practices, it isn't always the best tool, and/or isn't always worth the investment to cut over to. It sounds like there are many ways that code can be improved without having to sell them on OO and with a much, much lower investment.
    – keshlam
    Aug 3, 2015 at 13:29
  • 1
    FTR: I left and progressed my career elsewhere where I help others learn best practices and teach how to apply them pragmatically with an aim to be more open to junior's ideas and not continue the cycle described in this post. Future readers - make sure you are where you deserve to be.
    – James
    Jan 24, 2018 at 15:54

1 Answer 1

Reset to default
20

You show them.

I've been in many places where I needed to train people, and over the years I've found that talking about things doesn't cut it. People will fall back on their experiences, and in their experience Object Oriented programming (OO) makes things too complex. What you need to do is show them value.

Take a problem they have and know, and solve it the way you would. Show them how your solution provides added value over what they know. This gives them a foundation for learning, and you both a concrete basis for discussion rather than a theoretical one that many will discard out of hand.

But that isn't enough by itself (for most people). Your solution will still look too complicated because new/novel concepts are invariably more work for people than what they know. The next step is to take a relatively simple example and get them to actually use it. If you were a senior developer, I'd say to implement some OO code and let others fix bugs in it. As a junior developer, I'm not sure. For some people, trying to get them to go to a code camp or work on some hobby project may be enough interesting incentive. But you may need to just implement some features in an OO manner and make the senior work with it (bug-fixes, extensions, etc).

In my experience, people only really believe how easy/good something can be when they've actually used it themselves.

Improve this answer
4
  • 2
    ^Ultimately what this answer suggests is that rather than engaging in a meeting discussing the merits, you go off and create an example of it and then show it to them. It should be mentioned that this does run the risk of criticism for doing something you haven't been directed to, but here you can apply to mantra 'it's easier to ask for forgiveness than permission'.
    – dwjohnston
    Aug 3, 2015 at 0:01
  • 3
    So, showing them worked. After the stuff I was building worked flawlessly (tested, designed etc) and others' didn't, they started listening to me :-) Shame I had to prove it, some of us are actually being honest with our knowledge...
    – James
    Sep 29, 2015 at 12:48
  • 1
    @Jimbo: We all have to prove ourselves, otherwise others have no way to know whether we're being honest or not. It's not enough to be right.
    – Lightness Races in Orbit
    Apr 25, 2016 at 11:44
  • @LightnessRacesinOrbit You're not wrong!
    – James
    Jul 31, 2016 at 19:29

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