7

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?

| improve this question | |
  • 4
    This question (and the linked questions) may be very relevant to you: How can I communicate my preference to stay where I am now in my career path, and not move “up”? – David K Oct 4 '16 at 17:56
  • You have a really good answer from Owens. It is not optimal for you or the company. But arguing with you manager if he is not going to move is not optimal for you or the company either. – paparazzo Oct 4 '16 at 18:56
  • 3
    There's no right or wrong here. There's what your boss wants you to do, and there's what you want to do. – WorkerDrone Oct 4 '16 at 20:08
  • 1
    Your question, as currently stated, is likely going to generate a few different opinions, each with valid points and counterpoints. The reality is, if you don't like your job as it is defined by the people who pay you to do it, you have two options: 1) try to persuade them to see things your way, and failing that, 2) find a job that is defined in a way that suits you. – Kent A. Oct 4 '16 at 21:19
  • They're trying to promote you to architect. That doesn't mean you can't do some hands-on work, but it means the biggest part of your job is to divide it into pieces others can do. Think of it as programming in a much higher level language, writing specs which the coders "compile" for you. It can tremendously amplify your own impact/productivity, if you can clearly communcate your design. Not a job for everyone, but it isn't nontechnical. – keshlam Oct 5 '16 at 3:27
8

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.

| improve this answer | |
3

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.

| improve this answer | |
1

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.

| improve this answer | |
0

I think you can do several things to keep your boss happy and your skills sharpened for future employment.

  1. Do the design work just like your boss asks.
  2. Get involved with code review, training and mentoring young developers. Teaching them how to code will elevate your coding knowledge.
  3. Continue to study and writing code on your own. You can also use this when working with young devs. Encourage them to stretch their skills by implementing newly learned strategies.

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.

| improve this answer | |
0

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.

| improve this answer | |
  • Why do you think that my answer only applies to the technical side? There's an article on Dr. Dobbs (which appears to be unavailable at this time) that asserts that "engineering managers should code 30% of their time". That may be a bit high (it's 12 hours in a 40 hour week) - I'd argue fpr 20%, or around 8 hours/week. The article makes arguments about improving estimates and budgets, giving insight into technical debt, understanding the tools the development team uses every day, and increasing knowledge to facilitate decision making. I don't think you can manage what you don't know. (1/2) – Thomas Owens Oct 5 '16 at 0:54
  • Many organizations (the article acknowledges this) don't allow for managers to have time to work in the software development process. However, if you aren't writing code in your organization's environment, you won't be good at making architectural and design decisions. If you aren't exposed to the domain and understand the users, you are going to be less effective at requirements development. If you don't understand of all of the phases, from requirements through test in the environment that it's done, you can't manage it. You don't have to be great, but you still need to understand. (2/2) – Thomas Owens Oct 5 '16 at 1:00

Not the answer you're looking for? Browse other questions tagged .