▲ | latchkey 4 days ago | |||||||
I don’t know if you’re trying to make assumptions about me or you, but I am those 3 things. It is definitely different approaches and both can achieve the same goals, but having started with your approach and then learned IDE’s, debugging and writing tests, I can from my own experience say that tests and debuggers are the way to go when it comes to building long term stable applications, especially in shared environments. As for speed to attach a debugger? Lol, it is one button click in a proper IDE and the speed and utility of figuring out the solution is faster. What I am hearing from you is that you’re unwilling to put the time into learning/using the tools. Or maybe you’re just stuck in your own headspace, many developers get that way, it is why we have editor wars and whatnot. | ||||||||
▲ | danudey 3 days ago | parent [-] | |||||||
> I can from my own experience say that tests and debuggers are the way to go when it comes to building long term stable applications, especially in shared environments. Ah, so there's the distinction for me - I don't build long-term stable applications in shared environments, I build small utilities or one-offs in private or occasionally shared environments. > As for speed to attach a debugger? Lol, it is one button click in a proper IDE and the speed and utility of figuring out the solution is faster. For me, I haven't used "a proper IDE" for most of my projects - again, because the nature of my projects has never required it, nor are any of my projects long-term enough or complex enough to bother configuring anything. I just open a default configuration of vim, type what I need to, and then I'm done. > What I am hearing from you is that you’re unwilling to put the time into learning/using the tools. Maybe more like "I don't see any benefit setting up an entire IDE and learning how to use the debugger to diagnose a 200-line Python file that runs in 0.8 seconds. > Or maybe you’re just stuck in your own headspace, many developers get that way, it is why we have editor wars and whatnot. I would turn this around - because I don't use an IDE that I've spent time configuring and customizing, and learning how to use the tools it provides to be more efficient, I'm less invested in which editor I'm using. I certainly get used to certain editors so I don't just randomly select a text editor each time I need to write something, but I would argue that the time and effort spent integrating yourself with a specific IDE and configuration makes someone more likely to "editor wars" than not doing so. Fundamentally, I understand the core benefits of using a debugger in the abstract; I see why and how it's useful, especially if you're able to do things like attach a debugger to a running process and inspect an error case as it's happening rather than having to reproduce it locally (or e.g. in a unit test). That said, I cannot see any way in which my workflow would be improved by that level of integration with an IDE when my current approach - useful debug logging - only has to be added to a program once, is useful for debugging this problem and any other down the road, and works whether I'm editing code locally in VS Code or SSH'ed into some remote machine running a cut-down version of Vim. | ||||||||
|