Seems to help.
260 karma · joined January 12, 2021
Seems to help.
self interested and short sighted says nothing about intelligence, irrationality, or poor decision making. Back handed and inhumane covid hiring and firing is probably not a mistake from their perspective. professional bullshitting is a form of intelligence (I hate it too, I've been done in by it, but I respect it)
No one is making this claim.
My comment was a bit terse and provocative, rude, deserves the downvotes tbh. I'll take them.
To elaborate ~ I've got a lot of empathy for the poster I was originally replying to. I've fallen into that way of thinking before, and it sure is comfortable. Of course, companies and their leadership make poor and irrational decisions. Often, however, it's easy to perceive their decisions as poor and irrational when you simply don't have the context they do. "Why would they x ?? if only y!!" but, you know, there may well be a good reason why that you aren't aware of, they may have different goals to you (which may well be selfish! and that doesn't make them irrational or anything). Feels similar to programmers hating when people say "can't you 'just' x" - well yes, but actually there's a mountain of additional considerations behind the scene that the person spouting "just" hasn't considered.
Is leadership unintelligent, or displaying poor/irrational decision making, if the company self destructs? Perhaps. But quite possibly not. They probably got a whole lot out of it. Different priorities.
Consider that leadership may label a developer unintelligent if that dev doesn't always consider how to drive shareholder value "gee they're so focused on increasing their salary not on business value". Well actually the dev is quite smart, from their own perspective. Same thing.
And if every company you've ever worked for truly has poor leadership then, yeah, it's probably worth reassessing how you interview. Do you need to dig deeper into the business? Do you just not have the market value to negotiate landing a job at a company with intelligent leadership?
So, two broad perspectives: either the poster has a challenge with perception, or they are poor at picking companies. Or perhaps the companies truly do have poor leadership but I think that unlikely. Hence it comes back to the individual.
@y-c-o-m-b sorry for being a bit rude.
Cheers for reading
Says nothing about companies and everything about you
> you also over-estimate the desire for developers to increase their productivity with AI. I use AI to reduce complexity and give me more breathing room, not to increase my output.
I'm the same. But I expect that once many begin to do this, there will be some who do use it for productivity and they will set the bar. Then people like you and I will either use it for productivity or fall behind.
> Show me everywhere this API is used incorrectly across the entire codebase
This is possible these days with (you guessed it) LLMS, likely with RAG. In fact I've made MCPunk https://github.com/jurasofish/mcpunk with exactly this in mind. There's a nack to wielding it effectively (bullying the LLM just right, feeling when it's bullshitting, etc) but it feels like this kind of capability will soon be commoditised. Super handy for code review like "Hey pal are the changes in the currently checked out branch logically consistent with the rest of the codebase"
Like imagine giving the same prompt (instruction, directive, task) to a human - you would in all likelihood get out a similar high level diagram because you've not provided even the slightest whiff of what you want to use the diagram for.
The blog's takeaway is essentially "LLM didn't read my mind so no good". They're tools to be used and you get out what you put in.
Anecdotally I've had great success with code to diagram via LLM including fine details. But as with anything LLM you need to really get the context right. This can not be overemphasized. And iterate with the LLM, goodness.
I find this works really nicely, I can periodically clean up my commit history and do a full review of my changes so far and make sure they're all coherent before continuing. And doing this regularly makes it much easier to keep the commits nicely self contained. It's like `final_version_final_ii_for_real_final.xlsx` on top of git
If the alternative to Async is more processes, rather than threads, a clear benefit is reduced memory usage and reduced process startup time.
For more complex diagrams, where explainer notes are beneficial, I find hand tweaked diagrams can not be beaten (my go to is draw.io)
If a simple DaC diagram is 1000 words, then a hand tweaked diagram is 10,000. And that 10,000 pays off. The bang for buck payoff is there. Of course, other considerations like maintainability etc etc
Nice
Bello, fellow Minion! Let me tell you about the banana-tastic article I just read called "LIKE SLUGS THROUGH THE HOURGLASS, THESE ARE THE DAYS OF OUR TECH TRIUMPHS"! Minion 1: Ooh, banana! Tell me more! Minion 2: Bananaaaa! What's it about? Minion 1: Well, it's like a big banana split of tech job market woes! The writer talks about how interest rates going up made tech jobs go splat, like mushy bananas. Minion 2: Papoy! That sounds bad for techie bananas! Minion 1: Totally! And get this - some companies want one Minion to do the work of many Minions! They call it "Everything Bagel" jobs, but it's more like asking for a banana, apple, and potato all in one fruit! Minion 2: Bapple? Bapple bad!
Is this true? I thought GitHub had no official affiliation with the git project
If only :)
Far too often I find myself working with tests that patch one too many implementation details, putting me in a refactoring pickle
And various C APIs for solvers have other callbacks
It's generally quite limited of course, for the reasons you mentioned.
python-mip is substantially faster than cvxpy, pulp, and pyomo for constructing _and solving_ a very simple LP with 10k variables. It's on par even with cylp using vectorisation (maybe I haven't used cylp as well as I could (either way cylp is dreadful to use)). I say _and solving_ because for my use case it's the time to construct and solve relatively simple & small problems (like, <100ms overall) that I'm interested in, which includes anything like serialising the problem to a file and invoking the solver.
But keep in mind these kinds of benchmarks can depend a lot on how you're using the library. Like, are you spending almost all time actually solving the model? Then it probably doesn't matter what library you use to construct the model.
python-mip in general is pretty nice. It supports advanced solver features if you're into that sorta stuff. But their typing is a bit whacky (no py.typed file, use numbers.Real for typing which makes type checking a bit whacky). And it relies on a funky pre-compiled CBC binary (I had to compile it from scratch at a very specific commit to get it working on M1). python-mip creates/modifies variables in the underlying solver library (CBC/Gurobi) as you create/modify variables through the python interface (I believe this is an uncommon approach, but good). The internal data model of variables & linear expressions is quite clean and tidy.
Overall would recommend python-mip if you just need to solve MILP problems.
From my scrappy benchmark constructing and solving a very simple LP with 10k variables:
'benchmark_python_mip' took: 40.33 ms
'benchmark_cvxpy' took: 738.11 ms
'benchmark_pulp' took: 152.68 ms
'benchmark_pyomo' took: 191.66 ms
'benchmark_cylp' took: 38.91 ms