8

I am fairly new to a company and I was assigned to a project with only myself and one other staff member.

He has been assigned to this project longer than me, but technology-wise, I am more experienced than him. His background is in COBOL, and he is now handling C#, wpf and MSSQL - which are my bread and butter.

Now, I think I am intimidating him and making him think/feel that I'm pushing him out of the project. I don't want that. I like our teamwork and us as a team. I don't know what are his plans for his career but making him feel pushed out is not what I wanted. What I want is for us to be a solid team. I would like the opportunity to teach him C# and wpf and get him to at least the same level as I am.

How do I do that?

  • I never thought this question will attract a lot of upvotes and comments but thanks to you guys I managed to earn pts. Hehe... Anyway, update on my end, everything is going smoothly and the "intimidating" stuff is slowly decreasing thanks to the answers below I managed to ease up a bit 'coz seriously, whenever we're working, I'm tensed. And yes, I am younger than him if that's relevant – Jack Frost May 23 '18 at 13:14
9

Sounds like you've got a really good attitude already and that goes a long way!

You don't mention how much experience your co-worker does have with C# etc. I'm guessing it's not zero since you probably would have mentioned that and you've stated that they have been working on this particular project longer than you have and from the fact that he has been working in COBOL I'm guessing his general coding experience is reasonably substantial (my assumption here is based on the fact that it's relatively rare for new coders to pick up COBOL in today's industry).

It is possible though that he might find your skills somewhat intimidating in this project - especially if he is used to being the experienced one from his time working in COBOL and other technologies and while this probably has much more to do with his own internal (and to be honest pretty human) insecurities as opposed to anything you are specifically doing that doesn't mean that you aren't in a position to help make his life a bit easier.

I've been on both sides of this situation before and here's my Do's and Don'ts:

DO

  • Give him a decent amount of slack when he doesn't know something, remember that we are all beginners in a given language at some point

  • Remember that he might be inexperienced in C#, but that doesn't mean he's inexperienced in coding in general. If you have the time it may be useful to read up on the general concepts and principles of COBOL (I'm not talking about learning it, just a general overview of it) as this may help you better understand what areas he's likely to find completely new and give you some shortcuts when talking to him "feature X in C# is like feature Y in COBOL but with twist Z" that sort of thing

  • Make sure he knows that you're approachable and happy to help with anything he has a question on.

  • If he has any issues with something that you yourself found difficult when you learned point that out - "oh yeah I had a bit of a headache getting my head wrapped around lambda expressions when I was learning" or whatever. This will not only give you two some common ground but it will also help prevent him feeling stupid for not getting something that seems so easy to you.

  • Ask him things - given he's been at the business/on the project longer than you there's bound to be some domain-specific knowledge that he has that you don't. Even if you can find the information out from another source or figure it out on your own it's worth asking him.

DON'T

  • Jump in and take over.. it's probably to be expected that you'd be able to do many of the things that he is doing better and faster and it's going to be mighty tempting to just do it yourself and save the time but this is not only likely to engender the exact feelings that you are looking to avoid but it's also a false economy "teach a man to fish" and all that. If time pressures are too high in a particular instance then take the time to revisit the situation and explain it to him afterwards.

  • Fall in to that all to common developer trope of pretending to be a perfect coding god who never makes mistakes and was born with the full knowledge of every detail about a language. Let's be honest as a group we aren't good at admitting we don't know something, especially when we are new in jobs and still have that "interview" mentality that makes us want to present as perfect. If you don't know something that he asks you or that comes up in general admit that to him, let him see that you (like all of us) are still learning too.

  • 1
    "Jump in and take over" - this is exactly the reason why I posted this here... Hahaha! I think I overstepped my boundaries. Not that I can help it but, what else can I do? He was on leave for 2 days. And when he came back, everything is done and we are just waiting for the meeting. He jokingly said "nice. everything goes smoothly. I guess I can switch projects now". Then I said "NO YOU DON'T Hahaha" – Jack Frost May 22 '18 at 10:07
  • @JackFrost actually in that scenario I don't think you did anything wrong - he wasn't there to do the work so doing it yourself (assuming it needed attention before his return) wasn't a bad thing at all. I probably would take some time to run through what you did with him though, and if he makes any comments about how fast you did it just point out that you have more practice that's all. – motosubatsu May 22 '18 at 11:29
  • 1
    Nice answer. I would like to add code reviews. After each story, you review each others pull requests, make comments, learn from each other. I find this as a fast track to bring up everybody in the team to a similar level. Just don't forget to use a polite, positive language in your comments. – s.alem May 22 '18 at 12:17
  • I like this answer because it focuses on the human and relationship aspect more than the code aspect. It doesn't matter if you're teaching C# to a COBOL developer or gardening to a groundskeeper, the important part is the human relationship - putting yourself in their shoes, understanding things from their perspective, and helping them understand what you're trying to accomplish. – dwizum May 22 '18 at 13:05
  • And make sure if you do code review, that you suggest the changes, but he makes them. He won't learn and progress if you just fix everything he does. – HLGEM May 22 '18 at 14:09
1

It really depends on his mindset. If he wants to learn, no problem, but it seems he doesn't want to go back to the rookie place. If you're younger than him, it's even worse: he probably feels like he's becoming obsolete: all the things he learnt and know are now useless.

The solution might be to do some pair-programming, on some subject he might be better or feel more confident. For example, since he works on this project for longer than you, he should know it better, at least functionally.

Approach him with something like "I'm not sure how to deal with this functionality and fear I might forget something, could we work on it together ? " In this way, you can show him how you handle things technically without teaching him formally, and he can feel useful by pointing out some functional points. Thus, you're not only his professor: his experience is valued, he feels useful and not like a burden waiting to be replaced.

  • The thing is, he's really new to the technology. I even taught him how to nuget on VS2015 and the difference betwin global variable and properties. Chemistry-wise, I think we're good. Or at least that's what I think... I can't compare things from COBOL to C# since I have no idea what COBOL is but when he asks about C# or WPF, I'm always there. Its just that, sometimes, I feel like he's contented that I'm handling it now and ready to go... – Jack Frost May 22 '18 at 14:03
0

I am answering as someone who has a primarily COBOL and Mainframe background.

Let me start by saying, while all of my background is in COBOL, that does not mean I have not seen other languages. The same goes for you co-worker (lets call him Bob). Bob may not have coded in other languages for a long time, but that does not mean he will not be able to pick it up.

I am going to try and be nice about this:

He has been assigned to this project longer than me, but technology-wise, I am more experienced than him.

No. I mean maybe? but probably not. You may have more experience in this particular technology, but let me stop you right there. Just because Bob is a COBOLer does not mean you are more technically experienced than him. This assumption (IMO) is a mistake.

I am a COBOLer, and I have coded in many languages, COBOL is just my bread and butter because I work in it everyday. That being said, when called to I can also coded in JAVA (and other languages), just not as quickly.

Something to consider here:

Does Bob actually need to know C# as well as you? Maybe you were hired to cover that base and he is going to help you design the solution and pass on knowledge.

At the end of the day, I think you really need to find out what your role in this project is. If your roll is to teach Bob C#, then have at it. However, if this is not your job, then don't. You were placed on this project for a reason and it appears you may not be clear what this reason is. Talk to your supervisor and find out what exactly your role in the project is. After that, maybe offer to the supervisor that you could help Bob with C#. Do what is assigned to you and try not worry about others. If Bob needs helps, he will seek help (hopefully).

  • I was placed on this project because I am more fluent to C# and wpf than him and he openly admitted it when I joined in. Everyone else too says that this was the first time he handled VS2015 and everything is new to him. I know he's not a newbie when it comes to programming but telling him the OOP way, he's slowly but steadily learning. I am very happy about that. As for "Do what is assigned to you and try not worry about others", I'm afraid if I do that, he might leave that project which I don't want to. Worse, leave the company – Jack Frost May 23 '18 at 13:03
  • Cont: "Does Bob actually need to know C# as well as you?" - I don't know but since we're here on the same project, might as well, right? I can see from him that he wants to learn C# its just that sometimes, I feel like he's intimidated by me which I don't intend to that's why I want him to be, at the very least, the same as me. – Jack Frost May 23 '18 at 13:07
  • It might be worse for the company and this project, but it may be best him. Do your best to help him when he requests assistance, but other than that, focus on your tasks. I know if I was assigned a project in Haskell (or any other language I have not programmed in), I wouldn't want people stepping in all the time to teach me. If I haven't asked for help, I don't want it and I would hope people would respect that wish. – SaggingRufus May 23 '18 at 13:08
0

I came from a COBOL background. Started on this fancy desktop stuff with VB6. Now I do C# full-stack Microsoft stuff. So I understand his pain.

Throwing an experienced procedural programmer straight into the OO world and expecting them to understand the OO world is almost guaranteed to fail. The reverse would also apply if (for whatever reason) you were now on a COBOL project. The learning curve would be huge.

So, as someone that went through this please start slow. Divide the project up into small modules. If there is something COBOL-like such as as file import/export or reporting these would be a great place to start. Additionally, pair programming where you each take turns writing the code while the other provides feedback would give immediate feedback on programming. Who knows, you might also learn something.

-1

Answer from someone who had to transition from COBOL to more standard languages : you have a problem.

You have a problem, because most COBOL veterans are die hard, excellent programmers..... with a different mindset than the mindset needed for object-based languages.

I therefore totally agree with motobatsu that despite your local superiority(i.e. you know C# better, and you also are more fluent in the underlying), you have to stay very humble. That person has other qualities, and probably proved its capacity as problem solver in other settings.

The huge cultural difference IMHO is the use of objects & classes(they actually exist in COBOL, but are so cumbersome that their use is very uncommon, so I do assume he discovered those concepts transitionning to C#, and the shock has been hard). You'll probably have to introduce him to class-related concepts, one by one, and as gently as motobatsu says(i.e. "by the way, I learned this the hard way, but in C#, there is a kickass trick to do that kind of things : (your explanation)").

Other cultural differences(all of them are justified, btw) do include :

  • trend to store data in files instead of databases(for performance issues, and also because COBOL is literally designed around fixed-length files)
  • trend to do longer paragraphs(this is more related to the kind of programming that is done in COBOL than to the language itself), and to have more information in a single data description(while in languages as C#, it's usually wise to have more smaller classes, for reasons you know better than me)
  • trend to use global variables(as parametrized functions did appear late, and are somewhat cumbersome to use, though far easier than classes)
  • trend to use loosely linked elements, which means you can usually recompile only one element or two instead of recompiling everything. This is actually a force of COBOL, and he might be unsettled by the stronger coupling between classes and the full recompile required in modern projects(or not, but that's a possibility).

For all those cultural switches(if you are lucky, he already did some of them. If he's at trouble with the very notion of classes, leave me a comment, I'll extend this part and how he can understand this), you'll need patience, and cherry picking. remember : you are dealing with a seasoned veteran who make complex systems actually work.

EDIT : I can't help with WPF, but here is a little tutorial for properties :

  • Think of a class as a COPY with data description. And just a few more cool things we'll see later.
  • Think how cool are Level 88 to control data behaviour.
  • A property has the same role than a level 88 : give an indirect data access.
  • A property is therefore an addition to the data description. Like you add a level 88 to describe how you access to your data, you add a property to describe how you access your data as described in the class.
  • main difference : LEVEL 88 are descriptive. Properties are prescriptive. You program them with the language, instead of using a specific description like in COBOL.

something like

01 PLAYER. 05 JERSEY-NUMBER PIC 99. 88 QUARTERBACK VALUES 01 THRU 19. 88 WIDE-RECEIVER VALUES 80 TO 89.

would be translated more or less so(beware, I didn't do C# since ages, so you'll have probably to improve this a lot)

Class Player {
   private double jerseyNumber;

   public boolean isQuarterback
   {
       get { private boolean answer;
             answer = False;
             If ((jerseyNumber > 0) &&(jerseyNumber < 20)){answer = True;}
             return answer; }
   }
   public boolean isWideReceiver
   {
       get { private boolean answer;
             answer = False;
             If ((jerseyNumber > 79) &&(jerseyNumber < 90)){answer = True;}
             return answer; }
   }
   public double JerseyNumber
   {
       set JerseyNumber = value;
   }
}

In this example, you can see the power of each language : COBOL is extremely efficient for managing fixed datas, but if you need more, you're blocked. C# is more verbose but allows far more tasks to be done thanks to real language. I could easily add more controls to the JerseyNumber setter. Which I can't do ith the Level 88.

  • He does ask me things about wpf and classes (properties in particular) and I explain it to him and why is it like that. I even showed him how to do MVVM and let him do the rest so he can see and feel how to do it. I guess my most challenging part is how can I let him learn C# and wpf because he have little to nothing free time as he is getting married soon... – Jack Frost May 22 '18 at 10:36
  • @JackFrost : added a little something about properties. Something that should speak to his ear. – gazzz0x2z May 22 '18 at 11:30

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.