5 ms·
Fix your tools
- wofo 8mo agoOP here, thanks for submitting!
- obsidianbases1 8mo agoHow'd you get the notice that this was submitted so quickly?
- bombcar 8mo agoIf you watch your refers you'll see HN pretty easily. Could be even setup as a notification.
- wofo 8mo agoI got a notification through F5 bot (https://f5bot.com/ https://f5bot.com/)
- obsidianbases1 8mo agoGood to know, thanks!
- bpavuk 8mo agohey, the idea of Krossover is actually dope! my sole question is, why does it exist? I understand that one might call Rust from Kotlin for performance reasons (I do that often, Mozilla does, some others too), but Kotlin from Rust? where would it be useful? no snark or subtext here, I'm genuinely curious
- wofo 8mo agoCalling Kotlin from Rust (and other languages) is useful when you want access to an existing Kotlin codebase and would rather avoid creating a full-blown port. I guess most people don't do things like this because creating bindings for languages that are not C (or C-like) is usually cumbersome. Krossover is trying to fill that gap for Kotlin. Does that make sense?
- bpavuk 8mo agopretty much! I'm still curious about case studies. I can imagine that something has SDK for Kotlin but not for Rust, yet outside of that case, technical benefits are not yet obvious to me.
- vinhnx 8mo agoYou're welcome! Love the article, I hope you write more.
- r1cka 8mo ago"Give me six hours to chop down a tree and I will spend the first 4 sharpening the axe"
- bluGill 8mo ago[flagged]
- b00ty4breakfast 8mo agohello, it's me the Language Fairy. Sometimes when people use an expression to convey an idea concisely , the details of the imaginary scenario within the expression are less important than the concept being expressed (just so long as the general shape of that scenario fits the thing being discussed). To be more particular, the exact time it takes to sharpen an ax and chop down a tree are not important here.
- bluGill 8mo agopeople are so far removed from the ax that they don't realize my point. I'm sure the people Lincoln was talking to had more knowledge and so would get a different picture from the modern reader.
- phendrenad2 8mo agoI always liked "The craftsman who wishes to do his work well must first sharpen his tools" by Confucius
- stivikivi 8mo agoThis is the reminder I needed. For some projects the python LSP I am using in Neovim just breaks sometimes. Always so frustrating when I start fuzzy searching instead of just jumping to a declaration or restart it.
- nicbou 8mo agoThe caveat is that you might end up shaving a yak. More often than not I end up three or four tasks deep while trying to fix a tiny issue. https://m.youtube.com/watch?v=_UZFI-8D5uA https://m.youtube.com/watch?v=_UZFI-8D5uA
- Sophira 8mo agoRelevant XKCD: https://xkcd.com/349 https://xkcd.com/349
- wredcoll 8mo agoThis comic definitely speaks to me on a deep emotional level, but at the same time one of the things I like so much about computers is they're essentially unbreakable. Not that you can't get one into a non-working state, that is, of course, trivial but with the lone exception of deleting data, you can always restore a computer, the only tool being needed is some kind of boot disk. (Compare that to breaking a literal hammer, you'd need a pretty specialized set of tools handy if you wanted to actually restore it)
- deleted 8mo ago[deleted]
- buildbot 8mo agoAh; if only this was really true. You can certainly get a computer into a permanently bricked state, especially an embedded device. Even a modern x86 machine can be basically toasted by a bad firmware update.
- sltkr 8mo agoAnd perhaps less well known to the Hacker News crowd, relevant Malcom in the Middle: https://www.youtube.com/watch?v=5W4NFcamRhM https://www.youtube.com/watch?v=5W4NFcamRhM
- teddyh 8mo ago
- highfrequency 8mo agoEngineering is a continual lesson in axe-sharpening (if you have 6 hours to chop down a tree, spend the first 4 sharpening your axe). My favorite framing, from Kent Beck: “first make the change easy, then make the easy change.”
- goda90 8mo agoI recently got assigned to enhance some code I've never seen before. The code was so bad that I'd have to fully understand it and change multiple places to make my enhancement. I decided that if I was going to be doing that anyway, I might as well refactor it into a better state first. It feels so good to make things better instead of just making them do an extra thing.
- hvb2 8mo agoJust be careful that 'better' doesn't just mean 'written by me'. I've seen that a lot too
- rglynn 8mo agoMore often than not I've seen this be the case. Refactoring as "rewrite using my idiomatic style, so that I can understand it", which does not scale across the team so the next engineer does the same thing.
- IshKebab 8mo agoMost of my colleagues are content to spend 50 hours chopping up the tree with a pipe. We don't have time to spend making things work properly! This tree has to be finished by tomorrow! Maybe after we've cut up this forest, then we'll have a bit of spare time to sharpen things.
- eddythompson80 8mo agoAs Charlie Munger used to say “show me the incentives and I’ll show you the outcome”. What are the incentives for these developers? Most businesses want trees on trucks. That’s the only box they care to check. There is no box for doing it with a sharp axe. You might care, and take the time to sharpen all the axes. Everyone will love it, you might get a pat on the back and a round of applause, but you didn’t check any boxes for the business. Everyone will proceed to go through all the axes until they are dull, and keeping chopping anyway. I see 2 year old projects that are considered legacy systems. They have an insurmountable amount of technical debt. No one can touch anything without breaking half a dozen others. Everyone who worked on it gets reasonable rewarded for shipping a product, and they just move on. The business got its initial boxes checked and everyone who was looking for a promotion got it. What other incentives are there?
- unkulunkulu 8mo agoUsing the debugger to understand/read code is invaluable. Seeing live stacks is so powerful compared to static analysis.
- bluGill 8mo agoI'm not convinced. At times it can be valueable, but at times you can go around in circles, changing checking variables/break points all the time, but never finding the problem. Often thinking about the problem and what is important is what you need. Playing in the debugger is fun and feels like progress, but it can just be a distraction from understanding the real problem. I'm not completely against debuggers, but in my experience they only are useful either to get the trace of the problem when it first occurs and then use static analysis until you have a theory the debugger can prove/disprove - but only prove/disprove that theory don't keep looking: you will feel productive but in fact be spinning circles
- unkulunkulu 8mo agoI’m talking about using debuggers not even to debug, but to familiarize yourself with the codebase and gain general understanding. Measure of progress for me is formulating and answering questions. Sometimes trying to answer a question leads to formulating sub questions.
- Bukhmanizer 8mo agoAs with most continuous arguments in SWE, it really depends. I used to do a lot of debugging of random (i.e. not written by me) bioinformatics tools and being able to just fire up gdb and get an immediate landscape of what the issues were in the program was just invaluable. Times when I was more familiar with the program or there were fewer variables to track it was less helpful
- chihuahua 8mo agoUgh, this brings on flashbacks to when I had to work with Ruby, and the *** debugger would break with every single release. The RubyMine IDE that 45% of the company used was based on some bizarre custom Ruby gems to enable debugging, and that crap would take a month to be fixed by JetBrains. 10% used VSCode where debugging would sometimes work and sometimes not.
- d--b 8mo agoAlso, FYI: Claude is very good at fixing tools
- wofo 8mo agoThat's what I actually used to fix this one! I'm not too deep into the JVM ecosystem, so I gave Claude a try just in case... and it fixed it :) Btw I didn't mention it in the blog post, because I think that would have derailed the conversation (after all, the point of the article is not "use LLMs", but "fix your tools"). In any case, I agree that LLMs can make it easier to fix the tools without getting side-tracked.
- wangzhongwang 8mo ago[dead]
- fragmede 8mo agohttps://xkcd.com/1205/ https://xkcd.com/1205/
- saulpw 8mo agoThis comic ("Is it worth the time?") is categorically incorrect, because it assumes a static system. Instead, when you make something take less time, you can do it more often. Sometimes, much more often. See: Jevon's Paradox. You would never have known that CI/CD was a useful strategy since you didn't optimize your build because you only did a full build when you released.
- bergheim 8mo agoIf you like what you just read you should probably never install Emacs. You're welcome.
- yegle 8mo agoMy friend once told this joke: > "A good programmer, when encountering a debugger bug," he paused, cleared his throat, and said solemnly: "should immediately drop the program they're debugging and start debugging the debugger instead!" The auditorium once again erupted in thunderous applause.
- mentalgear 8mo ago"first we shape our tools, then our tools shape us"
- maccard 8mo agoI aim for the Boy Scout rule - always leave things better than you found it. It’s always a balance and you have to not lose the forest for the trees. Always ask what is the end goal, and am I still moving forward on that.
- esafak 8mo agoWhen I find something wrong with my tools I file a report or submit a fix.
- didgetmaster 8mo agoIt's not just the tools, it is your tests. Most times you encounter and fix a bug, your first question should be 'Why didn't my tests catch this?'
- deepsun 8mo agoYes, but the answer depends on the bug. 100% test coverage leads to brittle tests, when any change leads to many broken tests, and fixing them is like repeating the change multiple times.
- adriaanmol 8mo agoNext time use AI.
- socalgal2 8mo agoFunny you got downvoted when the OP admitted that's what they did.
- semiinfinitely 8mo ago> The very desire to fix the bug prevented me from seeing I had to fix the tool first, and made me less effective in my bug hunt Kenneth Stanley's book "Why Greatness Cannot Be Planned: The Myth of the Objective" is dedicated to this phenomenon
- cloverich 8mo agoIf you're still dipping your toes into an LLM world, this is an excellent place to begin. I helped with a deploy at work the other day, we have some QA instructions (Notion). I pointed the LLM at one of the sections, asked it to generate task list for each section, and once that looked good, had to convert the processes into a set of scripts. The latest models make short work of scriptable stuff that you can use for debugging, testing, poking, summarizing, etc.
- doctorhandshake 8mo agoMy version of this is ‘always be toolin’, but then of course one must use judgement lest it be better to just get on with it.
- umairnadeem123 8mo ago[dead]
- melvinroest 8mo agoI haven’t tried n8n and similar tools but I always had the suspicion that they wouldn’t be that good. Would you say there are scenarios where tools like n8n would be better to use than Python and calling some APIs?
- Rietty 8mo agoAnd this is why I just love Airflow so much.
- sfink 8mo agoExcellent advice. I try to follow it in my daily work, with some success. Excellent follow-up advice: now stop fixing your tools, and go fix your actual problem instead. I try to follow it in my daily work, with noticeably less success.
- thaumasiotes 8mo ago> So I fixed the debugger (it turned out to be a one-line configuration change) That line links to the commit, which adds .withDebug(true) to an invocation of GradleRunner in a file named AllFunctionalTests.kt in the krossover project. My question is: Why can the software choose whether, when I run a debugger on it, the debugger will work? It can't, of course, so what's going on?
- socalgal2 8mo agoyea, good point. The debugger should be able to say up front. "This code isn't debuggable" or some warning to that effect.
- wisemang 8mo agoI also clicked through to that and was similarly confused. Not a Kotlin dev but this doesn’t really seem like fixing your tools? More like understanding them properly. I wouldn’t call a configuration change like this “debugging the debugger” as another comment mentioned. I’d also like to know the answer to your question about what is going on. I know Java and maven but not kotlin or gradle, but wouldn’t a debugger be interfacing more at the JVM level?
- rileymichael 8mo agothe tests are validating the plugin by executing actual builds in an isolated/temporary gradle project. debugging doesn't work out of the box because it's another process https://docs.gradle.org/current/userguide/test_kit.html#sub:test-kit-debug https://docs.gradle.org/current/userguide/test_kit.html#sub:...
- cube00 8mo agoI would fix my tools but apparently my CPU is too old to run the Rust debugger which needs SSE4.
- nanobuilds 8mo agoGood lesson! Can be tempting to fix the problems up the chain especially if the problem might happen again in the future. It depends on how much time, attention, and number of steps up the chain. Sometimes a work around keeps you moving forward but you miss some interesting (rare? learnings).
- MantraHQ 8mo ago[dead]
- vismit2000 8mo agoThat's why this course is so important: https://missing.csail.mit.edu https://missing.csail.mit.edu
- px1999 8mo agoTools exist to be an energy/effort multiplier, so it's pretty intuitive that increasing that multiplier will make it easier to get more done. In practice it's pretty difficult to find the balance between yak shaving and piling in unnecessary manual labour by just trying to do the work with existing (possibly poorly fitting) tools. If you're planning to stick with your current tools for a long time, each 1% improvement compounds massively over time, so that balance is probably much closer to yak shaving than most people might realise.
- allinonetools_ 8mo ago[flagged]
- brador 8mo agoIt’s 2026. Just use AI for debugging. At least try it. This could have been solved in 15 minutes.
- samiv 8mo agoI'm nearly 30 years into my career and I feel like the tools today are so broken that if I was going to "fix" them that's all I would ever be doing. I write a bunch of my code on Linux with Clio and for the last several years that "tool" has gotten buggier abd buggier. Sometimes there's a similar issue with breakpoints not breaking. But I just can't be bothered anymore. If something doesn't work out of the box it doesn't work and I simply move on and find another way around the issue. Life's too short to fix other people's code too.
- psybrg-prtcls 8mo agoThis is the seventh principle from 7 habits of highly effective people: sharpen the saw