Good on you for considering other perspectives, and acting. Many people only come to reinforce their existing ideas. FWIW your product itself looks good, if I'm ever in the market for a Datagrid type component, I'll consider it.
I know this isn't your actual question, but I think you should consider if the tone of your article represents the company you're trying to build. To me it reads as informal (comparison table "yes but weird), jokey (meme at top) & one-sided (can't find one point you lose at). It feels like poking at your competitor, not like an attempt at a neutral comparison. Now they're poking back via lawyers.
Maybe you do need a lawyer in this instance, maybe not, but if you're committed to this style when dealing with competitors you'll likely need a lawyer in the future.
With the increasing balkanization of streaming TV/film services, I wonder if piracy will start making a comeback. When everything (or most things) are under one roof, streaming makes sense - a single bill, one place to find content etc. Wondering which show is on which platform, or having to consider signing up for a subscription to a new service for a single show is not a good user experience, not to mention the single monthly bill ballooning to 3 or more.
If you you call out any of the rampant self-aggrandizement, exaggeration, humble-brags, or in some case outright lies there's no real upside, and plenty of potential downside.
For a small team of capable engineers, working on something that has low consequence for any single change failing plus a strong business motivation to move fast: sure, do without code reviews if you want.
There is no universal "best practise" for building software, there is just whatever works best for your context. Practices can, and should change as your business context does. There are some things that are net beneficial for a team in the majority of situations though, I'd consider code reviews one of these things and make that the default.
Yeah - in my experience 6-10 people per team is typical, often with one of them being dedicated QA. Having this, plus a separate central QA team is one way to address the pitfalls of embedded QA I was pointing out - they can cover for time away for team QA, or act as bench capacity.
A person doing manual testing, which is a gate to deployment would certainly be hard to make work for deploys as fast as you're targeting. It may still be valuable to have someone separate to the devs testing your product (in production, not as a gate to release) looking for things your automated testing, customer feedback or metrics may have missed. Whether this would be valuable is really context-dependent.
I agree, this all makes sense. Although I think the team-embedded QA is generally the right thing, I wouldn't use it blindly in all cases. Some teams I manage only produce HTTP API's, these are ideal candidates for automated testing (incl. end-to-end integrated tests) and the developers are happy to own this without a QA on the team.
I've also arrived at this approach and don't think it's that uncommon - IMO the article is presenting a false dichotomy.
There are still gotchas to look out for in the team-embedded QA approach. In typical team sizes, you often end up with only one QA per team - you need to make sure they have cover (everyone needs a break), and they need support in their discipline (do something to share QA knowledge across teams).
There is still competition to consider though. If a SaaS product has competitors that are more reliable, or more feature rich, they should win & retain more customers over time.
As a casual observer of self-driving, I feel like this is a really interesting part of the overall problem space. Until such time as a vehicle fleet is 100% autonomous, human piloted & autonomous vehicles need to co-exist. Humans bend & break driving rules by social interactions which autonomous vehicles don't currently participate in.
I’m a manager of ~25 developers (who report through a few leads). I also come from a dev background. IMO metrics are dangerous, but can also be useful. Often I find basic code metrics useful as smell tests, but would never use them alone, wouldn’t set them as goals, and wouldn’t use them alone to rank performance in a team.
If someone has a very low number of commits relative to others on their team, I’ll investigate deeper - review a few Pull Requests, check if they’re working on something outside source control etc. sometimes I find problems, other times not.
Several regional councils in New Zealand have also declared a "Climate Emergency" over the last year (e.g. https://www.stuff.co.nz/environment/climate-news/113747732/c...). I appreciate the sentiment, but fear that this amounts to little more than posturing when what we need is action.
This is not specific to Mavericks amongst “big wave” surf spots. Waves break as a function of swell period vs. ocean depth. More powerful (longer period) swell will break in deeper water, so in many places known for big waves, shorter period swell will just go right over and not break until closer to shore.
The first wave of tiny houses seemed to be mostly self-built and people had poured a lot of love & hours into construction. Then they were all over Instagram/Pinterest. This has paved the way for a second wave, where some occupiers aren't quite as enraptured: mass production (or at least not self-built), living this way by more by necessity than choice.
For use cases where this level of rigour is desired, it would be nice to have real separate metadata vs. convention. Doing this by convention is unreliable.
I can't see anything about this particular vehicle that would make it any more suitable to sell via subscription than any other EV (or indeed ICE). Wouldn't there be a greater chance of success if they focussed on one or the other: being a subscription car service OR an (electric) car maker?
I really love the whole story, especially the idea of the domain name being like the "starter sentence" in a creative writing course. Much has been written about constraints enhancing creativity.
In addition to the constraint of the domain name itself, the author also spent $17,949 (taking 6-9 months to repay) which would help constrain them to focus on just this one idea over that time.
I will admit to not actually looking at how third-party keyboards are implemented (specifically, how are security risks mitigated), but have always stayed away from them on instinct. For me, the potential value just doesn't outweigh risk.
If the effect of having plastic recycling collection is increased plastic consumption (less guilt “it gets recycled”), and our ability to recycle is as abysmal as is reported in many places... we may be better off stopping plastic recycling collection. We could then focus more on eliminating unwarranted usage and/or safe disposal.
For anyone looking to get involved but unsure how or where, try this too: http://worrydream.com/ClimateChange/. It's been posted before, but is a great starting point.
I’m all for the idea of incremental positive change. Yes, no individual person, city or country can fix this, but if our response to that is to be pessimistic, defeated and do nothing, then we all fail. Advocacy for cycling is one positive thing, and there are so many more.
In classic waterfall type process, big requirements/design docs were often not updated after initial creation, so were often wrong/misleading if you read them as a newcomer. Good doc seems to me more about values/competence of the team vs. which process they use.
I worked at a (big) company where this happened: Very expensive HQ offices built with policy that >= Director get private offices. Due to miscount, restructuring or some combination thereof there ended up being ~3 offices less than needed. "Fixed" with a policy change that only >= VP get private offices. This left a very large number of vacant offices and the HQ looking a ghost town.