-5

I'm a junior developer and recently joined my company. There are developers and consultants. Some people are just consultants without programming knowledge. I'm working on an important project where the client is a big bank. The team is composed of me (a junior), a more experienced consultant, a software architect, and a senior developer.

Both seniors (architect and senior developer) don't like each other but they show respect most of time, however they disagree with each other constantly about technical decisions.

The architect is supposed to be the person responsible for general technical decisions and I think he isn't that person.

  1. He doesn't know how to build a project and asked for team (he built the project for first time in 7 Sprint, each sprint took 15 days)
  2. He doesn't know how to make a continuous deployment with Jenkins
  3. He doesn't know how send to Nexus Repository a new snapshot and what the settings.xml file is in Maven

How can an architect not know these things? It's very stressful to answer his development questions because I'm a junior developer and I'm sharing all my knowledge and being paid less (I'm a teaching consultant too, he doesn't have any coding skills).

He is supposed to be my technical coach and help me, not the opposite. In a specific situation, he had a meeting with a client to get the system requirements and later explain them to the team, but I needed to go out for 2 hours and didn't get part of the explanation. A few days latter, I asked him about some task, he answered one thing and I coded it. In the end, he said:

  • It's wrong
  • But this morning, you explained it this way to me
  • I didn't
  • Yes, this morning you said I needed an access database etc
  • When I explained it to the entire team you wasn't

I was very angry after that because he wouldn't admit his error and misrepresented this to the client.

The project manager doesn't like the senior developer because he is the only one who works in his home office all week and doesn't go to the company to help us (manager has asked) and he doesn't reply to the team quickly.

I like the senior because he is the only one who knows how to resolve my issues and explain things to me.

What can I do to have a better relationship with the architect? Must I ask for a better pay grade? What do I do if, in the worst case, the senior developer is fired?

closed as too broad by gnat, JazzmanJim, jimm101, IDrinkandIKnowThings, Michael Grubey Oct 10 '18 at 5:23

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.

  • 8
    Is your communication with these people in English? Maybe you are not understanding each other. – DJClayworth Aug 17 '17 at 2:38
  • 13
    software architect in general is responsible for creating and deciding the architectural design of the system. he/she does not necessarily need to know how to setup CI/CD with jenkins or send snapshots, those seems to be devops oriented tasks. – overloading Aug 17 '17 at 4:44
  • 10
    He is supposed to be my technical coach and help me, not the opposite. Are you sure? Has anyone actually said that's part of his role? Because it seems to me that the senior developer would be coaching the junior developers. – BSMP Aug 17 '17 at 5:18
  • 4
    (1) We have absolutely no way to know what an "architect" in your company is supposed to know, (2) nor can we tell you whether you should be getting a raise, (3) nor is there much use in discussing what you should do in case something happens that hasn't happened yet. I suggest to you remove those questions and stick to the remaining one - "What can I do to have a better relationship...". – Dukeling Aug 17 '17 at 6:33
  • 7
    No offense, but this seems to be more of a rant than an actual question... Could you edit this question in a more generic form ? – everyone Aug 17 '17 at 9:23
12

The job of an architect is to design the overall system flow. I could write you an architecture document for different applications without any knowledge of the underlying programming language or the development framework. And why should I have to know that? I am going to tell you with the architecture: Look, this information should be processed at that point, and this input from the user is needed now, and this file should be created after this procedure has finished.

This is basically free of any language background. How to realize this is the job of the senior developer (who will sometimes be disagreeing with the architect because some solutions might be easier to realize in a specific framework than others), and it seems the senior developer does his job well.

So don't expect the architect to have all that knowledge and teach you. Ask him questions if you think the overall flow is wrong or he designed the algorithms incorrectly, but handling Jenkins or the Nexus Repository is irrelevant to this.

1

Here are some points you could work on:

  • Get thing by writing. If you have a (technical) architect, you're supposed to developed based on a written document (or ticket in Jira). You need to cover yourself. If you see something wrong, communicate it by writing and let the decision to that architect. If he doesn't care, that's not your problem anymore.
  • As a non-technical architect he can just write what the build process should deliver, how the project must be split into modules and leave the Maven/Nexus/Jenkins details to the senior developer.
  • As you said, code is not his forte, so that means that the definition of "technical architect" in that company is not the same as yours. I think he's probably more like an functional architect (assuming he does have a knowledge in something).
  • The senior developer clearly avoids that team; this is likely because the architect that lacks technical knowledge is contesting his decisions. The fact that he works remotely forces them to get everything inby writing. He does answer your questions, so learn from him.
  • As a developer under that "architect", you don't have decision at hand, so it is not your problem. Do what you've been told (in writing!), learn from what you have done and if the project sinks, I said it again, it is not your problem and if they try to scapegoat you, you have written proof.
  • Once you have a paper trail, you can try to setup a meetings with your manager and raise your concerns about the project. Ideally your manager will like if you have ideas about how improve things (i.e : let the senior developer make the technical decisions).

If your manager don't seems like to be interested in improving things (like firing the senior developer), you may start to search for another job.

-1

An analogy may help. other people do. For example, you say the architect is responsible for "general technical decisions" and then list very detailed technical skills that he's missing. If you don't understand his role, you can't possibly learn from him.

How about if we consider home building as an analogy?

You are a carpenter. You can swing a hammer (nail gun!) a saw, tape measure, etc. Your boss is a contractor. Once upon a time she was better at your job than you are today. The architect designed the home. They don't know a lot about efficient carpentry, although a good architect DOES understand what it takes to build their designs in general. They want a house that's buildable as well as effective for the purpose. But their primary expertise lies elsewhere. What do homeowners want? How is that best translated into a design? And lots of big picture details... forces, stresses, long term quality, legal requirements, weather resistance, drainage, on and on. The big picture in general... lots of stuff that you as a carpenter don't need to worry about.

Back to you. You're a junior developer. Are you aware of the architect's expertise? It may be entirely different from what you're thinking. Ask a few good questions... such as: what does the project look like from the architect's perspective? What looks easy and difficult to them, in this project?

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