5 ms·
I had the same thing happen to me lately, but I was at the stupid end. I am not a programmer by profession, so it matters very little to me, but I had been stru
by bjoli 7y ago
I had the same thing happen to me lately, but I was at the stupid end. I am not a programmer by profession, so it matters very little to me, but I had been struggling to produce a correct solution to a seemingly simple problem (writing a macro to allow definitions in expression context in r6rs scheme). My solution worked but had the side-effect rewriting obviously bad syntax into correct one and not in a good way.
I was struggling with how to do it correctly, and then one of the people in the r7rs working group simplified the problem by a very large factor by pointing out to me that I was trying to solve a non-existant problem, because I tried to add definitions to expression contexts where it simply made no sense. In fact, instead of supporting all forms, I could get a better result by just focusing on one of them and add simple wrappers for another 5.
It was all quite humbling. Had I taken a step back and actually analyzed the problem I would have come to the same solution, but I immediately tried the, to me, most obvious and also hard-to-get-right solution.
- ajna91 7y agoA very humane telling of a humbling experience.
- trilila 7y agoGreat engineers learn from mistakes, and it seems like you did. Formal training or not, we all make mistakes, but indeed a good approach is to take a step back and analyse _any_ issue or complex problem before implementing it. Sometimes prototyping separate from the main codebase helps.
- tempguy9999 7y agoSuch dumbness is very common with me too, and yet I also call myself a great problem solver, for good reason too. It's not a paradox, it's a matter if excess focus - once I get into a rut I just keep bulldozing[0], but coming to a problem fresh it's often trivial because the rut hasn't formed. I'd say it gets better with experience, and you're probably better than you think - my guess is you don't see your successes as clearly as your failures. I guess you spend so much time on the failures, but if you instantly perceive the right approach to a hard problem and solve it in a shot, well, it wasn't a hard problem, right? A kind of bias of perception. [0]I get the impression that's a bit of a man thing generally
- namibj 7y agoThis is what pair programming fixes, among other things. You have someone who can literally take a step back to get a broader overview. It's quite nice from what I can tell (I do want to do more of it, but at work we don't have the problems that make the most fun with pair programming, and for side projects I lack friends who are willing and able to grasp the math behind it (nothing extreme, just on the level/around pose reconstruction and some simple (linear core) optimizations intertwined with (photogrammetry) domain specific data shuffling).
- quickthrower2 7y agoYou had trouble writing a scheme macro? I think most pro software developers would struggle to! I don’t think this is dumb.
- bjoli 7y agoI do not have any problems writing macros (in fact, I recently finished my guile scheme version of rackets for loops) It is just that the macro I wrote did a lot more work than it had to, and led to weird syntax behaviour. I didn't delimit what I was trying to do. John over in #guile put me on the right track.
- quickthrower2 7y agoI didn’t mean to imply you had trouble writing all macros. But as someone who is trying to learn some c-lisp on the side I can see why they can get a lot more tricky than “regular” coding that one might do say in Java. So the point is you are probably doing something more advanced there.