> We’re launching with $1.25 million to be invested across 125 projects, backed through the kind support of Alfred P. Sloan Foundation, American Express, Chainguard, HeroDevs, Kraken, Mayfield Fund, Microsoft, 1Password, Shopify, Stripe, Superbloom, Vercel, Zerodha, and others.
It's quite logical to think that they have an incentive to get you as much money as possible but in reality it's often not quite correct. Their stronger incentive is to establish a relationship with a business and to continue feeding them candidates at an attractive price point for the business. The marginal amount of extra commission that they make on your increased salary is not that significant.
I think it depends on how motivated the attackers are.
If we are talking about the account creation form of Facebook, you bet you will need some CAPTCHA. If it's a random form with no obvious benefit of spamming then I'm not sure how many "attempts" will be done to begin with regardless of the protection mechanisms.
In those cases you may be enocuntering bots that "blast spam" and usually the slightest form of barrier stops them because they tend to be made for the common denominator, for example by targeting popular blog/forum software that have a predictable form structure that the bot can be programmed for.
I have seen some basic anti-spam features that are "home-made captcha".
For example it says something like "Pandas are black and:" and you have to enter "white".
Those can sometimes be made in a way that is more user-friendly compared to a "real captcha".
However it takes some careful consideration and knowing your audience to make sure that they understand what to do. Some users may not understand it due to language or cultural differences or due to people being used to the traditional captcha.
You may want to remove the protection mechanism to see if you get any spam at all or not (or at least log and measure success vs failure cases).
Without knowing anything about your use case, personally I'd remove the CAPTCHA and see how many spams come through. Then I'd put a very basic and gentle barrier just enough to remove those spams and gradually increase the barrier if required.
Another thing to consider is that if your users have to login you can have some kind of basic reputation metric so that "known good" users are not subject to the same restrictions.
In large codebases you can have a problem where people randomly import things from different locations leading to a host of issues including circular import issues.
For example someone finds a convenient helper function in "my_thing.foo.bar.helpers" and imports it but you don't want that dependency between those modules and the helper function was not intended to be used outside of that module.
In Python this problem is especially severe because there is no native module encapsulation mechanism other than a weak conventio of using the underscore prefix.
A tool like this helps you enforce "intentional" module boundaries so modules can't randomly reach into each other to import things. You will be forced to consider an intentional modular design where the helpers that are needed by many things are separated out and other things are allowed to import from it.
Especially in a large codebase where lots of different modules are technically in the same package as each other.
It's easier when a library author is publishing a small package for external consumption by other parties.
Another issue is that in Python any name in a module is implicitly available to be imported from other places.
For example let's say you have "A.py" inside of "A.py" you have "from something import foo". Now "B.py" can do something like "from A import foo".
So now "B" has a dependency that nobody really wanted to create.
Later "foo" may not be needed in "A.py" anymore and it will look like a totally unused import to anyone. Except it is being used by "B.py" too behind your back.
Someone deletes the "unused import" and something else somewhere else breaks because it can no longer import "foo" from "A".
(I have seen variations of this issue happen many many times so don't think I'm making some theoretical scenario.)
It's a very contrived scenario, and practically never happens if you use a python IDE. I've worked on multi-million line python codebases and this kind of stuff only happened when the (junior) dev insisted on using something like VSCode and not bothering to do a casual check of where they're importing something from. Also happened when you got "senior" devs with the idea of "python is just a silly little scripting language, I can pick it up in a weekend", but even then they were stubborn and didn't use a Python IDE, instead resorting to using a barebone and barely-configured installation of VSCode.
I'm not sure what use-case this serves, as all my library "don't be naughty" needs are handled by my IDE.
In many cases that page is a "catch all errors" page.
There are technically "infinite" different reasons it could be shown. For example a variable is unexpectedly undefined due to a bug in the code.
So the error message can't elaborate in detail exactly what's wrong or why it happened or what to do about it, or whether trying again will help or not, etc...
Behind the scenes (hopefully) the actual error is captured and logged for further inspection.
In other words the end user will see a generic and friendly error message but behind the scenes the developers will see the actual code error along with other information such as a stacktrace to show how the code reached the path where the error happened.
Yes and some people don't appreciate that some jobs really do require quiet focus for extended periods of time.
Asking someone to be a programmer in a loud chaotic open office environment is not dissimilar to asking them to program while juggling two balls and sitting on a unicycle. Its just excess difficulty that doesn't need to be added on top of the jobs.
I just always assumed an "open office", really meaning a non-office, an empty building, was what was available for startups after the dot com bust in SF.
Then after the fact we made up a bunch of bullshit as to why this is some brilliant idea. Then this idea spread as if it was some kind of technological advancement because it worked for small tech companies trying to not spend money on furniture and walls.
We just aren't very good at any of this at scale. The open "office" and battle against remote work are different flavors of the same type of stupidity.
I actually like that environment, unless I'm having problems debugging something. If something is not working after an hour or so I am on edge and need peace and quiet, but otherwise I can program fine for most tasks with noise around me.
My team is very small remote-primary, but we will travel to each others cities / offices quarterly or so.
We have long since given up on getting any work done on our in-office days, but see them as collaborative / bonding / light planning only.
It's gotten to the point that even if we fly to each others city for a week, we might only go to the office 2~3 days, or by Wednesday/Thursday we might by physically collocated but go to different rooms in silence with headphones to actually get work done.
As a dev these days are actually pretty stressful as they have the feeling of creating work faster than doing any of it. It makes me remember how unproductive my dev teams used to be with the constant in-office interruptions. At prior jobs, I used to do most of my actual dev work after hours, and on unilaterally declared WFH days
I don't think it was super crazy compared to the other websites during that time. A lot of the websites shared similar vibes even outside of GeoCities.
