Mixing
![Handed notice in at work & now have interview with a company owned by original employer! [closed]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjbpfN9tAutmK93bJRC3ZoROZzi2TJDms5n8_qJuhgE0a9b52OOHayv3NGT8igAdFL7byXNst-_1DZK5SjrIJ28_6RQPUpBROqMs5s6jo-ZsjX8kjDwfxJufIitH3TaQRXWaGSQKRQib-f/s72-c/1.jpg)
What shall I expect from an architect? [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
-7
down vote
favorite
I am working for a huge multinational software firm, and have been on job for slightly over 1 year.
The architect of my team has 15+ years of experience.
Th architect:
- Gets off from work at 3pm. (The majority of my team start late & finish late)
- Refuses to do necessary designs for the project, such as drawing diagrams or providing documentations. ("I couldn't spend all my day drawing pictures")
- Doesn't write code. Struggling to provide unit tests to a block of code he copied from an example project.
- Showed no interest in trying out new technologies, even if they are potentially valuable to the team. We have to write PoCs for him.
Our manager shows interest in listening to our thoughts during meetings. I couldn't help but call out on some of these lunacies. He would get noticeably aggressive and impatient. My manager would then engage in a discussion with me, and the architect would say stuff like is this worth discussing for so long.
EDIT: I tried to make the question more specific. I am expecting the architect to:
- Understand the basic interaction of classes/components of the current implementation.
- Read the code.
- Provide guidance and mentorship to the juniors. Challenge our implementations.
- Hold code review sessions,
- Design the architecture (class/component) from a grand view.
- Be curious about newly emerged frameworks/technologies, and provide a PoC to test them out if he thinks it's useful to our project.
- Do not say because this is a project of small scope so there's no design necessary. We implement it as easy as possible, even breaking established software principles.
Am I expecting too much from an architect?
EDIT AGAIN: I asked partially because our manager (the APO I mentioned) actually did point 3,4, to some extent 5, 6 (although not directly writing PoCs, we developers did that, as he brought these new techs up to us). I don't know if they are indeed the responsibilities of a manager, or should rather be the responsibilities of architects, if they have to be done anyways?
Regarding point 1 and 2, please do correct me if I'm wrong, but an architect should understand the architecture of the project inside-out? I am not exactly sure if he/she can if the architecture was not envisioned by him/herself, and also without thoroughly reading our code.
professionalism
edited Aug 7 at 0:17
mcknz
15.7k55468
asked Aug 6 at 14:08
FizzyTidus
12
closed as off-topic by Mister Positive, gnat, paparazzo, DarkCygnus, mcknz Aug 6 at 17:10
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions require a goal that we can address. Rather than explaining the difficulties of your situation, explain what you want to do to make it better. For more information, see this meta post." – gnat, paparazzo, DarkCygnus, mcknz
add a comment |Â
up vote
-7
down vote
favorite
I am working for a huge multinational software firm, and have been on job for slightly over 1 year.
The architect of my team has 15+ years of experience.
Th architect:
- Gets off from work at 3pm. (The majority of my team start late & finish late)
- Refuses to do necessary designs for the project, such as drawing diagrams or providing documentations. ("I couldn't spend all my day drawing pictures")
- Doesn't write code. Struggling to provide unit tests to a block of code he copied from an example project.
- Showed no interest in trying out new technologies, even if they are potentially valuable to the team. We have to write PoCs for him.
Our manager shows interest in listening to our thoughts during meetings. I couldn't help but call out on some of these lunacies. He would get noticeably aggressive and impatient. My manager would then engage in a discussion with me, and the architect would say stuff like is this worth discussing for so long.
EDIT: I tried to make the question more specific. I am expecting the architect to:
- Understand the basic interaction of classes/components of the current implementation.
- Read the code.
- Provide guidance and mentorship to the juniors. Challenge our implementations.
- Hold code review sessions,
- Design the architecture (class/component) from a grand view.
- Be curious about newly emerged frameworks/technologies, and provide a PoC to test them out if he thinks it's useful to our project.
- Do not say because this is a project of small scope so there's no design necessary. We implement it as easy as possible, even breaking established software principles.
Am I expecting too much from an architect?
EDIT AGAIN: I asked partially because our manager (the APO I mentioned) actually did point 3,4, to some extent 5, 6 (although not directly writing PoCs, we developers did that, as he brought these new techs up to us). I don't know if they are indeed the responsibilities of a manager, or should rather be the responsibilities of architects, if they have to be done anyways?
Regarding point 1 and 2, please do correct me if I'm wrong, but an architect should understand the architecture of the project inside-out? I am not exactly sure if he/she can if the architecture was not envisioned by him/herself, and also without thoroughly reading our code.
professionalism
edited Aug 7 at 0:17
mcknz
15.7k55468
asked Aug 6 at 14:08
FizzyTidus
12
closed as off-topic by Mister Positive, gnat, paparazzo, DarkCygnus, mcknz Aug 6 at 17:10
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions require a goal that we can address. Rather than explaining the difficulties of your situation, explain what you want to do to make it better. For more information, see this meta post." – gnat, paparazzo, DarkCygnus, mcknz
This seems a bit broad, without a goal we can address. Can you consider narrowing this down a bit?
– Mister Positive
Aug 6 at 14:19
What is your position? "I couldn't help but call out on some of these lunacies." - What does this mean? Did you voice your concerns to your manager about the architect?
– Brandin
Aug 7 at 5:44
add a comment |Â
up vote
-7
down vote
favorite
up vote
-7
down vote
favorite
I am working for a huge multinational software firm, and have been on job for slightly over 1 year.
The architect of my team has 15+ years of experience.
Th architect:
- Gets off from work at 3pm. (The majority of my team start late & finish late)
- Refuses to do necessary designs for the project, such as drawing diagrams or providing documentations. ("I couldn't spend all my day drawing pictures")
- Doesn't write code. Struggling to provide unit tests to a block of code he copied from an example project.
- Showed no interest in trying out new technologies, even if they are potentially valuable to the team. We have to write PoCs for him.
Our manager shows interest in listening to our thoughts during meetings. I couldn't help but call out on some of these lunacies. He would get noticeably aggressive and impatient. My manager would then engage in a discussion with me, and the architect would say stuff like is this worth discussing for so long.
EDIT: I tried to make the question more specific. I am expecting the architect to:
- Understand the basic interaction of classes/components of the current implementation.
- Read the code.
- Provide guidance and mentorship to the juniors. Challenge our implementations.
- Hold code review sessions,
- Design the architecture (class/component) from a grand view.
- Be curious about newly emerged frameworks/technologies, and provide a PoC to test them out if he thinks it's useful to our project.
- Do not say because this is a project of small scope so there's no design necessary. We implement it as easy as possible, even breaking established software principles.
Am I expecting too much from an architect?
EDIT AGAIN: I asked partially because our manager (the APO I mentioned) actually did point 3,4, to some extent 5, 6 (although not directly writing PoCs, we developers did that, as he brought these new techs up to us). I don't know if they are indeed the responsibilities of a manager, or should rather be the responsibilities of architects, if they have to be done anyways?
Regarding point 1 and 2, please do correct me if I'm wrong, but an architect should understand the architecture of the project inside-out? I am not exactly sure if he/she can if the architecture was not envisioned by him/herself, and also without thoroughly reading our code.
professionalism
edited Aug 7 at 0:17
mcknz
15.7k55468
asked Aug 6 at 14:08
FizzyTidus
12
I am working for a huge multinational software firm, and have been on job for slightly over 1 year.
The architect of my team has 15+ years of experience.
Th architect:
- Gets off from work at 3pm. (The majority of my team start late & finish late)
- Refuses to do necessary designs for the project, such as drawing diagrams or providing documentations. ("I couldn't spend all my day drawing pictures")
- Doesn't write code. Struggling to provide unit tests to a block of code he copied from an example project.
- Showed no interest in trying out new technologies, even if they are potentially valuable to the team. We have to write PoCs for him.
Our manager shows interest in listening to our thoughts during meetings. I couldn't help but call out on some of these lunacies. He would get noticeably aggressive and impatient. My manager would then engage in a discussion with me, and the architect would say stuff like is this worth discussing for so long.
EDIT: I tried to make the question more specific. I am expecting the architect to:
- Understand the basic interaction of classes/components of the current implementation.
- Read the code.
- Provide guidance and mentorship to the juniors. Challenge our implementations.
- Hold code review sessions,
- Design the architecture (class/component) from a grand view.
- Be curious about newly emerged frameworks/technologies, and provide a PoC to test them out if he thinks it's useful to our project.
- Do not say because this is a project of small scope so there's no design necessary. We implement it as easy as possible, even breaking established software principles.
Am I expecting too much from an architect?
EDIT AGAIN: I asked partially because our manager (the APO I mentioned) actually did point 3,4, to some extent 5, 6 (although not directly writing PoCs, we developers did that, as he brought these new techs up to us). I don't know if they are indeed the responsibilities of a manager, or should rather be the responsibilities of architects, if they have to be done anyways?
Regarding point 1 and 2, please do correct me if I'm wrong, but an architect should understand the architecture of the project inside-out? I am not exactly sure if he/she can if the architecture was not envisioned by him/herself, and also without thoroughly reading our code.
professionalism
edited Aug 7 at 0:17
mcknz
15.7k55468
asked Aug 6 at 14:08
FizzyTidus
12
edited Aug 7 at 0:17
mcknz
15.7k55468
edited Aug 7 at 0:17
mcknz
15.7k55468
edited Aug 7 at 0:17
mcknz
15.7k55468
15.7k55468
asked Aug 6 at 14:08
FizzyTidus
12
asked Aug 6 at 14:08
FizzyTidus
12
asked Aug 6 at 14:08
FizzyTidus
12
12
closed as off-topic by Mister Positive, gnat, paparazzo, DarkCygnus, mcknz Aug 6 at 17:10
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions require a goal that we can address. Rather than explaining the difficulties of your situation, explain what you want to do to make it better. For more information, see this meta post." – gnat, paparazzo, DarkCygnus, mcknz
closed as off-topic by Mister Positive, gnat, paparazzo, DarkCygnus, mcknz Aug 6 at 17:10
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions require a goal that we can address. Rather than explaining the difficulties of your situation, explain what you want to do to make it better. For more information, see this meta post." – gnat, paparazzo, DarkCygnus, mcknz
This seems a bit broad, without a goal we can address. Can you consider narrowing this down a bit?
– Mister Positive
Aug 6 at 14:19
What is your position? "I couldn't help but call out on some of these lunacies." - What does this mean? Did you voice your concerns to your manager about the architect?
– Brandin
Aug 7 at 5:44
add a comment |Â
This seems a bit broad, without a goal we can address. Can you consider narrowing this down a bit?
– Mister Positive
Aug 6 at 14:19
What is your position? "I couldn't help but call out on some of these lunacies." - What does this mean? Did you voice your concerns to your manager about the architect?
– Brandin
Aug 7 at 5:44
This seems a bit broad, without a goal we can address. Can you consider narrowing this down a bit?
– Mister Positive
Aug 6 at 14:19
This seems a bit broad, without a goal we can address. Can you consider narrowing this down a bit?
– Mister Positive
Aug 6 at 14:19
What is your position? "I couldn't help but call out on some of these lunacies." - What does this mean? Did you voice your concerns to your manager about the architect?
– Brandin
Aug 7 at 5:44
What is your position? "I couldn't help but call out on some of these lunacies." - What does this mean? Did you voice your concerns to your manager about the architect?
– Brandin
Aug 7 at 5:44
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
6
down vote
accepted
Your question is "should i keep voicing my thoughts".
The answer is yes. But do it politely.
There is nothing wrong with engaging in a software team and proposing new ideas and technologies, and it is a very rare and poor manager who does not support this.
The is something wrong if you go in thinking something is "lunacy" and then attack the person aggressively. You'll just make the architect dislike you, which will just make life more difficult. You use the word "lunacy" in your question, among other more aggressive terms.
The majority of your question, however, reads poorly. You express that you feel the architect is incompetent, effectively. However a software architect cares about very different things from a software engineer.
Architects care about how the product fits into the existing ecosystem. They understand how the various bits of data flow from one end of an org to another, and how to best ensure data is reliable and available.
Understand that you shouldn't be attacking the architect, because they're worried about different things than you, and they have different skillsets.
As a rule of thumb:
You need to learn to be polite and work on the problem, not the person.
After all, you're all there to find solutions to the same problem.
As for your new points:
- Understand the basic interaction of classes/components of the current implementation.
Why do you want this? If you want it will help the team, then raise it to the manager to start having training sessions about the design/implementation.
- Read the code.
Why do you want this? If the person isn't a developer then they have no real gain from reading the code.
- Provide guidance and mentorship to the juniors. Challenge our implementations.
Ok, I understand this. But you need to ask this person and their manager to create time - say an hour or two or so a week - to do this.
- Hold code review sessions,
Why do you want this? This is highly dependent on the team and what the manager of the team decides. In some teams, for some projects, code review sessions are great. In other teams, a couple of leads pushing "bad" code back to get fixed online is great.
- Design the architecture (class/component) from a grand view.
Why do you think they are not? What does "grand view" mean? And grand views take time - look, I myself prefer simple code that works that is then, as it is upgraded, fixed with better design patterns. Design patterns are heavy. There's no point having a factory pattern thing if it only makes one thing in one way. Add the pattern in when you need to make it two or, preferably, three ways.
- Be curious about newly emerged frameworks/technologies, and provide a PoC to test them out if he thinks it's useful to our project.
Hm. Teams are mostly paid to execute business tasks, not investigate emergent tech. If you want to investigate emergent tech, then do it on your own time. Make the PoC on your own time.
- Do not say because this is a project of small scope so there's no design necessary. We implement it as easy as possible, even breaking established software principles.
Disagree here - if a project is very small, or the lifetime is going to be short, or you're unsure if anybody needs the project, then it's better to make it small and simple and fast. You can make it fancy later on when there's a need.
Just because a design pattern exists doesn't mean it has to be used all the time. McDonald's makes more money than the best gourmet burger joint in the world - because they're fast and cheap. I'm not saying they're good, and heck I don't eat their food - but while it's nice to know how to make a fancy burger, it's even nicer to make money.
answered Aug 6 at 14:29
bharal
11.4k22453
I guess you are right. It seems like I may have too much expectations for an architect, and that comes down as some sort of a disappointment to me when things don't work out as I hope. But what would be the best course of action when you subconsciously think the architect (or a more senior colleague generically) gives out poor decisions based on an incomplete understanding (of course from my perspective) of the implementation details of the project? I didn't realize my question would sound like a rant until I finished writing it.
– FizzyTidus
Aug 6 at 15:34
Maybe I'm affected too deeply by the methodology that the only way to go fast is to go well. Thank you so very much for your time and input, and sorry that my question is downvoted to dirt. Your answer deserves to be read by more people.
– FizzyTidus
Aug 6 at 17:36
1
@FizzyTidus, As old technologies mature, those technologies are better documented, there is better training for them, and there are better samples and case studies. This tends to reduce the need for software architects in general, especially if those architects don't know (or do not remember) how to code and/or refuse to learn new emergent technologies. And this is actually ok in a large multinational software company. The saying "if it ain't broken, don't fix it" applies here. If you do not like that environment, I'd suggest that you join a (serious) startup.
– Stephan Branczyk
Aug 6 at 21:19
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
accepted
Your question is "should i keep voicing my thoughts".
The answer is yes. But do it politely.
There is nothing wrong with engaging in a software team and proposing new ideas and technologies, and it is a very rare and poor manager who does not support this.
The is something wrong if you go in thinking something is "lunacy" and then attack the person aggressively. You'll just make the architect dislike you, which will just make life more difficult. You use the word "lunacy" in your question, among other more aggressive terms.
The majority of your question, however, reads poorly. You express that you feel the architect is incompetent, effectively. However a software architect cares about very different things from a software engineer.
Architects care about how the product fits into the existing ecosystem. They understand how the various bits of data flow from one end of an org to another, and how to best ensure data is reliable and available.
Understand that you shouldn't be attacking the architect, because they're worried about different things than you, and they have different skillsets.
As a rule of thumb:
You need to learn to be polite and work on the problem, not the person.
After all, you're all there to find solutions to the same problem.
As for your new points:
- Understand the basic interaction of classes/components of the current implementation.
Why do you want this? If you want it will help the team, then raise it to the manager to start having training sessions about the design/implementation.
- Read the code.
Why do you want this? If the person isn't a developer then they have no real gain from reading the code.
- Provide guidance and mentorship to the juniors. Challenge our implementations.
Ok, I understand this. But you need to ask this person and their manager to create time - say an hour or two or so a week - to do this.
- Hold code review sessions,
Why do you want this? This is highly dependent on the team and what the manager of the team decides. In some teams, for some projects, code review sessions are great. In other teams, a couple of leads pushing "bad" code back to get fixed online is great.
- Design the architecture (class/component) from a grand view.
Why do you think they are not? What does "grand view" mean? And grand views take time - look, I myself prefer simple code that works that is then, as it is upgraded, fixed with better design patterns. Design patterns are heavy. There's no point having a factory pattern thing if it only makes one thing in one way. Add the pattern in when you need to make it two or, preferably, three ways.
- Be curious about newly emerged frameworks/technologies, and provide a PoC to test them out if he thinks it's useful to our project.
Hm. Teams are mostly paid to execute business tasks, not investigate emergent tech. If you want to investigate emergent tech, then do it on your own time. Make the PoC on your own time.
- Do not say because this is a project of small scope so there's no design necessary. We implement it as easy as possible, even breaking established software principles.
Disagree here - if a project is very small, or the lifetime is going to be short, or you're unsure if anybody needs the project, then it's better to make it small and simple and fast. You can make it fancy later on when there's a need.
Just because a design pattern exists doesn't mean it has to be used all the time. McDonald's makes more money than the best gourmet burger joint in the world - because they're fast and cheap. I'm not saying they're good, and heck I don't eat their food - but while it's nice to know how to make a fancy burger, it's even nicer to make money.
answered Aug 6 at 14:29
bharal
11.4k22453
I guess you are right. It seems like I may have too much expectations for an architect, and that comes down as some sort of a disappointment to me when things don't work out as I hope. But what would be the best course of action when you subconsciously think the architect (or a more senior colleague generically) gives out poor decisions based on an incomplete understanding (of course from my perspective) of the implementation details of the project? I didn't realize my question would sound like a rant until I finished writing it.
– FizzyTidus
Aug 6 at 15:34
Maybe I'm affected too deeply by the methodology that the only way to go fast is to go well. Thank you so very much for your time and input, and sorry that my question is downvoted to dirt. Your answer deserves to be read by more people.
– FizzyTidus
Aug 6 at 17:36
1
@FizzyTidus, As old technologies mature, those technologies are better documented, there is better training for them, and there are better samples and case studies. This tends to reduce the need for software architects in general, especially if those architects don't know (or do not remember) how to code and/or refuse to learn new emergent technologies. And this is actually ok in a large multinational software company. The saying "if it ain't broken, don't fix it" applies here. If you do not like that environment, I'd suggest that you join a (serious) startup.
– Stephan Branczyk
Aug 6 at 21:19
add a comment |Â
up vote
6
down vote
accepted
Your question is "should i keep voicing my thoughts".
The answer is yes. But do it politely.
There is nothing wrong with engaging in a software team and proposing new ideas and technologies, and it is a very rare and poor manager who does not support this.
The is something wrong if you go in thinking something is "lunacy" and then attack the person aggressively. You'll just make the architect dislike you, which will just make life more difficult. You use the word "lunacy" in your question, among other more aggressive terms.
The majority of your question, however, reads poorly. You express that you feel the architect is incompetent, effectively. However a software architect cares about very different things from a software engineer.
Architects care about how the product fits into the existing ecosystem. They understand how the various bits of data flow from one end of an org to another, and how to best ensure data is reliable and available.
Understand that you shouldn't be attacking the architect, because they're worried about different things than you, and they have different skillsets.
As a rule of thumb:
You need to learn to be polite and work on the problem, not the person.
After all, you're all there to find solutions to the same problem.
As for your new points:
- Understand the basic interaction of classes/components of the current implementation.
Why do you want this? If you want it will help the team, then raise it to the manager to start having training sessions about the design/implementation.
- Read the code.
Why do you want this? If the person isn't a developer then they have no real gain from reading the code.
- Provide guidance and mentorship to the juniors. Challenge our implementations.
Ok, I understand this. But you need to ask this person and their manager to create time - say an hour or two or so a week - to do this.
- Hold code review sessions,
Why do you want this? This is highly dependent on the team and what the manager of the team decides. In some teams, for some projects, code review sessions are great. In other teams, a couple of leads pushing "bad" code back to get fixed online is great.
- Design the architecture (class/component) from a grand view.
Why do you think they are not? What does "grand view" mean? And grand views take time - look, I myself prefer simple code that works that is then, as it is upgraded, fixed with better design patterns. Design patterns are heavy. There's no point having a factory pattern thing if it only makes one thing in one way. Add the pattern in when you need to make it two or, preferably, three ways.
- Be curious about newly emerged frameworks/technologies, and provide a PoC to test them out if he thinks it's useful to our project.
Hm. Teams are mostly paid to execute business tasks, not investigate emergent tech. If you want to investigate emergent tech, then do it on your own time. Make the PoC on your own time.
- Do not say because this is a project of small scope so there's no design necessary. We implement it as easy as possible, even breaking established software principles.
Disagree here - if a project is very small, or the lifetime is going to be short, or you're unsure if anybody needs the project, then it's better to make it small and simple and fast. You can make it fancy later on when there's a need.
Just because a design pattern exists doesn't mean it has to be used all the time. McDonald's makes more money than the best gourmet burger joint in the world - because they're fast and cheap. I'm not saying they're good, and heck I don't eat their food - but while it's nice to know how to make a fancy burger, it's even nicer to make money.
answered Aug 6 at 14:29
bharal
11.4k22453
I guess you are right. It seems like I may have too much expectations for an architect, and that comes down as some sort of a disappointment to me when things don't work out as I hope. But what would be the best course of action when you subconsciously think the architect (or a more senior colleague generically) gives out poor decisions based on an incomplete understanding (of course from my perspective) of the implementation details of the project? I didn't realize my question would sound like a rant until I finished writing it.
– FizzyTidus
Aug 6 at 15:34
Maybe I'm affected too deeply by the methodology that the only way to go fast is to go well. Thank you so very much for your time and input, and sorry that my question is downvoted to dirt. Your answer deserves to be read by more people.
– FizzyTidus
Aug 6 at 17:36
1
@FizzyTidus, As old technologies mature, those technologies are better documented, there is better training for them, and there are better samples and case studies. This tends to reduce the need for software architects in general, especially if those architects don't know (or do not remember) how to code and/or refuse to learn new emergent technologies. And this is actually ok in a large multinational software company. The saying "if it ain't broken, don't fix it" applies here. If you do not like that environment, I'd suggest that you join a (serious) startup.
– Stephan Branczyk
Aug 6 at 21:19
add a comment |Â
up vote
6
down vote
accepted
up vote
6
down vote
accepted
Your question is "should i keep voicing my thoughts".
The answer is yes. But do it politely.
There is nothing wrong with engaging in a software team and proposing new ideas and technologies, and it is a very rare and poor manager who does not support this.
The is something wrong if you go in thinking something is "lunacy" and then attack the person aggressively. You'll just make the architect dislike you, which will just make life more difficult. You use the word "lunacy" in your question, among other more aggressive terms.
The majority of your question, however, reads poorly. You express that you feel the architect is incompetent, effectively. However a software architect cares about very different things from a software engineer.
Architects care about how the product fits into the existing ecosystem. They understand how the various bits of data flow from one end of an org to another, and how to best ensure data is reliable and available.
Understand that you shouldn't be attacking the architect, because they're worried about different things than you, and they have different skillsets.
As a rule of thumb:
You need to learn to be polite and work on the problem, not the person.
After all, you're all there to find solutions to the same problem.
As for your new points:
- Understand the basic interaction of classes/components of the current implementation.
Why do you want this? If you want it will help the team, then raise it to the manager to start having training sessions about the design/implementation.
- Read the code.
Why do you want this? If the person isn't a developer then they have no real gain from reading the code.
- Provide guidance and mentorship to the juniors. Challenge our implementations.
Ok, I understand this. But you need to ask this person and their manager to create time - say an hour or two or so a week - to do this.
- Hold code review sessions,
Why do you want this? This is highly dependent on the team and what the manager of the team decides. In some teams, for some projects, code review sessions are great. In other teams, a couple of leads pushing "bad" code back to get fixed online is great.
- Design the architecture (class/component) from a grand view.
Why do you think they are not? What does "grand view" mean? And grand views take time - look, I myself prefer simple code that works that is then, as it is upgraded, fixed with better design patterns. Design patterns are heavy. There's no point having a factory pattern thing if it only makes one thing in one way. Add the pattern in when you need to make it two or, preferably, three ways.
- Be curious about newly emerged frameworks/technologies, and provide a PoC to test them out if he thinks it's useful to our project.
Hm. Teams are mostly paid to execute business tasks, not investigate emergent tech. If you want to investigate emergent tech, then do it on your own time. Make the PoC on your own time.
- Do not say because this is a project of small scope so there's no design necessary. We implement it as easy as possible, even breaking established software principles.
Disagree here - if a project is very small, or the lifetime is going to be short, or you're unsure if anybody needs the project, then it's better to make it small and simple and fast. You can make it fancy later on when there's a need.
Just because a design pattern exists doesn't mean it has to be used all the time. McDonald's makes more money than the best gourmet burger joint in the world - because they're fast and cheap. I'm not saying they're good, and heck I don't eat their food - but while it's nice to know how to make a fancy burger, it's even nicer to make money.
answered Aug 6 at 14:29
bharal
11.4k22453
Your question is "should i keep voicing my thoughts".
The answer is yes. But do it politely.
There is nothing wrong with engaging in a software team and proposing new ideas and technologies, and it is a very rare and poor manager who does not support this.
The is something wrong if you go in thinking something is "lunacy" and then attack the person aggressively. You'll just make the architect dislike you, which will just make life more difficult. You use the word "lunacy" in your question, among other more aggressive terms.
The majority of your question, however, reads poorly. You express that you feel the architect is incompetent, effectively. However a software architect cares about very different things from a software engineer.
Architects care about how the product fits into the existing ecosystem. They understand how the various bits of data flow from one end of an org to another, and how to best ensure data is reliable and available.
Understand that you shouldn't be attacking the architect, because they're worried about different things than you, and they have different skillsets.
As a rule of thumb:
You need to learn to be polite and work on the problem, not the person.
After all, you're all there to find solutions to the same problem.
As for your new points:
- Understand the basic interaction of classes/components of the current implementation.
Why do you want this? If you want it will help the team, then raise it to the manager to start having training sessions about the design/implementation.
- Read the code.
Why do you want this? If the person isn't a developer then they have no real gain from reading the code.
- Provide guidance and mentorship to the juniors. Challenge our implementations.
Ok, I understand this. But you need to ask this person and their manager to create time - say an hour or two or so a week - to do this.
- Hold code review sessions,
Why do you want this? This is highly dependent on the team and what the manager of the team decides. In some teams, for some projects, code review sessions are great. In other teams, a couple of leads pushing "bad" code back to get fixed online is great.
- Design the architecture (class/component) from a grand view.
Why do you think they are not? What does "grand view" mean? And grand views take time - look, I myself prefer simple code that works that is then, as it is upgraded, fixed with better design patterns. Design patterns are heavy. There's no point having a factory pattern thing if it only makes one thing in one way. Add the pattern in when you need to make it two or, preferably, three ways.
- Be curious about newly emerged frameworks/technologies, and provide a PoC to test them out if he thinks it's useful to our project.
Hm. Teams are mostly paid to execute business tasks, not investigate emergent tech. If you want to investigate emergent tech, then do it on your own time. Make the PoC on your own time.
- Do not say because this is a project of small scope so there's no design necessary. We implement it as easy as possible, even breaking established software principles.
Disagree here - if a project is very small, or the lifetime is going to be short, or you're unsure if anybody needs the project, then it's better to make it small and simple and fast. You can make it fancy later on when there's a need.
Just because a design pattern exists doesn't mean it has to be used all the time. McDonald's makes more money than the best gourmet burger joint in the world - because they're fast and cheap. I'm not saying they're good, and heck I don't eat their food - but while it's nice to know how to make a fancy burger, it's even nicer to make money.
answered Aug 6 at 14:29
bharal
11.4k22453
edited Aug 6 at 17:03
answered Aug 6 at 14:29
bharal
11.4k22453
answered Aug 6 at 14:29
bharal
11.4k22453
answered Aug 6 at 14:29
bharal
11.4k22453
11.4k22453
I guess you are right. It seems like I may have too much expectations for an architect, and that comes down as some sort of a disappointment to me when things don't work out as I hope. But what would be the best course of action when you subconsciously think the architect (or a more senior colleague generically) gives out poor decisions based on an incomplete understanding (of course from my perspective) of the implementation details of the project? I didn't realize my question would sound like a rant until I finished writing it.
– FizzyTidus
Aug 6 at 15:34
Maybe I'm affected too deeply by the methodology that the only way to go fast is to go well. Thank you so very much for your time and input, and sorry that my question is downvoted to dirt. Your answer deserves to be read by more people.
– FizzyTidus
Aug 6 at 17:36
1
@FizzyTidus, As old technologies mature, those technologies are better documented, there is better training for them, and there are better samples and case studies. This tends to reduce the need for software architects in general, especially if those architects don't know (or do not remember) how to code and/or refuse to learn new emergent technologies. And this is actually ok in a large multinational software company. The saying "if it ain't broken, don't fix it" applies here. If you do not like that environment, I'd suggest that you join a (serious) startup.
– Stephan Branczyk
Aug 6 at 21:19
add a comment |Â
I guess you are right. It seems like I may have too much expectations for an architect, and that comes down as some sort of a disappointment to me when things don't work out as I hope. But what would be the best course of action when you subconsciously think the architect (or a more senior colleague generically) gives out poor decisions based on an incomplete understanding (of course from my perspective) of the implementation details of the project? I didn't realize my question would sound like a rant until I finished writing it.
– FizzyTidus
Aug 6 at 15:34
Maybe I'm affected too deeply by the methodology that the only way to go fast is to go well. Thank you so very much for your time and input, and sorry that my question is downvoted to dirt. Your answer deserves to be read by more people.
– FizzyTidus
Aug 6 at 17:36
1
@FizzyTidus, As old technologies mature, those technologies are better documented, there is better training for them, and there are better samples and case studies. This tends to reduce the need for software architects in general, especially if those architects don't know (or do not remember) how to code and/or refuse to learn new emergent technologies. And this is actually ok in a large multinational software company. The saying "if it ain't broken, don't fix it" applies here. If you do not like that environment, I'd suggest that you join a (serious) startup.
– Stephan Branczyk
Aug 6 at 21:19
I guess you are right. It seems like I may have too much expectations for an architect, and that comes down as some sort of a disappointment to me when things don't work out as I hope. But what would be the best course of action when you subconsciously think the architect (or a more senior colleague generically) gives out poor decisions based on an incomplete understanding (of course from my perspective) of the implementation details of the project? I didn't realize my question would sound like a rant until I finished writing it.
– FizzyTidus
Aug 6 at 15:34
I guess you are right. It seems like I may have too much expectations for an architect, and that comes down as some sort of a disappointment to me when things don't work out as I hope. But what would be the best course of action when you subconsciously think the architect (or a more senior colleague generically) gives out poor decisions based on an incomplete understanding (of course from my perspective) of the implementation details of the project? I didn't realize my question would sound like a rant until I finished writing it.
– FizzyTidus
Aug 6 at 15:34
Maybe I'm affected too deeply by the methodology that the only way to go fast is to go well. Thank you so very much for your time and input, and sorry that my question is downvoted to dirt. Your answer deserves to be read by more people.
– FizzyTidus
Aug 6 at 17:36
Maybe I'm affected too deeply by the methodology that the only way to go fast is to go well. Thank you so very much for your time and input, and sorry that my question is downvoted to dirt. Your answer deserves to be read by more people.
– FizzyTidus
Aug 6 at 17:36
1
1
@FizzyTidus, As old technologies mature, those technologies are better documented, there is better training for them, and there are better samples and case studies. This tends to reduce the need for software architects in general, especially if those architects don't know (or do not remember) how to code and/or refuse to learn new emergent technologies. And this is actually ok in a large multinational software company. The saying "if it ain't broken, don't fix it" applies here. If you do not like that environment, I'd suggest that you join a (serious) startup.
– Stephan Branczyk
Aug 6 at 21:19
@FizzyTidus, As old technologies mature, those technologies are better documented, there is better training for them, and there are better samples and case studies. This tends to reduce the need for software architects in general, especially if those architects don't know (or do not remember) how to code and/or refuse to learn new emergent technologies. And this is actually ok in a large multinational software company. The saying "if it ain't broken, don't fix it" applies here. If you do not like that environment, I'd suggest that you join a (serious) startup.
– Stephan Branczyk
Aug 6 at 21:19
add a comment |Â
This seems a bit broad, without a goal we can address. Can you consider narrowing this down a bit?
– Mister Positive
Aug 6 at 14:19
What is your position? "I couldn't help but call out on some of these lunacies." - What does this mean? Did you voice your concerns to your manager about the architect?
– Brandin
Aug 7 at 5:44