I am a software engineer with 8+ years of experience. In my projects currently assigned to me, my manager is urging me to do only the design part, not the implementation. His doctrine is that senior member of the team(myself) need to be involved in framing the design and leave the coding activities to juniors.
I do enjoy writing code myself. But, is my manager right? Is it good for my career as software engineer not to write code but only design software?
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
It sounds like your boss subscribes to the idea that software engineering is more like traditional engineering disciplines, where the engineers draw up detailed designs and specifications and hand them to laborers who go off and build the thing. In this idea, the junior engineers are the laborers who take designs and turn them into code while the senior engineers are architects and designers, and maybe even requirements engineers.
However, this model really doesn't hold up. Unlike a skyscraper or a bridge, it's very hard to specify software in models with sufficient detail to actually hand to someone to "crank the wheel" and turn the models into working code. There's the idea that, in software development, code is design. Someone's deep knowledge of programming paradigms, languages, frameworks, and technologies will inform the design of the system that uses those paradigms, languages, frameworks, and technologies.
I believe that the more senior people in an organization should be involved in requirements, architecture, and design, since they are more likely to understand the domain and system under development, and also the tools used to build the system. People who have a senior title are, simply, more experienced and should be able to make better informed decisions that impact the product. However, junior developers learn by doing, so some of their time should be involved in these activities as they progress. There's no other way for them to steadily progress from a junior (coding) role in a senior (design) role.
As you spend more time in an organization or domain and gain more experience, it's likely that you will take on more non-coding activities. But the sharp divide that your boss sees doesn't make much sense to me. In my opinion, entirely removing yourself from the act of coding will eventually make it hard for you to keep up-to-date on the tools and technologies that are used in your product. Your architectural decisions may not be the best in the current landscape, which would have a negative impact on product functionality and quality.
I would recommend checking out the talk "Real Software Engineering" by Glenn Vanderburg. He gave this same talk several times, as well.
The reality of software development is that is not effective to have distinct "design" and "implementation" phases.
Software requirements almost always change as the project progresses so you are continually trying to hit a moving target. This leads to a tight loop of requirements->design->implementation (i.e. agile development).
In many cases, design and implementation evolve together as you learn more about the requirements, domain, and technologies being used.
In this dynamic environment, it's exceedingly difficult to create a wall between design and implementation. In my opinion, such a model is doomed to be at best inefficient and, at worst, a total failure.
I've been a software developer for over 20 years and the most effective teams have everyone doing both design and implementation.
Personally, I think it's a bad idea to have developers who only design and never implement. You don't find out if a design is good or bad until you actually write the code.
You're not a junior anymore, you've been around for 8+ years. You know what kinds of more senior roles are out there. It's time to pull your eyes up from the code, look around, and figure out what you want out of your career.
Only after you know what you want your career to be can you determine whether writing less code will be good or bad for it.
I think you can do several things to keep your boss happy and your skills sharpened for future employment.
Banging away a the keyboard is just a part of the coding process. Stay closely involved with code without actually writing much of it. Your boss may not prefer this either, but you definitely know he doesn't want to see you sitting at your desk and just writing code.
This is how you leverage your skills and make your teams better. Hopefully the improvements in code you can produce will be what you boss really wants whether he knows it or not.
While I totally agree with Thomas Owens & 17 of 26's answers, they just say this part of the answer : this is a bad move if you want to stay in the technical aspect of code.
If, OTOH, you'd like to try yourself in management, this is an opportunity to take. While the situation is not perfect, it gives you an edge against "true" developers when it comes to management training, and a soft way.
Be sure, however, to check that your company has positions in management, that those positions know some turnover, and make sure to work your politics. Without all this, you don't have future in management in this company, and therefore, stopping to code is just a bad move.
