I'm currently an employed Software Engineer for a moderately sized IT company. Initially I enjoyed the challenge of my work, but over time I have become burnt out of the non-stop technical learning required of the position. I enjoy the design conversations and high-level discussions on architecture/framework, but once I get to the actual programming and half a dozen technologies involved... not so much.

I would like to ask if there are other less technically demanding positions for someone with a decent understanding of the front-end/back-end/SDLC who is also a good communicator?

To clarify; I'm not against learning. I want to put my technical skills to use and continue to grow my knowledge. But I'm curious as to if there are maybe more collaborative positions where the amount of knowledge required is relatively defined, instead of now where I spend all day everyday trying to learn and apply new technologies/concepts.

closed as too broad by Dukeling, Stian Yttervik, user59301, DarkCygnus, IDrinkandIKnowThings Jul 12 '18 at 17:41

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.

  • So, what do you intend to do when you find out this less intensive positions exist? Given all the possible jobs out there, it's safe to say that there are jobs like you describe out there...What is your goal on asking that? – DarkCygnus Jul 9 '18 at 17:41
  • I'm just trying to explore my options to see if I can find a good fit for the future. Right now I'm okay where I'm at, but I'd like to be happier at work. If there's another position out there that I am better suited for, I'd like the try it out. – Brian Brian Jul 11 '18 at 1:10

There are domains withing software development which shun the momentum to evolve technology at a rapid pace. One great example is COBOL programing within financial institutions. It can pay very well, and you will not be expected to learn the popular programing language or framework of the season.

  • 2
    I've actually heard a decent amount about COBOL, and I think the learning curve to learn that from scratch would be rather steep. Though you are right, anything using COBOL is pretty set in their ways ha – Brian Brian Jul 6 '18 at 23:52

I am in a similar position and have started looking into Technical Product Manager/Owner positions. Being a Scrum Master may also be a good idea too, it will allow you utilize your technical knowledge within technical teams in addition to communicating with the business side.

  • As a technical product manager: Don't expect you have to gain less new knowledge than an engineer, in my case it's the exact opposite. Mainly because I need to look deeper at related (interworking) technologies engineering can mostly ignore or have to evaluate technologies that end up not being viable for our product so engineering doesn't even hear of them. This won't be true for every company of course, but keep this in mind. – KillianDS Jul 10 '18 at 9:13

There can also be companies where you don't need to constantly learn.

If company develops their own product. Technologies/frameworks/languages are typically set beforehand, and they don't change too often. However this isn't always the case. I've heard about start-up where CTO/lead architect wanted to embrace all latest frameworks and it was pretty chaotic in the end.

Or in those cases where company has delivered a product for customer and is still responsible for maintaining it. Maintenance work usually avoids any drastic changes to prevent issues from emerging.

And there are also consulting companies who specialize in very limited skill set. Developers with certain expertise from these companies are then hired to deliver something specific. But how well this works in practice varies quite a lot.

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