I've realized I'm a bad software engineer and I'm over 30, what's next?

I'd argue differently. Congrats for having the courage to recognize your problem.

The analogy that comes to mind is I've been playing basketball in my local town, and now I've gotten promoted to play in the big city. I now feel like a small fish in a big pond.

If you enjoy software engineering, I'd say, double down. Now that you're at the medium software company, seek mentorship and coaching from others.

In addition, there might be more homework (hitting the gym sort of), things you also have to do on your own.

It isn't going to feel good being humbled and I've been there myself. But if you think about the goal as "learning to get better" than "prove to others I am better", you'll have a better time walking through this challenge. This all comes from a person who is a PM.

So some tactical thoughts of possible advice: 1. Face the issues head on -> take all the negative feedback on the code and rework the medium complexity task 2. Learn to unlearn bad habits. Yes, it's harder, but it comes with practice. 3. Commit to maybe taking a course work online (maybe seek advice from others on what are good ones to address weaknesses you have)

Hope this helps.

BTW, you don't need to be able to code things the right way to be a PM. Coding is only one specific skill and not always necessary for a PM.

You could be suffering from impostor syndrome. This is the feeling that someone gets when they are in a role but feel like they aren't living up to it and don't belong there, even though they may not be doing anything wrong.

I also have 10+ years in software development and have switched companies several times. Every place is very different in terms of how their architecture is set up and what's expected in a software solution. I've been at my current job for only about six months, but there are a lot of nuances and things that have thrown me off in implementing various features and fixes.

In some cases, I'd start questioning whether or not I'm taking the right approach or if I'm even the right one for the role. Though, some of these things I would bring up with my manager who would either give me advice on ways I could understand their setup better or would give me reassurance that there's nothing fundamentally wrong with what I've been doing. I'd suggest you talk to your manager, too, because I get the feeling that we're in the same boat.

A long time ago, I described what I did as a programmer, and my friend said "Oh, so you get paid to learn?" I thought about it, and agreed. Part of programming is learning.

Sounds like you've got a great opportunity to learn what you don't yet know: you already have a list of things you know you need to work on, a codebase, and a job. Do you think one or more of your co-workers would be willing to give you feedback? Would you be willing to take time (maybe extra time, 'off the clock') to practice?

If, e.g., hard-coding is where you're at, maybe something like working your way through 'Code Complete' would be of help, but I would pair the reading with doing, as close to the company's codebase and personnel as makes sense.

I've heard tell of people who asked to be shifted to a lower-level position so they could work at the level they were comfortable with.

There is no shame in being an average or below average software engineer. I would know, I am one myself. The key is to remember that we have one of the best jobs in human history.

You get paid an incredible amount of money, you can work from just about any place you want - from the most modern cities to a remote cabin in the countryside - and you have great job security. You can work for yourself as a freelancer and control your schedule, or work as an employee and have structure and security. If one place doesn't treat you well, there are countless other places that will hire you.

Not everyone gets to be above average or amazing at their job, so stop comparing yourself to other people. But if you really can't stop comparing yourself to other people, compare yourself to people in other trades. There are expert chefs, top 10%, and their job pays far less, demands far more hours, and is much more cutthroat than yours. There are musicians, athletes, artists, and performers who have spent almost every moment of their free time practicing their trade since they were kids, but they struggle to pay the bills or even find someone to hire them at all in their desired line of work. Just accept that, and forget about job titles. Don't find your identity in your title or in how you stack up compared to your peers. Just find a place to work where you can learn every day and that pays the bills, and then enjoy the life that you have inside and outside of work. You may never be a Mozart of software engineering, but that's really okay. You can still make beautiful, useful things and build a rich life being average. :-)

> I've been able to always have work on my desk because I'm always moving and talking with people in the industry

There were a lot of good suggestions from others. But just from this, it sounds like your true skill is sales.

Just put two and two together, taking the facts in your post as a given. You're a (supposedly) bad coder, but always had customers as a freelancer. In other words, you were doing a great job selling a mediocre product, without even realizing or trying. That's the mark of a salesman.

The good part is that you don't have to completely waste your technical skills by switching to this route. There's plenty of jobs for sales engineers or sales positions that require an engineering background. Maybe you're not the best at building software, but you certainly understand it well enough to know the products.

One way to transition may be to find one or two "good engineers" to team up with. There's a lot of great coders out there, who'd love to work for themselves, but unlike you can never get enough business. Maybe it's a consultancy. Maybe it's a startup. Either way, they can handle the engineering side of the business and you handle the sales. A partnership like this can be extremely lucrative for all parties involved.

Having been a programmer for forty years, I am senior in every sense of the word.

Also, I hate everything I have ever written. When I look at something I wrote three months ago, it is embarrassing.

Now, today's code, that's a different story. It is awesome.

And it will be until I turn my attention elsewhere. When I come back to it, it will also suck.

Which is to say, Of course you hate your previous work. You learned that hardcoded values are a bad thing. Probably you won't do that again.

But, you will do something new that is egregious. In forty years, this is the pattern. Every new thing I learn makes my previous code suck.

Embrace the suck. It is part of life. When you see something you did that sucks, don't do it anymore. Find some new suckage to write.

Don't worry about trying to become a good programmer because, you will only achieve that if you stop learning new things. That would be bad.

I think it's worth thinking about why you were successful as a freelancer and in smaller companies. I started my career in a simmilar place, and I was very successful because I loved learning about the business, talking to stakeholders and delivering value. The code wasn't always great, or even good, but it was delivered quickly and users found it solved genuine problems.

When I transitioned into larger "software" companies I found I was often surrounded by people who were focused on ideological purity, but insulated from the impacts of their changes. They would spent 6 months polishing something that nobody used, or replacing a perfectly good system with a rewrite that had half as many features. I simultaneously felt like I wasn't good at writing software, and that the problems I was working on didn't matter, which is a pretty kiler combo and burns you out very quickly.

My advice is: emphasize how you deliver value, how you're flexible, pick things up quickly, understand the business, etc. Freelancing is more impressive to me when I'm hiring than career big-co developers, because you can't fuck around. If you're not delivering value you're gone.

Structuring code well and making it easy to debug is something you'll learn as you work on more, larger systems. It's a muscle you can practice, and you can be up front that it's something you want to improve on. I absolutely think it's something you'll improve on when you're at a company, it's hard to learn on your own.

It sounds to me like you haven't internalized a lot of the advice in the first half of "Clean Code" and/or the entirety of "The Pragmatic Programmer". Either of those books takes a few weeks to read slowly and a few months-to-years of deliberate practice to internalize and synthesize as your own. The good news is that admitting you have a problem is the first step.

Personally I find I still frequently write pretty atrocious code on the first draft, and it's only by stepping back from the problem after demonstrating to myself I understand it well enough to solve it at all that I can begin to write a more graceful solution. But deadlines and reality being what they are, I think the majority of us are embarrassed by our past code a majority of the time.

So don't be too hard on yourself, but also frankly don't worry about shoe-horning yourself into "A Career" either. They're kind of a recent invention and the whole concept might need a few more iterations. You could spend a few years as a Product Manager, an Engineering Manager, a Highschool Teacher, or a Business Analyst, leveraging your past experience to gain competency in a new niche.

I want to emphasize of self-awareness you have is commendable and not universally present: If you can realistically assess your own current skill level and then apply yourself to improving, you could be an above average software engineer before you know it. And right now it seems like so so many companies just can't get enough software engineers, so it's a pretty safe place to practice learning how to learn while also earning a decent income.

We hired someone like this last year who was a lead in the last role at a small firm, had senior titles over a couple roles prior.

This person is smart and well-liked and called out their concerns early on, so we're working with them and have seen considerable improvement in the half-year since they were hired.

So I'd say it really comes down to your environment. If you have a good, supportive culture, I would have a frank discussion with your supervisor. Either you'll find out you're doing better than expected (and it is imposter syndrome like some are saying), or you'll have a path for improvement and a supervisor who is appreciative of the self-awareness and desire to improve.

At the end of the day, an experienced manager will be aware of this type of situation, that there's a wide berth of quality when it comes to software firms, and an engineer typically will only be as good as the teams they've worked with.

It's not clear from your post (and you don't have to make it clear, of course) whether you're getting fired from your current company or not.

Merely failing one task won't get you fired and if you have the self-awareness demonstrated above to realize that you haven't yet learned what you need to become senior, gives you a clear path (and one that won't even be that hard if you've been selling and making software for 10 years).

Making software in a team is a somewhat different skill and you just need to learn it.

I contrast your case (understanding the issues) with a code review I did around 20 years ago where someone had hardcoded the value 17 in a bunch of places in a mixed c / c++ codebase. I suggested he use a #define for the magic/hardcoded values.

I kid you not, his resubmission contained:

  #define SEVENTEEN 17

and the points of use all now said SEVENTEEN. (At least the instances of 34 were replaced with SEVENTEEN * 2.)

That programmer wasn't going to make senior. You will. If you're getting code reviews that are pointing out these issues at your current place, stay there and learn. 6 months from now, you'll look back at your thread here and realize just how much you've progressed with the live mentoring in a team and the spaced-repetition of go away and code, get review, improve it, get review, etc.

I used to sing in a choir and whenever someone said that they can't sing because they're off key all the time our choirmaster would reply with:

"Good! At least you can hear it, which means you can be taught."

If there is someone in the company who will give you the time of the day to work with you on these problems then you're in a good position and your best course of action would be to make the most of it.

As for hardcoded values etc.: you would not believe what passes for working code in large corporations.

I have been a semi-similar position, worked 3 years in non-tech world where I was a full-stack tech lead wizard champion. But decided to go into tech, since I wasn't learning anymore and was tired of being considered a senior in my field when I actually was just senior in my role.

Long story short, joined tech, got wrecked and started to doubt about my skills. Things to keep in mind:

- you got hired. unless they did a shit job interviewing they probably know that you are not Martin Fowler

- you made this career move for that very reason: learning, getting your ego shuddered a little bit

- talk to your supervisor and share your feelings

There might also be some other issues here that are not completely tied to your skills/competences. Some projects are tough. I would not consider working on a codebase that is full of hard coded values, magic and hacks "medium difficulty". In fact, this sounds like a really difficult task as you have to make constant trade-offs (refactor/rewrite/leave it alone).

Anyway, don't be so hard on yourself, we all suck at our job. Communicate with your team.

1. The quality of your work as a developer has no bearing on the quality of your work as a PM. It's a different skillset altogether and you may or may not have it but your experience as a developer is only an asset when applying to be a PM. Whether you decide to go in that direction is a personal decision, but you should do it because you're interested in that kind of work, not because you think that your software work is subpar.

2. You don't need to take a break. You can incrementally improve on the things that you know that you're doing wrong at your current job and improve while you're still there. Since you're already aware of a bunch of them, it shouldn't be too difficult to improve on them over time.

3. You may or may not be too self-critical. The way to find out is to prepare for interviews for a bit and then try out a few. Don't disqualify yourself, let other people do that.

Why do you have to come at me like this? This is a feeling I go through all the time. It's partly imposter syndrome, but partly that you're probably holding yourself to a higher standard than others.

> I'd been assigned a medium complexity task

Who decided that it was medium? A manger? Some lead? You? You can't really compare what is easy and what is hard when it comes to software. I worked on a project that timelines started to slide when I came on board. Not because I didn't know what I was doing, I had just moved from one project to another. It was because the manager didn't account for the time it would take for me to learn the code base. He assumed that developers were cogs in a machine that can be replaced with no downtime. That doesn't work.

> I've realized I'm not a senior software engineer as I thought and now I don't know what to do next.

There are two pieces of advice I can give you here;

1. Nobody else knows what they're doing either. We're all making it up.

2. You're going to fail at something, a lot, before you get good at it. Go dunk a basketball and get back to me if you think you should just coach(manage) because you couldn't dunk

>A third option would be to take a break from work and try to learn to write good code

You're already at a place paying you to write code. Why take a break to do it for free?

Do you want to be a software developer still? (That isn't clear from your summary). If so, you need to learn better habits.

I suggest picking up a book on the subject, like "Code Complete" (at Amazon or wherever books are sold. Pretty sure it's at the library if you'd rather read it for free -- but it'll do better as a reference book on your desk for a few years). Use it and start practicing with personal projects hosted out of Github.

I also suggest using a daily practice like a code kata: http://codekata.com/

Honestly, in most of my experience the higher the title of the developer, the worse the code is. Developers aren't promoted for writing nice code, they are promoted for getting projects out the door, on time. This usually requires sacrifices in terms of engineering.

I'm in a pretty similar situation: I'm reasonably adept at coding challenges, but fall down when it comes to developing more complicated applications. I've found that I'm most useful on teams with good tech leadership. Every medium+ size team has unglamorous, easy work that just needs to be done by someone. So I'd suggest keep moving jobs until you find such a team, then stick it out.

Also -- and this is going to sound terrible -- but at a large enough company, you can be incompetent and still collect a paycheck. You'll probably be given busy work or tasks that the managers understand aren't going anywhere. And realize that 50% of profits from companies are generated by sqrt(total_employees), meaning, that, in general almost nobody is a big money maker.

I’m not sure I really follow - what’s an example of a project you solved successfully before in “hacky” way?

When you get knocked off your horse you either give up or stand up. Maybe you are feeling it really hurt. But you’ve invested a lot in this industry and career, so don’t give up after your first real challenge. Get the fuck up and figure out how to deliver successfully on this project 1) what parts can you solve? Do those 2) for the parts you can’t, how can you? How do you break it down into specific problems? In this case, maybe one piece is centralizing hard coded variables into one place. What’s the best way to do that? Once you have specific questions, you’ll be able to find specific answers. Start working through them. If you can’t find self help, what about some colleagues you’ve amassed over 10 years? Worst case ask your manager, at some point you can’t bullshit things anymore, but give it an honest try first and outline what you were able to do and which problem(s) you are stuck on and what you tried already. Your manager will appreciate your ownership and your concrete ask for help.

Context: I made a career change and got fired from my first job 5 months in. It was devastating, but I got back up and got another job. I got a second job, went ok until i got a manager who said I was focused on the wrong things. After a year he kept complaining about it and in the end gave me a bad performance review. It left me shaken. I got back up and got a third job, where I am today, and I am crushing it. I still doubt myself, I still have wounds from before, and I even have doubts sometimes if I could succeed elsewhere, but I keep getting better, and getting up when I’m knocked off.

Good luck

> I'm thinking about looking for semi senior roles but I'm afraid it'll look weird for the company interviewing me to hire a semi senior with +10 years of experience.

I think this is definitely an option if you want to go for it. There might be some companies who will discriminate against you, but they'll definitely be some who won't. The key will be explaining to them (and convincing them) that the reason you're not as senior as one might expect is because you were never exposed to good practices or challenged to do better, rather than because you tried and failed to learn how to do things better. It sounds like this is genuinely the case, so I imagine it wouldn't be too hard to find people you can convince.

However:

> If you read my resume it'll seem I am a senior but I don't really know where to place me in the "experience" spectrum

To me it very much sounds like "junior". So it really depends if you are prepared to suck it up and learn everything afresh with an open mind. If you are, then I'd certainly be willing to hire you for a junior position (if I were interviewing you).

Project management is potentially a good option. Before you give up though I think you are potentially being too hard on yourself. Projects fail (a lot of them).

I'm guessing that potentially you brought your smaller problem solving skills to a bigger task than you are accustomed to. If that is true it might simply be the case that if you were to have broken the large/medium task into a bunch of small tasks then you would have been a smashing success.

For me, this sounds like a developer with a lot of potential. You realized your weaknesses and want to improve. That's a big step forward.

To improve, you need to work on projects with more senior developers.

Few things that work for me well:

1. Talk with a senior person about everything you are going to do. How are you going to architect and implement stuff. You will learn a lot just by talking with smart people.

2. Have all your code reviewed by a senior person. It's good practice to do code reviews anyway.

3. Iterate quickly. Preferably, submit your code for review every day. This way you will get immediate feedback and can improve rapidly. I'm even often submitting empty classes and methods just to outline data flow and overall design.

The only way to get better is to practice. I didnt code for about 15 years while I ran my own company and only started coding again about 3 years ago. My brain feels like mush sometimes.

Start by modifying other people's code - fixing bugs. When you have to write new code model it after other peoples' structures. Write comments for how the logic should work before you write the actual code.

You can get it working in one big method using hardcoded values, then slowly break it apart. It might be you just stopped your code at the first draft.

Alternately you can do product management. Being technical and doing product management means you can actually understand what is going on under the hood.

Keep at it. Why would you quit just because you've realized that you've done some things the wrong way?

I get the feeling that quite a few engineers come at it from your kind of side. Only one dev, stuff needs to be done, it gets done with a lot of heaving and sweating.

Now you're in a larger place, there should be some breathing room. Find out how people do things:

- Maybe read the GoF patterns book to get some cookie-cutter solutions to common problems.

- A lot of the simpler DS&A learnings can be practiced with introductory leetcode problems. Don't sweat it too much, I'm sure there are a lot unuseful brainteasers there too.

- Get used to all the tooling around the code. Git, CI/CD. Build scripts.

  > try to learn to write good code
  > not sure it's possible without working on a company with other people

Sounds like you are in the perfect place to learn how to write better code right now. Use the feedback you're getting to improve and get to the level you feel you should be at. You probably aren't as far away as you think.

I started programming at gymnasium and through uni. Throughout uni I did a lot of Competitive Programming. Most programs in CP are written and discarded within hours of each other. You also pretty much only use the standard library and no third-party tools. You never interact with the hardware of the system that the program runs on. Maybe reading files from the filesystem (depending on judge software) but definitely no networking. No threading or parallelism. No CI/CD. No Docker, K8s. No build systems. No project management & other "soft knowledge". No "Does it work on IE8?"-stuff.

Essentially you become an expert in writing 100-200 lines of code that reads data from standard input and prints data to standard output. Useful for CP, not so much in the real world. After doing CP as a hobby for a few years at uni I realized this and instantly looked to my peers. What were they doing? One guy was building something similar to IFTTT in golang. Another one was building his own window manager for Linux. Some were really good with constructing websites. But what except solve toy computer science questions could I do?

I don't come with any specific advice, but the way you described being down in the dumps felt very similar to my experience. I think that kind of experience is quite common and normal... Maybe more people have had such a moment than not? I hope you manage to find a way were you get to do what you love.

I was in the same boat as you as a mostly self taught engineer. What really helped me personally are the following and I would like to share:

* Read “Clean Code” and try to apply the principles even in toy projects. I only have five years of experience but this is the most profound book so far in my career, and it’s one that is good to re-read every so often to keep it fresh and apply :)

* If you’re at a mid size company now with other engineers judging your work, then this is a great opportunity to review their PRs and see how they’re going about their business. You have a decade of experience and I’m sure you’ll both have suggestions and learn something. Hop on a video call and pair with someone senior or staff at your company.

* Do you have any ideas that you wish you could bring to life? Even a small ToDo app or something like that. If you can plan the requirements, design the application architecture, and choose a good set of libraries and tools to aid you, you will feel a huge surge of confidence that you have the ability to create. This is important. This would also aid you if you decide to become a PM because if you’re in charge of making a vision come true, what better than to be technically aware of what’s really going to make that vision a reality.

Just a couple things that helped me. All the best, and remember we are both student and teacher til our last breath so don’t sweat it if someone is younger/older at different stations in life.

Find a safe place to get high quality code reviews. I recommend high quality software projects like Rails or Postgres. The biggest aid to my creating better software is code reviews.

Also, put this[0] in your calendar and read through it once a month. Read through books on your stack, and choose a stack known for high quality.

I can't tell you the number of times I've worked with "senior" devs that weren't. The number one thing they had in common was hostility towards code reviews. Pay attention to the little details and start absorbing and following advice in code style guides. Take this[1] one, for example. Also, there are some rules of thumb worth following. I do my very best to avoid inheritance (outside of mocks / fakes for testing) and I move hard coded constants into config files with ENV overrides available. Avoid over-commenting and try to follow TDD if you can, since it makes your interfaces more from the point of view of the caller rather than the implementer.

It's hard to talk about these types of things over text, so if you want me to review some of your work feel free to reach out to me and I'll give you some more advice over a video call.

[0] https://en.wikipedia.org/wiki/Code_smell

[1] https://google.github.io/styleguide/pyguide.html

I've been doing a bit of evaluating/recruiting new hires, and I'd say that noone in their right mind would expect someone to be perfectly adapted at the start. With your background in mind, you probably feel like you have been studying alone for ten years, and are now going through the exams. The truth is that there are multiple right ways to pass this exam, and which one is correct depends on the workplace. It takes a few months to get in pace, and if they are sensible, they understand this.

My advise would be to talk to your team lead or closest superior and explain what you feel. It might seem awkward, but it's in everyone's best interest. Get some clarification on what the expectations are, and ask for an honest assessment. My wild guess is that it isn't as big of a deal as you think it is.

If you decide to stick around, my suggestion is to read a bunch of code that has been written at that workplace. Take a cup of coffee and go through a repo or two and get a sense of how people like to structure/reuse/centralize/test/style/document their code base. Then try to imitate it for your next task.

Best of luck!

Clearly you have moved to a better league and your performance has dropped because of it. It does not mean you cannot improve and cover that gap. Maybe just because of your environment or background you have missed exposure to learn what you now see you are missing. Now that you see what you are missing go and fix it. Knowing what you lack is a good first step.

Do not give up so early thinking on changing roles unless this is what you want to do. And notice that PM requieres a different set of skills. I even dare to say that the knolwedge gap could be bigger moving to a bigger company and in the way taking a new PM role. And learning PM without experiencing the role is even more difficult.

If I were you I will get a good book or on-line course and work on it on the side. Go to the sylabus of some good university course or some online course of the same sort and get some funcdamentals of computer science on algorithms and data structures. It might take you a number of months but you will enjoy and learn from the begining. The type of mistakes you say you did in that first role are pointing that you need some fundamentals.

A funny side-note, 9 years ago you asked about working with a bad engineer https://news.ycombinator.com/item?id=4783995

Maybe this is not applicable because your circumstances are likely different now, but you could look back at that time, think about what you would have wanted the other person to have done and do that.

Do you want to do better in your current position? Then the answer is to get better deliberately. Do this through seeking mentorship and studying up on where you are feeling less confident.

Seeking mentorship is simple enough, talk to those around you. Take interest in their work, and ask them to walk you through the solutions they've proposed and created. Ask for advice on your work, but do this in a 1:1 setting.

To get better by self study, I'd highly suggest beginning with systems interview problems. Each of them have a unique hook, be it a data structure, data model, messaging queue, etc. Understand the simplest implementation, and then go deep. Find the canonical implementation, and papers that use them. It's in systems and their interdependencies that you may grow fastest.

If you do not want to get better along the technical path, my suggestion is for your to find an outlet for your experience and interest. This may be in technical project management, as opposed to product management. This may be in QA, but it may also be other technical directions that don't involve software engineering.

I'm going to come at this from a different angle than the (good) advice that others are offering.

You say you started a few months ago; I take it you started remote and you've been remote the whole time?

I started my current job in quarantine and I've dealt with a ton of impostor syndrome ever since (I'd never really had impostor syndrome before this). I'm constantly feeling like a disappointment, wondering if they still want me, trying desperately to come up with ways to prove my worth.

I think at least part of that feeling of inadequacy is based in the lack of day to day, nonverbal feedback and interaction with my coworkers and managers. I feel precarious because I have very little data to go off of one way or the other. We even do one-on-ones, but still. A conversation about my performance once a month doesn't replace daily body-language, off the cuff remarks, expressions on people's faces after I've made suggestions or completed tasks.

Anyway: I'm hoping my situation will get better once I'm back in an office. Maybe yours will too.

Best of luck.

I write resumes for a living (yes, that's a thing) and have advised many HN'ers on career topics. When you're working by yourself you generally don't have any useful point of comparison as to 'how good' you are, and perhaps more importantly, you don't have anyone to learn from. Both are potential problems.

The best way to get some feedback on how senior you actually are is to do some interviews - practice interviews and interviewing.io is one way to do so in a no-risk setting, and the feedback you'll get will give you some ideas on things to brush up on.

As for long-term career, if you've managed to take home a paycheck for 10 years as an engineer you must be doing at least some things right. Finding a role with a team that truly invests in their employees and finding a mentor might be useful. In your case I wouldn't accept any job where you're the most senior person - if there is nobody at the company better than you, find another company.

> If you read my resume it'll seem I am a senior but I don't really know where to place me in the "experience" spectrum. I've always managed to solve the problems in front of me but in a "hacky way" and now the issue was totally revealed to me.

Man, you'd really benefit from reading The Career Stories Method by Carrie Twig [0].

It's about defining yourself professionally in a holistic way. It's not that you're a bad this or that, it's just that you're marketing yourself (to yourself and to others) not by the things you love and that you're good at. You need a professional narrative that's grounded in your personality. It's like that story about a fish being depressed because he feels he should be a dog.

[0] https://www.amazon.com/Career-Stories-Method-Career-Discover...

>I'm afraid it'll look weird for the company interviewing me to hire a semi senior with +10 years of experience.

Weird? Not really. They may ask you about your career aspirations (they may think you will leave a month into a new role) and you should have some sort of solid answer ready. If they straight up ask "Why aren't you going for a senior role" you can say that you're not comfortable with the coaching element that most senior roles will involve. Or anything really - the specifics of the answer doesn't usually matter.

>I'm not sure if I can be a PM if I'm not able to code things the right way myself.

A Project Manager (I assume that's what you mean) does not need to know how to code things the right way. It's a very different set of skills and even if you're a terrible programmer than you will likely be in the top 1% of PM's in terms of programming ability.

Sounds to me like you just need to get better at refactoring. The first working code for a feature should be a mess because it's a learning exercise. The important thing is that you don't stop there and push to develop; refactor the initial working-but-messy code so that it becomes well structured and self documenting.

+1 for being self aware.

The question you need to ask is simple; What do you want to do?

Just because you've come to the realization that you're not a good coder doesn't mean you cannot become a good coder. Most of software engineering is not about being clever. It's about being well organized and paying attention to details. Experience is largely gained, and wisdom learned, from screwing up. Then being able to recognize the screw up and understand how to prevent it in the future.

I have a firm conviction that most people can become productive software engineers. The main impediment I've seen to getting better is lack of interest in programming or an inability to learn from past mistakes. This is why I gave your show of self reflection a +1. The fact that you are asking yourself this question, and doubting your ability, tells me you are willing and interested in learning from your mistakes.

I'm not sure even "Senior" software developers will be able to understand badly written code at first glance. However what experienced developers will most likely do is make a copy of the code, open it up in a good IDE add a breakpoint and run it. Add your own comments to the code as you go along and figure things out. And don't forget to take some notes separately too.

As others have mentioned in the comments, you might be suffering from "imposter syndrome" but don't let it get you down. Some of the best out there have been through what you're experiencing [0].

[0] https://www.hanselman.com/blog/how-do-you-even-know-this-cra...

This might happen and I have had similar issues at one point in time. Sometimes, I feel I still have those issues but here's the things that I would do:

1. Instead of a broader approach, I would pick one side, backend/frontend/mobile to start with. I would choose the one I have the most experience with.

2. From the chosen above, I would pick the most widely used language/library/framework (Python + Django or Ruby + rails) for example.

3. Find some open source projects of medium scale and READ their code. Module by module. Reading the real code would polish they way no Uncle Bob or Martin or their books can. You'll intuitively get to know idioms/patterns/tricks of laying out abstractions and organising functionality and of course, testing it.

Hope you find it useful.

I think I've seen people I'd describe similar to the way you describe yourself.

Disclaimer: I think you sound to be quite a bit better than the 2 people I'm about to describe. Just to be clear.

Both people, lots of experience: 30+ years (while me and peers are not even 30 years old) and yet we look at their code (when asked to make changes, or we find a bug, etc) and it's like... We couldn't even write code like that if we tried for, e.g., an April Fool's joke. There's just way too much commitment to doing things dreadfully for it to be possible to be a joke. 1-3 character variable names, huge blocks of code copy/pasted, redundant hard-coded constants, bizarre abuse of scope, resistance to using functions and classes to split up code, god-classes and 5000-line functions when they do get used, etc etc.

And I never felt like their main issue was that they're "bad engineers" or "too old" or anything. It was that they were:

1. completely unapologetic 2. showed absolutely no interest in changing 3. extremely resistant to any process changes that would hold them accountable for code quality (like doing code reviews or using a linter or CI build process)

I think they'd mainly gotten away with just writing crap code for so long that they didn't want to have to change, or had internalized it as "I just write the code plainly, without using tons of layers of functions and classes and stuff". And don't mistake this as someone being woke in a herd of people building big towering oop abstraction factories. That job never got anywhere close to having too much abstraction in the code. People were always way over at the "low abstraction" side of the spectrum. There was no ORM use, no dependency injection frameworks, no unit testing and nothing was testable (because making code testable requires encapsulating and abstracting things into units, yknow), etc.

So I'd say the fact that you understand, have the humility to admit it, and want to do something to change are the biggest issues out of the way.

I would suggest looking for interesting videos and twitch streams that let you watch more experienced coders live-code. Not video courses where you're trying to learn a curriculum, but live-coding streams is a way to watch the process of more experienced engineers.

There might also be online mentorship platforms (I googled and https://www.platohq.com/ came up), but I don't know as much about these.

Related: https://www.cnbc.com/2019/11/24/doctors-are-watching-surgica...

Your real problem is that you've had no mentors and that's not your fault. Software people need good mentors. Always being at a place with few or none programmers never gave you the opportunity to learn by example and that 10 years wasn't very valuable. You have probably grown some bad habits and lack the understanding to recognize them.

If the people you are working with now are nice then you should take this as an opportunity to become the senior engineer you thought you were. Hiring people is annoying and if you are personable, humble, and eager to learn more often than not they would rather train you up than get rid of you. You did the fake it part, now do the make it part.

Read code from successful projects in languages you understand on github. Figure out why they're doing what they're doing. When you find something you don't understand, either search online for more context or ask another developer. You don't need to spend fifty hours a week reinventing the wheel, you just need to figure out why successful developers are successful. Books will close some of that gap, but nothing is as informative as understanding what and why something works.

I've coded by myself for my own business, for the last 10 years. The best tool I found to give me objective feedback on my code is Code Climate. You can upload your code there and get a grade and feedback, which helped me improve immensely. I also focused on learning how to write good tests and used a web app called "codecov" to understand my gaps. It's not an easy hill to climb so don't be so tough on yourself, just make some changes and improve.

First off it sucks that you feel this way, but its a good thing you are aware of your short-comings and what you feel you want to improve on.

You can definitely be a PM, most I know have no coding experience. Its an entirely different skillset. Maybe not a PM but a PO or management role if that suits you more. If it helps, my current manager realised after a few years of coding that he'd never be a great programmer (whatever that means to you) and went into management. Turns out helping other people be great programmers is a lot more satisfying to him and the background in programming is a huge asset for him. If you are a PM and you have more than just a superficial knowledge of programming, that is a huge asset.

As far as coding, I have nowhere near your years of experience, but focusing mostly on quality, clean code and really learning how to do stuff like write meaningful tests really helped me. Read Clean Code and A Philosophy of Software Design. Go find some people at your company who clearly have no issue with these things and pick their brains.

I don't think you're lost, just not sure about what you want to do with the rest of your years. Take a break and figure that out. You're clearly willing to learn so if its better coding, go learn, if not go do something else.

I don't have much experience in years or with complex tasks, but consider my code quite clean, as I worry about legibility a lot, and my colleagues often understand it clearly.

For code legibility, I suggest this course, which I found very insightful (1). I think this is a good first approach that solves immediate legibility problems: what to these lines of code do? .

For "medium level" understanding, I would look into design patterns. These can frequently cause ugly code when you use too many, but expose you to nice principles about composition, interfaces, inversion of control, etc. This provides answers to: what is these files/modules/classes do? I read this book for university and it was decent: (2)

I would define high level understanding as architecture. A clean architecture provides an answer to "what does this project do?" . I don't have a good resource for you, but would research about architectures such as client-server, consumer-subscriber, REST APIs, pipelines.

These are a lot of topics and you should definitely take your time in each one. Bear in mind mind these" levels" are just something I came up with, but I think they make sense.

1: https://www.google.com/url?q=https://www.pluralsight.com/cou...

2: https://en.m.wikipedia.org/wiki/Design_Patterns

Being a PM doesn't mean you have to code. In fact most PMs can't really.

Another option is to progress to team leadership. That role is more about listening to your team's good ideas and having good enough instincts to empower the good idea rather than you being a rock star developer yourself.

Alternatively you can just keep doing what you're doing but use this awareness you already have to continually up your game. Even the best of us are constantly learning.

I had to respond on this one! I'm 47 and don't code "full time" anymore, but do spend at least 20 hours a week coding (mostly because I love it, partly because it's good as a business owner to look for better ways to cut costs and improve the UX at the same time). If you have some domain level expertise for a particular field and _also_ know how to code you will do very well indeed. You will do great if you know where your weaknesses are and work on them. The best coders I have ever worked with were folks that were humble and knew they didn't know $%&!. So the fact that you are willing to say you aren't great makes me believe you are better than you think.

My only advice (disclaimer not a sage here) is to continue to specialize in an areas that hasn't been commoditized yet and to work on the process, rather than the specific technology. You don't need to know all the "secrets" of a language to make you more productive. That will allow you to charge higher rates than for example commodity developer. Also, another great way to work on weaknesses is to teach others, learn by teaching as they say.

I'm sure you will do great things keep it up, love your attitude.

I work in software sales so I get to see things from a slightly different perspective here that might be valuable for you to consider.

Over a decade with a handful of different vendors I've worked with, I have had "are they seriously asking us this question? how could they possibly not know this?" conversations with internal tech people at least once a day.

There are people and teams everywhere who have been assigned projects over their head - many with more fancy titles than "senior software engineer". Often we as the vendor are literally writing or correcting code they've written in order to solve the problem. And we're able to do so with minimal context because the mistakes are so basic. Sad to admit - but the reason they often buy software is that they're lost and need help and have no where else to turn and there is this nice vendor who they can email stuff too and have it returned fixed bc they're trying to close some million $ deal.

So yeah, par for the course. I guess don't be so hard on yourself and just focus learning on the job (that's what everyone else is doing). Software sales or a sales engineer type role could be an easy transition as well if you just want out.

Good luck.

Several of the PMs and UX people at the digital services agency where I work have compsci degrees or some experience as developers. Transitioning into developer-adjacent roles is a kind of graceful exit from development where your experience is viewed as a positive. A PM who actually understands development and developers is much more effective than one who doesn't. A UX architect who knows what's possible, what's easy, and what's hard has a big advantage too. Overall, you mesh better with the development team on a project than someone without your experience.

On my side, I like working with these people because I can communicate much more easily with them on technical issues.

As a bonus, you would be entry level, but it's not a weird issue to be experienced and entry level moving to a different field, and another bonus you have is that, having 10 years of practical employment experience means someone looking at hiring you can reasonably assume you've already learned to be a good employee and won't need to be handheld through basics like "don't be late" and "communicate appropriately in a work environment".

One word: Epistemology

Having been at this for over twenty years. The one distinguishing factor I've found between the great and the good, is their personal epistemological process; How they seek out, evaluate, and incorporate new knowledge, then transfer that knowledge into skills. The good ones have a great process for this, and they do it constantly.

Mad props for recognizing your problem, there is a solution, and it is the thing to which other posters have mentioned. I was in your same position about 7 years into my career. I went from a small town, in jobs with 1 or 2 engineers, to a major city with thousands of very talented engineers. I nearly drowned at first, but I rose to the challenge and adapted and you can to. Every day will be like drinking from the firehose for a while.

You should be learning. Constantly.

Being in small shops, you likely suffered from the fact that your work was not being challenged, and therefor you were not being challenged. It is easy to get comfortable and to stop learning and growing in this state.

When you are frequently challenged, you have to seek out new ideas, algorithms, techniques, languages. This all adds to your knowledge base and skill set.

If your company hasn't outsourced coding to eastern Europe or Russia yet, just wait. You'll become a de-facto PM that way.

Beyond that pair program and read the books suggested here. Practice and review some open source projects. Maybe refactor some code. That's really all it is. Basically keep writing software and practice.

Junior devs get assigned bugs to learn the code base. So do the same thing with open source.

I know people like you. One's a great product designer, technical enough to understand literally at a glance what needs to be done to solve the user's problem, but there was a great skill gap when it came to his actual code. I still have HUGE respect for his work.

Don't sweat it. You're only "bad" because you haven't exercised the proper skills. If you want to keep coding, skill up! Maybe take a course online that will show you the proper techniques for working in e.g. JavaScript. Learn the design patterns that will give your program the "proper structure". Then start looking for jobs in the field. You've been at it long enough to have an advantage over more junior peers with more experience coding "the right way". At the senior level, soft skills start tending to dominate technical acumen. Play that card to your advantage.

If you hate coding, maybe the softer aspects -- PM, PO in an Agile shop, Scrum master, UI/UX design -- are right for you.

It's up to you though. It's not too late to build your skill on the coding side of things.

Don't become a project manager.

If anything become a product manager. It is a desperate need to have product managers that have some inkling of what it's like to develop software. In some places this might be a semantic difference, but project managers seem more about people and scheduling than understanding a software product. Your background will be more useful a bit closer to the code.

If you are interested in continuing to build software: everybody sucks.

Difference is: some realize it and some don't. You are a rare person that made the jump over the chasm.

We all take shortcuts. We all compromise. And none of us knows enough to have the perfect solution pouring from our fingertips at any given time.

Guess what? Those things you've identified? Yeah. Bad. But even after you fix all of those, there are hundreds, maybe thousands more waiting for you to identify them and fix them.

And when you fix enough of them you'll realize that striving to code perfectly is, itself, a code smell.

And you'll start doing some things 'wrong' on purpose. Why? Because it's all a trade off. And you're not coding to code, you're coding to solve a problem. And sometimes that problem doesn't need perfect code to be solved.

All of that 'bad' code you've created? It solved a problem. It's probably not as bad as you think, given the parameters of the problems you were solving.

By all means, fix the problems you see. Try to do better. Learn from others. Rinse and repeat.

You have to enjoy that journey because it should last a lifetime.

And if you don't, there's always product management.

Had you been a bad developer you would have failed at the smaller companies. People thrive in different environments, and it can be jarring to go from a small shop to a large shop. They're different animals.

I've worked at places where I'm the either the only dev or one of just a few. It's fun and it's easy to impress, but also easy to develop bad practices. But as long as you're getting the work done and your boss is happy, you're doing a good job. Larger places will be more formal (code reviews, sprints, very large code bases, etc etc). It sounds like you're beating yourself up for struggling with a task others thought would be "medium" complexity. It could just be that it's medium complexity to someone who knows the ropes at that particular company. It can be awkward to adjust to having more eyes on your code, but if you survived in the smaller environment, then in time you can adjust to the larger one. However, if you really feel out of your element, you may just want to go back to the smaller shops.

I too am in the same boat. I do not have people skills, I am shy and introverted. I am considered as a non lead material since my manager thinks that I am very soft spoken and so I am told I need to be aggressive. I don't even know what the solution is. With 12 years of experience, I am in the same band as a 7yrs experience colleague.

What am I doing to overcome this situation? - I have clearly understood and made up my mind that I cannot be a PM. - However, to stay in the job I always have to prove my technical skills. - I am trying to get into competitive programming which I discovered recently and my aim for 2021 is to at least solve one codeforces round - I started enjoying Flutter and I also did 30 days of live streaming on youtube (Just screenshare with music). - I have a mobile app idea that I plan to work in coming days. - I try to write 1k words per day

During work hours, I try not to think about hobbies and concentrate on finishing my work. However, during free time, I fire up my personal laptop and start focusing on my hobbies.

It's kind of a fork on the road yeah? I went through a similar process...

It turns out I had real issues with CPTSD and other things going on that interfered with my ability to perform at work. What's worse, I didn't even know I was this bad.

Your reasons may be different. I actually really like doing my job even though I know I'm not the best.

for my case I had to stand back and realize what was actually really important to me and what would it take for me to just really throw myself into a job, to really just get good at something. It's kind of hard to say with your situation cuz it could be different you know?

For me, it was figuring out what exactly high-performing meant, what it took to achieve excellence and what the path looks like. There were also drugs involved.

I'm reading some anxiety in your message, like looking weird etc. does it really look weird or is it something that you're just sort of afraid of?

All I have is shitty advice, but I went through what you went through. :-( I don't know what you're specific situation is but your story reads a lot like mine

There's a difference between software quality and software value. Maybe your quality is low but you can still add value in the right places on the right problems by understanding the context and use cases. Focus on that and you can still have a career.

There are tons of examples of software teams weighing down their organizations with excessive investment in software quality and not enough on the business case and delivering value. Be a value-oriented developer and work for smaller organizations that necessarily prioritize value over quality. Learn and improve your coding practice on the job.

There are lots of bad programmers making useful things every day. We've all written bad code. You are not your code. Coding is actually just one of the skills of a good prigrammer. Sounds like you've picked up some others, too. Build on your strengths. Write more code, watch videos, read books. If you don't enjoy programming, find a different career. Not everyone likes to program, but if you do you'll improve by doing more of it.

Seek an opportunity with mentorship by someone who is committed to your growth, on a team with good hygiene and respect for learning. Rebuild your identity. You have career value. Don't throw it away. Transition to a different direction from a place of success and you'll carry that self-confidence and story of redemption instead of regret.

I am 58 yo computer dinosaur soon to be extinct and I feel confident to give some advice before it happens.

The rules of structured and systematic programming are not difficult to learn and acquire. So the question for me is do you like what you are doing? If so, you could arrange with your employer to have some time out for qualification measures. Or you could do the same between jobs. It could be an online course specialized to your field or one more general. Also you could just study for yourself. For continued success in the computer field there is no other approach than 'life long learning' nobody can know everything. I am self-employed and I regularly take qualification time off where I extend and refresh my knowledge in the field. It is never a mistake to acknowledge our limitations, it is a mistake to give up something we like just because we feel we could be better. Nobody stops you to become as good and as competitive as you want.

All the best!

There's a thing called the imposter syndrome, which a lot of software engineers seem to experience through their career.

Also, one needs time to get used to a new project, new environment, new colleagues, etc.

In every domain, the more you learn, the less you feel knowing about, and that's a good sign.

In this industry, the ones that make it, are the ones that keep on going forward.

Like you I’ve been developing for over a decade. I work with a lot of similar people. I still encounter people who hardcode this or repeat that or whatever. Never run the linter or used git poorly. I don’t mind at all. The value good developers bring to the table is the ability to learn, solve problems, and collaborate with me.

You can get better at writing code, but many people can’t figure out the other things. That’s when it’ll never work.

You recognize your shortcomings so you can work on them. Most people don’t, in my experience, and developing software with them is a struggle at best and a dead end at the worst. You’re probably better off than you realize.

I’ve also felt like you do at times. It’s normal to feel down on yourself, especially if you’re exposed to very talented or skilled people. But it’s all fine. You can catch up, and you probably bring something to the team that’s still very valuable.

I completely understand how you feel. I started off programming for only a handful of years before realizing that the most differentiated thing I could do was communicate with multiple groups in language they care about, talk confidently about complex subjects, and find business value in neat technology for my company.

Are you interested in being a PM? You for sure do not need to code to be a PM. It can help, but what you do need to do is communicate a lot and figure out how to make the company money. There is usually not an obvious answer as to what a PM does day to day and I have experienced organizations that have extremely differing ways of using them. I find it engaging and exciting, but I also get to be a human punching bag for when things go wrong. Takes a lot of person management and self management to do. For sure not for the thin skinned or introverted.

I'm coming in late to the discussion, so there is a good chance you won't see this which is okay, it's a reminder for me to apply this advice to my own life.

I read a few years back (long since forgotten where) in an advice thread to new people that you want to be careful that as you spend more time in your career you want ensure your experience levels up too. And there is a difference between 2 years of experience versus 1 year of experience 2 times.

There is already a lot of great advice in other replies. What many of them are getting at is being honest with ourselves what our actual level of experience is, and shaping the environment to best help level up the skills we need to improve. It sounds like you have already done one very difficult thing - moving to a position that forces you to improve and see clearly where to make changes.

I don't think you are a bad software engineer, most probably you are just not used to work in a big team. You are new in this middle size company and you are given the very badly written code which you are not familiar with at all. Most probably this code is big and exists for the long time and was modified chaotically to satisfy the urgent needs of customers. It is almost impossible to become efficient with this code immediately. May be I am wrong, but it seems you tried to work on your task without getting enough help from another people how know that code much better. The fact that your role is senior doesn't mean that you need to know everything and need to solve your problems alone. I work in a big company as a software developer and the interaction with people is the most important thing here.

> I'd been assigned a medium complexity task and I've failed to accomplish it, the code was all filled with hardcoded values, wrong structure, difficult to debug bugs and similar things.

First thing is work out to spin this properly - you're seeing this as a failure with hindsight, but why is it really like that? E.g: were the requirements firmly defined or were you trying to hit a moving target? Were you trying to appease too many owners? Were you lazy? Lack support? The most valuable thing you can provide is some objective context around why things are the way they are. Theres also different "software engineers". Maybe its the company type that you dns fit in well with? Rule number one: cut yourself some slack like you've probably given the other folk involved in the project.

Stop (if you are) using trial and error, hacky approaches to solving your problems.

I can't comment on your domain complexity but this in itself helped me improve a lot.

Just try to understand what you are doing and why you are doing it. The idea that a problem should be 90% analysis and 10% execution has a lot of merit.

You've characterized your performance as "bad", but I'd challenge you to do a little more analysis. You can learn a lot from retrospecting over projects you've lead, especially as they transition into the hands of other people, who will inevitably find faults that you missed.

You're probably not bad generally but made some more specific mistakes. Maybe you rushed in without thinking about the use case. Maybe you didn't seek input early and had to go all in on a flawed design. Maybe your design could be made more modular with some careful diagramming.

If you get specific in your self review, you'll probably find a few actionable lessons, which will be more useful than this general sense of "badness".

By the way it takes competence to spot your own mistakes. Cheers.

Just commenting to encourage you to keep at it!

I was in sort of the same position, and I found that my prior experience gave me a decent framework to hang new information on. I only realized this after 9 months of solid panic.

> I've always managed to solve the problems in front of me but in a "hacky way" and now the issue was totally revealed to me.

You solved the problem in a way that makes sense for solo development. Hardcoded values suck for other people. What's been revealed to you is that you don't know what interfacing with other people looks like.

Once you get a handle on communication I think you'll find that a lot of your experience is directly transferrable. What makes you a senior developer is your understanding of the process you're operating within.

Good luck and go get em, tiger!

>but some months ago I decided to go to work on a proper medium software company.

I'm barely sure what that actually means in practice, day-to-day. If that's really what it is, they should know how to help you get up to speed and understand your situation.

Your core feelings here (not to be dismissive) seem to be about them "finding out" and suddenly firing you. It's remotely possible they do that, but unlikely. Even if they do, it was just a company you don't qualify for. It doesn't diminish the previous work you've done.

There's a lot of advice here already about what to do within this company, so consider the worst case: you fail 2-3 more times and they ultimately fire you. You still have something to fall back on by going back to your previous work.

“the code was all filled with hardcoded values, wrong structure, difficult to debug bugs and similar things”

to me it sounds like you are catching on quite fast. so why not just read a few books on best practice for the language you use, and within a year you will be in a much better position.

As a bad engineer who switched to PM 20 years ago, here are some thoughts: - do you have a high tolerance for bullshit and stress? you will get more BS and stress in a PM role - are you good at persuasion or want to develop that? As a PM or a leader, persuading people is going to be your primary skill - do like understanding systems and ecosystems? You still need to be able to understand systems and how to change them (either technical systems or organizations and how they make decisions) - can you explain complex topics concisely and accurately? - can you explain abstract (desired future state) concepts to other engineers in a way that they can understand?

Hopefully these questions will help you decide if PMing is in your future.

I am a Sr. Product Manager that considers himself at best a Script Kiddie. If you have a firm grasp on logic and conceptually understand how the modern stack works, you can be a successful Product Manager embedded with an engineering team. That success hinges on the relationships and credibility you build up with the engineering team. It helps if you can remain conversant and can join a conversation about technical / business tradeoffs. Mature teams will abstract away the second order technical complexity when interfacing with the PM and will translate why things are hard, costly, and risky.

Obviously there is a whole other skill set that is required for a PM but those skills vary depending on the organization.

I had a similar feelings, even though the circumstances were different. I worked in medium sized companies for 7 years before getting into FAAMG. I thought I’m a decent SWE who knows patterns, processes and can deliver high quality code.

First couple months there were hard. My PRs were teared apart with tons of nits, I had troubles communicating as I was embarrassed.

Dev process was also very slow with a lot of back and forth. I felt I was doing something boring + doing it so slowly I stopped caring.

It was miserable and I quit after a year. Looking back, I glad I did. The company did teach me something, but I also wasn’t compatible with their slow moving culture. Did some very interesting work after I moved on and my carrier skyrocketed.

That you've gotten this far as a freelancer means you're able to complete projects and interact with customers. I would argue those skills alone make you a senior engineer.

Over the last couple years I've transitioned from thinking of code as "hacky" versus "elegant" to thinking more in terms of maintainability. First the code has to work, but then I have to be able to understand it when I inevitably come back to fix it in a year. Toward that end I will second the recommendations below for "Code Complete" and add "Working Effectively with Legacy Code". These two books transformed my views on what makes good code.

You are being too hard on yourself. We all suffer from "imposter syndrome" but you seem to have taken it very hard.

See the post from "yowlingcat" in this thread for a positive outlook.

To add to the above, If you have already spent 10 years in this industry as an SWE, you cannot be as bad as you think you are. Yes there will always be much to learn and you might have some catching up to do but that can be fixed with studies and collaboration with coworkers. Do not give in to self-doubt and quit your job; particularly in these difficult financial times. Ask for help, mentorship and study/work hard and you will grow in knowledge and confidence.

If you feel motivated to improve, then do it. The greatest strides I ever made was when I realized that I needed to level up to fit in with my new team. That means studying their code, structure, habits and emulating those. Every time you right code, think about what others on the team would say about it.

If you don't really like what you do, it's perfectly fine to try out project management. Management involves its own skill set, but being a good developer is not a requirement. Knowing how to write a little code yourself and being able to empathize with your team is a rare and useful ability in project management.

You know there are issues, so that is a good thing.

Hang tight. You can clearly learn to fix these issues and become better at building/architecting solutions. Spend some time reviewing projects on github and see how others have tackled the issues you are struggling with. Practice by creating your own projects. They don't need to be complete but will allow you to try different strategies for structure, hard coded values etc.

You could become a PM if you really wanted to... the PM's I work with have zero coding experience. This would be difficult for me as I don't see a PM as being creative and I like to build things.

You can do this!

Now there's actually hope for you ;-)

> Do you see a man wise in his own eyes? There is more hope for a fool than for him.

Copied from https://www.biblegateway.com/passage/?search=Proverbs+26%3A1...

Really "seing oneself" is incredibly valuable. If one gets a glimpse one should think more than once about it and use it to take action to become better.

Just forget where this is from if it makes you feel better, in this context it is just the oldest written source of this saying that I am aware of :-) :

Imposter syndrome is real. At the same time, it seems like you've noticed things you could improve.

Give yourself more time to iterate and fix problems, give yourself some time to iterate this code and fix the basics.

For things of medium difficulty, I've found it good to prototype things outside the codebase, inside a jupyter notebook until the bit of code I'm working on looks right.

For some things, stepping away from the keyboard and making a list / diagrams can definitely help.

Just try to carry on improving, it's all you can do.

Once you've done any project it's easy to think of ways you'd do it differently / better a second time.

Question: did your bad habits never bite you before? If they did, what did you do about it. If not, that’s either unfortunate or you didn’t notice.

The only case where I would expect you to change this trajectory is one where you legitimately had no need for best practices before now. In some contract work, this may be the case.

Otherwise I would say PM is a better path for you. In fact if you’ve gotten this far, I’d imagine you put a lot of emphasis on the deliverable itself and ensuring it works right, which is all a PM cares about anyway. Your description of yourself is far more technical than most PMs I know.

Don't beat yourself up - if you've gone 10 years without failing at a task then you did a lot better than I did.

At least you recognise where the problems were - why not try and fix those problems in your next bit of work?

Slightly offtopic, but don't get hung on job titles.

I'm a mid-level software engineer in a large company, and I'm in my mid 30s. Certainly I'm in the older side of this tenure bracket, but I'm far from the only one.

This is the thing: my current position has far bigger scope and impact as a mid level than senior+ roles have at other companies. Also, we regularly interview people in their 40s for mid level roles.

Bottom line, if you want to improve you'll need to let go of personal ego and what others might think. It's certainly uncomfortable, but it's also the best way to improve.

You are humble about it and willing to learn; don't underestimate how important that is. Being in close proximity to other developers has helped you see ways you can improve, and it will help you improve quickly.

Do code review to learn from the code of others and pick one thing a day to focus on in improving your own code. Improve at that thing.

Refactor your code and see how you could do it differently using the new principles you learn.

Find someone who can mentor you by doing code reviews for you; having someone to help point out a better way to do things can save hours of searching for it yourself.

Seniority is in the eyes of the beholder.

But what you say makes little sense. You think you're not senior enough because you can't debug piece of garbage?

> I've also thought about transitioning to a PM role

Maybe you're just tired of working with code. That's alright after 10 years. And it's ok to want to try management. I can recommend reading this https://charity.wtf/2017/05/11/the-engineer-manager-pendulum...

If you were a bad engineer, you wouldn't care about hardcoded values, wrong structure, difficult to debug bugs etc.

I've worked with different types of programmers. Some weren't great a writing solid, well documented, well structuted code. But they were really good at understanding what the customer wanted and hacking together a quick and dirty 'good enough' solution for the customer and then moving on to the next problem. Maybe you are one of those? Or maybe you just need more exposure to best practises?

A lot of people I know do not progress in development because they are unable to reflect on their work and performance. You've just made a first step that many people never make.

Well, realizing you have a problem is first step before you can fix it.

Don't feel bad about this.

I would suggest -- stay where you are. Avoid commotion (like changing jobs).

You want to get some throughput to spend some (hopefully significant) portion of your time to improve your work.

Keep an eye on deliverables but try to focus on improving particular aspect of your work with every task you are performing.

I feel the same way. I have been at the same company out of college. I don't work with any real software engineers. I haven't learned like anything. We have no tests, no ci/cd, no code review. I haven't gotten any real feedback on what I have developed besides it works/doesn't work. I need to get out NOW. I have been trying to practice for code interviews but I've forgotten everything from university. I am always burnt out after work. I need to fix this ASAP.

It does not necessarily mean you are a bad software developer. Each project has different setup and is done in different way. It just takes some time to learn it and work with it. Don't be discouraged. If you made your way so far with a backup way, you are perfectly fine to learn some ways that bigger teams use. Actually you being able to solve stuff on your own, being self dependant and being able to find hacky but working solutions is your adventage you can use to help teams move forward.

I used to be pretty bad too... I think it took me about 5 years to get to decent... and probably 5 more to get to damn good. A lot of software is about having the right mental models... for me the book that helped was Steven's Advanced Programming in the Unix Environment... after that book I knew a LOT more about OS's and all my mental models were improved greatly.

also learn to recognize what parts you don't know and figure those parts out with tiny test programs... THEN code your solutions.

I think the level of transparency on display here is really inspiring. I'd apply that same level of candor in a meeting with a peer or a higher-up and basically tell them that you are dissatisfied with the quality of the work that you deliver.

A good manager or colleague will be really receptive towards that kind of openness. They'll be able to help you cut through the "bs" so to speak and help you separate impostor syndrome noise from actionable facts.

Not to sound like a jerk, but I feel like I have completely the opposite problem. I work at a large software company as a senior engineer. Every problem is way too easy and uninteresting. I don't do much work most days and complete all my tasks for a 2 week sprint in a day or two. I work on side projects in new technologies just to keep myself sane. Most recently working on blockchain dapps because they are such a departure from traditional architectures.

The fact that you're realizing you don't know anything already puts you ahead of most "senior" developers.

We still treat software like a traditional job, where time-in-field determines bulk of who gets sorted into what role.

Software comes with both soft and hard skills. Maybe you feel you're lacking in the hard skills (the actual coding) but do not dismiss the soft skills you've accumulated in the last 10yrs.

Just to be clear, Product Management is not really a backup role for bad Software Engineers, unless that is what they were really good at instead of coding.

If you are bad at PM you can do mid-long term damage to a product which is not fixable like a problem in the code.

PM might have coding experience or not, it helps a lot if they do, but good PMs have a set of skills which are completely unrelated to being a software developer.

My company is starting to move away from custom software development for our clients in favor of leveraging and configuring commercial software packages and services. You might need to create a python script or a make a few API calls, but most of the job is learning how to get the software to solve the client's business needs. Maybe you would enjoy that more? Maybe we could switch jobs. :)

Are you sure you’re just not used to the way things are done at bigger companies? When you work in a small team or by yourself on small projects, you might not encounter the opportunity to fully flesh out solid architecture and coding practices because it’s not in the budget.

I imagine after a little while working in a different environment, you’d adapt to the new way just as you had adapted before.

Most of the "senior" engineers I know don't care about the craft and are pretty mediocre developers.

You faked it until you made it. You care about becoming better.

Just work harder on your skills and get better.

Learn about best practices, learn from your mistakes, learn from code reviews from better developers, look into OSS, contribute to OSS and get feedback by better engineers.

There is no reason to sabotage your career over this.

As the old guy here today, I'd like to add another note.

Stop judging people. 'You' are not a good or bad anything. You do good or bad things.

Some people here talk about knowing a bad programmer or project manager. You will be happier if you change your mindset to understand that the person isn't a bad anything. It's just that you don't like their code and that can change.

You've encountered a Legacy Codebase. They're everywhere, and they are awful.

There are ways to work with them, and you can learn them.

If there are people you can ask and work together with who already know the codebase, that is by far the best way.

I mean, you could be an incompetent programmer, but the fact that this codebase is very hard to get into doesn't prove that at all.

If you want to improve, you could find an OSS project that is in your languages/area and start contributing (ideally find a professional OSS project that is basically full time devs and outside contributions) - this will help you write code following specific standards and they will help you.

Be nice, don't expect instant replies and be useful.

Why not try a few different things and see how that goes? Your idea with becoming a PM sounds intriguing. You are likely technical enough to understand the 'how' of what's being built. Remember, your job as a PM is to own the 'why', you should intentionally stay away from trying to manage the 'how'.

>I'm not sure if I can be a PM if I'm not able to code things the right way myself.

You don't need to know how to code the solution to be a good PM, it's a different set of skills.

QA - writing testcases, automated regression tests is also a possible path. Lots of companies want QA engineers that can write automated regresion tests (selenium etc)

So a couple of things:

If the first thing you failed to accomplish after 10 years was a medium complexity task, consider yourself lucky in some sense. Also, who determined the complexity level of this task, did you decide it was medium complexity, and if so is that corroborated by the team?

Moreover, most "bad" programmers don't necessarily think they are writing bad code, did you come to this conclusion yourself? If you did, it seems like maybe some other factors came into play, maybe you didn't have enough time, maybe the requirements were unclear. In either case, 1 failed task seems like a lot to evaluate 10 years of a career on; having recognized this behavior in myself, you might be catastrophizing this failure in a way that's not productive for you.

If you received this criticism from somewhere else, that's okay too, being "over 30" isn't some death sentence, there's plenty of time to reinvent yourself, start a new career or rebuild your skills from the ground up - if that's what you want to do.

Maybe part of this is just, you aren't sure you want to be a programmer and you are using this "failure" as a kind of escape hatch, which you know, is also fine. Or, maybe you aren't sure you want to devote the effort you might think it would take to actually improve as a developer

I would say, check in with yourself, and figure out what you want to do or at least what you don't want to do. I wouldn't change careers simply because you think you aren't good at this one. Being a PM, has a whole other set of challenges (but if you are actually curious, the idea that you have to be able to "code it the right way" should not be a blocker).

If you do decide you want to become a better programmer, realize it's not going to happen overnight, but conversely it's not going to take as long as you think. But you do have to start somewhere. Rather than ask on HN, I would go find someone whose technical opinions you trust (you mentioned talking with people in the industry - hey developer evangelist is also a role out there for you, heh), and ask them to review some code you've written and have them articulate those weak points, and start from there.

If you decide to start, just remember to start small. It doesn't have to be late night grinding sessions, 15-30 minutes a day reviewing a topic, solving a code challenge, reading a chapter of a book - can really add up after a few months.

The fact that you have the self knowledge and modesty to admit that you're bad makes you already a better employee than 80% of your colleagues. Also your honesty to admit your own mistakes will allow you to grow and improve.

You should congratulate yourself, with your mindset you have it in you to become one of the very best.

Everyone writes shit code once in a while. If you're aware of your shortcomings, you're likely better than you realize.

What helped me significantly:gGet on a team with devs who are better than you, where PRs are actively reviewed, and get as many PR comments as you can. This may mean moving to a larger company.

Suggestion: I've found that doing a graduate CS degree really helps me build a theoretical foundation which has made me much better at my work. Example: a much deeper understanding of the HTTP protocol and the client-server model, and how it relates to the world of networking and computing overall.

> A third option would be to take a break from work and try to learn to write good code

I would say that learing to write good code takes practice and feedback, so if you want to stay in software engineering stay in your job.

Maybe switching to a field where basic coding skills come in handy, e.g. data science, would be an option.

I’m a product manager partly because I’m not a great coder. Other engineers are faster and better, so I wanted to add value by helping figure out what they should actually be building based on user needs. It has its up and downs but you can still do well without being the most proficient coder.

I don't see what the big deal is. Just go back and improve your code. Your team needs to be patient, nobody should be expected to push perfect code in every commit, even seniors.

If you can spot your own code smells, you're doing fine. Otherwise, read up on how to do so. I recommend Code Complete.

Please don't fret. I can't be specific, but I have worked with a wildly successful engineer that wrote "bad code" and knew it, but came up with some useful paradigm-shifting ideas in their space. I would be glad to chat more if you are interested. Don't give up.

Honestly just don't be a jerk. That's half the battle.

As long as you listen when I tell you hey this is how we can fix this. I actually left a job because of exceptionally bad code , if your attitude is to get defensive when you obviously don't know what your doing , that's an issue.

most bad engineers I've experienced have no idea that they're even bad, in the sense they can't identify what's wrong with their code or even be aware of hacky patterns.

that you can self-critique would indicate you potentially have a great future of leveling-up ahead of you.

Not even digging about if this is really not the case, I question the premise that you should be a senior software engineer after merely 10 years in the field. In tons of other area, this would certainly be considered a criteria for "seniority"...

Just realizing this and being able to verbalize this makes you way better than 90% of people in IT.

Most senior consultants in Accenture are big dummies that know tech buzzwords. Most of them have never used an IDE.

So I would say your doing good. Don't worry you are good software engineer.

Same here. I'm a senior developer with 8+ experience. Never coded in any job with seriousness. My code is as bad as my handwriting. I started applying monastic orders and I'm left with one as others have rejected my application because of age limit.

Recognizing the problem is the first step in solving it. It's good that you are dissatisfied with yourself and have specified the reasons for your dissatisfaction.

But since the problems you gave are so specific, it is obvious that the solution is to solve them first.

If you do want to take a break to catch up, I strongly recommend making contributions to large open source projects. They are a fantastic experience in learning to maintain large complicated codebases with a constantly updating set of contributors.

Being able to hack together code without formal education gives you a very unique skill imho. It’s not the same skill as writing large code but just as valuable and maybe even rarer as you can’t really learn how to hack things together.

You've taken on a new challenge, and that's great. You're missing a few elements of coding style, particularly the elements that make code easier to read and maintain for a team of engineers. That means you're new to devoping on a team, not that you're bad overall. Your co-workers may take these things for granted, but you have your own skillset, like the abilities to manage time, hit deadlines, and solve problems completely independently. (Those will be seem to be missing for a while as you grapple with a new codebase, company, and team, but they're still there!) Think of learning coding style on the job just like learning a new language on the job, and ask your co-workers to be patient and point out how you can improve while you adjust and onboard. It'll go faster than you expect!

Give yourself 6 months and find several people who can show you expected work. Read code until you see how it can be done better. Most corporate code is pure garbage, so don't sell yourself short.

Just the fact that you realize there's some things you need to work on is proof itself that you do belong there.

You pointed out specific issues with your work, so you can go about improving on those thing.

Keep your chin up.

Why would you need to be a great coder to be a Product Manager? The challenge will be proving your product chops. Being a bad coder is quite good enough technically to be a good PM.

Since you recognize it - and it sounds like you’re able to get work... I think you should start a software company! Be a product person - hire people smarter than you to code!

HTDP.org? There's so many good learning resources. How much time have you dedicated to improving?

There's also SICP. The first chapter leveled up my recursion skills forever.

Dont forget you are not bad until other people realize you are bad.

Keep working. Most of the failures you have identifies seem to be resolvable by learninh good practices in 1 week.

From what i've seen most ppl in your situation try to go into engineering management.

My advice would be try to get into managment positions where you don't have to code.

You worry too much, friend. Most of my colleagues are positively clueless, and this is at a FAANG company. It's often a matter of drive.

you can write perfect code who nobody will use or crap code with millions of users. focus on delivering maximum value over some ideologies or dogmas. purity is overrated focus on value means as well to find the perfect balance between good architecture, timing, maintenance and value for users. good luck and don't get the judge inside your head beat you up.

Just learn to code. During work. As Senior Freelancer. My experience says that there are enough out there that are doing the same.

There's this myth that the PM must have knowledge in the field. The best PM I've ever worked with never touched code.

Emotional maturity has way more value, thanks for being honest with yourself and the others. I wish more people did that.

IMO, see if you can find a government or big corp position where things move slowly and nobody really cares about the job.

10 years is way too long to stick with anything you dont like, i'd say jump ship and try something else.

Well do you enjoy programming? If so I would say stick it out, you'll get it eventually

Suck it up, learn and keep trudging dude. Lots of us have been where you are! Hang in there.

I guarantee you can be a PM without being able to code things the right way yourself.

Don't be discouraged! Sounds to me like you're just growing up.

Young developers (in both actual age and years of experience) tend to think they're amazing and better than others. (This is true in many/most fields, and was very true for me.) And then as you get better, you discover how much you don't know, and start to feel worse and worse about your abilities.

There was an XKCD comic about this, but I can't find it. In essence, given any field, the journey looks something like:

1. I don't know how to do X, so I'm going to learn.

2. Wow, X is awesome and I'm awesome at it!

3. X is a little more complicated than I realized.

4. OMG, X is hard and I'm shit at it.

5. Maybe I should give up on X.

6. Well, I'm not the worst person in the world at X. Bob's worse than I am, and still somehow gets paid for it.

7. I can now see all the things I don't know, but at least I can start learning them, one by one. This is going to take a while.

8. I'm now better than most, but there will always be more to learn and someone better than me. I accept that I will forever be a student at X, and so is everyone else.

Or, as the old adage goes: Fools think they're wise. The wise know they're fools.

The first question you should ask yourself: do you like being a software engineer?

Changing languages might be a hybrid approach that allows you to take a step back.

"the code was all filled with hardcoded values, wrong structure, difficult to debug bugs and similar things."

If you can identify the problems you are 70% of the way there.

Also, PMs don't need to be able to code.

If you have good interpersonal skills, you might just shine in such a role.

"Senior management material" written all over you.

The first step is acknowledging your current limitations, and you’ve done that admirably. Next, I encourage you to give yourself grace. Know that many of us have been in your position, and have been able to build on the experience and develop our talents and careers anyway.

If you do want to improve your software skills (and it’s okay if you don’t, but don’t be discouraged just yet!), my main advice is to surround yourself with people more talented than yourself, whose work you admire, and who have the patience and social skills to mentor you. This is how I went from basically you’re at now... to being one of those mentors for others. I learned to drop my ego, to embrace rigor I’d previously considered onerous, and to be transparent when I had room for improvement.

I’d also recommend spending some time learning something far outside your comfort zone. For me, this was learning functional programming (Clojure) and working on distributed systems in that environment (previously I’d been primarily a frontend dev).

Getting involved with an open source project is also a great way to get exposure to both the talent and learning opportunities I discussed.

Lastly, I’d recommend pushing yourself to embrace some rigor yourself and see how it improves your work experience. If you don’t do TDD (as in real Red->Green->Refactor), try it out. If you’re not comfortable with a debugger, find one that works well with your toolchain (or try new tools that provide a good debugging experience). If you’re not accustomed to a consistent peer review process, ask a friend/colleague to review your work whenever possible.

Some or all of that may sound daunting. And again if you’re more interested in changing track, that’s okay too. But if you do want to become a better developer, these things are not as tough as they sound, and future you will thank present you for the effort.

Oh, actually one more thing:

> I'm thinking about looking for semi senior roles but I'm afraid it'll look weird for the company interviewing me to hire a semi senior with +10 years of experience.

I recently left a job, and asked some friends/former coworkers for recommendations. One that came up was for a less senior role than my previous roles over the last several years. At first I was hesitant, and had similar thoughts to those you expressed here. But I did consider the role anyway, because it would also leave more room for compensation advancement without moving into management. If you’re concerned about this sort of judgment (and if you’re concerned about ageism), feel free to just leave some older experience off your resume. I personally tend to only list my last 3-4 positions unless there’s something especially impressive further back.

What about management? Overseeing other coders?

why not just market yourself as a software engineer without 'senior' and put some pressure off

Ah no you are still senior don't worry. Whether problems are solved in hacky ways or not is up to process not you.

wrt PMs, many bigSoftwareCorp PMs dont know how to write code. probably most tbh

any examples of "proper medium software company" just so i understand?

The first thing I think I would say is: Hang in there. Regardless of your situation there's going to be a way out of it with the facts on hand -- you have a lot of the skills you need to do "Senior Software Engineer" type roles, as well.

For example: one large professional skill you have is this: "I've been able to always have work on my desk because I'm always moving and talking with people in the industry" combined with this: "I've always managed to solve the problems in front of me but in a 'hacky way'."

Those to things together say to me: "This person is able to communicate with others in order to solve problems" which is really one of the key differentiators between a more "senior" software engineer and a more "junior" software engineer.

I have some questions: Are you still at the company? If so I think you have a great opportunity ahead of you to improve some of your software design/engineering/crafting skills while leveraging some of your strengths.

If not, I think you should consider another medium sized company and not worry about this most recent experience as being the end of your software career.

Next question: The code that was filled with hardcoded values, wrong structure, difficult to debug bugs... was that your code or the existing code? If it's your code, then you're in a great position (like others have said) because you've already identified problems and so that's your list of things to work on next.

What does "failed to accomplish it" mean in terms of the task? The thing about software, especially at a company that's not going to go down in flames because of a problem you've failed to solve is that... you can try again. You can keep taking swings at the task until you figure it out and eventually knock it out. So that doesn't seem bad.

"I'm thinking about looking for semi senior roles but I'm afraid it'll look weird..." As a hiring manager who's been interviewing people in this industry for more than 15 years it never looks weird. And if it looks weird and you have something to offer and the company can't see past whatever "weirdness" that's their loss -- you sound like a thoughtful, introspective employee who's got an impetus towards self improvement. That's gold.

You could transition to PM, you could "take a break" -- but I'd want to think carefully about the answers to the first few questions if I were you because it sounds to me like you are interested in software development and are interested in self improvement in software development and if so it sounds to me like you have a great opportunity in front of you.

If you are still feeling lost, and actually make it to my message, hit me up at the email in my profile -- I would be happy to talk about it further in more detail.

Sorry. If you're over 30, you get sent to one of the euthanasia camps.

Not quite April 1, but good stuff nevertheless.

Woodworking.

Long answer incoming:

I've always maintained that you really learn how to write code for a particular problem when you've done it three times. The first is usually to get working code, the second is to redesign it to improve some aspect (adding features, improving performance, code maintainability, etc.), and the third is when you really get it "right". Using this approach, it takes time and deliberate practice (borrowing the term from Geoff Colvin's "Talent is Overrated").

From my point of view, the core question that you're asking is "How do I get deliberate practice with coding?" There is no easy answer for this, but here are some ways to break things down so that you can come up with a plan for yourself.

1) "Clean Code"

This was brought up in another comment, but the book does an excellent job of covering many of the techniques for keeping a code base in good shape over time.

What can be trickier is 1) there are a lot of techniques, and 2) you may have a hard time taking the techniques from the book and applying them to your situation. While the examples in the book are universal, I think it's easy to get lost applying the technique to a more complex problem.

2) Applying One Technique to a Known Situation

Either start with a smaller piece of code or a medium piece of code that you know really well. Ideally, use some advanced piece of source code control that allows multiple branches. Then, start doing the practices from "Clean Code" one a time with a goal in mind, such as eliminated duplicated code, limiting scope, making functions more configurable via parameters, etc.

The real trick? Just do one of these improvement areas at a time. Do it a few times in different parts of the code. Eventually, the patterns start to emerge as to why it improves and where else it can be applied.

3) Recognizing Patterns

You may or may not have read articles/books about API design, coding style guidelines, etc. While many of those rules may seem arbitrary, as you get more practice, you'll start to see why such guidelines exist.

There will be similar patterns for how your code refactoring can improve modularity, debuggability, development time, testing, error handling, etc. Each code change may not improve all those things simultaneously, but you'll eventually start making improvements that cover more than one area of improvement.

4) Improving Your Learning Acceleration

There's a point you'll reach where you can keep refactoring, but you may not learn much more. At that point, try adding a feature. It can be a minor feature or a major one, but you'll start to see where the new feature forces your code to be refactored again. You can write a bunch of code or you can go through the "what do I need to change in the existing code base to add feature X?" as a mental exercise. In either case, you'll start to see what prior decisions may not have worked since they only considered one aspect of code improvement instead of three or four.

5) Putting All of the Above into Context

Another aspect of being a "Senior" engineer means that you recognize the problems really being solved by your software and what value it has. As you get more senior, you can answer all sorts of questions such as:

- How does the customer use this software? What pieces do they pay for? What features save them the most time/money/suffering? - What should the next features be? - What parts can be improved? Speed? Usability? Data Input? Connectivity/compatibility with other software? - What sort of documentation does the user need? - Is this software getting dated? What parts need replacing? Does there need to be a new solution (rewrite vs. continued refactoring)?

Not all of the above questions are applicable (e.g. tools used inside a company vs. a tool customers buy and use on their own computers), but being able to put the software usage into context (sort of the PM area you were talking about) and breaking down the technical context (the "senior" engineer role) are both useful skills.

You may need to go back and forth a bit between coding and reading books like "Clean Code" before the lessons really get internalized. Using the above guidelines and knowing what sort of learning process works best for yourself, hopefully you can start taking steps to improving in ways that help your career.

I don't have a lot of specific advice for you. It sounds like maybe code isn't clicking as much as you think it should, and that's stressing you out in a negative way. You shouldn't be stressed out like that about your job if you can avoid it.

I had an engineer on my team that was struggling. For some projects that should take a single day to do, he would take almost two weeks. We started pairing him up with other engineers to teach him, and he was able to work with them effectively, but his solo productivity and his code quality on his own never really increased.

I considered putting him on a PIP and then letting him go, but while I was considering that, there was an incident, and the whole team jumped on a Zoom to handle the incident. Maybe it was because I was thinking of him specifically, but I could tell that he was thriving in this environment. He was identifying the bugs quickly, he was pinging the right people, he pulled up the right graphs and metrics immediately. It was honestly really impressive.

So I spoke with our head of Site Reliability and asked if he had an open role. He did. And he agreed that this guy was doing a good job and that he would take him on.

This engineer is now one of the most productive SREs in our organization. He writes a lot less code, but he's a lot more involved in adrenaline-pumping incidents. He's a great people person, so he knows everyone, and everyone knows him. When an incident pops up and people get paged, he communicates it clearly.

This is nothing less than a huge success story. I didn't lose anything by losing an underperforming engineer, but I gained a stellar SRE.

All of this is to say... maybe there are other roles in the company that would be a better fit for you. Maybe you would thrive in a DevOps role focusing less on code and more on infrastructure, or maybe in a SRE role that is about building redundancies and safety nets for the organization. Maybe you'd absolutely kill it as a PM. (Contrary to what you said, most PMs I know are not technical, so having any level of technical expertise is a huge plus. If you have lots of product ideas and like doing research, this might be a winner for you.)

If you trust your boss (and I hope you do), it would be worth talking to them and getting their perspective. Phrase it in a positive way, not in a self-deprecating way. Something along the lines of "I'm thinking about my long-term career, and I'm not sure I see myself as a Principal Engineer someday. What skill sets do you think I excel in? Do you think you can help me find opportunities to level up those skills and maybe find a role where I can utilize them the best?" Something like that.

Finally, I forget who said it, but someone said that you should work on improving your strengths, not your weaknesses. In other words, you don't see Michael Phelps running marathons or Usain Bolt swimming across the English Channel. Phelps swims and Bolt runs... because they're good at those things! And because they keep focusing on their strongest skill set, they get better and better. Just a thought.

Good luck!

Hi! I was late into the software game, or really I had a career reset. Breath a sigh of relief, your career is not over.

1. Age does not play a factor

2. Resume progression looks cool but practically means nothing. I have hired engineers that have been demoted (maybe adversity yields character.) I'm determining if you can pass my interview, not the last person's.

3. Software Engineers go in and out of relevancy all the time, the only difference is that you're noticing it during interviewing.

Now, as a drop out, I had to learn things on my own. I'll go over what I expect out of a Senior engineer. Keep in mind I work on a team where algorithms and data structures do matter, not all teams are like this. So, think about what you want your next team to be about.

1. Have knowledge of how algorithms work and what data structures work best with them. This is useful when dealing with tasks that must scale incredible loads.

2. Asymptotics. I generally only ask Big O questions, but know what the others are too. Big O is either memorization or a deep understanding, either is fine for Senior. You would need to be able to answer time and space complexity questions in my interview, in the form of, "walk me through the time complexity of what we just did." Sometimes I'll ask about space complexity but only if I see that you allocated memory for reasons I don't understand.

3. Abstract Systems Design is my love-child. Be inventive and take calculated risks. I don't expect you to be perfect, but I do expect a data-informed plan.

4. "Clean code" is a hyped term but it will communicate something about you. Use clearly defined interfaces and keep your concerns/domains separated in code. I'll explain a bit more below.

5. Learn to write tests with definitive outcomes. Usually when I'm helping a SWE with a problem and I'm short on time it's easier to crank out some tests that will keep them within my expectations rather than hold their hand the whole way through.

The whole "clean code" thing is iffy, imo. I learned to write good looking code by attaching linters, formatters, and static analysis tools to my IDE and learning through repetition. Designing good applications was harder, but it dawned on me when I had to write multi-threaded applications or applications that implement concurrency. You will start to naturally separate your code if you start doing this.

Learning asymptotics was iterative for me. Start on one of the Big O cheat sheet pages then Google each data structure/operation to understand why it works out the way it does.

There are lots of tutorials for learning to identify algorithms and data structures. This will be time consuming, but it can also yield benefits in your work depending on what you decide to do next.

I hope this helps!

you're probably fine

Most developers are terrible.

They are either extremely untalented and take a whole Sprint to write a simple function,

Or are really smart and take a whole Sprint to write a simple function (because it must be perfect).

So you're in good company.

Also, the person that "just gets it done" can be king in some companies (agencies/consultancies/corp). Just learn to avoid critical security mistakes and you're golden.

What was this medium complexity task? I wouldn't discredit your ability entirely on the basis of one project.

Honestly, I went through a similar experience in my career around 30. I was mostly self taught and been writing code in academia where my peers were also self-taught scientists who were even worse programmers than I was. It was at my first interview at a real software company where I realized just how far behind the curve I was.

Fortunately I was in a position to take a break from work to focus on learning new skills. I built a few demo apps which were enough to land me a dev position at a small agency where there wasn't a concept of junior or senior devs, but where the others were better enough than me that I could learn quickly from them.

Now that you're in such a position you'll see that maybe you didn't learn as much as you could have in those 10 years, but just by spending years getting exposed to real software development issues you will be able to rapidly assimilate better practices.

Become a data scientist.

so, what's your actual programming experience? It sounds like you are just an IT guy from The IT Crowd.

If you can tie your shoelaces, you can PM.

And that's Product Manager. Project Manager. Product Owner. People Master. etc.

That said, you sound like you are having a down day/time. Sucks.

You might be a bit burned out, too.

If you are not completely addicated to the salary, then there are a zillion things you can do.

Tho, all these other roles make decent money too.

One thing that I have done is 'developer support'.

'Support', to me, as in 'Support Engineer', can be, and often is, the lowliest, most wretched and grinding position in the company -- often depends on the company.

But doing 'Developer Support' can be more interesting and even fun because the customers are just more technically competent on average, and you'll basically be overqualified for the position -- i.e. you will not have any performance issues.

Forget coding during the day -- it sucks -- save your coding for after-work hours when you can create your own shit and have fun.