PIRL: Learn Image Representations Immune to Geometric Transformation - <AUTHOR> https://amitness.com/2020/03/illustrated-pirl/ <comment><USER2> Thank you @amitness for this wonderful website with graphical explanations :)

The PIRL technique in question here seems useless to me, because its loss deliberately trains it to behave differently from what a human would do. But that overview page [https://amitness.com/2020/02/illustrated-self-supervised- lea...](https://amitness.com/2020/02/illustrated-self-supervised-learning/) is gold.

</comment><comment><USER3> This looks a lot to me like learned image descriptors from the computer vision community. Some examples are Discriminative learning of local image descriptors ([http://matthewalunbrown.com/papers/pami2010.pdf](http://matthewalunbrown.com/papers/pami2010.pdf)) DeepDesc ([https://icwww.epfl.ch/~trulls/pdf/iccv-2015-deepdesc.pdf](https://icwww.epfl.ch/~trulls/pdf/iccv-2015-deepdesc.pdf)) L2-net ([http://www.nlpr.ia.ac.cn/fanbin/pub/L2-Net_CVPR17.pdf](http://www.nlpr.ia.ac.cn/fanbin/pub/L2-Net_CVPR17.pdf))

</comment><comment><USER4> The issue with this is that you (most of the time) don't want your image representations to be immune to geometric transformation.

A rotated p should be recognized as a d. In nature pictures you want to recognize blue at the top as sky and blue at the bottom as water.

<comment><USER5> I think that's taking a dim view of what machine vision should be capable of. If a picture is rotated 180 degrees, upside down text _should_ be recognized as its flipped version, i.e., the word "6op" should be read as "dog" having been rotated. Similarly a machine should be able to tell if it's looking at the reflection of the sky in a lake. And disregarding entire scenes, any object upside down (upside down chair, upside down dog, upside down car, ...) is clearly recognizable as such to a human, and hence should be to a machine as well.

<comment><USER4> Upside down objects and scenes look alien to us. We can recognize them but not without effort. It's a combination of having seen objects upside down before and being able to reason about what we are seeing. It does not come for free from invariance.

<comment><USER6> The classic Thatcher illusion[0].

[0] [https://en.wikipedia.org/wiki/Thatcher_effect](https://en.wikipedia.org/wiki/Thatcher_effect)

Edited for clarity, started writing then wiped half and didn't check first half.</comment></comment></comment></comment>


Why Are People into Event Sourcing? - <AUTHOR> http://adaptechsolutions.net/eventsourcing-why-are-people-into-that/ <comment><USER2> Event sourcing isn't nearly as common knowledge among new programmers as the CRUD-one-row-per-entity pattern, and it really should be. I liken it to introducing version control for your data; when immutable updates are your canonical source, no matter how much the system behind them changes, or the business requirements change, and no matter how many teams are deriving different things from them in parallel, they can all work off of the same data and "merge" their efforts together.

The one downside is that shifting your business logic to read-time means that you need to have very efficient ways of accessing and memoizing derived data. For some applications, this can be as simple as having the correct database indices over your WhateverUpdates tables, fetching all updates into memory and merging on each request. For others, you'll need to have a real-time stream processing pipeline to preemptively get your derived data into the right shape into a cache. And those are more moving parts than your typical monolith app, but the

One benefit to actually using event sourcing with a stream processing system is that, in many cases, it can be the most effective way to scale both traffic capacity and organizational bandwidth, much in the same way that individually scalable microservices can (and fully compatible with that approach!). Martin Kleppman at Confluent (a LinkedIn spinoff creating and consulting on stream processing systems) writes some great and highly-approachable articles about this. Highly recommended reading.

[http://www.confluent.io/blog/making-sense-of-stream- processi...](http://www.confluent.io/blog/making-sense-of-stream-processing/)

[http://www.confluent.io/blog/turning-the-database-inside- out...](http://www.confluent.io/blog/turning-the-database-inside-out-with- apache-samza/)

<comment><USER3> The CRUD one-row-per-pattern is common because it's enough for most projects. It works well with ORMs so you can build quickly and securely. And most of the time, performance isn't an issue and having a history of an entity is unnecessary.

I'm worried that event sourcing is going to become this year's over-applied design pattern with libraries in every language for every database with blog posts that recommend it be used on every project.

It's a good idea, very useful - in the right hands on the right projects. But it makes sense that junior devs normally use CRUD because that's normally the right solution. At least until better tools come along.

<comment><USER4> > The CRUD one-row-per-pattern is common because it's enough for most > projects. It works well with ORMs so you can build quickly and securely.

If by "works well", you mean it works until someone asks for historical data - then IT guy has to say w/ a straight face "we lost it". This is unacceptable considering the value of data and the strategic leverage it can have today.

Considering immutable facts tables are the most stable data model; companies often have to re-invent it (poorly) on top of relational at some point; that storage is often not a problem; and that having clean historical data is crucial for data science; there are increasingly fewer excuses to not adopt a sane data model from day one.

I agree partially w.r.t. to tooling - few implementations aid adopting this pattern, but I believe the value of historical data, over time, overcomes not being able to slap some quick Rail CRUD together and then being stuck at local minima.

<comment><USER5> > _If by "works well", you mean it works until someone asks for historical > data - then IT guy has to say w/ a straight face "we lost it". This is > unacceptable_

You'd be surprised.

For tons of projects it's totally acceptable, has worked for years, nobody paying to implement them cares about historical data and their leverage. In fact the majority of web apps is like this.

I always find it strange when people use "unacceptable" with wild abandon, like they're generals receiving some demand of unconditional surrender.

<comment><USER4> The full sentence is:

> This is unacceptable _considering the value of data and the strategic > leverage it can have today._

The last part is important.

Just because it's been true in the past, it doesn't mean this trend will continue. Maybe it keeps being true for your run-of-the-mill MVP, but I don't see it being acceptable for a system in any industry w/ any chance of making serious money in the mid-term.

<comment><USER3> As long as managers have limited budgets and projects have deadlines, then tradeoffs will still have to be made.

Event sourcing is an extremely expensive design pattern to implement, and it's also very easy to get wrong. Implementing it tends to preclude junior developers from working on the project, makes it harder for database admins to understand the data, and it requires a lot of thought on how to structure the events.

So on a project with, say, a £20K budget, it might triple the cost. On a project that would take 4 weeks to implement with CRUD, it might take 3 months with event sourcing. You've got to justify that extra cost. It's better to let a BA decide what they will need, and by all means explain the pros and cons of different solutions.

But I don't for a second believe that every single project should now be using event sourcing instead of CRUD.

</comment></comment></comment></comment></comment></comment><comment><USER6> Here's the term I wish was unfashionable with the kids: reshaping.

Did you spot all those command-to-query-to-event-to-log-to-storage data type conversions in those pretty diagrams? That's a whole bunch of needless reshaping of data as it flows through the system.

For each one of those data transformations to be successful, there has to be accurate communications between people and bug free code written in the data conversion and routing of messages through the system. All those moving parts make changing the system extremely painful, lotsa ripple effects - and every time you have to make a change to your events, you'd have a data migration project for any running event streams.

Naming things is hard too, and there's a lot more naming of entities needed in a CQRS-ES system.

I like all the promised benefits of a CQRS and ES, but I can't imagine a case where I'd take the risk of attempting it on anything but a toy project. Perhaps if I was on the version 5 rewrite project for an insanely profitable system where the requirements and design are completely understood up-front. I would need to grok some canonical example of a large, well-architected, well- implemented representative system before I would ever attempt to implement one.

Are there any non-toy examples of successful CQRS-ES with open source available to read? Did those projects go over-budget, and by how much? Would the authors of those examples still recommend the architecture now that they've gone through the experience?

<comment><USER7> Open sourced ones? The largest example I'm aware of is [https://github.com/MicrosoftArchive/cqrs- journey](https://github.com/MicrosoftArchive/cqrs-journey). There's a pretty extensive write-up of their experiences too. [https://msdn.microsoft.com/en- us/library/jj554200.aspx](https://msdn.microsoft.com/en- us/library/jj554200.aspx)

<comment><USER6> I can't tell if this is a toy experiment or not.

</comment></comment></comment><comment><USER8> As someone that has fallen for the "event sourcing" promise before, the article does a decent job explaining the promise. Not sure if it will be the next article, but the actual task of delivering on this work is where things break. Hard.

The vast majority of the things you will ever program are pretty much guaranteed from one statement to the next. Hard boundaries, where things can fail, are often decently understood and actually quite visible in the code.

Moving everything to be an event completely throws this out the window. You can take a naive view, where you pretend from one event to the next is safe to happen. However, to start building up the system to cope when this is not the case starts to build a complicated system. In areas that are decidedly not related to your business domain. (Well, for most of us.)

Maybe some day there will be a system that helps with this. Until then, my main advice is to make sure you have solved your system with a naive solution before you move on.

<comment><USER7> Agree with the potential for complexity. Here's how we've dealt with this (on a so far / so good basis): Didn't seem necessary to go asynchronous and beef up on heavy infrastructure, so we went with simple in-thread, in memory message buses to start with. I think a lot of the perceived complexity of building event sourced systems comes because people start with the heavy plumbing instead of going YAGNI in order to get the domain model implemented. Easier to beef things up as needed once everything works.

I became disillusioned with doing the naive solution, for two reasons:

Found it to be impossible (from a time/project mgmt perspective) to ever replace it with the "non-naive" one, so it turns into the usual mess because CRUD doesn't work well as you load more functionality on it over time.

Secondly ... it's thinking machines. From a business perspective, does it still make sense to hand code glorified rolodexes without behaviour? Maybe Excel does the trick. Seeing it as a red flag if someone asks me to build dumb data entry forms in 2016.

Therefore, I always start eventsourced theses days. YMMV.

<comment><USER8> This seems solid advice. I guess my main questions are:

* If you are in-memory and in-process, why bother with the events in the first place? (Simpler put, why not go with the simpler process based solutions?)

* If you are not testing distributed, how do you know you will be able to distribute?

In particular, there is a very large chance that you will have the same difficulty in replacing an in-memory/process solution that you would have had with a naive one.

And don't underestimate the amount of manpower you can get with success. Nor the amount of features that will not help get success.

<comment><USER7> I don't really do eventsourcing for technical reasons. To me it's about creating an environment for project delivery where teams can succeed because they own more of their stack, from an org chart & organizational perspective.

As far as code is concerned, I see that as coming down to managing coupling & cohesion in such a way that the various pieces can be designed, built, supported, deployed and enhanced by the same team, with minimal need to wait for, coordinate with or be on the same page with any other team.

I think event sourcing & CQRS are great for enabling that because they result in the lowest form of coupling: Commands are fire and forget. You don't care who subscribes to your events. You don't care who publishes events you subscribe to. You never query anything you don't own in order to get information you need for your business logic. While the system is still small, we seem to get these advantages just fine when we do in-memory and in-process. Once package management, performance, units of deployment, etc. become an issue, we build out to add infrastructure, as needed. Because the pieces are pretty standalone within the code, it's not all that complicated to do, compared to "traditional" CRUD systems.

Not testing distributed: It's possible to deduce a lot with testing locally if it's simple to understand what's coupled to what and if good shared contracts for commands and events are in place, but ultimately the proof is of course in the pudding. When the time comes, there is a big advantage: The system is already fully operational and testing comes down to "does it still work?" If one were to do the plumbing before the business functionality and tests that in isolation ... does that really amount to knowing that it'll still be OK once it actually runs what it needs running ...? For starters, there is a danger of over-engineering because the required performance characteristics of the end products are more difficult to asses if there is no end product yet.

<comment><USER8> I think the problem is best seen by considering the statement "You don't care who subscribes to your events." This is great when you are literally doing something only on one end of the event creation barrier. This makes sense when creating something takes a lot of effort.

However, for many many shops, this is an abstraction they will never get to. They care intimately about who will subscribe to the events they publish, because they are planning on doing something as the primary subscriber.

</comment></comment></comment></comment></comment><comment><USER9> Architecting around events has several ramifications.

For building up a picture of the world, it's pretty good. It's very nice to be able to replay a log of events and recreate a view of the way things are expected to be; if there's a bug in your code, you can fix it and repeat the replay to get back into a good state (with caveats, sometimes later actions creating events may be dependent on an invalid intermediate state). Whereas mutating updates erase history, perhaps with some ad-hoc logging on the side that is more often than not worthless for machine consumption.

For decoupled related action, it's not too bad. If you have some subsystem that needs to twiddle some bits or trigger an action when it sees an event go by, it just needs to plug into the event stream, appropriately filtered.

For coordinated action OTOH, e.g. a high-level application business-logic algorithm, you need to start thinking in terms of explicit state machines and, in the worst case, COMEFROM-oriented programming[1]. Depending on how the events are represented, published and subscribed to, navigating control flow involves repeated whole-repo text searching.

It's best if your application logic is not very complicated and inherently suitable to loose coupling, IMO.

[1] [https://en.wikipedia.org/wiki/COMEFROM](https://en.wikipedia.org/wiki/COMEFROM)

</comment><comment><USER10> FYI in case the author reads this, since this seems to be intended as an intro for people who aren't already familiar with this stuff: I didn't see "CQRS" defined anywhere in this article or in the two or three links I followed from it; they all begin with an assumption that you know the acronym, and delve straight into details. It might be good to define some terms in the front matter (unless I've misunderstood the target audience).

<comment><USER7> Always a problem with techie - acronymania. :) Thanks, noted. I'll do an edit.

</comment></comment><comment><USER11> Two must-read documents for those who want to learn more about this method of building reactive applications:

[https://engineering.linkedin.com/distributed-systems/log- wha...](https://engineering.linkedin.com/distributed-systems/log-what-every- software-engineer-should-know-about-real-time-datas-unifying)

[http://martinfowler.com/eaaDev/EventSourcing.html](http://martinfowler.com/eaaDev/EventSourcing.html)

Note that Martin's blog is what inspired the event bus in [https://home- assistant.io](https://home-assistant.io), an open source home automation project I occasionally contribute to.

</comment><comment><USER12> I've tried working out how to move to an event sourcing system, but I always struggle with locking behavior. Do you just have to invent your own locking mechanisms on top of event sourcing?

<comment><USER13> Combine this with the actor model (using Akka or similar) gives you guaranteed "one message at a time" processing and you don't have to deal with locks.

<comment><USER8> I question any amount of guarantees around "one message" anything. There might be this guarantee per actor, but you have no such guarantee per system. And, assuming a real system, this will be a problem.

So, you get to pick, "at most once" or "at least once." And then you need to build your system to act accordingly.

<comment><USER14> Slightly shooting from the hip here (as I'm still learning).

Low-ish volume- design your system such that data flows [at the relevant crucial points] through a single actor to ensure proper concurrency.

High volume- trickier but I think same idea in principle. First thought that comes to mind here is the new GenStage stuff in Elixir.

<comment><USER8> I'm not sure what you are suggesting. There is no getting around "at most/at least once." You can shift the posts, some, but at some point that is your choice. This is a good read on the problem: [http://bravenewgeek.com/you- cannot-have-exactly-once-deliver...](http://bravenewgeek.com/you-cannot-have- exactly-once-delivery/)

<comment><USER15> "Exactly once delivery" is not the same as "One message at a time". Akka Actors process one message at a time. Akka does no provide exactly once delivery. It default defaults to "at most once".

<comment><USER8> So, then to go back to the original.

You may not have to do deal with locks at a local level. You absolutely have to deal with locks at a system level.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> Axon Framework [http://www.axonframework.org](http://www.axonframework.org) is a great place to start if you're into Java and want to get a feeling for how event sourcing works.

There's also a great presentation by the developer, Allard Buijze, at [https://www.youtube.com/watch?v=s2zH7BsqtAk](https://www.youtube.com/watch?v=s2zH7BsqtAk).

</comment><comment><USER17> There is a lot that could be done to make event sourcing easier to work with...

Imagine tooling that allowed an event stream to be used to create state for testing modules, crudlike helpers to allow crud-familiar developers to think that way at first, and workflows based on snapshots, rewind, etc.

I think a model that used events that correlated to graph deltas rather than crud deltas would be the cat's ass, and many queries about the near-current state could be handled efficiently using ephemeral subgraphs as indexes located at the network's edges.

If anyone wants to discuss and possibly build some of this stuff, let me know :)

<comment><USER18> > Imagine tooling that allowed an event stream to be used to create state for > testing modules, crudlike helpers to allow crud-familiar developers to think > that way at first, and workflows based on snapshots, rewind, etc.

i know where you're going with this, and i honestly believe its a terrible idea (not to be discouraging or rude—just experienced.)

if your event streams contain mostly CRUD (possibly ANY) then you're most likely applying it incorrectly. Its not just a version history of your data. The event type itself _is_ data, which provides context and semantics over and above the notion of writes and deletes. If you're falling back to crud events all you're doing is creating a lot more work for yourself and deriving almost no benefit from the use of ES—in that case, you should just use CRUD and the ORM of your choice.

<comment><USER19> > if your event streams contain mostly CRUD (possibly ANY) then you're most > likely applying it incorrectly. Its not just a version history of your data. > The event type itself is data, which provides context and semantics over and > above the notion of writes and deletes.

Right. A good way to think about this is that as with rows in an RDBMS, events in an ES system are facts, and just as tables in an RDBMS define a category of facts with a particular shape, event-types in ES do the same thing. The difference is that whereas in an RDBMS the facts represented by rows can be general (and are often, in many designs, facts about the current state of the world), events are facts about a specific occurrence in the world rather than the state of the world (and the "state of the world" is an aggregate function of the collection of events.)

<comment><USER20> Right^2: Good events are facts that occur at a higher level of abstraction, trying to capture more of the "why" behind what goes on. It's not about describing the effect on data, but the business-decision itself. (Which, when reapplied to a set of rules, will do the actual data-change.)

</comment></comment></comment></comment><comment><USER21> I was looking into Event sourcing for a system I built recently, and the tooling just doesn't seem to be that widespread yet. How do you read out of the entire event stream to figure out the current state? While there are tols, they seem to be .net focused. Just didn't seem to be a "standard" answer yet.

We ended up going with microservices that pub/sub events into Kafka, but maintain their own databases. There's another microservice that lets you query past events for statistics.

<comment><USER7> We find that a simple in-memory synchronous message bus + event logging to files goes a long way. See e.g. [https://github.com/robertreppel/hist](https://github.com/robertreppel/hist) for an in-memory bus + file system (and DynamoDB ...) helloworld which isn't .net.

Scaling that up by adding asynchronicity and more ambitious plumbing when needed seems reasonably straightforward. For something more out-of-the-box, see [https://geteventstore.com/](https://geteventstore.com/) . It has clients in a variety of languages. Comes with a nice HTTP API too.

I wouldn't normally read the entire event stream; usually, only the state of a particular object (aggregate, in Domain Driven Design speak) is of interest, E.g. the customer with id 12345. Events contain the aggregate ID, so the query to whatever event store you use would be "give me all events with aggregate ID 12345".

<comment><USER22> Are you using DynamoDB Streams at all? I've been toying the idea of using DynamoDB as an event store and having other services listen to a table's stream, allowing them to update caches/views (the read-side of CQRS), report analytics, perform asynchronous tasks, etc.

<comment><USER23> You could quite nicely use AWS Lambda for the materialized views, I think.

</comment></comment></comment></comment><comment><USER24> I for some months now have tried to build a small test-case for a invoice app. I wish to have a good syn strategy and the use of ES sound good. However, I have find how replicate the functionality of a normal app with this: For example, what to do for avoid duplicates and in general pre-saving validations. Also, I need to anyway to use RDBMS tables for hold current-data and RDBMS have not a good history for stream back results.

</comment><comment><USER25> I have been working with this sort of patterns for a while but I have yet to find good texts exploring the topic. Does anyone have book or paper recommendations for event sourcing? The stuff I have seen is mostly programmers reporting on something that worked on their particular domain. I am, looking for something more rigorous and comprehensive.

<comment><USER18> Lurk on the CQRS/DDD list [1], lots of good info there. I'm not aware of any textbooks on ES per se but there are a few good books on areas that overlap. [2] [3] [4]

[1] [https://groups.google.com/forum/#!forum/dddcqrs](https://groups.google.com/forum/#!forum/dddcqrs)

[2] [https://www.amazon.com/Enterprise-Integration-Patterns- Desig...](https://www.amazon.com/Enterprise-Integration-Patterns-Designing- Deploying/dp/0321200683/ref=sr_1_1?ie=UTF8&qid=1475563462&sr=8-1&keywords=patterns+of+enterprise+integration)

[3] [https://www.amazon.com/Implementing-Domain-Driven-Design- Vau...](https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn- Vernon/dp/0321834577/ref=sr_1_sc_3?ie=UTF8&qid=1475563596&sr=8-3-spell&keywords=vaugn+vernor)

[4] [https://www.amazon.com/Domain-Driven-Design-Tackling- Complex...](https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity- Software/dp/0321125215/ref=pd_bxgy_14_2?ie=UTF8&psc=1&refRID=0HVKJD3MP0QACV5SJK6F)

</comment></comment><comment><USER26> As an interesting comparison, some people see the Redux/Flux pattern as a front-end parallel to event sourcing.

[0]: [https://github.com/reactjs/redux/issues/891#issuecomment-158...](https://github.com/reactjs/redux/issues/891#issuecomment-158693484)

</comment><comment><USER27> How strange, just today I've heard the Event Sourcing name and thought I don't know what it is. (Turns out it is this old idea I knew under various different names). And at the same day I hear about Event Sourcing on HN. What's the buzz?

<comment><USER18> Its been slowly building steam (under that name) for about ten years, first in .Net and now filtering out to other ecosystems. I think its kind of inevitable given the recent popularity of functional programming models.

</comment></comment><comment><USER28> Very curious: if you have multiple datastores, how do you ensure they are consistent? If you scale sideways, how do you ensure nothing gets lost if there's a partition? Etc?

<comment><USER29> Embrace eventual consistency. A good deal of collaborative domains (things involving human decisions) are naturally eventually consistent. Meat computers appear to be particularly good at resolving conflicts and compensating.

</comment></comment><comment><USER30> Having been part of a project to rewrite a monolith e-commerce site into an event-sourced, domain driven, CQRS system, let me tell you in which situation that is not possible: when you already have data. Remember that in a DDD, ES, CQRS system, the event store is the single source of truth. If you already have data in a relational database, then the existing data is the source of truth. You can't have two sources of truth, that completely defeats the purpose. So it's not actually possible to migrate to an event sourced system, you can only create one from scratch, with no existing data.

<comment><USER19> Conceptually, that's not really true: you just transform the pre-ES state into one or more events (in an basic accounting system, which is pretty much the simplest ES system, long-predating the name for the model, this is just creating "starting balance" entries as transactions.)

In practice, that can be challenging, but it doesn't seem fundamentally _more_ challenging than any other legacy data conversion effort.

<comment><USER30> Sure, if the existing DB is simple, that is straight forward, but remember that likely this is a monolith that is so bad that even management have agreed that it needs to be rewritten. Likely there are lots of DB tables with foreign keys and relations (sometimes documented and enforced, most often not). This means you can't really convert the entire database into an event sourced system, as that means converting all of the tables in one single go, instead of a gradual change. And believe me, in a system like this you want slow gradual changes! Also, even of you got it into events, what happened to the domains? There are so many relations between the different events sources (because you didn't put everything into just one event source, right? What happened to bounding contexts?) that you are no better off. And this means you have to prevent anything else from using the database anymore, and in a legacy system where you can just join across any two or three tables to extract whatever information you want, you can be certain there are some analysis engines that are just feeding directly on the sql data. And there might be other systems writing to the database too!

So the first step is to disentangle all the data and encapsulate it, trying to prevent others from using it, so you have full control over it. This includes tracking down any other system using this data, and ensuring they too go through the database. And you have to do this for one subsystem at a time, often in several iterations.

<comment><USER19> > Sure, if the existing DB is simple, that is straight forward, but remember > that likely this is a monolith that is so bad that even management have > agreed that it needs to be rewritten.

Yeah, but that's not a "converting legacy data to ES" problem, that's a "converting legacy data to any non-broken thing" problem.

> This means you can't really convert the entire database into an event > sourced system, as that means converting all of the tables in one single go, > instead of a gradual change.

Whether its ES or something else you are converting to, you either do a big- bang conversion and eat the pain of that (which can be tremendous, sure), or you instead eat the pain of taking the monolith and finding a way to break out components and do it incrementally, even though that takes not only building the new components, but reengineering parts of the old monolith to support that. Which, also, can be tremendous pain. But, again, this isn't really essentially tied to event sourcing, you face this dilemma even if you are going from a (broken for current needs, which is why it is being replaced) classically-designed "current state" RDBMS-backed system to a (meeting current needs, and hopefully more adaptable to future needS) classically-designed "current state" RDBMS-backed system.

<comment><USER30> Yup, agree, this is the problem of having a legacy monolith RDBMS that needs to be rewritten and split apart. It's tempting to throw every new fancy technology at the problem when that is suddenly an option, but it's better to focus on the goal of splitting it apart only. If you have split it out, and it's now simple to convert to ES CQRS, then you are probably in a situation where you don't need to do that, as it works quite well.

<comment><USER19> > It's tempting to throw every new fancy technology at the problem when that > is suddenly an option, but it's better to focus on the goal of splitting it > apart only.

Splitting it apart involves:

(1) Dividing the data and functionality into a legacy component and a new- implementation component,

(2) Making changes to the DB and application code for the legacy component,

(3) Implementing the new-implementation component.

In a monolith that you are breaking apart, the reusability of legacy code for the new-implementation component is likely to be low (you'll actually likely have to do extensive changes to the larger "legacy component" as well, but the reusability should be somewhat higher there.)

You have to use _some_ technology for the new implementation component, and what you should aim for is whatever is the best fit for the job, whether it is similar to what existed before or not.

> If you have split it out, and it's now simple to convert to ES CQRS, then > you are probably in a situation where you don't need to do that, as it works > quite well.

I disagree. The hard part of converting to ES/CQRS for the components that are broken out ("new implementation" components, not the "legacy" reduced- monolith) is done in the analysis phase of what you are breaking out. Once that is done, _implementation_ in a ES/CQRS manner is fairly straightforward, since defining the events that the component will handle is a core part of analysis, as is defining the impacts those events have on stored, reportable data (the query side of CQRS).

<comment><USER31> "The hard part [...] is done in the analysis phase..." smells like big design up front that is usually more likely to fail than not, especially so for complex systems.

<comment><USER19> Big design up front would be a complete system replacement, not incremental replacement by component. An incremental replacement still requires definition of the components to be replaced with new implementation and the part to be essentially retained with only the changes necessary to interface with the new component.</comment></comment></comment></comment></comment></comment></comment></comment>


How Renters Work The System To Live For Free In One of America's Most Expensive Cities - <AUTHOR> http://www.sfweekly.com/content/printVersion/1104331 <comment><USER2> This is hardly news to anyone that has been a landlord in the last twenty years in any state. Residential Real Estate law is so screwed up and has encouraged this type of behavior for years.

And where is the Hacker News connection?

</comment><comment><USER3> From the article: _And San Francisco has its share of heartless landlords. One extreme example is the terror tactics allegedly employed by property owners Kip and Nicole Macy, who were charged with numerous felonies earlier this year for, among other things, cutting the support beams from one tenant's floor, burglarizing another's apartment, and cutting off utilities to another._

The key word here is "allegedly". As in "alleged by a tenant who doesn't pay his rent and is fighting eviction".

<comment><USER4> Cutting beams makes no sense! That would be a stupid and heartless landlord. The apartment is no longer rentable for the next tenant, and repairs are likely to cost a lot.

I've had friends here in Houston whose landlords have lollygagged with fixing the water heater and the air conditioner -- for about half a year. The landlord of the friend with the broken water heater tried not cashing her rent checks for several months in order to evict her ahead of the lease. My friend just explained that she had been sending checks, and she also had the cash on hand and just handed the amount due over to her landlord in front of the judge.</comment></comment>


How do you make a startup without faking it? - <AUTHOR> Connecting two parties (people + places) as a startup lacks both first as you just started. You want to show you exist but need to collect both so your website is not empty.<p>How do you convince people you're real and not "fake", "imposter", "fraud", or even a "lier" so they don't feel betrayed? <comment><USER2> You can create a placeholder site that explains your idea and see if you can get people to sign up to be on your announcement and/or beta list.

That will also tell you if your idea is any good - if you can convince people to sign up.

<comment><AUTHOR> Thank you jakejake. I have the feeling that people more and more want an already well executed MVP instead of a placeholder site explaining the idea and ask them to sign up.

What about feedback like:

"I'm personally getting sick of websites that have a button that says it'll do one thing, but instead I get redirected to give my information to someone I don't know or trust. No thanks."

The person felt offended because of being asked to enter information, information that was necessary to provide what the person was looking for, hence he pressed the button in the first place.

So, the person doesn't trust or know the business or service but the service needs that information to provide what the person is looking for.

A chicken-egg problem, it feels. Or a matter of communication it well?

<comment><USER2> I think the only way really to make it work is by having a private "beta" invites or the placeholder or something so that you can build some excitement and get people signed up. Because if your app requires a lot of data (i.e. people) before it becomes useful, then you can't really turn it on with like 5 users!

It is a very tough problem. I might look to other sites and try to see what they have done. Ello for example is one recent site. Perhaps there is a way to partner with an existing service. You will have to get creative to get past the chicken/egg problem. I wish you success!

<comment><AUTHOR> That's a good idea with the private beta. Yet, even with a small amount of people we can do our service of connecting already - it's more manual work though for now.

Yes, we're working on it to get creative with that challenge, like with all the other challenges ;)

Thanks a lot for your words, jakejake. Very much appreciated! :)</comment></comment></comment></comment>


Colocation in San Francisco? - <AUTHOR>

Does anyone have advice/recommendations about colocation in San Francisco? I need a full rack, 5Mbps. I took a tour of 365 Main and was impressed, but it's very expensive ~$1400/month for such a setup. <comment><USER2> ColoServe is around the corner and generally cheaper. But $1400 for a full rack (assuming at least 20A) is not a bad deal in this city. You'll find cheaper colo as you leave the city and peninsula.

</comment><comment><USER3> Do you need to be in San Francisco? SF has the second highest power prices in the country. I'd check out Layer42 down in Santa Clara, email email@example.com and tell him BitPusher sent you. Their network is great, their facilities decent, and their customer support blows 365main's out of hte water.</comment>


Apple Watch Adoption - <AUTHOR> https://david-smith.org/blog/2018/03/14/apple-watch-series-3-adoption/ <comment><USER3> I don't care about your problems as a developer. As a consumer I expect a watch to last 5-10 years. As a developer working in the consumer space you need to get out of the mindset that everyone is replacing everything every 2-3 years. That's neither reasonable nor sustainable.

<comment><USER4> I use a 10 year old Dell Core 2 Duo 2.66Ghz laptop with 4GB of RAM, a 1920x1200 display as a Plex Server running Windows 10 and it only feels when I run too many things at once but that could be alleviated by putting in another 4GB of RAM.

It's a 10 year old computer that can take full advantage of my gigabit home internet connection (940Mbps up and down) - something only dreamed about 10 years ago - can run the latest OS and can be upgraded to have the same amount of RAM as most computers that are sold today.

In 2008, a 10 year old computer would have probably had these specs and be unusable as a modern computer.

[http://www.tomshardware.com/forum/266641-28-average-1998-com...](http://www.tomshardware.com/forum/266641-28-average-1998-computer- specs)

 _To sum it up, a decent compy around 1998 /early 1999 could look likte this:

400Mhz P2 64mb sdram running at 100 mhz one or two voodoo 2 cards (90mhz core, 8 or 12 mb EDO VRAM) a 2D card (voodoo 2 was a 3d accelerator only) ATA-2 HD_

In 1998 a 10 year old computer would have been less usable.

How fast improvements come to the smart watch will slow down in time but it's a brand new product.

<comment><USER5> I get your point but none of your comparisons fit:

o Your Plex system is a home server, which have always typically been lower powered desktops even 10 year ago (I know because I was building home servers back then. In fact 10 years ago I was running ZFS off an old desktop PC with some really budget consumer RAID controllers)

o and you're comparing that to a gaming machine which are systems which are typically at the higher end of spectrum). To put things into perspective, in 1999 I most certainly did not have a 3D accelerator. Yet I was still using my computer for software development and web development (including, by the way, 3D markup via VRML). In fact I don't think I even had a P2 considering my upgrade a few years later was to Celeron. I have a feeling my '98 PC was a Cyrix.

o It was really common even in the 90s to run old PCs. Even in 1995 I was still seeing 386s and even the occasional 286 in use running Windows 3.x.

o Lastly you cannot really compare a watch to a PC. Sure, smart watches are basically just computers these days; but the point the OP was making was peoples expectations are different for watches. I mean we have digital watches from the 80s that still work as well today as they ever have done, yet smart watches made 2 years ago are already junk. Before people comment on the difference in tech, yes I already know. But that's not the point. The point is people's expectations - which frankly I think are more than reasonable. If there's anything we have learned in the last 20 years it's how to futureproof our products.

<comment><USER4> _Your Plex system is a home server, which have always typically been lower powered desktops even 10 year ago_

The Plex Server has to transcode all types of formats to H.264 in real time. My old 2006 Core Duo 1.66Ghz Mac couldn't handle it. It is still being used by my parents running Windows 7. I also tried using a 2Ghz Pentium Dual Core.

* (I know because I was building home servers back then. In fact 10 years ago I was running ZFS off an old desktop PC with some really budget consumer RAID controllers)*

They weren't transcoding 1080 video to H.264 real time in 2008.

 _o and you 're comparing that to a gaming machine which are systems which are typically at the higher end of spectrum). To put things into perspective, in 1999 I most certainly did not have a 3D accelerator. Yet I was still using my computer for software development and web development (including, by the way, 3D markup via VRML). In fact I don't think I even had a P2 considering my upgrade a few years later was to Celeron. I have a feeling my '98 PC was a Cyrix._

Would you still be using that computer in 2008? Could it run the latest version of Windows? Could it take advantage of the fastest speed internet that was available to home users in 2008?

 _o It was really common even in the 90s to run old PCs. Even in 1995 I was still seeing 386s and even the occasional 286 in use running Windows 3.x._

My 2008 Core 2 Duo can run the latest software and the latest version of Windows well. Could those 10 year old computers run Windows 98 in 1998?

 _Lastly you cannot really compare a watch to a PC. Sure, smart watches are basically just computers these days; but the point the OP was making was peoples expectations are different for watches._

How is a watch that runs a phone OS that makes phone calls not considered more of a phone than a watch?

 _I mean we have digital watches from the 80s that still work as well today as they ever have done,_

The difference is that my 10 year old computer can do the same thing as a modern computer - run the latest OS and software, has just as much memory and storage (HDD vs SsD) and has a slightly better display (1920x1200 vs 1930x1080). Can that 10 year old digital watch do the same as a modern smart watch?

 _If there 's anything we have learned in the last 20 years it's how to futureproof our products. _

The only reason that my old Core 2 Duo is "future proofed" is because useful improvements have slowed down dramatically in the last 10 years. In 1998 the typical computer was coming with 32-64Gb of RAM and couldn't be upgraded to 4GB. My computer from 2008 came with 4GB RAM, the same amount as some low end computers today and can be upgraded to 8GB.

My 2008 computer has gigabit Ethernet. Which is still the fastest consumer internet connection.

<comment><USER5> > _The Plex Server has to transcode all types of formats to H.264 in real > time. My old 2006 Core Duo 1.66Ghz Mac couldn 't handle it._

That that's more than 10 years old. Your original point was that you're using a 10 year old system.

> _They weren 't transcoding 1080 video to H.264 real time in 2008._

Again you're comparing apples to oranges because most people wouldn't have had a need for transcoding 1080p videos from home servers back then. Most broadcasters still weren't sending HD streams or had only just started to. So a 10 year old PC in 2008 doing HD would be like a 10 year old PC in 2018 doing 4k.

>* My 2008 Core 2 Duo can run the latest software and the latest version of Windows well. Could those 10 year old computers run Windows 98 in 1998?*

The examples I gave were from around 1994/5 and as I had already cited they were running Windows 3.x (Windows 95 hadn't been released at that time). So yes, the latest OS.

 _> How is a watch that runs a phone OS that makes phone calls not considered more of a phone than a watch?_

I'd already address that point as well. One word: "expectations". I don't expect a watch to be obsoleted after 2 years regardless of the tech it includes. If said tech means my expectations cannot be met then I simply will not buy any more watches made by that company. After all, I already have a phone; what I need is a watch.

 _> The difference is that my 10 year old computer can do the same thing as a modern computer - run the latest OS and software, has just as much memory and storage (HDD vs SsD) and has a slightly better display (1920x1200 vs 1930x1080). Can that 10 year old digital watch do the same as a modern smart watch?_

I've already addressed that point too. Watches are not PCs (forget the technology and thing about it's form factor and what it's actual usage is). Thus comparing the two doesn't make much sense.

>* The only reason that my old Core 2 Duo is "future proofed" is because useful improvements have slowed down dramatically in the last 10 years. In 1998 the typical computer was coming with 32-64Gb of RAM and couldn't be upgraded to 4GB. My computer from 2008 came with 4GB RAM, the same amount as some low end computers today and can be upgraded to 8GB.*

Nope. I've already demonstrated that software likes to keep up with hardware. This it as true now as it was 10 years ago (even 20). What's changed is:

o we've moved back towards a time sharing model where processing is offloaded to the cloud

o we've learned lessons about security after the mistakes of the 90s and 00s where PCs were basically just honeypots for malware. Granted we still make lots of mistakes even now (particularly around the area of IoT where we seemed doomed to repeat past mistakes) but in terms of actual PCs the groundwork was put in 10 years ago.

o software development processes have matured and also include better automated testing frameworks making it easier to detect problems and test on a wide range of platforms

o Microsoft also got their fingers burnt with the whole "Vista Compatible" thing on backstock Intels that clearly weren't capable. So invested more in the future releases of Windows to ensure that didn't happen again.

You could also argue that the pace of "useful improvements" in OS development has sped up over the last 10 years because more time has been invested in making platforms stable, secure and performant instead of just throwing new shiney feature after new shiney feature.

>* My 2008 computer has gigabit Ethernet. Which is still the fastest consumer internet connection.*

Another meaningless comparison because my 1998 computer had 100Mb ethernet, which was several orders of magnitude faster than the then fastest consumer internet connection. If anything I think the state of networking gear has stagnated because I was handling gigabit switches back in 1998 (with AppleTalk - yuk), which took _forever_ to reach consumers and still many ISP routers only offer 1 complimentary gigabit port. Yet most offices / server rooms are still only on gigabit switches some 20 years later and most home users are probably on WiFi or Powerline adapters (neither of which will come even close to 1GbE). So I guess the real question is, how fast does one actually need their LAN to be? Either way, it's wildly off topic.

<comment><USER4> _Again you 're comparing apples to oranges because most people wouldn't have had a need for transcoding 1080p videos from home servers back then. Most broadcasters still weren't sending HD streams or had only just started to. So a 10 year old PC in 2008 doing HD would be like a 10 year old PC in 2018 doing 4k._

My 10 year old computer _is_ doing real time transcoding in 2018.

 _The examples I gave were from around 1994 /5 and as I had already cited they were running Windows 3.x (Windows 95 hadn't been released at that time). So yes, the latest OS._

Again. That's the point. My 10 year old computer is running the current latest OS in 2018. A 10 year old computer in 2008 couldn't run the latest OS.

My major point being that in the first few facades of PCs, technology was moving so fast that to run the latest software, you had to upgrade your computer more frequently. Now, a 10 year old computer can run the latest software.

The smart watch and the phone to a lesser extent is still seeing the type of rapid improvements that you saw in computers until 10 years ago.

An electronic watch from 10 years ago can't do everything a modern smart watch can. A 10 year old computer can.

As far as the actual usage. A modern smart watch is used for a lot of things that a 10 year old watch wasn't.

<comment><USER5> >* My 10 year old computer is doing real time transcoding in 2018.*

Yes, I got that point. And I'm saying 10 year old computers in 2008 were doing transcoding as well - just with standard definition streams rather than HD (the "HD" part seemed important to you but I was making the point that you're not doing 4k transcoding in 2018 with your 10 year old PC so why fixate on HD recording in 2008 when HD was just as new as 4k is today)

>* Again. That's the point. My 10 year old computer is running the current latest OS in 2018. A 10 year old computer in 2008 couldn't run the latest OS.*

Maybe I'm not making myself clear enough because this is the 3rd time I've now had to say that I've used 10 year old computers both in 2008 and in 1998 - <USER2> of which were running the latest OS. Like I said, in 1995 I was still supporting Windows 3.x on a 286s.

 _> My major point being that in the first few facades of PCs, technology was moving so fast that to run the latest software, you had to upgrade your computer more frequently. Now, a 10 year old computer can run the latest software._

And I'm saying that is bullshit. I have first hand experience - originally as an owner and a support engineer; and then as a developer and systems administrator - with examples over the last 20 years that directly disprove your point. Examples I've repeatedly cited. Frankly if I've seen any trend it's people replacing hardware quicker now that laptops have gotten so cheap - which is the exact opposite of the point you're trying to make.

 _> The smart watch and the phone to a lesser extent is still seeing the type of rapid improvements that you saw in computers until 10 years ago._

I've repeatedly demonstrated that your argument about rapid developments in the PC landscape is completely baseless and given numerous examples why.

> _An electronic watch from 10 years ago can 't do everything a modern smart > watch can. A 10 year old computer can._

Again you're comparing apples to oranges. A watch is not a PC. Hell why don't we just compare it to cars and have the same meaningless discussion: a digital watch is like a small hatchback and a smartwatch is like a campervan. What we've now proved is that smartwatches have running water....oh wait.

 _> As far as the actual usage. A modern smart watch is used for a lot of things that a 10 year old watch wasn't._

That is literally the only accurate thing you've posted. The real question is whether the other stuff is enough to make people want to upgrade their watches (as well as their phones) every two years. I don't think it is. I think those kind of people are the exception and most people wouldn't want their smartwatch to become obsolete so quickly. I think most people see their smartwatch as a digital watch on steroids rather than a PC. And thus I think most people's expectations would be for their watch to outlast their phone.

At risk of repeating myself (but let's be honest, you've missed the other points I made on 2 separate occasions) the hardware is irrelevant to most people. Most people aren't techy. Most people will look at a smartwatch and see " _something_ -watch" not "computer- _something_ " like you and I.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I surprised myself by buying a series three Watch recently: I had stopped wearing a watch 20 years ago when my didgeridoo class instructor started teasing me about always looking at my watch. He said that to master the didgeridoo you need a different view of time.

Anyway, the series 3 with LTE wireless is incredibly useful. I often don't carry my phone when I want to be more offline, but I can get email and messages as needed. Works OK as a phone also. I like that it takes about 1 second to switch between normal and airplane mode when I don't want to be interrupted.

I understand the article author's viewpoint, but why not just write apps that only support later models? Doesn't Apple allow that?

<comment><USER7> Apple has historically allowed developers only to restrict to certain features, rather than hardware speed or generation.

i.e. one may be able to only create a watch app for the LTE watch, if it requires that, but one cannot restrict to the faster models, so apps on slower models still have to run fast enough to be useful.

Also, I wouldn't be surprised if Apple don't allow you to restrict to LTE watches, as I suspect their view would be that LTE is an improvement to usability, not a fundamental difference, and therefore apps should be able to function fully with no LTE. Not to mention user restrictions on certain apps due to data usage.

The classic example would be restricting iOS apps to only 64bit devices, only devices with Siri capabilities, only devices with the motion detection chip, etc.

</comment></comment><comment><USER8> I bought the series 3+LTE hoping to get a device that would allow me to leave my phone home when I went out at night. After getting stranded one too many times when the Uber and Lyft apps both failed, I abandoned that dream. Hopefully broader watch adoption and watchOS 5 fixes this (I'm not sure which exactly is causing the problem). Judging from conversations with my friends, I'm not alone. It seems like "ability to reliably hail a ride" is key functionality for any technology that hopes to replace a phone in any meaningful part of someone's daily/nightly routine in a place like San Francisco.

</comment><comment><USER9> Not having to wear a watch is the best thing mobile phones did to me. Thanks, but no thanks.

<comment><USER10> As a man, my watch is the only piece of jewelry I get to wear - I'm keeping mine forever, thanks.

<comment><USER11> Nobody's forcing you to conform to outdated gender roles. It never stopped Mr. T [1]. If you really want to wear jewelry, don't let your testosterone hold you back. You know you can even pimp out your phone, too [2].

[1] [http://www.blazenfluff.com/mr-t-jewelry-starter-kit- golden-c...](http://www.blazenfluff.com/mr-t-jewelry-starter-kit-golden- chains-and-bling-rings/10391)

[2] [http://www.mobiletor.com/iphone-princess-plus-the-worlds- mos...](http://www.mobiletor.com/iphone-princess-plus-the-worlds-most- expensive-iphone-bearing-diamonds-costs-176400/)

<comment><USER12> > _Nobody 's forcing you to conform to outdated gender roles_

Except good judgement.

<comment><USER11> Outdated judgementalism.

<comment><USER12> Out of date doesn't mean stale or bad, just that it's not the fashion du jour.

People should think better than using categories like "outdated".

Or "judgementalism" for that matter. Not sure when being able to judge things (a prerequisite for not going through life blindly) went out of fashion.

</comment></comment></comment></comment></comment></comment><comment><USER13> So the Series 3 now has more apple watch marketshare than the previous offerings; that's good (disclaimer: Series 3 LTE was my first Apple Watch; I like it a lot)

<comment><USER14> It is being subsidized by several health insurance companies in the US.

It would be interesting to see adoption rates in countries with socialized medicine (not watches).

<comment><USER15> The UK has socialised health but Vitality Health are also offering an Apple Watch as part of the health insurance:

[https://www.vitality.co.uk/rewards/partners/active- rewards/a...](https://www.vitality.co.uk/rewards/partners/active- rewards/apple-watch/)

</comment></comment></comment><comment><USER16> Odd question - but how does one tell which 'series' watch they have? I received mine as a gift a few years ago, and curious as to whether it is series 0 or 1 etc.

<comment><USER17> It doesn't help that Apple has been inconsistent about their terminology. This page doesn't even mention "Series 0", which I guess is supposed to be the same thing as "Series 1 (first generation)":

[https://support.apple.com/en-us/HT204507](https://support.apple.com/en- us/HT204507)

<comment><USER18> "Series 2" added a GPS, brighter screen, and better water resistance compared to the original model.

At the same time, they dropped the original "Apple Watch (1st generation)" and replaced it with "Series 1", which as far as most users were concerned is basically the same thing, but it has a slightly faster processor than the original.

I wouldn't be surprised to see "Series 0" get dropped sooner rather than later. The iPad analogy is a good fit, the very first one is stuck at iOS 5, but anything newer than that gets iOS 9 at a minimum.

Re: terminology, "Series 0" is definitely not an official name for it, just a convenient shorthand that feels easier to understand than its official name to me.

<comment><USER19> It is much easier. There's "Apple Watch", "Apple Watch Series 1", Series 2, Series 3 ..

So we end up with a classic fence-post error, where if I say I have the first model, most people could assume I mean Series 1. So we've taken to calling it Series 0 (a term Apple never used/uses). Otherwise if I just call it "Apple Watch", you have no idea if I'm implying a version number or not.

I get their problem. "Series 1" is less "2nd generation" and more "revision 1.1". If they'd called it a 2nd generation, they'd overpromise and under- deliver, which is never popular. But calling the 2nd revision "Series 1" is all kinds of confusion.

</comment></comment></comment></comment><comment><USER20> I have a series 0 and I haven't felt the urge to change at all. Is the series 3 that much better? Like life-changing better?

<comment><USER21> I upgraded from a Series 0 to a Series 3 last winter.

It's a huge difference if you use your watch for anything other than a clock/notification machine.

<comment><USER22> What else do you use it for?

I also have a series 0, and maybe I'm self-constrained because of its limitations, but I use it mainly as a simple PDA in my wrist. Notifications, workouts, Siri, calendar, weather and messages. Works fine though a bit slow, but I don't mind

Are there really any other uses for the watch?

<comment><USER23> I use it for:

* sleep tracking * displaying todos on my watch face * Creating reminders * timers * pomodoros * step counting * music playing * phone calls * Logging my weight with the workflow app * apple pay * music and volume controls

You can probably do all those? The series 3 will just be a lot faster in all transitions. Also has connectivity even if you go phoneless. (Though not all apps work)

<comment><USER22> More or less. I do more PIM but occasionally play music and do calls.

I'm in Spain, so no LTE for me. Otherwise I'd bought a Series 3 it in a heartbeat. Most important feature IMO.

<comment><USER23> Yeah. That is exactly what convinced me to buy. I hadn't even cared about any of the stuff that I listed.

Now that I have it, I love those features and would not want to go back. And I use the LTE less than I expected. But I am extremely glad to have it.

</comment></comment></comment></comment></comment></comment><comment><USER24> Never wore a watch.

Apple's new marketing push showing health and life savings benefits to having/using a wearable is pretty compelling, but yet and again I have lived a few decades without ever wearing a watch. It would annoy me!

If Apple built health and life saving tech into clothing or shoes then it's a no brainer.

<comment><USER25> Before the Apple Watch, I hadn't worn a watch ever either. Adjusting to having something on my wrist took a week or two, but it seems like just any other article of clothing to me now. I don't even notice it there.

</comment></comment><comment><USER26> If the life-cycle of these devices, and therefore your software, is that short, why bother fixing bugs? Now that I think about it, this __DOES __seem to be the mindset of many mobile developers!

</comment><comment><USER27> api sum articles

</comment><comment><USER28> This should probably link to the source at [https://david- smith.org/blog/2018/03/14/apple-watch-series-3...](https://david- smith.org/blog/2018/03/14/apple-watch-series-3-adoption/) , unless i'm missing something.

<comment><USER29> Yes. Changed now from [https://sixcolors.com/link/2018/03/apple-watch- adoption-numb...](https://sixcolors.com/link/2018/03/apple-watch-adoption- numbers/).

</comment></comment><comment><USER30> Would love to see the numbers of how many purchased and now in the drawer never to be worn again.

</comment><comment><USER31> A friend of mine buys everything Apple releases, and the Apple Watch is probably the most useless piece of electronics I've ever seen.

He used it for a couple of weeks, but I don't think I wouldn't have lasted more than 2-3 days having yet another thing I have to charge every day.

Do a lot of people actually use them and download and use apps? Why would I want to carry a smartwatch besides for exercising (where I'd personally want something much lighter and a lot cheaper) when I have my cell phone with me at all times?

I'm not making fun, just curious.

<comment><USER32> The other day I went out for a 10 mile run (from Brooklyn to Queens) with my Apple Watch and wireless earbuds. I was running to my mechanic to pick up my car which had been serviced.

I listened to a couple of podcasts I had downloaded offline with Watch Player. Then I switched to streaming Apple Music. About 5 miles into the run I got a phone call from the mechanic which I answered, to confirm that I was still coming to pick up the vehicle. I also stopped in to a pharmacy and bought an energy bar using Apple Pay.

When I got to the mechanic, I picked up the car, and used Apple Maps driving directions to navigate home, while listening to Apple Music, connected to the bluetooth stereo in my car. I was also able to make a phone call to my girlfriend to tell her that I was on my way back and make dinner plans.

So yes, people actually use them, and download and use apps.

<comment><USER33> The thing I find interesting about these stories is: the 500$ watch, is in essence a flip phone, plus an iPod Shuffle, in one.

A flip phone and an iPod Shuffle cost me 100$, and a 25$/mo plan, unlimited talk/text, almost 15 years ago.

Now we have a flip phone + shuffle on your wrist, for 500$, plus you almost certainly have an iPhone - 50-100$/mo plan, plus what, 200-500$ flat fee for the phone? Oh, how much are those airPods? Add 150$ to that bill.

The same functionality from 10-20 years ago, should cost less, not more, if we are to use a little common sense. It feels like Apple's fantastic feel for aesthetics and horrid android offerings, have led people to believe it's reasonable to spend roughly a thousand dollars a year if not more, to do the same things you did 15 years ago for 1/5th if not 1/10 the cost. We're getting the same functionality, in a SLIGHTLY more convenient (arguable) wrapper, and it costs way more! This is the opposite of progress.

Before anyone jumps out and tells me how useful their 'smart'-phone is, let me remind you the most used apps on there are pure empty entertainment (social media, games), with very questionable long-term costs (I predict an epidemic of neck and shoulder problems hitting the developed countries in the next 20-30 years)

<comment><USER34> I've run a few miles with a phone and a shuffle before.

I don't think it's the same experience as running with just a smartwatch.

There's less dread that you're going to drop and destroy an expensive heavy device if you focus on your run.

I also didn't and don't pay anything near your prices, and don't find Apple's aesthetics that great, or Android's offerings that horrible.

<comment><USER35>
      There's less dread that you're going to drop and destroy
      an expensive heavy device if you focus on your run.

I run with a phone all the time - I just make sure my shorts have decent pockets. I can get a lot of pairs of shorts for the $400 list price of a GPS + Cellular Apple watch :)

<comment><USER34> I found it annoying to strap a weight to one of my legs, or have it pound against me when sprinting. So cuffs and straps come into play, and the fun of choking off circulation, all while making it difficult to access any controls.

And again, 400 is a silly price to pay for small tech, but that's not a criticism of watches, it's a criticism of Apple. Did you see the teardown of Beats headphones and their cheap components? There are lots of lousy ways to conspicuously give Apple too much money without watches.

You could get a cheap smartphone and an entry level watch for a third of the price of some people's iPhones, and if you share my somewhat odd preferences, have a better experience for it.</comment></comment></comment></comment></comment></comment>


The 21 most dangerous foods in the world - <AUTHOR> http://www.businessinsider.com.au/the-most-dangerous-foods-in-the-world-2015-10 <comment><USER2> Hot dogs are definitely a dangerous food item for children because they can be a choking hazard. Jello can also be a choking hazard for small children as well. Teaching children to chew and swallow their food well will prevent them from choking.</comment>


Beck Design Rules (2015) - <AUTHOR> https://martinfowler.com/bliki/BeckDesignRules.html <comment><USER2> >Such things as adding duplication to increase clarity is often papering over a problem, when it would be better to solve it.

So much this, lately. I've found myself unsatisfied with the convoluted code needed to share some functionality across two similar but distinct areas, and trying to figure out if the repetition or the convolution is easier to understand for the reader, and what it means for maintainability.

But really what's tickling me is that there is a better solution waiting in there somewhere.

<comment><USER3> Compare that with Go's "A little copying is better than a little dependency".

The problem with religious DRY is that the shared bits may eventually evolve into something that does everything for everyone, used everywhere, and becomes unmaintainable and buggy. You can't touch it without breaking something. The notion that tests will guarantee its correctness doesn't tend to work either since there's no way to cover all of a product's functionality via tests.

I think it's important to look at XP in context, see what issues it tried to address and how it tried to address them, and try to be pragmatic. There's certainly local situations where DRY is a good principle but generally you should strive to break your software down into independently maintainable pieces with well defined/small-ish interfaces, trying to stretch DRY across those boundaries would create problems (i.e. the dependency mentioned in that Go proverb).</comment></comment>


An island that switches countries every six months - <AUTHOR> http://www.bbc.com/news/stories-42817859 <comment><USER2> > This sort of joint sovereignty is called a condominium, and Faisans Island > is one of the oldest in existence.

I don't think this strictly counts as condominium. In a true condominium, France and Spain would exercise joint sovereignty 100% of the time. But in this case, they never exercise joint sovereignty, it is just they have agreed to transfer the single sovereignty of the territory back and forth on a regular basis.

New Hebrides (now known as Vanuatu) was a true condominium in that 100% of the territory was under joint British-French sovereignty 100% of the time (until independence in 1980).

</comment><comment><USER3> Google Maps currently shows it on the Spanish side of the border for me (despite that fact that it's France's "turn" for a few more days). I suspect this sort of detail isn't worth bothering with, but it is interesting...

<comment><USER4> This is a pretty tame example, but Google is definitely active in delivering maps based on the viewers location in some more tumultuous parts of the world, for example the disputed borders of China/India/Pakistan in the kashmir region.

[https://www.google.nl/amp/s/www.gislounge.com/the- politics-o...](https://www.google.nl/amp/s/www.gislounge.com/the-politics-of- googles-mapping/amp/)

<comment><USER5> Link without AMP crap: [https://www.gislounge.com/the-politics-of-googles- mapping/](https://www.gislounge.com/the-politics-of-googles-mapping/)

<comment><USER6> Screenshot 'without AMP crap' : [https://imgur.com/a/6i7ae](https://imgur.com/a/6i7ae)

Screenshot with AMP : [https://imgur.com/a/3IsGe](https://imgur.com/a/3IsGe)

I hope you understand why people might prefer AMP.

<comment><USER5> That's actually why I prefer adblockers.

<comment><USER6> That is just digging your head in the sand. If everyone starts using adblockers, ads will no longer be blockable (say, just a dumb image).

Accept it or not, ad revenue is how the internet runs at today's scale.

</comment></comment></comment></comment></comment></comment><comment><USER7> This could be one of the "Falsehoods programmers believe about" series. Imagine how this complicates maps, geography data etc. Obviously, unless you ignore the reality.

<comment><USER8> I do believe it's mentioned, either in the article or in the discussion:

[https://wiesmann.codiferes.net/wordpress/?p=15187](https://wiesmann.codiferes.net/wordpress/?p=15187)

[https://news.ycombinator.com/item?id=14891185](https://news.ycombinator.com/item?id=14891185)

</comment></comment><comment><USER9> > For six months of the year, from February 1 to 31 July, it's under Spanish > rule - and for the following six months it's French

If I'm counting right, France has it 184 days per year (185 in leap years), and Spain has it 181 days.

I wonder why they didn't balance that better? April 1 to Sept 30 for France and Aug 1 to March 31 for Spain would have given 183 for France and 182 for Spain (183 in leap years).

The same balance would also arise from June 1 to November 30 for France and December 1 to May 31 for Spain.

<comment><USER10> It would hardly be fair if one country got to enjoy the island in the nice warm summer months, while the other only got it for the cold winter, would it?

<comment><USER11> Given that it's uninhabited, I don't think anyone _enjoys_ it as such.

It's located in what, either side of the river, was the medieval kingdom of Navarre, subsequently ruled by distant monarchs in Paris and Madrid.

</comment></comment></comment><comment><USER12> > Next week, France will hand over 3,000 sq m (3,200 sq ft) of its territory > to Spain without a single shot being fired.

Those numbers don't add up.

> The island is tiny - just over 200m long and 40m wide.

Assuming the island is roughly an ellipse, it's area should be ~6,280 m^2 or ~67,400 ft^2. Wikipedia reports the island's area as 0.00682 km^2 (6,820 m^2) and 0.00263 mi^2 (73,300 ft^2) [1].

So the reported area is half of the actual area, and the U.S. conversion to feet is off by an order of magnitude. BBC should have someone double check the numbers.

[1]: [https://en.wikipedia.org/wiki/Pheasant_Island](https://en.wikipedia.org/wiki/Pheasant_Island)

<comment><USER8> It does say "over 3000 sq m." 6280 > 3000 ;)

(The article also says that it's eroded and diminished recently)

</comment></comment><comment><USER13> Cool and weird! You'd think by now, they would have made some sort of agreement for one country to take it full-time, and the other to pay a modest price or give some other sort of diplomatic consideration. Guess nobody cares enough because it's so small and nobody lives there.

<comment><USER14> I like to think that rather there is no reason for either country to want the island full time, except to say they have it and the other does not, and plenty of reasons to keep a quirky tradition that serves as occasional reminder of an old treaty.

</comment></comment><comment><USER15> My father's neighbor's garden covers more area than that. Isn't the administrative cost within, say, 10 years, not higher than the asking price?

<comment><USER16> You talk like a buyer...

</comment></comment><comment><USER17> With the housing shortage, I'm surprised that no one has built condominiums on this condominium.

<comment><USER18> Pun aside, allowing people to actually live there would open an interesting question. Would people be tax residents of France only just because it's 184 days under French rule vs. 181 days under Spanish?

<comment><USER16> Should you only pay tax where you live, or where you earn the money too?

<comment><USER19> In the EU this is a common issue in some areas where you can commute across a border each day. The rules are well established, albeit varying depending on which border is involved.[1]

[1] [https://europa.eu/youreurope/citizens/work/taxes/double- taxa...](https://europa.eu/youreurope/citizens/work/taxes/double- taxation/index_en.htm)</comment></comment></comment></comment>


Matt Mullenweg's 12 Rules to Move from 1 User to 100k - <AUTHOR> http://www.baychi.org/calendar/20060808a/#2

<comment><USER2> Some textual notes: [http://raincitystudios.com/blogs-and-pods/matt-mullenweg- sca...](http://raincitystudios.com/blogs-and-pods/matt-mullenweg-scaling-for- your-first-100k-users)

<comment><USER3> Thanks very much for this. I appreciate text more than audio.

</comment></comment><comment><USER4> For those people wondering if they should commit the time to listen to this I encourage you to do so.

I will say that the title lead me to think that the talk would have to do with marketing strategies, but instead it has to do with product direction and user support.

</comment><comment><USER5> appreciate the great advice about user/customer support. i especially liked when he talks about how to think about what the users want, relate to them, tell them what you can do for THEM - "nobody cares about you except you, people care about themselves" thanks

</comment><comment><USER6> This really makes me wish that when I booted up my computer this morning, my sound card _wasn't_ broken.

</comment><comment><USER7> "Be a pain killer, not a vitamin."

Pearl of wisdom for startups</comment>


Show HN: Social Network for Code Snippets - <AUTHOR> http://www.thiscodeworks.com <comment><USER2> The masonry grid makes exploring the snippet so troublesome.

How about Title list and on mouse over OR on click - POPOVER the code as well as option to open in new page.

</comment><comment><USER3> Looks very interesting. Have some feedback though:

* I couldn't identify what license the code snippets are shared under. Could you add an option of license selection when a person posts? (Default could be GPL)

* The links for 'Privacy Policy - Cookies - Contact' are only available on the Home page, not when I am browsing the snippets.

\- Sur</comment>


70 job interviews in 17 days - <AUTHOR> http://blog.brandonwang.ca/2017/06/how-to-get-70-job-interviews-in-17-days.html <comment><USER2> "5.4% conversion"

That is the key number here. And that was just to get an interview. He got 6 offers from those 70 interviews, which is over a 90% rejection rate, despite some pretty good credentials in his background.

Personally, I go the other way. I send out resumes selectively, and run closer to about a 30% response rate. And In my entire career, I've only ever NOT gotten an offer twice. Not because I am some extremely special coder --- I'm not. But because I take some care in selecting who I talk to in the first place to make sure we're a match before even getting that far.

<comment><USER3> I would like to believe this, too. However, after spending 6+ months helping my SO applying for more than 100 positions, handcrafting every CV and cover letter for each position, highlighting the skills that each position required, and all that we got back was maybe 5 negative answers, I think it's time to try the mass spamming approach. It's true the positions were not hardskills programming ones (more BA/data analyst oriented), but I still find it quite baffling.

<comment><USER4> May I ask what's SO?

<comment><USER5> Ah, an old /. refugee I see!

</comment></comment></comment></comment><comment><USER6> > the script I used to algorithmically apply

I'm not the same as everyone else, so take my opinions with a grain of salt.

I'm a hiring manager, with many openings. To those who are considering this approach, keep this in mind:

\- This industry is smaller than you think. I have colleagues all over town and across the country. It's not uncommon for me to be maybe 2-3 degrees of separation from any person or place on your resume. If I think you automated your way into a conversation with us, I don't discount you right away but I highly doubt your sincerity.

\- Generic templated messages vs. thoughtful direct messages are _easy_ to detect. Even if I'm wrong, if it doesn't pass the smell test, I will pass.

Do NOT kid yourself about the importance of managing quality vs. quantity in discussion with us. This process likely works in landing you an interview, but it can ignore the human element. To me, how you get in the door matters. Picking out the interested-after-the-fact vs. those who have done their homework on us is easy, and that matters greatly to me.

I hire for the long-term and career-growth minded, and I recognize anyone on my staff can up and leave at any moment. I commit time, resources and energy to ensuring my staff is healthy and happy with us. This saturate-the-airwaves approach to introductions, even if refined, makes me think you're going to treat us as a temporary stop, simply looking to jump to the next "better" opportunity, and therefore leaves me less interested in devoting time to you.

If all this just sounds like better execution with this approach, you're right. Just remember you don't get a second chance with us to make a first impression.

<comment><USER7> I'm a hiring manager as well and let me throw out a partial counterpoint: What OP is doing isn't because he doesn't want to be genuine with you. It's motivated because the HR screen is the hurdle to overcome, and there will be no opportunity to have a genuine conversation with you unless he gets past the HR filter first. I have a solution to this that works for me, but maybe not for everyone - I have HR do a very basic screen for my posting (candidate in market, unless I'm going to relo; current career level somewhere in my ballpark), with the exception that I want everything that includes a cover letter.

If you're not big enough to have an initial screen happening, then obviously my point doesn't apply and you're entirely correct. But for many, getting anywhere near the hiring manager is the most difficult step.

Plus, from my memories as an applicant - to startups and larger firms alike - I can't tell you how many times in my past I've taken the step of writing a nice, personalized cover letter and a tailored resume for something which was a reasonably good fit, only to either never hear a word or to receive an automated form rejection in return. Courtesy is a two way street - if your ATS blasts rejections to people, you can't get upset with candidates blasting applications to play the numbers.

<comment><USER6> Yes and thank you, very good points.

We are a larger organization, and getting past the HR filter is understandable. We have taken significant measures to improve that step with us, and it has yielded much better throughput on worthy candidates. At sounds as though we do something similar internally -- incorporate shared reviews from our team with inbound resumes.

And to your point about a two-way street -- I couldn't agree more. We respond to everyone, and do so manually. We don't automate that way, as I want a human contact behind the message. (We don't get thousands of resumes, but we do get in the low hundreds.) I've found executing those directly is meaningful and translates to better communication over time. I think of it as a function of customer service, not recruiting.

To really tie it all together: we want to speak with those who have genuine interest, and are willing to put effort into it from the beginning of any conversation with us. We hope our candidates do the same.

<comment><USER7> I agree with all of that. And just to be clear, I never disagreed with the principle of your original post. The thing is, for everyone doing it like you (or let's say us, since it sounds like we have a similar approach), there are hundreds of organizations letting the ATS handle it. Unfortunately, everyone else letting the ATS do it is going to harm our efforts indirectly.

I should add that this is probably easy for me to say since I'm outside of a tech hub and also receive a lower volume. If I were getting thousands per vacancy, I'd have to find a different approach, but handing the keys to the ATS is not how I'd want to have it go.

<comment><USER6> > everyone else letting the ATS do it is going to harm our efforts indirectly.

Yep, this. I actually see this as a future competitive advantage for us. I want us to be known for having a really positive experience for anyone who wishes to work with us, no matter the choice/decision that ultimately happens. It will take time to get there, but consistency builds reputation.

</comment></comment></comment></comment></comment><comment><USER8> The lesson here isn't that spamming works - it does now, but it'll very soon stop working if everyone does it. The real lesson is that applying for positions at companies that you want to work at, even if they aren't advertising the job you do, works. Send them your resume regardless and see what happens.

<comment><USER9> Meanwhile unemployment benefits in certain countries (e.g. Australia) legally require you to do this to keep your benefits. Literally applying.

On the one hand I get that you need to require them to do something and I don't have an immediately better idea, but on the other hand they keep talking about increasing the number of jobs you have to apply for etc despite their literally not being enough jobs for everyone on benefits.

Fun times

<comment><USER10> > Meanwhile unemployment benefits in certain countries (e.g. Australia) > legally require you to do this to keep your benefits. Literally applying.

I had to document a certain number of applications per week to get unemployment in the U.S., but those policies vary by state.

<comment><USER11> During the height of the recession I had to do the same (also US).

After a while you can tell that a good number of those positions are just recruiting firm honeypots; which makes the search both aggravating and depressing (since you feel like there aren't any /real/ jobs out there).

</comment></comment></comment></comment><comment><AUTHOR> Author here.

A few notes:

I'm not proposing high touch methods are incorrect. I'm proposing there exists an alternative.

HR professionals, the receiving end, spend their day spamming people on LinkedIn, email, etc. The same is true about sales people, marketers, and anybody trying to get the word out, except they do it at scale. I'm a little surprised by how many folks take issue with messaging people who might be interested and also do exactly what you're doing.

If everybody does this, then job hunting becomes more like marketing since your message/resume has to stand out more. Consumers are bombarded with messages every day, they're good at ignoring things they don't want. The folks doing the hiring would become better "consumers".

Engineering roles are, in general, way easier to land than a non-engineering roles because there aren't enough decent engineers.

<comment><USER12> I have a BS computer engineering from GT and the only interviews I have received have been from companies wishing me to sign a 3 year contract or other 1*star glassdoor type shenanigans. I am trying to stay positive but I have lost hope. Ive done the mass submitting and specific tailoring strategies to no avail. Now I wish I had gotten a degree in ANY other engineering discipline. Any advice?

<comment><AUTHOR> Sorry to hear it's been hard. It depends what you're going for.

I'm an EE, less relevant than CE to CS (if you're going after software positions). There are plenty of EEs, physicists, etc. who are in top posts at most tech companies for software. Your degree isn't limiting you.

Job hunting is about demonstrating value to people who matter. If you can demonstrate value to the hiring person (hiring manager, HR, etc.), then you'll get hired.

So while the resume and education are one thing, they're really the tip of the iceberg. You can contribute on open source, you can showcase papers you've authored, you can build relationships with hiring managers to show that you know your stuff.

If you're going for hardware, hardware positions are lower paying, harder to get, and require more experience than software positions. You might want to apply for internships. Broadcom, Qualcomm, Nvidia, all have great internship programs. They might get you to do fun things you'd never do as a full timer as well (Apple gets lots of interns to go to Shenzhen, Nvidia gets it's interns to drop boxes on the floor to test packaging).

Almost all tech companies I've ever interacted with have different staff that deal with new grads/university students than the rest of HR. A typical HR person probably doesn't like new candidates, but new grads are what university recruiters are supposed to do. I'd seek out university recruiters specifically (you can search "university recruiting" on LinkedIn).

I know lots of people who start companies because the jobs they're qualified for, suck. Honestly, I started my first company because I engineering stopped being challenging/fun and no business wanted to take me on. Now I can say I've scaled businesses, sold my B2B SaaS product to $B companies, etc.

Finally, on the motivation/keeping the hope alive. I've had my fair share of dark times. Tony Robbins, Art Williams, and Zig Ziglar are all great to listen to.

Best of luck!

<comment><USER12> I appreciate you taking your time to respond, I will try to find university recruiters.

</comment></comment></comment></comment><comment><USER13> This is a classic case of tragedy of the commons. I don't find anything particularly noteworthy about this to warrant communicating this to a larger audience.

Unilaterally spamming potential employers in this way may result in improving your outcomes, but at whose cost?

<comment><USER14> Exactly, this is a self reinforcing feedback loop. I've heard about getting 200 resumes for an open position multiple times. Obviously it varies. Assuming 40 1 hour interviews per week, this would be 5 weeks. Also, your employees aren't working during that time, which can be bad if you have way too much work, right now. So there's a need to filter heavily. Enter filter by keywords, or maybe even discrimination.

while(true) {

1\. faced with a large number of resumes, employer become aggressive about filtering.

2\. faced with a large number of rejections or not hearing back, employee sends even more resumes.

}

</comment></comment><comment><USER15> It was really hard, and took many spammy attempts, but you can do it too!

 _homeless dude looks up hopefully, fishes out his tattered, vacant resume_

"In my case, my message was: I've built 2 companies, got a strong technical background, worked at places like Microsoft/Amazon/Nvidia, and I'm looking to work with great people."

Oh.

<comment><USER16> I'm really not trying to start an argument here, because there are many disadvantages that are hard/impossible to hurdle. However, being unemployed comes with a single, potentially powerful advantage: time. As a programmer, you need a computer (cheap second hand one is fine), you need a place to work and you need and internet connection.

If you are unemployed for more than about 6 months, people start to look at you suspiciously, but after that you can't really fall any further. Being unemployed for 1 year or 2 years can be an advantage if you use that time productively. It won't appeal to everyone, but battling back from nothing is also a compelling story.

Like I said, there will be many people who can not do it, for one reason or another, but I think the message that brand is important is not wrong.

</comment></comment><comment><USER17> It seems very odd to me to treat the job application process in this way. If nothing else, interviews are pretty much an all-day affair, at least in the sense that even if you have a short one, it's still going to be tough to schedule 2 in a day. Add that onto how many companies want multiple rounds of interviews, phone screens, take-home projects, etc and you get that you want to have a good idea that you actually want to work for a company before you apply and go for an interview. That doesn't mesh very well with writing scripts to mass-apply to companies and going on multiple dozens of interviews.

</comment><comment><USER18> As a founder perspective:

1\. I highly second using angel list. Modern founders know, and we (graphistry) list there!

2\. ... We are overwhelmed by candidates from there, both by junior or bigco candidates who are hard to distinguish just on paper, and senior candidates who we are not sure are serious. Probably ~100% of the people we talk to didn't do the author's generic approach, but shared a carefully crafted 1-3 paragraphs. The more you go out of your way, the more we notice.

Take it from the perspective of a neat small team (like ours!) who is excited about what we do & are growing. Whoever we hire now has a huge impact on what we're building, and as we're planning out the next 3-4 doublings of our team, your personal DNA & culture will determine the success of the 10 people who descend from you. You want to apply to teams who are spending time on doing this well.. and in turn, do it well yourself.

Also.. firstname.lastname@example.com if you agree ;-)

</comment><comment><USER19> Even after reading the intro, knowing what was coming, it still somehow surprised me to bump into the word "funnel" referring to job applications. Good way to think about it if applying for lots and lots of jobs is the goal!

> Having lots of offers takes a lot of psychological pressure off of the > process.

This intrigues me the most, I'd love to hear more about it. I personally would have expected the opposite before reading this. Often having multiple job offers makes me freeze up and worry a lot about which one I should choose. But maybe that's because I'm worrying about 2-3 jobs I want, as opposed to 70. I'm often optimizing relationships and my own happiness potential rather than compensation. That one sentence does make me want to try an approach like this.

It'd be equally easy to spam without a script, right? This one looks like it hit "Apply" 1300 times in 1.5 hours - I'm looking at the 4 second delay. The script might be a 10-20 minute job, but I'd be paranoid enough about running something like this with my name attached that testing it and making absolutely certain it didn't go haywire would very likely take me a few hours. I probably would have done something that didn't scale, and clicked 1,300 times manually.

I did chuckle a little when creativity was mentioned multiple times, for a process that is automated and "spam". It is a bit creative, so I don't mean to judge - I'm seeing the word spam in many comments here - but I feel like there are some much more creative ways to get exactly the job you want, and the idea here might be more about DIY than "creative" per se.

</comment><comment><USER20> Personally, I would be reluctant to go to a face-to-face interview that hasn't been preceded by a phone interview and (ideally) a technical test.

By the time I step into the employer's office, I am 90% sure I would like to work for them. Anything else would be inefficient use of time, both mine and the employer's.

</comment><comment><USER21> > Startup compensation can be right up there with the big companies.

Does anyone know how to find these companies when you're already at the high end of the spectrum? There are thousands of start ups and even shooting an email or checking LinkedIn for previous work history of current engineers can be a time drain to figure this out.

Ideally, the compensation would be something like > 80% total comp of big tech company in liquid money + a lot of private RSU's ( > 50% of big tech total comp)

<comment><USER22> Most things about job seeking are a time drain, not only it is hard to find companies because of fragmentation but when companies use terms such as 'developer', 'programmer', 'engineer'(plus the weird ones: 'ninja'/ 'rockstar') it gets much harder to search, I would kill for someone to come up with international standard codes for these like SE0001 for a software engineer.

</comment></comment><comment><USER23> I recently had 4 good offers on the table at the same time and it was unbelievably stressful for me, I don't ever want to go through that again. I don't see the value in applying to even more companies and increasing that stress further...

<comment><USER24> This has to be some sort of logic fallacy. With multiple offers you are guaranteed to be able to get higher pay, more time off, and/or better working conditions. You can't see the opportunity cost for one job offer, but tradeoffs to other jobs still exist. You might still be happier more productive and better qualified for a different job at a different company.

<comment><USER25> > This has to be some sort of logic fallacy.

Not a Devo fan, are you?

[https://en.wikipedia.org/wiki/Buridan's_ass](https://en.wikipedia.org/wiki/Buridan's_ass)

> With multiple offers you are guaranteed to be able to get higher pay, more > time off, and/or better working conditions.

Actually, you aren't. You are, however, free to pick one of many offers, and one of them may suit you better than the others. Perhaps you can negotiate better offers, but this doesn't mean that a potential employer may be willing to present a better counter-offer.

<comment><USER26> They don't have to be willing to present a better counter. If they don't, you just eliminate them from the pool and your decision is that much easier. If you are afraid to do that, then the multiple offers are only illusory anyway, since you would clearly have a preference you should be acting on.

<comment><USER25> > If they don't, you just eliminate them from the pool and your decision is > that much easier.

You're somehow assuming that salary is the only relevant parameter in choosing a job, or even that all jobs are equivalent in career growth and creating more job opportunities. Some jobs are dead-ends and career killers, even if they pay more. This sort of stuff needs to be considered.

</comment></comment></comment></comment></comment><comment><USER27> Is job searching really at a point now where hiring people to mass apply to jobs for you is an actual suggestion?

</comment><comment><USER28> Any advice for interviewing? I have a second interview coming up soon.</comment>