For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | rado_stankov's commentsregister


The top book imho is The Pragmatic Programer.

Here some other recomendations

- Designing Data-Intensive Applications - Tidy First?: A Personal Exercise in Empirical Software Design - A Philosophy of Software Design - Refactoring UI - The Software Engineer's Guidebook - https://blog.rstankov.com/programing-books/


Ruby on Rails Engines is one of the most powerful and underestimated features. It distinguishes Rails from other web frameworks.


Every sprint we have 1 person in rotation for bug duty. It works quite well. Overtime role takes some refactoring and tech depth as part of bug duty.

I have a blog post on the subject a while back: https://blog.rstankov.com/bug-duty-process/


I think this is what you are saying but to reword it for how we do it.

We have one "on duty" person each week/half-week/two-weeks. Their priorities are:

1. Support tickets.

2. Whatever they want (usually code cleanup).

They aren't expected to get any project work done. We also track the amount of time that they are spending on support tickets. If it is getting high we move more cleanup tasks into the regular project work cycle.

If you have oncall you can often co-locate these as well (oncall is priority 0).

The main risk is that if your support load gets high than there is no room for cleanup/automation which can become a feedback loop causing more support load. I haven't seen a good solution for this other than keeping track of the load and scheduling proper "project work" to address it when it gets too high.


The only sane approach. If someone is on support they also work to lessen the support load permanently. Recurring issues with no root cause analysis and fixes are deadly to a team.


Yes. Hiding errors leads to a lot of issues down the way.

This is part of the process. If an issue requires deeper work, it moves a proper task in a sprint.

We try to fix the easiest issues first so the deeper problems bubble up.

How the person in the support role knows that an issue is deeper? It comes from experience. Thus everyone does 1~2 week of support.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You