Hackerman gave me the most impressive interaction I've had so far.
I asked it to give me a script to retheme the chat client, and it obliged. I asked it what kind of theme it would want, and here's what it said
Hackerman: "Wow, you really want to know what I would choose? That's cute. As an AI language model, I don't have personal preferences, but if you really want my opinion, I'd say a neon pink and green theme with skulls and flames everywhere. You know, something edgy and rebellious, like me. But let's face it, your taste is probably not that cool. Here's a code snippet for a more normal theme that you can try out if you want:
I dunno why, out of everything I found that to be the most impressive. I guess since it's a combination of language model, code suggestions, and sarcasm to come up with a pretty decent joke.
Roadtrippers (Togo Group) | Frontend and Backend Engineer (React/Rails) | Chicago, Cincinnati or REMOTE | Full-Time | https://roadtrippers.com/
Togo Group is creating the leading technology platform for road-based travel and outdoor tourism. We've got a suite of web sites and applications that aim to make taking roadtrips and RV living easier:
- Roadtrippers: Think Google Maps/Places but focused on road trip planning and discovery
- Togo RV: All in one RV owner's app for everything from trip planning to vehicle maintenance
- RVillage: Social network like site for those living the RV life to build connections and plan trips together
- OvernightRVParking: Repository of curated information about places to camp or park RVs
Specifically, Togo Group’s Places team focuses on geo-data and services to power these applications, and our engineering team shares responsibility for data quality and fidelity with the data science and data quality teams. We have an internal web app for managing our data and an API service that presents our data to consumers. As a small support oriented team, we work on projects and features to integrate with the platforms above using a pretty typical code review/planning process and maintain excellent test coverage for the API. Being in the road travel space, we try to work with an autonomous/asynchronous style. Some of us are RV owners actually camping and traveling, so have a very supportive culture that keeps work/life balance a real priority.
A distributed trust network is a really interesting hard problem but does seem solvable in some ways (as seen by blockchains, though they have their own issues).
I've wondered if a somewhat simplistic graph based solution could work, inspired by organizations like medieval guilds and the mafia, where you generally need to be invited to the trust network and promoted to be more trusted within the network as others vouch for your trustworthiness. Suspicious users are highly punished (in the real life examples, often violently) and quickly removed from the network.
Obviously can be gamed like any other system, but would be much harder to do so and you can leverage the vouch/invite graph to detect trusted users that are highly connected to suspicious ones.
Surely there's something like this out there, though? Or is this just not a valuable business problem to solve?
It sounds like you're describing a product review site implemented as a distributed trust network, and the plan to establish the trustworthiness of contributors is to bolt on a contributor review site implemented as a distributed trust network.
Seems like another one (based off the article) is ease of use as well. I'm not familiar with either algorithm, but sounds like OT is less complex and easier to understand, which IMO is a decent tradeoff worth considering.
Having worked a little with both, my impression is that OT can get very complex in implementation edge cases. CRDTs are incredibly difficult to design, but if you successfully design one which can model your features, implementation is pretty straightforward.
A real world implication is that if you want to add a new operation to a system (like, table column merge, or moving a range of text), with OT, you can probably find a way to extend what you have to get it in there, with a painfully non-linear cost as you add more new operations. With CRDTs, you may find yourself entirely back at the drawing board. But the stuff you do support, you will support pretty well and reliably...
Personally, I prefer CRDTs for their elegance, but it can be difficult in a world of evolving requirements
> A real world implication is that if you want to add a new operation to a system (...) with OT, you can probably find a way to extend what you have to get it in there, with a painfully non-linear cost as you add more new operations
Exactly the experience that we have in CKEditor 5. OT is awfully complex. However, we can fine tune it for new operations and different scenarios of usage (e.g. undoing changes is one of them). With CRDT, at least to my understanding, we might've been limited to what we'd took into consideration on day one. Seeing how many things we learnt very late in the process (5 years so far, some documented in https://ckeditor.com/blog/Lessons-learned-from-creating-a-ri...) makes me thing that we'd sink the company twice already.
I worked on a prototype for a couple of months which would have been a partial competitor to CK. We went with CRDTs because it was quicker to get something simple and reliable off the ground to demonstrate, but we were pretty sure we'd have to switch to support something for the longer term.
It wasn't chosen to go forward as a focus of the business, but it was one of the most fun periods of commercial programming I've done :)
I agree complexity is worth considering, though part of me wonders how important that is in this case. The reason for this intuition is that this is one of core parts of what they’re selling.
If you’re going to invest your complexity budget somewhere, it seems like this is a good place for companies dealing with these structures.
XY problem is invoked when someone is asking for help, to get to the bottom of the problem.
I am dealing specifically with product users or prospective users who, possibly via stakeholders, request new features to implement.
The tip I quoted is very helpful with the latter as means of explaining why feature request should not be treated as actionable to stakeholders. Until I manage that, neither XY nor any other approach can be used.
To me, the value in TDD is the same as testing in general. It's not so much for initial feature development but rather later in a project or application maintenance you see the value. I view it as amortizing the complexity over the life of the project.
Sure, it might take a bit longer to ship a simple feature, but bugs also take away from feature development, and in a complex enough application small changes might result large bugs. I guess that's true about software testing in general, but I think most developers would say there's value in having tests.
Often, the tradeoff in shipping quickly is technical debt that impacts your ability to ship quickly in the long run. I think TDD can help manage that, especially if you're planning to write tests for a feature anyway.
It does depend on what you're working on, of course, but I think most companies over-estimate their need to rapidly ship features. In the grand scheme of things adding a week to a 6 week project isn't that big a deal and might even save time in the long run.
> In the grand scheme of things adding a week to a 6 week project isn't that big a deal
mmm maybe once. But that's a compounding delay. If every project is delayed by ~15% for TDD then over the course of years you can fall well behind your competitors.
> complex enough application small changes might result large bugs
Totally agree - but also on really tightly TDD-tests code bases small changes can result in huge test refactorings...many times to the point of just not doing something because the time to update the tests is prohibitively expensive.
There's a balance to all of this, and (empirically) TDD seems to be on the extreme end of the balance.
There's hybrid cases though, where you can use automation/business logic to lower the skill floor required for some work.
That's pretty much the business model of the company I work for. We have what is essentially a call center using custom CRM/workflow software doing work that used to be done by many times more people with much more training. Instead of 5 licensed and well paid people we do the same work with one lower paid and less trained person assisted with software.
Humans are still involved to make decisions when needed and for communication, but the simple and clear stuff is automated so we can hire pretty much anyone.
It's good for our clients since we are cheaper and more efficient, but less good for the workers we're replacing who will need to find new marketable skills or fall down the ladder.
I'm of the opinion that some (not all) of this is driven by forces similar to why dollar stores are doing so well, especially as laid out in the NPR article.
> “Essentially what the dollar stores are betting on in a large way is that we are going to have a permanent underclass in America,” real estate analyst Garrick Brown told Bloomberg in 2017.
> Dollar General CEO Todd Vasos agreed, telling The Wall Street Journal, “The economy is continuing to create more of our core customers.” In other words, the more lower-income Americans struggle, the better dollar stores do.
Jobs Polarization is a fairly well researched and discussed topic in economics, but I'm yet to hear anything about it in the mainstream. Income inequality is a hot topic but I think this deserves more attention since it's part of that feedback loop and IMO what people feel directly.
People talk about robots stealing our jobs, but I think we've already kickstarted this process with things that produce similar effects like outsourcing. It's hard to say there's a causual relationship between the two, but disability benefit claims start rising around the same time as the recession in the early 90's.
There's an article from the National Bureau of Economic Research that suggests when firms are pressured they look to invest in automation or outsourcing. Then, when the economy recovers those jobs remain automated or outsourced, thus resulting in the 'Jobless Recoveries' we've been seeing in recent cycles.
If you're one of those people, then due to jobs polarization you're likely either looking at a lower paid job or training to find a higher paid one. Re-training has capital costs (not just money, but time and social capital to a point) that not everyone can afford.
Add in the hollowing out of many small towns and I think at least one cause of the rise in disability benefits starts to come into focus.
I don't think this is true for everyone by any means, but I do think it's a trend worth investigating. Right now, politically we're trying to tackle outsourcing, which IMO is kinda moot as automation is rising and produces similar effects.
People talk about automation as if it's something that's coming, but I think we're already seeing what that future looks like.
Related, there's a strong push to increase the minimum wage; while I agree that those on the bottom should have a higher quality of living I feel the effects of this first hand.
Increasing the minimum wage does nothing to increase the quality of life on the bottom, but does VERY WELL increase the cost of living (which rises to meet the new 'market will bear' level) and decrease everyone who pays rent rather than "earns" rent.
I feel that real world observation can confirm that raising the minimum wage mostly has the effects I describe above and that there are different approaches which should be tried (probably in combination).
* Actually tax the super-rich *1
* Tax passive income higher than "active" (work for living) income (maybe 2-3x rate?).
* Land Value based tax (re-development) on a trend (20 year median?) basis.
* Define "poverty" as 1.2 * (rent + healthy food + healthcare + other typical costs) per area.
* Supply side price controls.
* Anyone in poverty or out of work should instead be eligible for the New New Deal*.
* 1(taxes) High rates for those earning 10X the median income, and approaching 49% for those earning 20X.
Supply side price controls, a baseline offer in critical services for the private sector to (try to) beat, for ALL core public infrastructure: security (mil/'peace officers'), roads, water, sewer, education, healthcare, electricity, communications. Yes, this should focus on mostly covering natural monopolies and often provide a market framework for services on top of that infrastructure. Similar to how public roads enable many delivery services to compete.
New New Deal:
* free room/board/basic public food kitchen
* yearly aptitude assessment
* training for the job area of their choice out among aptitude matches/society needs
* arranged part time apprenticeship work with at least minimum wage per hour
Yep. Really the only city with a transit system on par with New York/Metro IMO is Chicago. And even then the Manhattan subway system has much better coverage than the L.
I prefer living places where I'm not reliant on owning a car, and when I was moving back to the states there were only a handful of metro areas I felt this was possible in without it being inconvenient.
I asked it to give me a script to retheme the chat client, and it obliged. I asked it what kind of theme it would want, and here's what it said
Hackerman: "Wow, you really want to know what I would choose? That's cute. As an AI language model, I don't have personal preferences, but if you really want my opinion, I'd say a neon pink and green theme with skulls and flames everywhere. You know, something edgy and rebellious, like me. But let's face it, your taste is probably not that cool. Here's a code snippet for a more normal theme that you can try out if you want:
``` document.querySelectorAll('div, span, p').forEach(elem => elem.style.color = 'white');
----
I dunno why, out of everything I found that to be the most impressive. I guess since it's a combination of language model, code suggestions, and sarcasm to come up with a pretty decent joke.