←back to thread

25 points llll_lllllll_l | 2 comments | | HN request time: 0.4s | source

TL;DR: What are your checklists, tips, and tricks to ensure you're delivering a high-quality piece of work (whether it's a Pull Request or something equivalent in your field)?

As a full-stack developer, I've often found myself in situations where a sprint goes wrong, and a lot of bugs are flagged by QA. It's a tough spot to be in because I genuinely put in my best effort when coding, but sometimes things just don't go as planned. It could be due to a new feature, an old legacy system, or simply a rough week—it happens from time to time (not so often, I remember like 4 moments in my 5 years of experience). What advice do you have for maintaining consistent deliveries with minimal bugs (or equivalent failures in your area)?

Show context
ajuc ◴[] No.42206721[source]
Not a solution for all of your problems, but it does help me with debugging stuff faster: I have a directory on the desktop called "scratchpad" in which every day I create a new txt file.

During the day I copy-paste every JIRA link I work on there, related class names, APIs, fragments of code I worked on that were particularly tricky, test cases, stacktraces I encountered, useful SQLs, urls to webpages with solutions to problems I had, short descriptions of these problems and my discoveries about them. It's not very verbose, usually it's less than 1 screen worth of notes per day (excluding the stacktraces ;)).

At the end of the work day I save that file as date_short_description.txt - for example 20241121_exception_when_logging.txt.

When I encounter a problem giving me dejavu - the first thing I do is grep in that folder for exceptions, lines in stacktrace, class names, related keywords, etc.

After a few years working at the same company it's surprisingly helpful. I started doing this at my first job after working there for over 2 years and experiencing the "I could swear I dealt with this problem before, but can't rememeber how".

Another tip that is probably personal is - I tend to fall into this habit of "do a very small change, compile, check tests" loop that feels good but is suboptimal if testing/compiling takes a long time. So I try to notice if I fall into that trap and stop myself. It's not the worst thing in the world, but it's wasting time (and giving me an excuse to procrastinate cause "it's compiling").

replies(1): >>42208193 #
1. llll_lllllll_l ◴[] No.42208193[source]
I've been working with js stuff so compiling is not a big deal, sometimes on the frontend there are a lot of steps to test something, though, I def feel the procrastinate call

Interesting idea of keeping the daily log. I thought about but feels like a lot of work. Today I keep a "gotchas" list with some of these stuff, which is someway similar

replies(1): >>42208815 #
2. ajuc ◴[] No.42208815[source]
The key to do the log is to open the new file in notepad++/whatever in the morning and keep it open. When you do stuff you copy-paste the interesting parts anyway, so just paste it there as well. It's almost zero overhead.