skysight-inc/HackerNews huggingface dataset:
In my opinion, that's in fact exactly how you should be developing your software.

Code is cheap to write, and mostly debt. A software product - a working system that meets some particular need - is not. The distinction is that building a software product is much more than banging out code; it's the experience of figuring out what exactly that need is (gathering requirements, getting a system out for users to test, getting real-world feedback). Sometimes you capture that in documentation, test cases, ADRs, comments, commit messages, etc. Sometimes it's in your head, which is okay as long as you're still there. (Of course, if it's in your head and you leave, then the next set of programmers will be scared to change the system until they redo the work of figuring out what the software is, despite the code being in front of them.)

If you have that understanding about what the software does, ideally in the form of automated test cases, you can rewrite the code. So you may as well bang out the code in a way that gets you a working system and remains comprehensible. Once you're making enough changes to it that you're worried about it getting incomprehensible, proceed to rewrite it. Probably the world has changed in many ways sine you wrote it - maybe you can run the system for a lot faster and cheaper with containers in the cloud talking to a SaaS database than with your expensive IBM mainframe talking to DB2. Or perhaps the requirements are changing significantly, and starting with the old code doesn't give you much of an advantage.

Trying to keep a codebase comprehensible over the long term makes it, if you'll excuse the pun, solidify - it becomes increasingly hard to make changes that weren't anticipated by the original design, and it also requires more and more effort to just do anything. You might be able to swap out the relational database for another one, but you probably can't switch to a design where you're using a key-value store with totally different performance characteristics. And even if you do just want to change the database, you have to figure out how ten classes get dependency-injected into each other before you can start coding.

All the time you spent making the code "future-proof" so it remains forever comprehensible could have been spent simply not doing that, delivering business value, and writing new code as the need arises.
Font Collections
I'm a healthy male who's been "hiding in [my] home for a year". I mean, other than shopping trips, and running, and cycling, and skiing, and.. However, I've done no social events, seen no friends, etc.

But, sorry if you think trying to avoid illness, trying to avoid passing on illness to others who don't have the comfort of working from home, passing on the illness to elderly family members, etc, is a waste of time. It's a pretty minor inconvenience for me to be largely isolated for a year, compared to those who are less fortunate than me.

How about a big 'ol [citation needed] on

> All current data shows areas that have taken that approach are significantly better off today than the places that hid in a hole the past year.

You know, a citation that doesn't involve correlation with countries that happened to have extreme lockdowns initially, acceptance of mass testing and screening and social restriction when necessary, etc.

By the way, my wife works in rehab in a hospital, and sees your "low risk" young people whose lives have been, as far as we can tell, permanently altered by the virus that some of us are seeking to avoid.
submit a pull request?
It's not that hard really in the UK. Salaries are shit, and my advice to anyone looking for work into the UK is to be a contractor. I was effectively on £100'000+ at 23 in the UK as a contractor.

British and American companies are structured quite differently. As a contractor in the UK, you effectively have the same rights as an American employee.

If you look on the job boards for contract work, hardly any of it (prior to corona) was under £500pd.
There's still plenty of latency sources on the way from he mouse hardware to the application's event handling code. The remaining way to the display just adds (more or less) latency on top - which isn't as important when it's just about the discrepancy of the mouse cursor and what's rendered beneath though. But the mouse cursor can use all sorts of special shortcuts, for instance the cursor is a hardware sprite which is updated and rendered indepedently from the rest of the "rendering pipeline" otherwise the cursor movement would feel laggy all the time.
Quick iteration times make debugging and experimenting much easier. I spend much more time debugging and experimenting then I do optimizing or making high level designs.
> 'typed' Python is a great language/dialect in its own right.

Like OO in Python, it feels bolted on. The syntax for generics is bad, at least compared to Java. Typing also exposes how poorly thought out Python's collections are. The hierarchy and methods make sense, but some things are in typing, others in collections.abc. It also falls over when using things like functools.partial.

Then there's the frequent complaint that if you're going to go to the effort to use something typed, you should use something that can take advantage of those types during compilation to optimize the code.
You the programmer do. Do you expect everything to be automated by successive application of precise rules?
>>>and are lobbying to get the federal minimum wage raised to that level from $7.25.

What you fell for the Con...

Amazon wants $15 in order to put the final nail in the coffin of small business hiring that teen for their first job stocking the small local store...

No they want those positions gone, they want those business shuttered.

This idea that Amazon is "fighting for the worker" in their drive for $15/hr minimum wage is moronic.

$15/hr min wage is also not based on any economic reality and as a basis for a "living wage" it would be far to low in some reasons, and far too high in many others.

Minimum Wage should be a LOCAL, or state level policy not a national one.
> All current data shows areas that have taken that approach are significantly better off today than the places that hid in a hole the past year.

Source?

I'd argue current data shows that those that showed an overabundance of caution, like New Zealand, are the ones significantly better off than everyone else.
> For every person that dies (an agonizing death akin to medieval torture)

I think this is wrong, at least in rich countries, at least those that are sane enough to cure their ill citizens.

A friend of mine died of covid last year. Then a family member this year. They were both sedated, and did not suffer at all on their last days in hospitals.
Lawyers (of the company) typically don't get involved in reviewing pitch decks for accuracy at least in the early stages. And even if they did, the lawyers only know what the founders tell them. Additionally, lawyers typically avoid asking probing questions of founders. especially if there is risk that the answer they get may be troubling - it's much easier to defend and advise a client when you're not explicitly aware of every dirty secret.

But you're not totally off base. It's absolutely the responsibility of VCs to do their own due diligence. VCs usually are investing other people's money. It's not a good look for VCs to invest in scams, so VCs typically do some degree of due diligence (which could be virtually zero diligence at seed stage / Series A, to quite a lot of diligence at later stages as the amount of money involved increases).
Yes, exclusive fullscreen mode applications are not running in a window, so they can have zero frames of latency (though almost all don't, for various reasons). I am not sure about borderless fullscreen mode, I think this may also have an optimization that can eliminate the 1 frame delay. But normal windows always get the delay.

There is also a feature designed to let applications bypass this delay in windowed mode using GPU hardware overlays, however it needs GPU driver support and it is not supported on Nvidia or AMD drivers AFAIK. Basically nobody uses it.
| they are realistically at zero risk of severe illness.

I didn't do it for me.
good point, it might raise our IQ as well!
I don’t agree.

You need to eat to not die before you need sex.
Agree. Programming is just too vast of a field to have universal principles. It is also changing to fast for most principles to remain relevant.

We just like mental shortcuts. We ask should we use SOLID/whatever, instead of asking why was SOLID/whatever used and does this why apply to us.
The author inverted the way we rationaly understand reality. Instead of observing and concluding, he concluded and then retro-fitted observations - he actually admited this by stating his motivation was to make an anti-solid presentation for the sake of it, I'm not making this up.

Thus it is unfair for us to try and contradict his arguments, it's like talking to a conspiracy theorist, they will glue random facts trying to support a pre-decided conclusion.

Having said that, this post is very shallow. Even if there is merit to criticising the SOLID principles (and I would be very interested in such a criticism), you can't just do it an a couple of sentences.
> instead, I read him saying that the alternative to SOLID was “Write simple code.”

The part you missed is in the same sentence as the three words you quoted.

"Instead I suggested to write simple code using the heuristic that it 'Fits In My Head'."

The obvious criticism here is that now any developer who wants to defend their code will simply claim a given spaghetti incident easily fit in their head. The author even seems to acknowledge this line of attack in the next paragraph:

> You might ask “Whose head?” For the purpose of the heuristic I assume the owner of the head can read and write idiomatic code in whichever languages are in play, and that they are familiar with the problem domain. If they need more esoteric knowledge than that, for instance knowing which of the many undocumented internal systems we need to integrate with to get any work done, then that should be made explicit in the code so that it will fit in their head.

But that just protects against spaghetti made from esoteric know of internals. For example, in C a "big head" would still be able to justify using global variables (after all, that's idiomatic C), rolling their own buggy threading approach, and deeply nested side-effect based programming.

I'd much prefer pointing big heads to the rule of "do one thing" than to ever read a response of the category, "Well, it fits in my head."
> Firstly if the dependency isn't doing any io, you can test your code as a whole along with its dependency. No need to mock.

This the thing. People have a tendency to overuse mocks. The point of automated testing (whether it's unit tests or something else), is to enable refactoring. That's really the only reason. Code that you don't touch doesn't suddenly change its behaviour one day.

In a previous jobs the developers started to go crazy with mocking and it reached a kind of singularity where essentially if a function called anything, that thing was mocked. It definitely tests each function in complete isolation, but what's the point? It makes refactoring impossible, which is the entire point of the tests in the first place!

This excellent talk completely changed the way I approached testing. Every developer who writes tests needs to watch this now! https://www.youtube.com/watch?v=EZ05e7EMOLM
So I may be navigating that Cookeo website wrong, but 150-250EUR is very expensive. I have a rice cooker that costs that much, but it's a high-end brand. You can get a pretty good mid-range rice cooker for $40 and a serviceable one meant for college students runs $20 USD.
I totally agree and had a very similar experience in graduate school. Writing about my experiences and things I had learned (technical and project management) had a huge impact on my ability to demonstrate my knowledge and is without a doubt why I quickly received two job offers before defending my phd (biology/neuroscience). I think papers are a really poor way to demonstrate the huge amounts of work you've done unless you stay in academia (and probably not even then).
> I have not seen support of changing underlying DB as a business requirement yet (well, outside of frameworks and platforms, of course).

... and, you haven't ever seen a business requirement of what used to be a "software" to become a framework / plateform instead ? it happens all the time
Implement yes, but will it make a relevant difference? IMHO Unlikely.

A BOM no one (of relevance) ever reads is as good as no BOM.

The main positive effects a BOM can have (outside of SaaS) is to more strongly discourage to use (continue to use) of known to be problematic libraries or services.
Well, he invented BDD, which very much builds on TDD, so, no, that's not the direction he's going.
Mark Seemann's blog I've been reading for the past couple years answers this question. In particular, his posts on Hexagonal Architecture[0] and Dependency Rejection[1], but there are many more articles that cover this and I highly endorse reading.

To summarize, you want to set up your code into two distinct categories, data and pure functions. Your data is at the top level of your code, so if you need external data that needs to be at the top level of your module. You then feed that data through a pipeline of pure functions that return with some sort of answer back to your top level module that can then pass into some other function(or through a quick lambda) that does the actual transformation at the top level. The key is that a function can either be a pure function or it can be an impure function. Never both.

As an example, let's say you've got code that has to read from a couple text files. Currently your code does this through a couple nested loops, with the loops passing in what folder it is in and what its file name is, but your code is filtering through some that you don't want to read.

To re-envision this code, you would create a pure function that comes back to the top of your module of which files to read. Then that top module would read those files, and pass them to some other function that does transformations on the result.

You now don't have to create mocks, just create data and pass that into your pipeline and then check if it gets the expected result. One of the interesting side effects of doing this, is at a certain point you stop unit testing for correctness(as the code is so easy to reason about written in this style), and start unit testing primarily for documentation.

[0]: https://blog.ploeh.dk/2013/12/03/layers-onions-ports-adapter...

[1]: https://blog.ploeh.dk/2017/02/02/dependency-rejection/
Not too surprising. YC’s more successful companies do have a history of skirting (Uber, AirBNB).

When I worked at PagerDuty, some of the less ethical aspects of the company (like the product was initially developed while interns at Amazon) were explained to me with this phrase, verbatim:

“Paul told us to be naughty, but not too naughty.”
This way of dealing with file-access is also not secure: if all your files eventually end up in a Downloads folder which is readable by all Flatpak apps, then what advantage does this have over sharing your entire home folder?
Upcoming Interesting JavaScript ES2021 (ES12) Features to Look For
I kind of feel that the health field is special because of the risks. I guess self-driving may eventually get there too, in terms of risks.

I don't remember any mainstream media reports talking about which VCs where early/heavy investors in Theranos though. :/
I do not waste my time trying to prove / figure out what is the "proper" way of doing things. I use whatever approach I feel suits better for particular case and do not give a flying hoot about what's the latest fashion.
They aren't being ordered to do anything though. The system that was built isn't the thing setting the targets, the users are. We wouldn't argue that the creators of email are responsible for any exploitation that email has enabled and I don't think it's reasonable to argue that a developer for a delivery routing system is responsible for the incentive structure set up around that system after it has been built.
I'm not picky. I have a drip coffee machine, but cheap instant coffee is fine too.
What's the alternative here? If you had to change a codebase's usage of ints to uuids, should the original author have used dependency inversion and required an IdentifierFactory that was ints at the time so you could just swap out the implementation? And if they did - why wouldn't they have just used UUIDs in the first place? You're betting on the fact that the original author anticipated a particular avenue of further change, but also made the wrong decision for their initial implementation, which seems like the wrong bet. If they made the wrong decision, they almost certainly didn't anticipate the need for another one, either.

And how long would it have taken for the original author to use an IdentifierFactory instead of ints and write meaningful tests for it? Less than two days?
SEC complaint:
https://www.sec.gov/litigation/complaints/2021/comp-pr2021-4...
I don’t see any reason new variants would ever stop coming. What are you proposing is the end point of all of this?
For those interested in this area I recommend:

https://www.psyonic.io/

It’s cheap and I’ve watched it be developed since the beginning. There are multiple ways to restore a sense of touch, this appears to use the method which stretches in the skin.

There’s also a method of restoring the senses that uses electrical current. It was fun to watch all the undergrads in the lab electrocute themselves lol. The reality is skin stretching is consistent; where as how electricity flows through the body varies wildly between people.

The one linked in my comment uses vibration:

https://www.psyonic.io/ability-hand

Which has less of an impact long term (Aka drying out skin from twisting, etc)
>>This never happens in union shops, by the way.

While that exact problem many never happen (and I have by doubts about even that statement)

unions are not the panacea of all virtue nor are they the solution to all labor problems
SRP is vague because it really depends on how your team prefers to draw boundaries around the responsibilities. Some places choose to have meatier responsibilities (an entire ETL pipeline as one class), or prefer smaller responsibilities (same ETL pipeline, but each stage of it is a separate class). Both of these could use roughly the same amount of code, whether it's implemented in 1 class or across 3 classes. Some of this is driven by how user stories and work is organized.

SRP never really recommended how large those responsibilities should be, but that's almost impossible to do given how widely programming is applied (especially for a quick acronym parroted in interviews). Had it tried to specify this size, we would likely be dealing with "OLID" instead of "SOLID", since it would be much easier to criticize.

It comes down to how many tabs you want opened in your IDE and how good you are at moving between them and keeping the object relationships in your head. If I have a god object to handle one responsibility, I only have to look at one file, but it might be thousands of lines long. Or I can reduce that down to tens of files open with hundreds of lines each. Or it could be hundreds of files with only around ten lines each. The god object allows me to mostly forget about any object relationships or abstractions. But I pay some price by having to learn the entire god object before being able to sensibly work on it.

If I have some object inheritance like:

IPipeline -> AbstractPipeline -> SqlPipeline -> PostgresPipeline, SQLServerPipeline, MySqlPipeline

IPipeline -> AbstractPipeline -> NoSqlPipeline -> MongoPipeline, CosmosDBPipeline

(every architect dreams of this)

It's easier to change things per database without affecting the others. Since each of these products change independently of one another (Mongo doesn't consult Microsoft about SQL Server), it makes more sense to do it this way as opposed to having a god object when you know you must support these other databases.

On the other hand, if you know you will only ever use Postgres, IPipeline, AbstractPipeline, SqlPipeline/NoSqlPipeline become mostly useless abstractions.

This also varies greatly whether you're trying to build building blocks for other developers or just trying to ship a product. Principles aren't always going to apply to both of those, and SRP might be one of them. It wouldn't hurt to add "depending on how your team defines responsibilities" at the end of SRP.
Yeah, I do use Tramp mode, but have, at times, had problems with it and actually found an smb mount to be more reliable (ha!) when editing files. But often what is the case is that I'm using a variety of bash tools while ssh'd in, and then quickly find I need to edit a file and so launch the server's copy of emacs. Theoretically, I could do everything in Emacs terminal mode, or eshell, either using Tramp, or in the remote instance of Emacs, but I never seem to find that it works hassle free, which is too bad, because I really like being able to move about the terminal field as if it were a text file (e.g. doing a regex on already existing output, etc.).
Are people publishing on Medium in order to earn money now or just that the large migration to a free platform is yet to occur?
Typescript at least has the excuse that you have to run JS, so the approach is more sensible. With types in Python, for the most part, you could choose a different language.
This is more typical than you'd expect. Once you hear about LEO involvement in high-profile cases, you start seeing it everywhere.
> Abstractions are a way of trying to find a common ground conceptually.

What's always amused me, in a tortured sort of way, is that SQL is already the abstraction. Then people go and layer an abstraction on top of it, such as some ORM flavor-of-the-day, which is obviously much less universal than SQL. In "SQL" I'm including vendor extensions too (Oracle, MySQL, etc.). It's easier to read up on vendor extensions than learn yet-another ORM.

Which do you think has had the longer shelf life: MySQL or some random Ruby ORM? If you've been doing MySQL since the '90s then it's largely the same as MySQL of 2021. That Ruby ORM? Probably hasn't seen an update since 2008. I can't even remember the names of all the ORMs I've had to use over the years.
As another data point, Musk is chief engineer, and also involved in securities fraud in other roles ("going private $420").
This is obviously false, it’s just too general a statement. Type errors are such a small time loss as a developer - when i think of the things that lose me time, it’s things like domain complexity, misunderstood requirements, not “ooops i passed a string instead of list of string”.

I wondered if there are any studies that support your assertion? The first few results in Google all refute your idea though, e.g. https://www.researchgate.net/publication/259634489_An_empiri...

Or https://www.ics.uci.edu/~jajones/INF102-S18/readings/23_hane...

And that intuitively makes sense. When i’m adopting types, time saving isn’t really what i’m buying. It’s the opposite - i’m saying “hey, i want to invest more time into this to help ensure correctness” - i.e. i am happy to wrestle with the type system if it means the delegation frees my brain for solving the problem.

And this comes back to what i mentioned earlier about domain complexity - you can use types to help make that easier to manage, often though, it’s better to push harder to eliminate complexity in the first place. Occasionally that’s just not possible, it’s a complex problem domain not another CRUD webapp, in those cases types are fantastic.
Solid: The First 5 Principles of Object Oriented Design