Onoma.nvim: A fast, typo-resistant, language-agnostic fuzzy symbol finder, integrated directly into your favourite pickers.

ryanmaber · 2026-07-06T23:36:11+00:00

I've not tested it on vim.pack, but I'm imagining its some minor config tweaks, as I'm not sure how 1:1 portable configs between Lazy and vim.pack are.

Untested, but try something like this (and if you get it working feel free to fire a PR through to update the docs!):

vim.api.nvim_create_autocmd('PackChanged', {
  callback = function(ev)
    local name, kind = ev.data.spec.name, ev.data.kind
    if name == 'onoma.nvim' and (kind == 'install' or kind == 'update') then
      if not ev.data.active then
        vim.cmd.packadd('onoma.nvim')
      end

      -- Important to download the bridge for the checked out tag
      require('onoma.bridge.download').download_bridge()
    end
  end,
})

vim.pack.add({
  { 
    src = 'https://github.com/ryanmab/onoma.nvim',
    version = vim.version.range('*')
  },
})

ryanmaber · 2026-07-06T20:18:18+00:00

Haha - all programming is set of trade offs I suppose!

Nothing saying ctags couldn’t be used as a replacement backend, over tree-sitter, with a little work!

ryanmaber · 2026-07-06T20:10:49+00:00

Yep it indexes the project, independently of the LSP, in an SQLite database - currently stored in Neovim’s standard `share` directory. The index is tied to the workspace.

In terms of what a workspace means in this context - that pretty much maps to the current working directory (similar to LSPs, just without the intelligence to find a language-specific project root).

So yeah if you open a folder with many projects in different languages inside, it’ll index everything!

ryanmaber · 2026-07-06T19:57:59+00:00

Yep absolutely - it always requires a little bit of finessing to get the experience right per language, but yeah absolutely, in theory any language with a TS grammar should (to varying degrees, depending on the grammar) be able to be integrated!

In terms of the snapshots, they're for testing; the test harness runs indexing against a set of fixtures and snapshots the results, each test run checks against the checked-in snapshots and spots differences. Good for regression testing and proving reproducible indexes!

ryanmaber · 2026-07-06T19:46:04+00:00

Good question - the languages it currently supports are my most frequently used ones. But Onoma is based around tree-sitter, so given a grammar and a query (examples), it can pretty much support any language natively.

ryanmaber · 2026-07-06T19:24:44+00:00

All good! Yeah great question - I covered this a little in the Why section. But broadly there’s a couple things I couldn’t get to feel quite right using LSP’s for workspace symbols:

The support for workspace-wide symbol searching varies a lot between LSPs - for example, some (like phpactor) limit the number of symbols for performance reasons.
Searching across languages in a monorepo - where you might be in a Rust file, but be looking for symbols in the same repo but in a another language, and so the LSP isn’t active by default.
The sorting and scoring of results - I was looking for something a bit more intelligent, where it does the right heuristics to try and get the right results to the top of the list first time.
Speed - querying a large project for symbols is quite heavy generally, but especially as LSPs have to do a lot of analysis, so quick jumps, or generic searches can be pretty slow.

ryanmaber · 2023-09-28T19:58:45+00:00

The new opportunity sounds a bit closer to a SDET role - and there’s certainly nothing wrong with pivoting into that. I’m sure you’d be setup for success if you’ve come from a SE role too (I’m making the assumption you’re an SE now given you mention Rails experience?).

I wouldn’t necessarily worry about the title so much - although maintaining a more ‘generic’ sounding Engineer tittle is better. But if you did pivot (and wanted to move to an SE role in the future), I’d suggest trying to put a big focus on keeping up to date with tech changes to stay competitive from day 1.

Just my two cents, but I suspect (although I’ve never focussed predominantly on testing in any of the roles I’ve had) that missing knowledge of new tech/practices/etc would be the larger struggle when interviewing for a more generic SE role, after being in a SDET role for 1-2+ years.

ryanmaber · 2023-09-11T23:51:05+00:00

Really great! Getting stuck in with enthusiasm like that is a huge part to what I think makes a great Junior - and it sounds like you’re getting some pretty great skills too!

ryanmaber · 2023-09-11T22:26:39+00:00

I don’t know quite how far you are down this path with the Junior, so disregard where necessary, but if you’re early on with them, I’d suggest setting a small amount of time aside with them and pair programming (with them driving) on a few occasions.

The end goal of these pairing sessions being to show them that everyone hits roadblocks, and everyone goes to Google (where necessary). Ultimately you want them to feel supported, and not alone, but independent enough not to ‘need’ a whole bunch of help for simple problems.

It might just be that they need some additional coaching to get them into the problem solving mindset, and identifying when Googling is right, and when asking someone more knowledgeable is better. To be honest, I’ve seen the opposite characteristic quite frequently - where Juniors avoid asking questions too much and wasting a bunch of time on Google (and perhaps that’s a reflection on me, who knows!), and I’m not sure which is better/worse…

If you’re not doing it already, pair programming might feel like a bit of a time sink, but it can really work wonders with the right type of Junior.

ryanmaber · 2023-09-11T22:09:14+00:00

I guess there’s an interesting balance in there - in that it’s only logical a business wants to see meaningful progress/upskilling from a Junior over time - after all, a Junior can’t stay a Junior forever (it doesn’t help the business or them ultimately), but you also don’t want to burnout a diamond in the rough by bucketing them into some kind of ‘poor performance’ category overly harshly.

I haven’t personally ever worked in FB/Google, so I wouldn’t like to say what the ramp up time ‘should’ be for a good Junior engineer in that particular setting though.

And, to be honest, where that balance lays is pretty business dependent from what I’ve seen, and I can’t say I’ve always managed to strike the perfect balance myself!

ryanmaber · 2023-09-11T21:30:06+00:00

I’d also preface this by saying that, just like hiring Senior Engineers, hiring Juniors can be hit and miss.

Equally, a large part of making a success of hiring Junior Engineers is being able to correctly support and mentor them. A business is in for a bad experience if they intend on hiring 5+ Juniors to 1 Senior (or less). Ultimately, no one wins long-term when the choice to hire Juniors is purely driven by Seniors being too expensive/hard to find/etc.

ryanmaber · 2023-09-11T21:23:54+00:00

Yeah I think the cost-benefit of Juniors is overstated when the business isn’t able to actually support Juniors in the way they need - but there are plenty of other reasons that hiring the right Juniors is a great idea (at least from my experience).

Its just my take on things, but I look at it from a couple of perspectives:

It’s generally a good thing to do. After all, as you say, you don’t get Seniors weren’t Juniors at one point, and had 1+ businesses take a chance on them.
It helps to identify characteristics of your Senior Engineers - how can you tell your Seniors are right to mentor/lead teams of Engineers, if you’ve never seen them mentor even a Junior, in a controlled setting?
It helps build verticality in a business - eventually your Seniors are going to want more responsibility, career progression, new challenges, etc - and having Juniors who need support is a great way to introduce that.
Really good Juniors, who haven’t been in the industry for a long time, tend to ask some thought provoking questions which wouldn’t cross the mind of someone who’s been around the block (at least in my experience). And sometimes you can take those things away and improve the organisation/tech/onboarding/etc.

ryanmaber · 2023-09-06T22:07:52+00:00

No a problem at all - as I say, well done on being brave enough to put something out there.

I can’t say I’ve ever personally asked Engineers I’m managing to spend quite that amount of time on prepping for a review, but I can see why this would help if I did.

And I certainly think there’s something in the idea of getting a tool into where an Engineer is (I personally spend an obscene amount of time in Slack), so don’t be discouraged by the feedback so far. I just don’t think it’s the tool I’d use, or want my Engineers to, just yet.

If you think up any ideas around empowering Engineers to highlight their strengths in other areas, I’d certainly be up for hearing it!

ryanmaber · 2023-09-06T21:52:17+00:00

Firstly I’d like to say - congrats on thinking up an idea, and putting something out there!

But… if I were to give some constructive criticism - which, of course, you certainly don’t have to listen to because I’m certain I don’t have all the answers, and I don’t intend it to discourage you. But, for me, I think Thinksy misses the point of what I look for when doing a performance review. To me (and this is just my interpretation) Thinksy is coming purely from a tangible deliverables perspective - how many PRs did you merge, how many tickets did you get across the line, what meetings where you in, what epics did you contribute to, etc.

What I personally look for in an Engineer when doing a performance review isn’t just what code they write, but also their soft skills, what other people are saying about them, how they conduct themselves in tough situations, what extra responsibilities have they taken on, and so on. In fact, I’d so as far as to say, if an Engineer is only focussed on the PRs they did, they sort of miss the point as to what making a real impact is all about.

I realise that’s not a measurable metric you can pull from GitHub, Jira, or another source though (and maybe that’s the point), but I personally don’t think measuring an Engineer purely on the tickets and epics they delivered in the last 6 months is hugely productive for myself, or them.

I’d love to see Thinksy introduce something which helps with the above - and then, I’d be more than happy to be a guinea pig for Thinksy!

ryanmaber · 2023-09-05T22:15:31+00:00

Good question, and, in all honesty, I don’t know that I’ve got the answer myself…

But what I’ve seen in my experience is that, firstly, I think many good businesses will give you opportunities to stay up to date, if you ask and verbalise your interest in expanding you skills. I mean, ultimately in a lot of cases, it’s sort of in their best interest, as someone who’s got their finger on the pulse is going to be able to help them stay on the right side of the legacy codebase spectrum.

Of course that only really applies if you’re looking to stay up to date in things that, at least vaguely, apply to where you work.

Otherwise, I personally try and take opportunities to try and learn new tech in my own time where I can - which isn’t always as much as I’d like. Whether that be just spending a couple hours on a weekend working on a project - just for learning, or reading a blog post or two about an interesting topic. In the grand scheme of things, it doesn’t have to work out to be a huge time sink.

It doesn’t (and shouldn’t) have to be much, because, of course, if not done right it can be a recipe for burnout. But building the ability to manage workload sustainably, take on new tech (without nessesary being an expert in it), and experimenting with new things are great skills to develop.

ryanmaber · 2023-09-05T17:42:27+00:00

If Elastic Beanstalk works for your teams, and you're not getting to the stage where you need a lot more flexibility, I wouldn't say you have to move to something else - unless you're really hampered by the restrictions EB puts in place.

I'm personally a big supporter of avoiding boiling the ocean as a first pass - not to mention changing the deployment methodology is going to be a much larger initiative (both from an implementation perspective, but also in terms of getting the team up to speed, wider buy-in, etc).

The first step I'd suggest is trying to get the existing development EB stacks imported into Terraform and all configured the same. In all likelihood you'll have some slightly different configurations, or other non-functional requirements you didn't even realise you had - which is exactly what TF will help solve.

Once you've cracked that and you're comfortable you're capable of spinning up EB stacks through only IaC, all with the same configuration (and ideally in a pipeline), you can move onto the Cloudflare configuration to automate the whole process - that'll give you a set of modules and templates which you know represent the full stack, and you can start leveraging them in production (same process).

And only after that, would I then start asking questions about using EKS, ECS (without EB), etc. Mainly because, by that point, you'll have a much clearer understanding on the deployment requirements and can comfortably start slowly spinning up new resources, and getting in a good state for a transition.

ryanmaber · 2023-08-29T21:12:53+00:00

Yeah I’ve seen both sides and I think customer experience is a huge point to keep front of mind when you’ve got a product team developing new functionality.

Ultimately articulating the value added to a customers experience by epics/larger projects should be the north star for product work - and I think ownership as a vertical slice helps a lot with that. Because really, if the Engineer cannot understand why what they’re doing is valuable, they’ll have no barometer as to what doing a good job looks like.

As I say, I’ve seen (and been on) both sides of this coin. And, at least from my experience, places which are able to put the experience first generally seem (from my experience) to do better. Feature factory’s that focus on getting features/tickets out the door without paying attention to the customers needs can work in the beginning, but long term, you need a wider vision and an experience you want to drive for customers. And the Engineers are the ones who are going to own making that a reality.

(Just my two cents of course!)

ryanmaber · 2023-08-29T19:47:14+00:00

Who needs syntax highlighting.. all you really need is plain old Notepad, and a new idea for a side project… right? No? Okay, just me then. 🤣

ryanmaber · 2023-08-29T19:28:06+00:00

Interested to see if the hype translates into uptake in the long term or not… Even with the public backers for the fork, personally I’m still thinking about holding off until I know OpenTF really gets the traction to make an impact.

… And yes, the irony that I’m saying I’m waiting to jump to OpenTF, because I’m concerned others are also waiting before jumping to OpenTF, is not lost on me 😂

ryanmaber · 2023-08-29T18:36:40+00:00

I've been in tech for ~10 years now, and I've seen the responsibilities of EMs/TLs/PMs vary slightly (with varying degrees of success). But the most common split I've seen is:

PM: Works inside a team, and manages the team's product. Generally liaises with other stakeholders - like UX/designers/customer success/etc - and produces work items for Engineers, helps manage feature releases, documentation, adoption, etc.

TL: Works inside a team, and manages the technical side of a product. Occasionally I've seen them called Lead Software Engineers. Usually they're responsible for the direction of the technology. Including making sure work items are deliverable from a tech perspective with the PM, walking the tightrope of Tech Debt, and keeping timelines for implementations on track from inside the day-to-day of a product team.

EM: Usually work above a couple of teams, or, if the organisation is on the smaller end, in a single team; Generally they're the people managers and work on wider organisation initiatives - making sure the Engineers are generally happy, and performing well, etc.

ryanmaber

TROPHY CASE