I'm working as a full stack software engineer for about 10 years, but recently I started wondering if I am actually suited for that profession (I'm currently 42 years old, if that matters)....

I graduated in CS in 2005, but only managed to work in that field as of 2013. At first I really did enjoy that job, but some developments in the engineering world make me feel like I'm completely out of sync with what's going on.

For example, it feels like utilizing microservice architecture with orchestration (likely Kubernetes) is the way to go in most places nowadays, whereas I feel like about 80% of all projects do not profit enough from the merits that they would warrant the additional overhead. I usually prefer going with monolithic, or at least basic client-server architecture until the need for changing the architecture comes apparent, especially if the project is run by me alone or a very small team.

I do encounter similar feelings towards database architecture, where it fells like nowadays databases are seen as nothing more than a mere key/value store to throw in some data and not worry too much about consistency, where I myself am a strong proponent of data modelling and utilizing SQL databases as far as possible, trying to ensure data consistency on a database level (my train of thought is whatever I allow into my database will at some point end up coming in, and if my data messes up I will have a very hard time fixing it up).

However, most of the time when discussing developing with my peers it feels like I'm about the only one with these kind of views, and that really makes me wonder whether I might be completely wrong in my profession (sometimes I feel like there might be fields outside of app development where my way of thinking might be better applicable, but then again, I wouldn't have any idea on how to get into there...).

I know this is probably a bad question as mostly opinion based, but I still would be interested if there are others experiencing similar feelings, and how they managed to handle it.

  • 2
    For what it's worth, IBM started as an enthusiastic supporter of microservices, then realized that they are really only of use when trying to open up APIs into an unmaintainable code monolith, and NOT a good way to build new applications, no matter how pretty the textbook examples may seem. (There have been many past attempts at assembling code from plug-in components, some of which were IBM's, which all came to much the same conclusion. When's the last time you heard someone mention java beanboxes?)
    – keshlam
    Aug 16, 2023 at 4:10
  • 8
    Monoliths, micro services, SQL, No-SQL,... they all have their purpose. Your goal as an engineer should be to know what tools are available to you and use the right one for the problem you're trying to solve. Quite often this is not a purely technical decision, but involves business as well. Amazon recently made a blog post about how they switched back to a monolith for one of their services: primevideotech.com/video-streaming/….
    – devb
    Aug 16, 2023 at 7:23
  • 2
    That said, I'll go to the barricades for docker. Having my dev environment extremely similar to prod is too nice to give up. The lack of stress over updates, too, is super nice.
    – lupe
    Aug 16, 2023 at 13:09
  • 1
    Microservices are only really useful if there is cause for separation. Like if you want to use different programming languages or you have multiple teams working on a large project. Or you want to share services across different applications. It's divide and conquer on a higher level. Nothing wrong with a monolith for simple applications.
    – seg
    Aug 16, 2023 at 14:46
  • 1
    It depends. How big (for various definitions of big) is your company/project? I work at a Fortune 50 company and there are facets of our business that absolutely benefit from k8s and NOSQL. But this is the first/only place I've ever worked where that was the case, every other place would be better served by monolithic architecture and RDBMS. Even here there are plenty of projects that don't need those. A lot of the usage of those things is what I'd call "resume driven development". You're not old just because you point out the Emperor is not, in fact, wearing clothes. Aug 16, 2023 at 15:31

3 Answers 3


how they managed to handle it.

By just doing what they know how to do. Most newfangled infrastructure and software are just gimmicks, they do not have enough actual value in most situations to warrant a change. Some have so many overheads and hidden costs that they're an expensive pain to use when solutions already exist.

So you analyse and discard the fluff and usually end up sticking with the old and tested. My strategy is to look at the most basic solution for a problem and leave the bells and whistles for the circus performers.


Its a great question and has much to do with the culture in your area and specific workplace. Often times culture in your workplace spreads to others in the area as turnover in this industry is quite high.

I agree with you about SQL and overdoing some projects. For the record I am 56 and work with some that are much older. One really sharp guy I work with is in his 70s. So you are not too old.

Often times, in this industry, the issue is not that you have presented a good case for your beliefs. Sometimes decisions are made simply because others do not know the tech you are a proposing. They have a vested interest in using their tech stack as they can appear as an expert and someone like you may not. They would be lost in a different tech stack.

Management sometimes supports this as finding people skilled in different tech stacks can be challenging and may cost them more money. For example, these days hiring a skilled Cobol programmer will cost big bucks.

What's the solution? When you run your own project do it your way. In the meantime do it their way. Even if your project comes in sooner and under budget, you will probably be criticized. It has happened to me and people a lot smarter than the both of us.

Good software engineers probably lie somewhere on the Autism spectrum. As a result the industry experiences a lot of mildly anti-social behavior. This is one of them. Learning new tech stacks is hard and uncomfortable.

IMHO you might be getting too old to put up with this crap, but really it is a great career. Nice pay and benefits and you mostly don't have to deal with people.

  • When I'm driven into a nervous wreck and to slap the side of my head repetitively, I tend to blame management, not autism. I don't think the proliferation of complexity has anything to do with autism, it has to do with the absence of training (and thus industry reliance on those who have self-taught, usually not as part of any collective of learners that helps knock the edges off people's personalities), as well as too little technological standardisation and consolidation, and too much corporate competition and interference by marketing departments.
    – Steve
    Aug 16, 2023 at 11:56
  • @Steve what I mean is that as developers we tend to not deal 100% well with others. The more in the conversation, the less likely a decent outcome. Given that most managers were once developers well same sort of problem.
    – Pete B.
    Aug 16, 2023 at 12:32
  • Agreed. Part of the issue is that many aspects of development require deep and sustained intellectual work and a carefully integrated result. It's like music-making in that respect - almost anyone who's any good at it has at some point clashed with others. However I think the other side is that there aren't the institutions that promote shared practices and standards. Compared to say music, most developers don't have a standard on what instruments are called, how to write down a tune, or how many keys in a scale. I think this is an industrial organisation problem, not a personality problem.
    – Steve
    Aug 16, 2023 at 14:17

I think there's a few things to consider here:

  • Not all of software engineering is one monolith. Some companies — often especially larger ones where reliability and correctness are often valued more highly over moving quickly — have similar values to what you've presented here.
  • I don't think there's really a right or wrong perspective here. I think different solutions can be better suited for different problems. When you're a small company that really needs to move fast to maintain a competitive edge, sometimes being broken doesn't matter so much. If you can get your feature released a month earlier, that might be worth more to the company than the fact that an engineer has to spend a week or two fixing a dodgy database after the fact... But on the flipside, if your software is dealing with financial transactions worth millions you probably don't want to be so laissez-faire.
  • Some companies (IMHO correctly) see that having people with different points of view is important to allow them to potentially find solutions that they wouldn't have found had everyone thought the same way. Think about the way you're treated by your colleagues and management chain — are your disagreements civil and polite; do people still respect you as an engineer despite having different opinions to you; are your different perspectives highlighted as valuable in your evaluation meetings? If these are all true then I'm not sure I would worry too much. If some or all of them are false then maybe consider that you're not a good fit for the company you're at and would perhaps be better off moving elsewhere within the industry.

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