Live data from Hacker News

Ask HN: How can I consistently deliver high-quality work with minimal issues?

news.ycombinator.com

31–40 of 42 posts

Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?

#31
post #6

I know this sounds like a zen koan but to be consistent, don't worry about consistency. A description of the desired outcome is not a strategy for achieving it. An actual strategy: track all of the blockers. You say that your sprints "go wrong" but that isn't a helpful observation. If you track why it goes wrong - write down the start and end time any time you get stuck, blocked, confused, waiting on others, dealing…

Good advice, really. love it. Maybe I can try harder to control these issues. One challenge with this is finding a way to talk about it without it sounding like I'm just complaining all the time

Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?

#32
post #29

This comment and many of the replies are ridiculous. Bugs are part of the process and so is QA. Having only a handful over a few years probably means you spent too much time trying to make it perfect. You will see fewer problems the more time you have to work on a feature or test it, but in my opinion if you consistently get to zero then that is inefficient because it delays the feedback from the user. Or it means yo…

Yah, making it clear, I def get more than a couple of bugs yearly hehe. You sound right for me, and I heard stuff like that from companies here and there. Stuff like "delivery it first, make it better later", like focusing on putting it together on front of our users besides of over engineering the right thing. This is cool, till dozens of bugs appears

Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?

#33

1. If the work is actually hard, your software will have bugs along the way. 2. Big projects do not look finished until the end. 3. If you want to dominate the dojo, only fight children. 4. The creative process is messy and mostly unsuccessful. Assembly lines are neat and predictable… …the sprint model comes out of consulting where the goal is to do the same thing that’s been done before. 5. QA’s job is to find bugs.…

> 3. If you want to dominate the dojo, only fight children.

hahah, love it, thanks!

Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?

#34
Do whatever QA is doing to find your bugs before they find them. Then spend 20% of the time to automate 80% of that work. That might be unit testing, it might be selenium, it might be some different linter settings, but keep the focus on bang for the buck stuff.

Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?

#35
post #9

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…

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

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.

Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?

#37
I like to write down any mistakes I make or see myself make, since I don't always have a QA team, but I'm not exactly trying to prevent the mistake.

I think of the thoughts in my head like LLM output. I don't expect it to be right every time, my job is to make it useful without relying on it.

If I make a mistake, I don't just think "I'll do better next time" I think "Why was that even possible".

Sounds like you're already doing great if this only happens occasionally!

Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?

#38
Remove the small errors to stay focused on the big ones. Use typed languages, linters, unit tests and the like.

Don’t trust your future self to remember anything. Not that the logic needs updating in multiple places (single source of truth!), not the steps of a process (scripts!), and not what you need to do (lists and flight checks!)

When something goes wrong, treat it as a learning experience and set up a countermeasure. Mistakes shouldn’t happen twice.

Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?

#39
post #6

I know this sounds like a zen koan but to be consistent, don't worry about consistency. A description of the desired outcome is not a strategy for achieving it. An actual strategy: track all of the blockers. You say that your sprints "go wrong" but that isn't a helpful observation. If you track why it goes wrong - write down the start and end time any time you get stuck, blocked, confused, waiting on others, dealing…

Good advice, really. love it. Maybe I can try harder to control these issues. One challenge with this is finding a way to talk about it without it sounding like I'm just complaining all the time

I've definitely been that guy complaining about all the unnecessary friction. What I've learned is that you have to be selective; take note of the flaws when you find them, but put them aside and focus on the things that directly impact current work on your plate. "I'm going to refactor this class in order to add X with less risk" is an easier sell compared to "I'm going to put development on hold while I refactor all the things for some reason."

Re: Ask HN: How can I consistently deliver high-quality work with minimal issues?

#40
It's great to have bugs because they become your next sprint.

My advise is to get out of the sprint ecosystem pressure if possible you need time and space to make/fix bugs. The focus should be on the overall deadline not a two week package. Trying to align with that creates issues.

The other is to pick a stack that you can pivot with.

Post reply on HN