rekahrv

9 ms·

31.
When is inplace in Python Pandas faster?(sourcery.ai)
1 points by rekahrv 4y ago|1 comments
32.
by rekahrv 4y ago
Wow, that looks amazing. It's a really comprehensive guide. > This could have been a paper book but the Rust ecosystem evolves pretty quickly so an online guide that is constantly updated makes a bit more sense. :-) My question: In
33.
by rekahrv 4y ago
That's insightful. It seems that a virtual environment created by Poetry looks very similar, except that it doesn't contain an `include` directory. It contains: * `bin` directory * `lib/<python-version>/site-packag
34.
by rekahrv 4y ago
I'm curious to hear: * your thoughts on automating (parts of) the code review process * tools you've been using for it: for Python and for other languages
35.
Code Review: What and What Not to Automate?(sourcery.ai)
2 points by rekahrv 4y ago|1 comments
36.
by rekahrv 4y ago
Thanks, that's very helpful. "Interleaving. Practice multiple related yet different skills/concepts simultaneously." That isn't mentioned as frequently as the others, but it's a great strategy.
37.
by rekahrv 4y ago
> Someday, I’d like to see some sort of AI platform that can gauge a users intuition about the concepts on the whiteboard and tailor lessons to be impressed upon that user the best way. I’d teach a 30yo with ten years of Excel munging ex
38.
by rekahrv 4y ago
> There’s a rather deep rabbit hole really about figuring out what the best beginner curriculum should look like, because if the diversity of the applicability of Python. So true. I really like that 1 day is devoted to: * PyPI * virtual
39.
by rekahrv 4y ago
Yes, some data with actigraphy would be very interesting. I guess in that case it would be difficult to follow 170K people over 4 years. Folks wearing fitness trackers have quantitative data over a long period of time. I have no idea how re
40.
Getting Good Sleep Could Add Years to Your Life(neurosciencenews.com)
9 points by rekahrv 4y ago|2 comments
41.
Reflections on Software Performance(blog.nelhage.com)
2 points by rekahrv 4y ago|0 comments
42.
by rekahrv 4y ago
TLDR * Architecture and performance influence each other in both directions. * Micro-optimizations sum up. * When looking for performance red flags, start with the loops.
43.
Avoiding Performance Killers in Python Loops(sourcery.ai)
4 points by rekahrv 4y ago|1 comments
44.
by rekahrv 4y ago
Thanks. Based on this description, I'm not sure how much it will be a cloud service, a web framework, or a collection of components. :-) Anyway, I'm looking forward to hearing more about it in the next months.
45.
by rekahrv 4y ago
Congrats!! As an enthusiastic Pydantic user, I'm looking forward to the cloud services. :-) "We’ll start by helping engineers with small applications or functions" Can you already share some preview what the first products wi
46.
US Cities Are Falling Out of Love with the Parking Lot(wired.com)
3 points by rekahrv 4y ago|0 comments
47.
Learnings from Southwest’s Operational Meltdown(forbes.com)
1 points by rekahrv 4y ago|0 comments
48.
Interest Rates Are Rising: Calculating Tech Debt’s Actual Impact(sourcery.ai)
3 points by rekahrv 4y ago|1 comments
49.
by rekahrv 4y ago
I've been intrigued by the concept of "impact interval". How long do we need to "work around" the impact of this tech debt? It was revealing to see how much this affects the actual costs of that debt.
50.
by rekahrv 4y ago
Thanks a lot, that's very insightful. I've worked in various environments, but this is super different from all of them. :-) How often do the non-coding participants comment on sth? Is it more like a continuous conversation? Or ra
51.
by rekahrv 4y ago
That's an intriguing approach. It makes sense that not all changes are equal and they don't require the same review process. (And it certainly makes sense to encourage small changes.) What qualifies as a "small change"?
52.
by rekahrv 4y ago
That sounds very interesting. Can you tell a bit more about those mob sessions? Do all 4 devs participate? Do you follow some structure?
53.
by rekahrv 4y ago
An awesome article. 3 surprises around Postgres and a detailed description of the investigation leading to them. "we had a query that was particularly slow in production, but it was very hard to reproduce as we didn’t know our ORM was
54.
by rekahrv 4y ago
Yeah, I agree with that. A pair often produces better code than an individual. But now, they have common blind spots. :-)
55.
by rekahrv 4y ago
"Do those things matter once the code is actually written though?" That's a great question. I guess it depends on how much the code will change in the future. These things CAN get relevant again when you consider changing tha
56.
by rekahrv 4y ago
"Context gap: you encounter the same issue in an IDE when exploring a new part of a codebase" Yes, that's one of my major arguments for async reviews, especially in large organizations: Future readers of the code will have ca
57.
by rekahrv 4y ago
"My biggest issue with code review is that people rely on it and trust it too much." That's a very good way to put it. Code review is useful, but the expectation around it is often over reasonable. I agree on your points rega
58.
by rekahrv 4y ago
'You should review the "metadata" of changes before you ever review the code itself' That's a great approach. It sounds logical, but I certainly don't do it consistently. :-)
59.
Code reviews need to shift-left(sourcery-ai.medium.com)
37 points by rekahrv 4y ago|61 comments
60.
by rekahrv 4y ago
An intriguing article, although my opinion on async reviews is much more positive. :-) There are many arguments for both sides. Pro pair / mob programming: * Faster feedback. * Less time spent on solutions that might be rejected. * Bet

More ›