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.

> Now that you're at the medium software company, seek mentorship and coaching from others.

Agreed. My abilities as a developer increased tremendously at one of my jobs, and I can attribute 90% of that to a single person at that company who mentored me and helped me grow. (Hi, René, you probably don't read this.)

You can read all the articles and books you want, but actively pairing with someone on tasks and getting personalized feedback has a much greater pay-off.

Absolutely- getting a mentor who will make time for pair programming is invaluable. Early in my career as a self-taught dev (my degree was in a different area), I landed a job as an associate dev and was assigned a "mentor" who wouldn't give me the time of day. While I'm sure he was very busy, it was also very frustrating to be told every time I reached out: "Give me one sec, I've gotta finish something up, I'll message you when I'm done" only for them to ghost me for days even after I'd reach out again (I couldn't even drop by their desk since we were both remote devs). So I made different connections, got to know my other coworkers better, and found a person who wasn't just willing to mentor me and pair with me, but was excited about it and glad I would reach out! I learned more from him in a week than three months with my former "mentor".

Moral of the story: find someone who's happy to mentor you, willing to pair program, and wants to see you grow and succeed. I can't promise that you'll never feel like a fraud again, but I can promise that you'll feel more confident about the work you do. The sooner you can do this, the sooner you'll find your "muchness" and become "much more muchier" (to quote Tim Burton's adaptation of the Mad Hatter).

At my first company, in order to commit anything we had to get someone else on the team to sit down with us and we'd have to go over the diffs with them and walk them through the changes and why. Incredibly annoying, but a great way to learn. I still rewrite "if (!condition)" to "if (positive_condition)" to this day based one guy's feedback that negative logic is hard to read and reason about. It was also really humbling to not remember why I did things, so I'd have to prepare for the code review so I'd have something besides "um, I don't remember" to say.

I have also realized that there are some categories of problems that I really don't know how to solve well. So if I find myself struggling, I try to ask someone for ideas.

Totally agree with this. If you see someone who's better at something than you are, go up to them and ask if they are willing to spend some time with you working on a topic. You'd be surprised how many people would love to help out. Depending on the company they may even have decent learning/pairing programs for this.

Can share that experience as well, my first job there were 2 devs who were great programmers, highly educated. At every chance I tried to get as much knowledge from them as possible. They were happy to share and equally happy when they saw me improving.

Pairing, pairing, pairing, and more pairing.

This. Suggest and attend stand-ups. Treat them like professors' office hours. Encourage and nurture people who are very good to give you things you can do, maybe with some help, but which are real tasks that are useful in the end.

Do you have tips or things you did to get more effective mentor ship? My company has assigned me a mentor but I always thing I am not using it to the fullest extent.

The `only` time I speak with my mentor is when I get stuck with a bug and need help getting started. I have asked frequently on how to do better code reviews or how did she get so good at programming - she always said it takes time. To get better with the code base - it takes time.

Ideally, this person should be on your team, or otherwise someone you work with regularly. But asking your mentor when you run into bugs is a good start! Pairing on those helps.

I guess in terms of concrete advice:

1. Put time on a calendar to work with this person; don't just slack back and forth about some specific issue for a bit.

2. If you're looking to become a better programmer, actually pair with them - take turns driving and writing code. If she's doing the driving, it would help to hear out her rationale for what she's doing - probably even before she starts writing. If you're driving, try to do the same.

3. Ask for code reviews on as many of your pull requests as she can provide; this is going to be pretty workplace specific, and is going to depend on how much code you end up putting up for review and how much time she has. It's a good way to get async feedback.

And yeah, it takes time and practice.

It is true that it takes time. And to some extent just observing others’ work is a lot of the benefit of time. But if you’re looking for your mentor to be more involved and she’s not engaging that, try asking more specific questions. Like “oh this bit of code is interesting and it wouldn’t occur to me to do it that way, what was your reasoning/thought process? Where can I learn more about this approach?”

You can also find others on your team whose work you admire and ask them similar questions. Lots of people are happy to talk about their work when asked.

interesting... I have never been in an environment where pair-programming was practised..

makes me think how much I could have improved...

I don't think pair programming should be done for every line of code written, but it's a really good way to transfer knowledge and mentor folks.

Also try to identify on three levels : how is your understanding of structure, how is your understanding on the functional level and how is the understanding on the syntax level (in the context of the company you are working for)

Totally agreed! My first thought on reading this was "this doesn't sound like a bad engineer, this sounds like an engineer with potential who's just been exposed to some good practices they hadn't encountered before."

Just set your mind to doing better and in as little as a year it'll be a different story.

Seriously. The bad engineers are the ones who accomplish nothing. I’d be concerned if he said the codebase was too hard for him make any significant changes.

About the only

Agreed with everyone else here that it's great that you've recognized areas of improvement for yourself. That's an important step, and in your position I would validate by chatting with your coworkers about it. Every time a colleague has asked me for my opinion on what they can improve upon or work on, I've always tried to give a straightforward critique; see if your colleagues independently bring up the same issues you think you have.

More generally, without having worked at a company that size yet, you can't be expected to come in with all the domain knowledge that dev team veterans have. Forget about titles like "senior" and what that means. Doing mostly-solo dev work for a long time is just a very different kind of work than writing code in a shared codebase with a team of coworkers of varying experience and skill levels. There will be aspects of maintainability and clarity which simply aren't a big concern in your solo projects but make a big difference when you have dozens or more developers working on the same code. Communication with coworkers becomes an important skill, collaborative project management etc. These are things which you can't just study and learn on your own, you ramp up on them over the course of working in that kind of environment. So yes, you might be pretty "junior" at some of these medium-sized-company aspects of software development, but that's fine and only to be expected at this stage. Keep at it, gain experience, level up by doing.

I really appreciate your (and everyone) help. I've always knew I was behind some things but this real world experience slapped me in the face and now I'm trying to readjust.

My manager has already been aware of my lack of knowledge but I'll talk to him to know if they still want me there. If I keep my job I for sure will be asking for more help at the start of a new project.

Crucially, don't start the discussion with "do you still want me" but with "I'm concerned that I might run into problems and wanted to discuss how we can avoid them" (or something like that).

Some managers would welcome this discussion. It shows that you are aware that you have limitations and that you would like to improve. If nothing else it helps keep the manager / company from placing you on a task that you wouldn't be able to complete successfully, which would ultimately hit their bottom line. If the company / management are sufficiently enlightened (such companies do exist), they may be able to find additional training or development opportunities to enhance your skills

FWIW, when I was a manager, I ALWAYS liked to find things out before they created a problem, when there was time to fix them, rather than in the middle of some critical task.

Good luck!

An even better starting point would be: "Hey Manager, I'm dissatisfied with the quality of my work on medium_complexity_project and want to make sure that I'm improving going forward. Here are the steps I'm taking (list steps) do you have any other suggestions on what I can do to improve here?"

Yes. In fact this is an interesting topic in its own right - how do you approach management when you have found a problem. In my experience, there is a sort of scale here, along the lines of:

* do nothing and keep quiet (almost always the wrong thing)

* say "help"

* say "I've found this specific problem, but I don't know what to do"

* say "I've found this specific problem, here are some options for fixing it - what do you think?"

* say ""I've found this specific problem, doing X will fix it - what do you think?"

This will vary a lot in practice and depending on circumstances, but I think as people increase in experience and knowledge they tend to approach management with solutions rather than just problems.

I agree with the sibling, but let me be more explicit: It's going to be hard to take time off, "level up" and then come back and get another job. Your best bet is to stay where you are and keep your job. The company has already invested in you and your manager has every incentive to help you improve rather than finding someone else.

You should go to you manager with a look to the future: come with some specific things you can do differently on the next project, and perhaps also some general 'goals' for improving your skill.

Then, most importantly, do what you said, and get better.

All this assumes you are happy and want to stay in engineering, if you do think you'll be happier doing something else, then by all means go ahead and do that.

Don't phrase the conversation like that. If you want to get better start there. Say you'd like to improve. That your first attempt here was rough and didn't work out but pairing up with a more experienced developer would give you some rails to keep you on the right path.

Either way. Keep your head up! Asking for help is the first step of an endless journey.

Make sure to really listen to what your manager says is the real problem. Sometimes in these situations we get flustered and jump to solving the wrong thing.

Maybe the real issue here isn't engineering ability but communication, that you didn't let anyone know you were having challenges, didn't set expectations about how the project was going.

There could be more or less going on here than just code quality, so like I said, really listen and ask questions and keep an open mind.

Also to reiterate what others are saying, don't go asking about being fired because it can come off like you want to leave or have given up. You've been humbled but it doesn't take away the good parts of what you do, you're a pragmatic, independent, get stuff out the door type adjusting to a larger team. This is normal growing pains.

> I'll talk to him to know if they still want me there.

Why would you think they don't want you there? This is not a helpful mindset to have. Here are the facts:

1) You passed the interview process.

2) They made you an offer.

3) They've continued to invest in you as an engineer by giving you feedback on your weak spots and where you can improve.

If you were really that far behind, they would have realized that in the hiring process and you would /not/ have received an offer. So let's start there. They definitely still want you there. That is why they hired you.

Second, let's talk about your "lack of knowledge," "being behind some things" and "real world experience" that "slapped [you] in the face" -- based on your mindset it looks like you are viewing this as a negative, or as proof of failure. Why is that the case?

You have 10 years of experience solving problems and getting paid for it. Now, you are solving different kinds of problems, so you're developing new muscles. It's expected on their end (and should be expected on yours) that there is some kind of /ramp up/. Talk about what ramp up means. Figure out your manager's expectations, and figure out what resources you have available to engage in ramp up. I guarantee you this, there's ramp up at any new medium-big company anywhere you go. There's tribal knowledge, spinning up on the industry vertical, etc -- all of this is incompressible, doesn't matter how good of an engineer your are.

If your manager is any good, they likely know about this and will appreciate you being aware of this problem as a logistics problem, not a moral problem. So think about it that way. Stop thinking about "whether they want you there" -- start thinking about "what blockers are in your way towards being productive" and start building a game plan with your manager. Worst case scenario, you're not able to accomplish it, but at least you gave it an effort and approached it the right way. That's a much more mature, proactive and effective approach than self-sabotaging yourself with feelings of inadequacy. I have a hunch that you won't fail if you do this, though. Just thinking about what you want to get accomplished and the nitty gritty details of how you get there and collaborating with your manager to get to a plan you're both happy with is /a lot/ of work -- once you've done that, if you work at a functional organization, the chances of you succeeding are very high!

Give yourself a pat on the back, while you're at it. Getting to a point where you're still being challenged after 10 years of experience is a /good/ thing! It reflects well on you and indicates your desire for growth. In all likelihood, your company saw this motivation in you and that's why they hired you. Look at the positives and opportunities here, and I'm sure you'll do amazing.

Good luck!

Much needed shot in the arm !

This is excellent advice. Take this to the heart, OP!

>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)

I'd also add to this: learn the why as well as the what. There are reasons why hardcoded values shouldn't be used, why OP's structure was bad, and so on. Learning why will help build those habits and make them stick.

I don't think I've come across coursework that's intended to level up coding ability itself (i.e. good software engineering/design) rather than teaching basic knowledge things. I'm curious if anyone has come across anything of that nature.

I've come across the book Clean Code, which presumes to improve your craftsmanship. It has been improving craftsmanship for 12 years, and everyone has noticed of course.

Have you seen a shortage in people who dress up their preferences as facts? Maybe a better question is, who is producing the good software? Oh, and software ought to include malware (personal preference).

I don't know, but some of the people I consider to be really good software developers seem to reference "The Pragmatic Programmer" (perhaps even more than I realize do since I never read the book but have heard of "rubber duck debugging" & "DRY").

Generally, good software would have to be first defined and there's no universal definition. In most projects, I require it to have the following properties: * New developers find it easy to ramp up on * A handle on the defect rate (usually through adoption of best-practices like unit tests, fuzzers, automated tools, CI/CD, reproducible builds, etc). * "Fires" infrequently enough relative to team size that it's manageable to accomplish your business goals. * No "surprises" in adding new features/fix bugs where you didn't expect them. * Meets business requirements today & can meet them tomorrow.

However, in other cases, like prototyping, "good software" means, "explores the problem space as quickly & cheaply as possible without worrying about any of those other things". Some of those other things can be useful in accomplishing this, especially if you plan to pivot from prototyping to the above definition. If you don't use them effectively then throw away your prototype before productionizing & start from scratch.

For me this knowledge has always come from working on a variety of projects and seeing the effects of various architectural and design decisions on the result. Hard to imagine how such things could be taught otherwise, honestly.

id argue acquiring the skills and experience to be a good pm is on par with doing the same to become a better engineer. good pms have very different skills to software engineers - communication, communication, more communication. obviously software experience lends itself to managing software projects well so youre half way there, but i wouldnt underestimate it. it sounds to me, that if you recognize and have identified your weaknesses as an engjneer, youre also half way there to learning from them and getting better at it. the question is what do you enjoy and what will you be motivated to work at? do that.

+1 on this. damn.

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.

I don't know what it is about "imposter syndrome" but it's clearly having a moment. People are quick to label things "imposter syndrome" these days.

Imposter syndrome is feeling like you are an imposter or fraud even though, objectively, your job performance is adequate.

If anything, the original poster is describing the opposite of imposter syndrome, because they cited specific objective criteria showing that their job performance is inadequate, and came to the realization that they need to improve despite their previous feeling of competence.

That's a great thing, IMO -- figuring out you need to improve before it becomes a problem with your peers/supervisors means that you can take action before it is forced on you. But it has nothing to do with imposter syndrome.

While this is a good point, I'm not so sure that this is the case. The OP has over a decade of experience, but is noting issues only after deciding to work for a "proper medium software company". It sounds like the OP may not have been used to working on projects that place a heavy emphasis on testability. But now that that's an important consideration, it's changing the entire approach for all of OP's implementations, which can be pretty startling.

If the OP hasn't been writing working software for the last ten years, I'd say that it wouldn't be a case of imposter syndrome.

> If anything, the original poster is describing the opposite of imposter syndrome, because they cited specific objective criteria showing that their job performance is inadequate

It is not clear if what original poster described is objective: I am guilty of writing such software myself in the past. I was given unrealistic timeframes to write good software - in no way did that make my performance "inadequate", that's just the trade-off chosen for me (I wonder if the author felt pressured to deliver quickly). The only difference is I didn't blame myself for the outcome; rather, I felt proud of being able to deliver something that works on short order.

Read the title again. That is impostor syndrome.

OP is not reacting by wanting to do self-improvement, OP has decided their 10 year experience is a fraud and wants to quit software development.

1. I know plenty of terrible software devs in their 30s.

2. OP wanted guidance about how to improve as a developer, if they wanted to quit they wouldn't have made the post.

>they cited specific objective criteria showing that their job performance is inadequate

The examples given by OP seem like subjective self-assessment to me. I doubt if they were that bad a programmer, they'd be able to identify such issues with their own code.

It would be different if OP has received consistently negative feedback on their work, I don't know if that's the case.

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.

> Part of programming is learning.

A big part.

Like 90%.

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. :-)

This is a really helpful piece of advice, thank you. It's always helpful to remember that the return on investment we get in software for time and effort invested is astronomical compared to other fields.

> 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.

> a mediocre product

We don't know if the product is mediocre. Good, useful software can have messy underlying code without the user being aware.

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'm not a dev. I am a professional learner in other contexts. And man... this is good advice for anybody who does anything creative. When I look at things I wrote in the past (articles, even forum comments ahem) I look back in disgust! This just means you've grown. It's awesome, and it's normal.

I am a professional writer and this is exactly my experience.

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.

> I think it's worth thinking about why you were successful as a freelancer and in smaller companies.

Assuming they were successful. I cringe thinking about the devs that inherited my code in my early days as a "dev" (using that term very loosely). Especially the freelance work, since in many cases you're the only that touches it until you move on. Then it's some other devs problem.

The idea that just because your code solved the problem then it's good enough is bullshit, especially if you're not the one that has to maintain your monstrosity of a codebase going forward.

I know many projects that I built in my earlier years were rewritten right after I left. The embarrassment I felt from that motivated me to learn to do things the right way.

> The idea that just because your code solved the problem then it's good enough is bullshit, especially if you're not the one that has to maintain your monstrosity of a codebase going forward.

It's a lot better than beautiful code that _doesn't_ solve the problem. If I had to choose between them, I'd rather rewrite something that's wildly successful than try and make an unpopular piece of software popular.

OP can learn how to write more maintainable software, but it sounds like they already have a good instinct for making useful software that people actually want. IMO that's rarer and more valuable.

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.

Highly recommend starting with "The Pragmatic Programmer". I found "Clean Code" to be much more narrow in its applicability (and I did not enjoy Martin's writing, but that's highly subjective).

The Pragmatic Programmer serves as inspiration for me every time I read it. I know everything in it, but somehow I always come away with at least one "I could totally be solving my current problem with this!" insight from a re-reading.

Reading the first ten chapters of Clean Code takes no more than 3 days yet so many programmers fail to do so. There is literary no other way to improve your coding skills and habits that fast.

Just a side note: reading fast doesn't make you learn fast. Be sure to take notes, to apply the knowledge in practical problems (project or small script), and make sure to revisit the topics, because you will forget things of you only do them once.

These are some of the principles of meta-learning that have been helping me greatly for the last year.

Thanks for the recommendations! If I find I like them after a chapter I'll pick up a physical copy

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.

> 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

This is key. At one of my first, real software jobs as a self-taught dev, I realized just how terrible my code was. It was a small company and the CTO would review all of my code. Sending PRs for the first 6 months or so was excruciating for me. I would just sit there and wait to hear him call me over to his desk and begin asking questions about what the fuck my code is doing. But he kept at it, and by the end of the first year, I finally felt like I knew what I was doing. I still had a ton of doubts in my abilities, but I wasn't embarrassed about having my code reviewed. I stayed at the company for 3 years and afterwards jumped to a major tech company.

Up until that job, I generally worked by myself and never received much input from others. I'm guessing OP is in a similar boat.

We had a similiar issues where a senior employee came and interviewed great. She ended up becoming a pm.

At another place something similiar happened and she ended up as a pm / developer.

I think pm move is a great idea for someone who can sell but maybe isn't as strong.

Perhaps moving to pm is a good answer for thread poster.

My attitude about this is, if it's not really the person's fault (ie. learning bad dev hygiene from bad teams) and they want to continue as an engineer then they should make an attempt.

There are of course people who at the end of the day just don't have a knack for this stuff, and in that case, I certainly agree.

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 remember one from Java ~20 years ago:

   public final static string HTTP = "http";
   public final static string COLON = ":";
   public final static string SLASH = "/";
   public final static string WWW = "www";

with code like

string url = HTTP + COLON + SLASH + SLASH + WWW ....

Ignore any Java issues - not used it much in ~15 years.

Edit: I asked the developer who had written this what it was achieving and he said it was best practise ;-)

What's the good practice advantage over just using "http://www"?

If we later change over to use https, it's not like I'd think

  public final static string HTTP = "https";

was any kind of improvement.

Yes, I'm struggling to thing why you'd ever want to construct URLs that way - I'd stick them in configuration with parameters if required.

Edit: Glad someone noticed it was "http" - which is one of the details I do remember correctly.

Autocomplete and composition purposes, i do it mostly with commonly used strings. Less likely to miss-type something.

Some devs are such stuck-ups smh

You could use refactoring tools in your IDE to rename all usages of HTTP to HTTPS.

Which will break other code where someone wrote:

  // Ensure all outgoing URLs are https:
  URL = URL.Replace(HTTP, HTTPS);

Technically it would still work though?

  Replace(HTTPS, HTTPS)

It depends on what you mean by "still work", but in general I'd say "No, it won't work."

If URL starts as "http://www.google.com/", and I expect that will get re-written to an https URL here, the code will compile and run without throwing any errors, but won't accomplish the intent of why that line of code was written and was doing previously. (URL will still contain "http://www.google.com/")

Would be ok if the variables were named like `PROTOCOL`, `SEPARATOR`, `HOST_PREFIX`. The names shown in GP are... well... a shining example of how naming things is hard, at least :)

It buys you nothing, and in the case of WWW, when you're grepping your code base to find everywhere you have "www.oldvendor.com", it fails.

What next? `ZERO = 0`, `ONE = 1`, ...?

Church encoding is mind-bending.

    ZERO  = (f, x) => x
    ONE   = (f, x) => f(x)
    TWO   = (f, x) => f(f(x))
    THREE = (f, x) => f(f(f(x)))
    TRUE  = (a, b) => a
    FALSE = (a, b) => b
    IF    = (p, a, b) => p(a, b)
    NOT   = (p, a, b) => p(b, a)
    AND   = (p, q) => p(q, p)
    OR    = (p, q) => p(p, q)

I had a coworker do this all over a Cold Fusion codebase.

He also claimed he used to be a dentist in Mexico, so anywhere he had his name, email sigs, code comments, etc., he would sign add "DDS" after his name.

Dude was a trip.

Pretty sure I've seen that as well (different codebase though) - that kind of thing happens when you have a code style rules that says "No literals in code, always define constants" and people take it literally.

Wasn't there a post here a month or so ago where someone found something like "three = 5" in the linux kernel?

You know, it wasn't that long ago when booleans in Python were essentially:

    True = 1
    False = 0

Wait, what was wrong with the #define solution? Just the name of the macro? Didn't he do what you wanted?

The 17 was a scaling factor for a graphics transformation (and sometimes was doubled to 34).

Let's imagine that we later decide we want to make a change and have it be a little bigger. Do we change it to:

  #define SEVENTEEN 23

Instead, if it was:

  #define MENU_SCALING_FACTOR 17 

then such a change would be sensible (which was the intention). I admit to having some sliver of culpability here (though the verbal explanation of why we'd prefer to pull the hard-coded numbers out of being sprinkled all over the codebase I assumed would have sufficed).

This seemed to border on /r/MaliciousCompliance, but I know he was actually trying his best (and was pre-reddit, of course).

You could improve your feedback in the same way as he could have improved his change. Create meaningful context. You told him what to do (replace 17), not why to do it (the value can change).

I think I disagree strongly on the first point.

If SEVENTEEN is used instead of MENU_SCALING_FACTOR and ARBITRARY_OTHER_THING (two semantically different things both happening to be 17), no refactoring tool (that I’m aware of) is going to be able to tease apart just the former use and amend it to 23, leaving ARBITRARY_OTHER_THING as 17.

  const int declarationAdoptedYear = SEVENTEEN * HUNDRED + THIRTY_EIGHT * TWO;

But the devs who would define SEVENTEEN to be 17 are unlikely to define OTHER_THING at all, since there’s a “perfectly good” macro that evaluates to 17 and avoids hard-coded numbers already. (They might even cite DRY: Don't Repeat Yourself as a misapplied best-practices shibboleth.)

See the (contrived) Declaration of Independence line above. Your editor would dutifully change the date to be off by six hundred years.

Sure, I understand what you mean. To be honest, that sounds like a different issue, one that would arise after additional circumstances took place.

I still stand by my initial comment, that if you had the quick ability to refactor SEVENTEEN at the time this developer committed this, it wouldn't be a very big deal, and this developer could be told that good variable names are important and he wouldn't be stuck as a junior developer forever, lol.

i think he meant you should #define whatever this 17 value represents

e.g. #define width 17

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.

Adding on to this, the kind of "hacky" code you produced while freelancing or working with small companies may have been entirely sufficient for that kind of problem. Now that you're a programmer in a much larger institution the way you code will need to change. It's going to feel very foreign to you for the first few months. The processes and patterns are almost entirely different and it's okay to take a lot of time to adjust.

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?

"He assumed that developers were cogs in a machine that can be replaced."

Well large corporations do want this very much and there are things you can do to make it work like this. Not without investment of course.

Right, it is understandable that a large company would want you to get going quickly. But yeah, without investing in code quality tools, or something to keep code bases similar, it won't be a fast transition.

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/

To your last point, it doesn't sound like algorithmic and practice problems are really OP's issue, as they suggested they can solve almost any problem given but do so in a way they now feel is amateur or hack-ish.

In a similar line of thinking to your Code Complete suggestion, a book like Architecture of Open Source Applications[1] might also be a good fit.

1 - http://aosabook.org/en/index.html

About Code Katas -- agreed. They can be used from simply an algorithmic learning viewpoint. They can also be used like an athlete uses weightlifting: Over time, certain motions become second nature.

When you're talking about such a mentally heavy discipline, it helps to have certain behaviors happen effortlessly. You might otherwise learn these things over time with a large team, but I think certain brains needs this kind of practice.

Just like there are different ways of learning any subject, there are different ways of maintaining proficiency (IMHO).

Thirding Code Complete (another top-level recommended it). I read that book very early on, and I credit it with my current ability to write clean code.

Another good one is The Pragmatic Programmer.

Lastly, this wiki is a gold mine of wisdom from hardened devs: http://wiki.c2.com/?StartingPoints

I really recommend you read lots and lots of those pages.

Yep, read these books and apply the ideas directly to your work as you go: Code Complete (which IMO is more detailed and explanatory than Clean Code) then Clean Architecture.

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).

With 10 years of experience, and ability to solve most problems given (even if it is hacky), I think junior is WAY too uncharitable.

I guess that depends on your perspective. From mine "not hacky" is absolutely required to move up from junior level. Hacky code is only useful if it's single-use or you can pass it off to a client and be done with it. In a bigger project (presumably what OP wants to be working on), hacky code is worse than no code at all.

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.

> 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.

Skills from CP transfer very well to the current FAANG interview coding olympics. Add some soft skills and you can easily land a job where you can learn the rest of the things you're listing there, while getting paid. So I wouldn't say there's not much use in the real world.

For context: The word "gymnasium" outside of Germany refers to a place where you do sports, inside of Germany it describes the "highest" out of the three typical types of secondary schools.

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...

any twitch streams you recommend?

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.

Strongly agree with you that there are two ways to significantly and inexpensively improve programming skills.

1. read books written by experts, especially those with good reviews. These books are often categorized as software engineering or software development methodologies. If you find one of these books, then go to sites such as Amazon to see the relevant recommendations, and gradually you can find almost all of them. 2. read the recognized good source code. This is hard, but necessary.

Then it needs to be accompanied by practice: use what you have learned above consciously in practice, so that you can consolidate this knowledge and even you can build on it to gain more specific insights.

Low cost means: no need to create a special environment and no need to be overly dependent on others.

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.

Wow. I kind of like that idea. I'm not sure it's true, but I like the idea.

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!

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

That was my thought too. Programming is kind of like American Idol--a lot of programmers don't know how bad they are. The submitter said they failed to accomplish a medium complexity task, but it's not clear what this means: got stuck and gave up; missed a deadline; finished, but with poor quality?

From one of the submitter's thirty previous Ask HN submissions, I see experience working with a variety of tools, including machine learning. With batteries-included languages and powerful libraries, you can get pretty far in Tinkertoy mode, assembling the pieces of a solution. When you're faced with a task that demands more programming skill, it can be an adjustment.

If you have a passion for software development, self awareness, and a desire to improve, I think you'll be okay.

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?

Also sometimes the best cure is more practice. You need to replace one set of habits with another.

Start small. Like how to do a flavor of integration testing. Perhaps take some online courses? There is also a huge amount of YT vids out there.

One thing you may need to do is go back to the basics. Also make a task of it. Have a set time where you for 1 hour a day 'learn new coding skills'. Such as refactoring, code style and when and why to us it. Also find a project that you are interested in and follow it. I learn quite a bit doing this I have a dozen or so I follow and watch the pull requests to see interesting uses of code and style, even if I disagree with them. I do not contribute to them but I follow the style and commits they do. You can learn a lot by doing your own code reviews of other peoples code. Seeing how other do it and work on that.

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?

Ha, I once worked in a team with someone exactly like this. His code was not great by industry standards but he was always able to bash out a feature or duct tape an issue quickly before a demo or presentation. Pretty valuable skill in a company.

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)

Depends on the path right? If its backend/systems related yes it may require you to write actual code and the person may still feel out of his depth. But there are areas in front-end for example where writing testcafe/cypress stuff is more like "go here, click on the thing, then click here", which doesn't need much more than basic coding ability.

It is code, and sometimes bigger and more complex than the product itself, but OTOH it is usually easier to get away with mediocre code level like I do...

This statement is far too definitive given the amount of info OP provided.

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.

Those were my thoughts too, recognizing bad code is a quality of good programmers.

The big question I would have for OP is 'do you want to do this anymore?'. I personally don't, I've loved development for 20 years but it's just not for me anymore, at least not for a day job. In that respect I'm in the same boat as OP, "What do I do now ?"

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"...

I know of "senior" software engineers with 2-3 years in the field...

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.

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.

"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

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.

Woodworking.