3 ms·

"As the code base improved, kdb+ releases became faster – and smaller." This is what I always strive for. Although I've only met Arthur a couple of times, he h

"As the code base improved, kdb+ releases became faster – and smaller." This is what I always strive for. Although I've only met Arthur a couple of times, he has been a huge influence on me as a developer. Besides some shared personal interests, his development philosophy that simplicity and consistency produces performance and malleability (to be able to constant add, subtract, or write). He's on the top 3 developers I try to model myself after. While he's a god among men, his products (A+, K, KDB, Q, and now Sakti) make others mortal also gods among men by just learning to think and use his tools. My co-workers I'm sure get annoyed at my code-reviews ("delete this", "rthisewrite fir first with that then delete the second", "delete all this and return this",. ...) where I consistenly call for deleting a remodeling code to be as minimal as needed. I'm brutal about it - as I learn from K and it is partially Arthur's fault (and another dev I look up to). Maybe now they know where I picked part of it up. https://shakti.com/ https://shakti.com/ is his new distributed database project that is still somewhat hush hush, (and he not the kind of person that plays buzzword bingo - so I assume he has something special planned). I cannot wait to see how that turns out. I don't know if he's ever produced a bad product.

delinka 7y ago
> ... "rthisewrite fir first with that then delete the second" I'd be annoyed at this code review comment. "rewrite this `for` loop first, then delete the second `for` loop" is what I assume you intended.
gmueckl 7y ago
Remember that as a reviewer, you always have an advantage over the coder: as the coder, you need to crack the problem and find an algorithmic solution. It's easy to have a couple of false starts with this. These do stick around through iterations and changes. Eventually, you submit something that works, but you're overlooking that the code could probably be less convoluted in places, because you know the solution and it is perfectly reasonable. The reviewer who gets to read the code gets to walk the shortcut to the solution after the trail was blazed for them: they get to think purely about the working solution without the intermediate steps. And they naturally will find places where the original developer was thinking in terms of his failed earlier attempts. I bet that if I gave you a non-trivial problem to solve in a reasonable amount of time I could do the same kind of review on your code, forcing you to shorten it. And I will find something. Guaranteed. That is just how these iterations work.
- jodrellblank 7y ago
  I bet that [..] I could do the same [..] And I will find something. Guaranteed. Why are you framing this as though it's adversarial and the parent comment is stating some kind of superiority, and you're here to turn it around and put them in their place? Isn't teamwork all about doing better than one person working alone?
  - gmueckl 7y ago
    My take on the parent comment is that it has some adversity and feeling of superiority to it. And I don't like that. I agree that in the end it is not a competition, I didn't think that I would have to point it out. In fact I am in the middle of fixing up code that I wrote as novel research because the powers that be want it in a production system. The code review I got was detailed and - frankly - embarassing at times because all the uncertainties and meanderings of research had me change pieces of code over and over and over again to a point where remnants of old approaches didn't stand out to me anymore and where I had at times built on top of bad decisions because they were meant as a temporary hack and experiment, but worked well enough and stayed in. And by the time I submitted the code for review I had become blind to these mistakes. I know how to write good and clean code and I get through code reviews easily when I know what I am doing. Not this time, though.

delinka 7y ago

> ... "rthisewrite fir first with that then delete the second" I'd be annoyed at this code review comment. "rewrite this `for` loop first, then delete the second `for` loop" is what I assume you intended.

gmueckl 7y ago

Remember that as a reviewer, you always have an advantage over the coder: as the coder, you need to crack the problem and find an algorithmic solution. It's easy to have a couple of false starts with this. These do stick around through iterations and changes. Eventually, you submit something that works, but you're overlooking that the code could probably be less convoluted in places, because you know the solution and it is perfectly reasonable. The reviewer who gets to read the code gets to walk the shortcut to the solution after the trail was blazed for them: they get to think purely about the working solution without the intermediate steps. And they naturally will find places where the original developer was thinking in terms of his failed earlier attempts. I bet that if I gave you a non-trivial problem to solve in a reasonable amount of time I could do the same kind of review on your code, forcing you to shorten it. And I will find something. Guaranteed. That is just how these iterations work.

jodrellblank 7y ago
I bet that [..] I could do the same [..] And I will find something. Guaranteed. Why are you framing this as though it's adversarial and the parent comment is stating some kind of superiority, and you're here to turn it around and put them in their place? Isn't teamwork all about doing better than one person working alone?
- gmueckl 7y ago
  My take on the parent comment is that it has some adversity and feeling of superiority to it. And I don't like that. I agree that in the end it is not a competition, I didn't think that I would have to point it out. In fact I am in the middle of fixing up code that I wrote as novel research because the powers that be want it in a production system. The code review I got was detailed and - frankly - embarassing at times because all the uncertainties and meanderings of research had me change pieces of code over and over and over again to a point where remnants of old approaches didn't stand out to me anymore and where I had at times built on top of bad decisions because they were meant as a temporary hack and experiment, but worked well enough and stayed in. And by the time I submitted the code for review I had become blind to these mistakes. I know how to write good and clean code and I get through code reviews easily when I know what I am doing. Not this time, though.