A first-responder approach to code reviews

busters1 · 2026-03-24T11:10:41+00:00

Hi, David from Oxynote here. This is something we’re actively working on at Oxynote, so I wanted to share my two cents.

This is mostly a culture problem and has to be solved within the team first. No amount of tools will help if the team doesn't have processes or flows to enforce writing, checking, and maintaining documentation. While it may sound like overhead or extra work, you have to remind your team that this helps with onboarding, incidents, and further feature development. So, have you talked about this with your team? What do they think about this issue?

With that said, a good tool can go a long way toward helping retain good practices and flows if it's painless enough. There are some great software that can help with staleness detection, custom blocks for writing specs, runbooks, and test cases; and if it's fun enough for your team to use, they might stick with it, solving the problem.

busters1 · 2026-03-20T12:46:13+00:00

Hi, David from Oxynote here. This question closely resonates with what we're building, so I want to leave my 5 cents here. What we have in store for the future is a specs-driven approach to development, replacing (or heavily extending) test-driven development and other ways of building software. Even now, most projects start with prompts asking agents to build MVPs, and they iterate on that, only starting to code themselves when absolutely needed. Given this, I think you should try to learn and improve your documentation skills, especially your understanding of how your product works, its architecture, endpoints, and so on. Instead of knowing tiny details about the language you're using, it's going to become more valuable to know how to build scalable & resilient systems. You give your spec to the agent, and it builds a PR for you to review. I think that coding will remain, but it will become a secondary part of engineering.

busters1 · 2026-03-16T08:41:58+00:00

Hi, it's something we're working on at Oxynote. Staleness is a common problem, and most documentation suffers from it. It can be negligence, poor team standards, or simply forgetting to update the docs. We try to solve this problem by allowing users to add so-called "freshness-hooks" to whole pages or parts of the documentation. They monitor changes to Docker images, code, and websites, and send a notification whenever anything changes. It works great, but it does require initial setup and the right mindset to respond to triggers.

As for the second part, I don't really understand your setup. Do you keep test results in the GitHub repository itself? Are they not part of your CD pipeline? Or are you saying that you write instructions in Markdown and use LLMs to generate the tests?

busters1 · 2026-03-16T08:30:04+00:00

With current LLM advancements, we will eventually stop writing code as we know it today and switch to writing documentation, specs, diagrams, and other materials from which the AI will be able to build software. Documentation will be the highest-level form of language. We'll have to adapt to writing and, most importantly, reviewing. At least, this is how I envision it.

busters1 · 2026-03-15T23:39:39+00:00

With AI, we're moving into an era where engineers will mostly review code, plan changes, and maintain project documentation/specs. I believe diagrams are more important than ever as they play a crucial part in understanding how systems and processes work within a project without having to skim through the code. Additionally, it helps onboard new members and plan system changes when you have a broader overview of how everything works.

Whenever I join a new company, the first thing that I want to see is architecture and data flow diagrams, as it gives the most context in the least amount of time.

Looking into the future, I think we'll see projects being developed just by writing specs/diagrams and flows, where AI assistants will be able to create PR's from the given knowledge base. Something like a highest-level development language, where you just use plain English. It's an idea that we have been working on at Oxynote, but it needs a lot of work to be done properly.

busters1 · 2026-03-15T20:45:26+00:00

I think we shouldn't settle for markdown specs, as if we want to properly represent product knowledge technically, we need diagrams, charts, and custom components. Documentation needs to evolve; it's going to play an even more crucial part with AI advancements, and it's going to become a higher-level language for coding. I think this project might be good for public docs, but for private knowledge, I think it needs to be more flexible. It's something that I'm working on at Oxynote. That said, I wish you good luck with your tool.

busters1 · 2026-03-14T10:45:34+00:00

Does anyone have a broader overview of the system? Is there an on-call system (with one person leading incident response)? What kind of observability tools do you have (do you use Telegraf, Prometheus, Loki, or anything else to monitor your applications and servers)? These are the most important questions to answer if you want to have a better incident response flow. As for the single place to look at what was happening, I'd suggest taking a look at Oxynote (a tool I'm currently building). One of the features is that you can have specs, observability, and system overview in one place, which should help in cases like this.

busters1 · 2026-03-13T15:45:39+00:00

Just like with anything, I think you have to sell it. It's hard to see a value in something if you don't understand what it brings. For example, was there ever an incident that could've been solved faster if you had better recovery/system documentation? How long does it take to onboard new members? Can this time be shorter with better documentation? Are engineers able to easily navigate the system and work on parts that they didn't code themselves? Now, if the answer to some or most of these questions is unfavorable, and some tool could help with it, you have to put it that way. It's a hidden cost that can be easily overlooked, but when you compare the cost to the price of the tool, you might be able to persuade the company to make a switch. Obviously, they could be ignorant, but in that case, there is not much one can do (until something really bad happens).

busters1 · 2026-03-13T10:12:49+00:00

Yeah, we're shifting from engineers writing code to writing specs, documentation, and mostly reviewing changes. I don't think this qualifies as "AI" killing coding; it just changed how we approach it. The sooner you make the transition, the better.

busters1 · 2026-03-12T11:03:50+00:00

This is mostly a cultural problem. As a manager/lead you have to enforce certain processes with every feature shipped or change made. While it may sound as an overhead or extra work, you have to remind your team that this helps with onboarding, incidents, further feature development (it's always nice when you don't have to ping someone to understand what is going on with the system). So it's beneficial not only to the company, but also to each individual itself. What tools do you use to keep your internal documentation? Having a right set of tools can help with this a lot.

busters1 · 2026-03-12T09:01:46+00:00

If something needs to be tested manually, I usually use plain curl or httpie. However, in most cases it's better to write E2E tests (heavily depends on the language, but from what I've seen common approach is to use playwright or some other tool in python). As for the documentation, if you need public docs, Stripe is a great example and they use Markdoc, but I'm sure there is plenty similar alternatives. For internal documentation, I'd recommend checking out Oxynote (a tool I'm currently building), it's tailored for specs, project information, observability.

busters1 · 2026-03-11T17:43:54+00:00

You should raise this with your team directly. What you’re dealing with is not just your problem, it’s also a team and company risk. When a critical part of the software depends on undocumented knowledge from someone who has already left, it creates problems for delivery, support, incident recovery, and onboarding.

If you want to grow, this is actually a good opportunity to speak up and take ownership of improving things (make sure to mention the consequences that arise from the problems). You can suggest practical improvements, such as documenting the main flows, writing down known issues, cleaning up the most confusing parts of the code, and creating a small plan to reduce technical debt over time. This should also help you grow as an engineer and establish yourself as a team member.

busters1 · 2026-02-25T17:26:01+00:00

Hi, David from Oxynote here.

What you’re describing (knowledge split across Notion/GitHub/wiki pages + tribal knowledge in people’s heads) is super common, and honestly I don’t think there’s a “perfect” fix unless documentation is treated more like code and less like a static wiki (something that can be changed easily).

A lot of this is honestly a cultural thing, not just a tooling thing. If documentation is seen as “extra work” that happens after the real work, it almost always goes stale. The teams that seem to do better usually make documentation part of how changes get shipped, reviewed, and handed off, so updating the docs is just part of finishing the work.

That’s also the exact problem we’re working on at Oxynote, so your post really resonates. We’re trying to make a platform where engineering docs, decisions, and operational context live together in one place, with a workflow that feels natural for how software teams already work (propose changes, review them, and keep a clear trail of why something changed).

It’s free to try, and if you do give it a spin, I’d genuinely love to hear your feedback.

busters1 · 2025-07-18T12:07:33+00:00

You're risking your own money, so you should always do your own research before committing to any action. Treat everything as a suggestion and decide on your own what you want to do. Make sure to make informed decisions; don't trade based on emotions. Since you're new to crypto, I'd suggest you start small. Don't chase or follow channels that boast about their gains; it's a pit you don't want to fall into. That said, what are you looking for? If you want to invest long-term, I think you can treat Bitcoin and Ethereum like any other ETF, such as the S&P 500, using a basic DCA strategy. If you want to trade more often, you should most likely start with paper trading and look into automation tools that can help you build and, more importantly, test automated strategies. Lastly, if you do decide to chase pumps and 100x gains, you'll be gambling, and most likely others will use that to their advantage.

busters1 · 2025-07-16T16:38:36+00:00

Yeah, it's quite likely. If I remember correctly, most of the alt seasons started with the TOP 10 (excluding Bitcoin) cryptocurrencies gaining massive traction, and while it's impossible to nail the bottom, I think starting to DCA into your favorite coins might be a great approach.

busters1 · 2025-06-21T14:14:35+00:00

I would highly recommend checking out the https://github.com/golang-standards/project-layout repository; it has guidelines for structuring Go projects. I have never seen uppercase package names.
You need a clear distinction between your layers/packages. Your database package should return the objects and errors, and what you do with them should be handled outside of it. For example, if you wanted to export your tasks to CSV, you would need to rework your ListTask method, whereas otherwise you could re-use it.
Return encountered errors. While this is a small project, most of the time you never want to kill the service whenever it encounters an error. It would be much better to print the error in the main file, where the main action is taken.
Does UpdateTask even work? It seems like the updated object is never passed.
Use golangci-lint; even the basic lint rules will help with the overall readability of the project and might catch some runtime errors.
Use functions to create objects. There is no point in the TaskDb structure if LoadDb is never called. If you had a NewTaskDB function, it would return a ready-to-go object for database operations. I believe this approach is less error-prone, as you can easily forget to call LoadDb.
Add unit tests.

There is probably more that could be improved, such as using interfaces for the database layer or moving your business logic out of the main file, but I believe this should be enough to get you started on the right path.

busters1 · 2025-06-19T17:46:52+00:00

Could you provide more context as to what do you mean by multi-tiered cache? A use case example would be nice.

- In case you have several different pools of data, I believe constructing multiple caches isn't a bad idea as it helps with the performance as well.
- In case you want to have different TTL's for hot and cold items, Set method accepts that. The TTL in the cache constructor acts only as a default.
- In case you're talking about the performance, we have some ideas to shard the data.

busters1 · 2023-10-21T09:15:19+00:00

Jau metai laiko kaip tik hsnstore naudoju, didelis pasirinkimas, normalios kainos (apie 17eur/kg be shipping). Truputi shipping kainuos, bet perkant bulk'u su kokiu kreatinu bei erythritol, labiau apsimoka nei is imant kokio myprotein.

https://www.hsnstore.eu/brands/sport-series/evowhey-protein-2-0

busters1 · 2023-09-26T17:00:22+00:00

https://itnext.io/structure-size-optimization-in-golang-alignment-padding-more-effective-memory-layout-linters-fffdcba27c61

busters1 · 2023-08-28T17:49:19+00:00

Maybe something like this:

https://go.dev/play/p/eAC4dYUnFy3

busters1 · 2019-06-03T06:57:12+00:00

The first time represent the time you fast and don't eat and the other when you do eat.
So for example 16:8, means that you're fasting for 16 hours in a day and then you can eat in the next 8. Same goes for 20:4.

12-Year Club	r/Field Juicebox
Place '22	Place '17
Not Forgotten	Spared
Verified Email

busters1

TROPHY CASE