Senior software developer [closed]

Question

I'm not sure if this is the place of my question or not.

I'm working in a software company as senior software engineer, but my team leader is controlling everything in the development life cycle. I can't give my opinion on anything.

I'm just forced to tasks only without any discussion. I can't even apply any design patterns or UI guidelines.

Is that OK in my career position now? What is the responsibilities of senior engineer?

Answer 1

IMHO it is time to start looking for a new job.

Any place where the words 'Force' and 'Without any discussion" are used aren't any good for any career, not even when you are a junior.

Normally I would have a more positive attitude but since there is no discussion possible than to me all is lost.

Answer 2

Talk to the manager, and ask him/her your role.

Answer 3

Ahmed, you have not mentioned how big is your company ? Aren't there a boss to your boss that you can talk to ? What is overall company culture ? Is this IT/Software company or just in house software team of some other vertical company ? what is the case with your peers, are they also have the same feelings on this topic ?

But, if you can find an alternative where there is more "freedom" and "democratic values" then go for it while not to forget to take into account overall picture and all the pros and cons.

While not favoring your boss, many a times a person sitting at the top has a better view and hence a particular attitude. It would be wise on your part if you can try to learn why he/she is so thick !!!

All the best !!

Answer 4

You need to determine if this is temporary. Sometimes a manager gets thrown into a project where they are over-whelmed, but still have a plan in mind and are determined to execute it with tunnel vision. They don't feel there is time for discussion only execution. Once they learn everyone's strengths and weaknesses they may be able to incorporate their ideas on the next project/version. Hopefully, you'll get some hints that this is the case. The success or failure of this project may influence the future use of this practice.

If you think this is the way it will always be, you need to start looking for a job.

Answer 5

As a softtware manager I would expect a Senior Software engineer to be able to:
- partner with the business to fully understand their requirements
- create a solution using standard best practices (design patterns, performant code, unit tests etc.)
Being able to delegate to them in this fashion would make my life easier and would allow me to expand my responsibilities.

I would actively encourage, if not require, them to provide feedback on what can be improved, whether its coding practices, processes, UI guidelines etc.

As a software manager, it is also critical that my developers feel that they can approach me and discuss things openly, even if that means constructive/critical feedback.

However, all managers/team leads and all Senior Software Engineers are not created alike.
I would recommend meeting with your team lead to discuss some of the things that you would like to do e.g. have a more active role in creating the design etc.
You should also do a quick self-assessment to see if there are things that you can improve on to be able to earn those additional responsibilities.

If you have already tried this approach and are actively being discouraged from voicing your opinion, and you have no other recourse - e.g. moving to another department in the same company - then finding a company that does value your input would be best for your career growth.

Answer 6

There are a number of ways of looking at this and I don't think that the question is detailed enough to be sure. The answers to date are all (largely) sympathetic to the OP - so I'll outline an instance when the team leader would be right to stop innovation.

If you have been put onto a project that has already started, has been specified and mapped out and has had the technologies etc already discussed and defined - then it is perfectly reasonable for a team leader to say "these areas have been decided, this is the way we will do it" and any further discussion could well be a drain on the project budget.

It may not feel nice to a new programmer parachuted into this role but many team leaders feel that developers always want to try some new tech or pattern that they've just read about - and its the lead's job to keep the project on schedule. Most developers have more focus on patterns and technologies than deadlines and costs.

That said if you are a senior on a new project then you really should be consulted about the technical structure of the project and it is at this point that you should be making good points about the architecture. If not then I'd suggest that its time to leave because you are not being valued.

Answer 7

Most of what has to be said about the topic has been covered well already, in the above posts. However, I wanted to factor in another point, that might not be as sympathetic.

From my (short) experience as a team lead, I have noticed multiple reasons why I would sometimes not accept the suggestions of a programmer.

1. The programmer was good, but his ideas were out of place for the current project, or we don't have the time or resources to put them into action.
2. The programmer is enthusiastic, but does not yet have the experience (or maturity) to properly evaluate the idea (in other words, it might not be a very good idea)
3. The programmer is bad / ignorant (and does not know it), and the ideas are likewise.

In case of 1, One should sit with the programmer, and tell him what is good about his idea, and then tell him what are the constraints that are keeping us from using it.

In case of 2, gently break it to the programmer, by pointing out the shortcomings in his ideas, and explain ways to evaluate the ideas before presenting them.

And lastly, in case of 3, there isn't really a single way i found useful to deal with a bad / ignorant programmer. Some tend to be self assured that they know it all, some can be reasoned with, some just recommend ideas for the sake of it, to later claim that they too tried to help with the project, etc

The above post might sound rather critical, but I am just listing out the types of ideas i had to turn down. All the good things were already mentioned above, and I didnt want to duplicate the effort.

What I would recommend to you, is find out if you are in any of the 3 categories, if you are, then learn how to deal with your category of issues. However, if your ideas are genuinely good, and deserve to be used, then by all means talk to your managers manager (or a recruitment agent :) )

Answer 8

Respect needs to be earned, it isn't granted by some title. I've had times where I've listened to very talented junior developers when I have confidence in them over the battle worn veteran who has not instilled any faith in me. Have you earned your respect yet or are you one of those who have earned a lack of faith? If you haven't done either then you are probably better off being told exactly what to do anyways.

Answer 9

Some years before, in the Software Development industry, there where several layers of experience as a programmer, "Junior", "Intermediate", "Senior", or even more, depending on the company. And the "Senior" developer performed the role of "program manager" / "team leader".

When a developer got promoted in a higher layer, he (she) has more choice of taking decisions. Sometimes, developers got "voice", not "vote", disgarding its "layer".

Today, many methodologies insist that ALL programmers should not interfiere in other tasks, because they are too much involved in programming and cannot see the "whole picture". There are Universities / Collegues that openly teach "Program Managers" that programmers should not take decisions, as an example of good I.T. management.

I disagree with that point of view.

Personally, I think that a "team leader" should take in care any opinion. And, as "Senior Developer", I see these techniques, both human and technically, wrong..

You should deal these with your "program manager". If he / she, doesn't care, you may try with other bosses. But, you should insist to them, that the idea of "ALL programmers are code monkeys" is wrong.

If it doesn't work, you should quietly seek job somewhere else...