Sure. Spend a day learning how to use a debugger, and force yourself to use it until it feels natural. In the most common cases, the bug is in code on your computer, even if it's buried deep in some dependency. Even if you're working on a distributed system, you should have a local test environment and hopefully some sort of tracing capabilities. With a properly configured debugger, you should be able to quickly find the source of most problems.
After replicating a bug, I usually follow a process that looks roughly like this. I try each step, and if it's not resolved by then, I move onto the next.
1) Examine git log to hopefully determine which commit introduced the bug, in order to narrow the search space
2) Set breakpoint when the bug becomes observable, attach debugger and identify root cause of bug.
3) Verify that any function calls to dependencies are correct according to documentation, and any conditionals are working as expected (double check logic too)
4) Try a bunch of google searches
5) Read dependency documentation more closely, and read its code on GitHub to understand how it works
I think the key is that it has the potential to be a great platform.
The text-editing "fundamentals" are covered by the Monaco engine. The rest is covered by extensions.
Out of the box, it's not much more than a glorified Notepad. Add some extensions and suddenly I'm stepping through my Rust breakpoints and inspecting values.
The language server protocol (LSP) is a massive leap forward. And unlike the Microsoft of Ballmer, LSP is an open standard that any editor designer can implement.
> Is there any reason to use LSP, rather than simple JSON messages passed between the front-end and back-end
Yes, there's a reason to use a documented open standard supported by multiple servers and clients that passes JSON back and forth rather than an ad hoc, client specific mechanism that also passes JSON back and forth.
In fact, the reason is exactly the problem LSP addresses, labeled as “The Matrix” at https://langserver.org
In short, a problem with N+M cost is better than N×M when both N and M are >2.
Because LSP is a widely used protocol for language tooling that's not coupled to any particular editor.
I'm surprised xi didn't just add an LSP client to leverage the existing ecosystem. The benefits of in-house language server implementations seem marginal at best.
Most LSP work is just simple JSON messages passed with HTTP-like headers for Content-Type and Content-Length, presumably to future proof it against other payload formats.
I thing it's already more an IDE than a plain editor. There is not even a normal file-explorer anymore, just an workspace-explorer. Using VS Code for regular editor-stuff is kinda painful IMHO.
I would like an answer to that too. I'm the youngest member of my team so the older more 'experienced' teammates are really good with politics.
We have a new project coming up and I basically was the one implementing the initial architecture, I showed them how to use the linux terminal, gitflow.
I am the dev with the fewest number of bugs reported, they are always on meeting about issues. They take the most visible, interesting features.
Yet during meetings, people talk to them more because they are older, so they basically take most of the credit.
Divide et impera, I'd say. Get a backer, someone that sees your values: your manager, your manager's manager, one of the senior devs. If you have 3 people in a room at work, there's bound to be at least 2-3 (hidden) conflicts. Figure out where they are and benefit from them: get your backer to help you with your task and when you present it, present it as being team work. While you're the person actually presenting. Your backer will... back you and you'll be able to stay a bit in the spotlight and you could use the exposure.
Or just find a sane work environment, which one is easier.
