Hacker Newsnew | past | comments | ask | show | jobs | submit | JCDenton2052's commentslogin

PlumGuide | Full-time | London, UK (2 days a week in office) or remote | https://www.plumguide.com

Plum Guide is building the marketplace of the world’s best holiday homes. We want to reduce the hours of anxiety that it takes to find a suitable home into a few clicks to find the perfect home. Every single time you use the Plum Guide, you are confident that there couldn’t be a better option.

Data Scientist: https://boards.greenhouse.io/plumguide/jobs/5005064003?gh_ji... Python, Pyspark, Django/Flask, Snowflake, Google cloud

Lead FrontEnd Engineer: https://boards.greenhouse.io/plumguide/jobs/4917026003?gh_ji... React (or Vue), Next.js, JavaScript (ES6+), TypeScript, CSS / CSS-in-JS, HTML5, Node, Jest, Cypress, Figma, Storybook

Senior BackEnd Engineer: https://boards.greenhouse.io/plumguide/jobs/4584486003?gh_ji... C#, .NET 6, Azure, Redis, Docker, Kubernetes, Bitbucket pipelines, high scalability distributed systems

Apply via links or reply here


One of the more insightful articles I have read lately.


If you were willing to speak truth to power like that, you would not be in her team in the first place.


A rather painful reading experience. The author needs to learn how to edit their thoughts and use punctuation/grammar properly.


A brief exercise in shipping an MVP and seeing if it gets traction before refining the feature set =). Thanks for reading my ramblings despite the lack of proofreading hopefully its a bit better for others now.


What came to my mind when reading the unedited copy is that you are confusing MVP with prototype. An effective MVP is something that does relatively very few things but that does them well or very well. Otherwise your churning will be huge. In other words, I read your post completely but it was somewhat painful because the copy was not polished for clarity, so I doubt I read a second one. I churned. To build effective MVPs you need to keep an eye on quality. Do fewer things that work flawlessly will have much more impact than throwing a bunch of things to the wall. You need to make a culture change and overweight quality. And I also recommend B2B if you happen to be trying B2C.


"I didn't have time to write a short letter, so I wrote a long one instead".

As a "tech guy", I never understood the notion of MVPs. Sure, start small makes sense, but delivering something half baked just demonstrates one doesn't care enough for their readers/customers. Why would anyone like to put himself in such a position?


Because people emphasize "minimum", when the important part was "viable product".


Haha I appreciate this response.


Of particular note:

"Google’s CEO Sundar Pichai (who believes AI is “more profound than electricity or fire”) has emphasized that Google is an “AI-first” company, with the company seeking to implement machine learning in nearly everything do"

Nearly everything they do with your data.


Not sure if a part of your post got cut off? As framed, it seems rather inflammatory without much direction or practical addition to the conversation. Perhaps I'm missing something.


Nope, nothing got cut. My post stands as I wrote it. It is not ad-hominem and not what-aboutery. It is very much a reasonable question to ask what they use their much-touted AI on and how this relates to the well documented privacy concerns around Google.


The original is actually more correct it seems.

IMO they are clearly betting (parts of) the farm on this as can be seen by the (often) ridiculous results many of us have witnessed in both search results quality and ad matching quality.


The best idea is to not use their services. Switch from Windows to Linux, de-google and if you must use Android keep the data on your phone to a minimum.


The churn rate is an effective question. In places with revolving door cultures interviewers get rather uncomfortable when asked such a question.


Questions about tests. I have found consistently that when an interviewer does not know what the test coverage of their codebase is, more likely than not they don't care about such trivialities.

No matter how respectable the company might look on the outside, the codebase is an incorrigible mess built by cowboys and they will expect you to maintain it.


I'm going to just say that making a codebase testable increases the complexity by a couple of orders of magnitude. Certainly it's great for some things. For other things it's a net negative.


Test is a small part of the whole picture. They might have lots of test but the system might still suck.


The article turns rather farcical towards the end... Erich Von Daeniken...


Did you go with full event-sourcing? That is, not persisting domain objects at all, just reconstructing their state from the event store?


In one project, where we could have done otherwise, we went consciously full Event Sourcing. In another project, the Domain Model was inherently event-based. In my book, the Sample Application first persists domain objects and is later refactored towards Event Sourcing.

While I read about the possibility of doing both at the same time, I never encountered this practice in a project. How I see it, there is always only one source of truth. If you apply Event Sourcing, it is the event log. Any other representation should be seen as derivation/projection.

The one long-term project where we applied Event Sourcing showed quite some challenges you can face with this pattern. For me, the most challenging aspect is the versioning of an event-sourced system. When the Domain Model evolves, it might necessitate changes to events or the introduction of new ones. Greg Young even wrote a book on this topic: https://leanpub.com/esversioning (I haven't read it though).


Can you tell me a bit a more about the long-term project where you applied full ES? What kind of domain/business context informs this decision?

I am aware of the costs of the approach, but would like to know the real world problems it solved for you.


Please note that I have limited experience with domains where Event Sourcing is without a doubt the weapon of choice. Hope my input still helps. Maybe there are other people that can give more qualified input on that. In the end, I am not trying to advocate for the pattern.

The project was about building a SaaS for structured meetings, both for on-site and remote use. It involved topical areas such as collaboration, moderation and presentation. The model defined that every meeting consists of six steps, where each is facilitated with one specific method (out of multiple). There were also additional functionalities such as a collaborative whiteboard and audio/video communication.

I briefly mentioned this in another comment: With regard to software architecture and pattern use, the project is a negative example. CQRS and Event Sourcing was prescribed on a system level. Regardless of conceptual/technological boundaries, every part made use of it. This decision was by no means reinforced with domain- or business-specific arguments. However, for us as developers, it was a great learning opportunity.

In terms of significant benefits for specific contexts, I can only think of the whiteboard part. However, even for that, it is about a feature we never got to implement. At some point, we wanted to add a "Undo" functionality. With Event Sourcing, you can simply append events that represent the reversal of previously persisted state transitions.

Independent of domain-specific aspects, I experienced three universal benefits. I hate to say it, but one was in fact reporting. Another benefit is the increased possibility to solve concurrency conflicts in a domain-specific way. Third, an event-sourced service is an ideal foundation for sending notifications, such as when publishing Domain Events. In the project, it helped us to build a real-time reactive User Interface. Of course, I'm not saying you necessarily need Event Sourcing for that.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: