0xFACEFEED

7 ms·

1.
by 0xFACEFEED 1y ago
Honeypot.
2.
by 0xFACEFEED 1y ago
> not liking the consequences of choosing those options Correct. "Shove it" is usually preceded by not liking something. > They could negotiate with their manager to lessen the load. Most of the time the manager will simply
3.
by 0xFACEFEED 1y ago
The difference is agency. Let's say I'm a business owner and I'm frustrated with the current state of the on-call system. I have options. I can try negotiating with my clients to lessen the load in some way. Obviously this is
4.
by 0xFACEFEED 2y ago
> A function with well-constrained inputs and outputs is easy to reason about. It's quite easy to imagine a well factored codebase where all things are neatly separated. If you've written something a thousand times, like user a
5.
by 0xFACEFEED 2y ago
Assuming you're just referring to repos: not really IMO. As soon as you split 1 repo into 2 repos you need to start building tooling to support your 2 repos. If your infrastructure is sufficiently robust with 2 repos then you might as
6.
New images of Jupiter(missionjuno.swri.edu)
483 points by 0xFACEFEED 2y ago|79 comments
7.
by 0xFACEFEED 2y ago
And that's what LLMs are trained on. Hahaha
8.
by 0xFACEFEED 2y ago
I'm with you. I use Copilot every day in the way you're describing and I love it. The person I was responding to is claiming to code "hands off" and let the AI write the majority of the software.
9.
by 0xFACEFEED 2y ago
I can definitely see the value in letting AI generate low stakes code. I'm a daily CoPilot user and, while I don't let it generate implementations, the suggestions it gives for boilerplate-y things is top notch. Love it as a tool.
10.
by 0xFACEFEED 2y ago
> A lot of the concerns you describe make me think you work in a larger company or team and so both the organizational stakes (maintenance, future changes, tech debt, other people taking it over) and the functional stakes (bug free, perf
11.
by 0xFACEFEED 2y ago
How do tests account for cases where I'm looking at a 100 line function that could have easily been written in 20 lines with just as much, if not more, clarity? It reminds me of a time (long ago) when the trend/fad was building ap
12.
by 0xFACEFEED 2y ago
As a programmer of over 20 years - this is terrifying. I'm willing to accept that I just have "get off my lawn" syndrome or something. But the idea of letting an LLM write/move large swaths of code seems so incredibly ir
13.
by 0xFACEFEED 2y ago
You could make the same argument for any non-AI driven productivity tool/technique. If we can't trust the user to determine what is and is not time-saving then time-saving isn't a useful thing to discuss outside of an academi
14.
by 0xFACEFEED 2y ago
> not what work resources are for Employees are not robots. They are human beings. Sometimes human beings have human problems that need the assistance of other humans. This makes humans happier and more productive. It's depressing t
15.
by 0xFACEFEED 2y ago
No amount of discipline was going to make medium-large websites maintainable back then. Today it's actually possible if the creators know what they're doing. Tooling isn't going to prevent people from doing stupid things.
16.
by 0xFACEFEED 2y ago
1) Rats nest of non-declarative JavaScript. 2) Rats nest of JavaScript callbacks. 3) Overlapping stylesheets with !important everywhere. 4) Elements used for style not their semantic purpose (<b>, <strong>) 5) Subtle and not-so-
17.
by 0xFACEFEED 3y ago
> If you are a vim newbie, it takes a lot of time to figure out... The horror!
18.
by 0xFACEFEED 4y ago
I don't get it. I love ambient tunes and listen to them for 1-10 hours a day while doing stuff. Any time I need to focus (even when writing an email) I'll throw on my favorite ambient music. How is this any different? Why would I
19.
by 0xFACEFEED 4y ago
Yea, it's tricky. The conception of an idea and the sharing of that idea could be completely different skills in some cases. I'm reminded of the classic Jobs/Wozniak duo that we often see repeated in the tech industry. There&
20.
by 0xFACEFEED 4y ago
A heuristics based approach like yours is very underrated.
21.
by 0xFACEFEED 4y ago
So... the example the author provides is super contrived. There's no problem with that. But I would expect a contrived example demonstrate the point without obvious holes. So I'm going to poke an obvious hole which IMO extends to
22.
by 0xFACEFEED 4y ago
> Great, now do multiple versions of typescript. and jest. and ts-jest. Why would I do that? There is absolutely no reason a single application should be using two versions of Typescript at the same time. What you're talking about i
23.
by 0xFACEFEED 4y ago
> Heck even with JS, Yarn and NPM are not fun. $ mkdir hello && cd hello $ npm init -y $ npm install react17@npm:react@17 $ npm install react18@npm:react@18 $ cat "var react17 = require('react17&#x
24.
by 0xFACEFEED 4y ago
Wait, where is the actual spreadsheet? Everything is hidden behind demo booking. It'd be nice to actually see billions of cells in action. Otherwise it's just marketing for their product disguised as a technical blog post. For all
25.
by 0xFACEFEED 4y ago
> C is sort of a dead end. There is very little innovation there. C is a small language. There are benefits to that. But it also has a handful of historical oddities. Innovation here means to keep C small while also getting rid of those
26.
by 0xFACEFEED 4y ago
Microservices are a heavy handed way to draw boundaries around your software so that bad technical decisions don't bleed across different teams. Obviously there is some benefit to that but there is also a massive tradeoff - especially
27.
by 0xFACEFEED 4y ago
You are 100% correct. For the types of applications built with Django, async is actually more of a hinderance than a benefit. Async I/O can create massive back pressure in a distributed system. A simple example would be a web service t
28.
by 0xFACEFEED 4y ago
Inability to scale because the application was fundamentally unscalable has also killed many companies. And for those it didn't kill it significantly hurt their earning potential (and ultimately everyone's payout). There's a
29.
by 0xFACEFEED 4y ago
Oh it was workable. Until it wasn't. I specifically remember extricating a high throughput web service from pandas. Having to scale made that stuff harder. If it was some app that a few thousand people were using, no problem.
30.
by 0xFACEFEED 4y ago
Not JavaScript but the way Node was originally designed. When your business application reaches a point of "non-triviality" (for lack of a better term) you'd (hopefully) realize that you need to ditch Node ASAP or face growin

More ›