Stay in your lane... if you apply for IC engineer roles and say you want to be a manager then this is not a good signal (they're hiring for an IC engineer). Or if you apply for manager roles and you want to continue coding then this is not a good signal (they want someone to manage). So pick the one you want to focus on and simplify this story for the next few years to make a success of the one you choose. I would say that whilst there is more need for managers in tech those are harder to find a fit on, and so you will have far better success finding a role as an IC. If you want to start in one lane and change lane after 1-2 years then aim for a startup that has 50-500 people and is growing as then you'll have the greatest number of opportunities to pick a different lane.
The employment gap is not an issue, and could be viewed as an advantage: Self-motivation, bias-to-action, drive. Of course it can also be viewed as a disadvantage: Not a team player, will they be onboard with the company goals/mission. You get to frame this, so when you present it ensure you do so in the former... "work was not stimulating and you had some tech itches to scratch so you applied yourself to those to support your own growth and learning and now wish to apply some of that to a role at a company".
On applying for roles... just apply. You don't mention where you are located but remote roles don't typically pay SF/tech hub salaries as they can opt for a far larger pool of people and don't have to prop up landlords in hot markets like SF. This too will be an advantage for you if you happen to be pretty much anywhere else so be sure to treat that as an advantage that you have, know that for remote your not being in SF is a plus.
TBH there's so little info in your post and nothing personally identifiable that it's hard to give specific and concrete advice, but the above comes to mind immediately.
Atom is technically substantially superior to RSS. RSS is riddled with ambiguities which lead to inconsistency of interpretation, and being outright unable to express some useful things.
My favourite is the format of all content: is it HTML or text? RSS doesn’t care, and leaves you to guess. So people added a namespace to fix that up, and you end up with what I think is normally spelled <content:encoded> to replace <description> or whatever it is—but there’s no equivalent for other content fields like titles. And because you can’t trust that tool will use <content:encoded>, now you need both. (And when you get to podcasts, the theme of the day is having the same field expressed in four or five different namespaces for different tools, in some cases for things that Atom has but RSS lacks.)
I have an article on my blog entitled <_>::v::<_>. I expect that a few RSS readers would mangle it if I served an RSS feed, but I serve an Atom feed, so I can express the title correctly:
(Bet you didn’t anticipate the <code> wrapping of that title! Now try that in RSS!) Anyway, NewsBlur got it right, and if any other client gets it wrong I can point to it and say that it is unequivocally a bug, whereas with RSS… eh, there’s enough ambiguity to drive a spaceship through, so what does “bug” even mean?
I hate the way that feeds are so commonly generically called “RSS”, because it gives mindshare to the bad and inferior product.
The only reason you should ever use RSS feeds is because you’re dealing with podcasts, because Apple sadly ignored the emerging Atom format when they did podcasts in iTunes in 2005, and annoyingly froze things in time there and then, and everyone else stupidly followed them, so that most of the major podcast things don’t support Atom… even if they sometimes claim to. (Like validation tools that allege that Atom is fine, butcher it completely if you give it to them, and report false results like that this RSS feed is fine or whatnot.)
The employment gap is not an issue, and could be viewed as an advantage: Self-motivation, bias-to-action, drive. Of course it can also be viewed as a disadvantage: Not a team player, will they be onboard with the company goals/mission. You get to frame this, so when you present it ensure you do so in the former... "work was not stimulating and you had some tech itches to scratch so you applied yourself to those to support your own growth and learning and now wish to apply some of that to a role at a company".
On applying for roles... just apply. You don't mention where you are located but remote roles don't typically pay SF/tech hub salaries as they can opt for a far larger pool of people and don't have to prop up landlords in hot markets like SF. This too will be an advantage for you if you happen to be pretty much anywhere else so be sure to treat that as an advantage that you have, know that for remote your not being in SF is a plus.
TBH there's so little info in your post and nothing personally identifiable that it's hard to give specific and concrete advice, but the above comes to mind immediately.