HN user

mtabini

425 karma
Posts22
Comments37
View on HN
medium.com 5y ago

Noom’s Engineering Team Prepares for the Holidays

mtabini
20pts0
medium.com 5y ago

The Growth Machine: How Noom Runs 365 Landing Page Experiments per Year

mtabini
1pts0
medium.com 5y ago

Speed Up Your AB Tests with Shared Control Groups and Optimal Allocation

mtabini
10pts0
medium.com 6y ago

Too Cool for Rules: Engineering Principles for Software Development Teams

mtabini
17pts1
medium.com 6y ago

Bug-Free Code That Speaks for Itself: Principles of State Management

mtabini
20pts0
blog.tabini.ca 9y ago

How bandit testing really works

mtabini
2pts0
blog.tabini.ca 9y ago

The Importance of Being Idle

mtabini
2pts0
www.linkedin.com 10y ago

The three essential ingredients of a successful remote engineering team

mtabini
1pts0
github.com 11y ago

Show HN: Bowtie, a (hopefully) idiomatic HTTP middleware for Go

mtabini
7pts0
mobile.businessweek.com 11y ago

Tim Cook Speaks Up

mtabini
2pts0
blog.tabini.ca 11y ago

A look at the state of Apple's developer tools

mtabini
2pts0
math.stackexchange.com 12y ago

Why do 400k random picks from 400k samples always give 63% distinct results?

mtabini
1pts0
blog.tabini.ca 12y ago

You need math to program, and that's a good thing

mtabini
2pts0
telemetryapp.com 12y ago

Announcing our new time series partner

mtabini
3pts0
blog.tabini.ca 12y ago

A humble wishlist for Apple developer relations improvements

mtabini
1pts0
opinionator.blogs.nytimes.com 12y ago

Young Minds in Critical Condition

mtabini
1pts0
www.telemetryapp.com 12y ago

Dashboards on a stick: Now with more Chromecast

mtabini
11pts1
telemetryapp.com 12y ago

One dashboard to rule them all: Introducing Virtual Channels

mtabini
12pts5
blog.tabini.ca 12y ago

I am not an introvert. I am just busy

mtabini
298pts143
www.telemetryapp.com 12y ago

Replacing your daily e-mail reports with a realtime board

mtabini
1pts0
blog.tabini.ca 13y ago

You need math to be a good programmer, and that’s a good thing

mtabini
1pts1
vore.cc 14y ago

A note to language haters

mtabini
3pts9

It's hard to make a sweeping statement, but I can tell you that I more or less use USB-C exclusively in all my hardware designs now, and I've found that most of these “decoy boards” work well enough. The model I use[1] most often supports basic the USB-C protocol well, is easy to solder to (and remove from) an existing PCB, and is pretty robust.

I cannot stress enough how convenient being able to “plug and play” USB-PD power in an existing project is. Whenever I send a finished device to a client, I no longer have to worry about having to source a compatible power brick, or about them misplacing it. Not to mention that, for the simpler projects, I can literally get a 20W power puck from IKEA that has really good performance and costs all of $5 (Canadian). On top of that, if I find that I need more voltage, I can just change a jumper on the decoy board and I'm ready to go.

The only thing I wish more of these boards came with is better overcurrent protection; with PPS so common these days, it would be pretty easy to let the user choose an appropriate current cutoff. Oh well!

[1] https://www.amazon.ca/dp/B0CNVN1N3J?ref_=ppx_hzsearch_conn_d...

Thank you! No videos yet, though both I and out beta testers have used Dr. PD to troubleshoot a bunch of devices. One of our testers actually develops USB-C sources, so it was very interesting to interact with them (and they found oh-so-many bugs :-) ).

There are some screenshots of the UI on the Github page[1], and I wrote a little bit about trying to figure out the mess of USB-C cables that I have accumulated over the years[2] to see which supports what capabilities.

I think some videos are a great idea… now that the device is done and we're starting to send review units out, hopefully I will have some time to actually shoot them :-)

[1] https://hackaday.io/page/399874-silence-the-usb-c-cable-spea... [2] https://hackaday.io/page/399874-silence-the-usb-c-cable-spea...

Bit of self-promotion: I spent the last year or so designing an open-source USB-PD protocol analyzer[1], and the complexity of the protocol can be mind-boggling. Most of the time, the communication between source and sink is really straightforward, but it can get amazingly complicated when both devices are dual-role or come from the same vendor[2].

As messy as it is, however, it's also a very useful protocol that allows even small players to take advantage of the same economies of scale that large companies can take advantage of. Pity that the communication often requires dedicated chips, though thankfully those are relatively inexpensive. I was able to get an RP2350 (the same MCU that's in the Raspberry Pi Pico 2) to interface directly with USB-PD, but they could have made it easier and more accessible.

[1] https://github.com/T76-org/drpd or https://www.crowdsupply.com/t76-org/dr-pd [2] https://hackaday.io/page/399885-a-mac-and-an-ipad-walk-into-...

Not only that, but EPR contracts must be actively maintained in order to remain in effect. The sink needs to send a ping to the source every ~500ms, or the source pops out of EPR mode and forces a renegotiation. This ensures that, if the sink crashes, the source doesn't keep pumping power into a device that can't take it anymore.

Can I offer a counterpoint? Much like OG USB put a 5V supply within everyone's reach, USB-PD has made programmable, higher power supplies available to everyone. That's a big deal, because PSUs are an expensive portion of a product, especially for small manufacturers and hobbyists. Having a dedicated standard that supports multiple voltages and currents allows small players to take advantage of the same economies of scale as the largest electronics manufacturers.

Case in point, IKEA will happily sell you a very well built 20W power supply that provides 5, 9, 12, or 15V for less than $5 here in Canada, and you can get a similar price from legitimate Asian distributors, even when buying in limited quantities. If you're working on a small-batch electronic product, that's a boon to your BOM; if you had to go out and source a dedicated barrel-jack PSU with the same capabilities, it'd cost much more, and you don't know what kind of quality you'd be getting.

Where the standard really falls on its face, IMO, is in its opacity. You can get a chip that does the PD negotiation for pennies, but there is no way to inspect the protocol without shelling out thousands for a dedicated analyzer, so when things don't work, it's really hard to troubleshoot the reason.

(Disclaimer: I'm working on an open-source protocol analyzer, so this probably colours my view on the matter a little.)

USB-PD 3.1 provides both a Get_Battery_Cap message, which asks the sink to tell the source the capacity of its battery) and a Get_Battery_Status message, which asks the sink to inform the source about the current charge of its battery.

Here's an example capture of an exchange between my MacBook Pro and iPad: https://imgur.com/a/8rZlN9X

The iPad responds to Get_Battery_Cap with Battery_Capabilities, which reports the total capacity in Wh:

USB Vendor ID: 0x05AC Product ID: 0x0000 Design capacity: 280 Last full-charge capacity: 280 Battery reference: valid

And then when the MBP asks for battery status, the iPad returns a Battery_Status message:

Battery is present. Present capacity: 14.2Wh Charging state: charging.

Later on, as the charging continues, the iPad will issue an Alert message:

Reported alerts: Battery status changed. Affected batteries: Fixed battery slots: 1

And then the MBP will send a Get_Battery_Status again, and so on. (Example capture here: https://imgur.com/a/TI5maV0

What's really cool is that this exchange happens both ways—the iPad also sends a Get_Battery_Cap message to the MBP, because it is also capable of acting as a source, and, if the laptop's battery drops sufficiently low, the source/sink roles may swap (using a DR_Swap message) so that the iPad ends up charging the MBP!

https://www.crowdsupply.com/t76-org/dr-pd

Dr. PD is an open-source USB-C Power Delivery analyzer and programmable sink. It can sit inline between a USB-PD source and sink to show you the communication between them, or connect directly to a source and emulate a sink so you can characterize chargers and power supplies.

The goal of the project is to make serious USB-PD analysis more accessible. The hardware, firmware, and host software are all open source. The control software runs locally in Chrome or Edge with no drivers or installation required, and the platform also provides Python, JavaScript, SCPI, and USBTMC interfaces for automation.

(Sorry that I don't have a link to the GH repo yet, but you can follow the project on https://hackaday.io/project/205495-dr-pd. Also, if you read this far, I'm looking for a few beta testers. Reach out if you're interested!)

Noom | Senior Data Science/Full Stack/Backend/Android/iOS/QA positions | REMOTE or HQ | FULL-TIME | https://noom.com

At Noom, we use scientifically-proven methods to help users get a handle on chronic medical conditions like obesity, diabetes, and heart disease. We use a variety of technologies, and get to work on hard problems that range from data warehousing to running experiments on mobile devices.

Our engineering team is expanding, and we have openings for a number of positions that include backend and mobile engineering. Our offices are in NYC, but we are a remote-first organization (some 90% of our team is remote) and are happy to consider candidates anywhere.

Here are some links where you can apply:

- Sr Data Scientist - https://grnh.se/2850e1a91

- Sr Full Stack Engineer - https://grnh.se/4cd542051

- Sr Backend Engineer - https://grnh.se/bcdd69491

- Sr iOS Engineer - https://grnh.se/8009698e1

- Sr Android Engineer - https://grnh.se/ff4d1d451

- Mobile QA Automation Engineer - https://grnh.se/1677c07a1

Our stack includes Python, React, Kotlin, Swift, and Go, all hosted on AWS.

I'm Noom's VP of Engineering -- feel free to drop me a note if you have questions; I'm mt at noom dot com.

Noom | Senior Data Science/Full Stack/Backend/Android/iOS/QA positions | NYC or REMOTE | FULLTIME | https://noom.com

At Noom, we use scientifically-proven methods to help users get a handle on chronic medical conditions like obesity, diabetes, and heart disease. We use a variety of technologies, and get to work on hard problems that range from data warehousing to running experiments on mobile devices.

Our engineering team is expanding, and we have openings for a number of positions that include backend and mobile engineering. Our offices are in NYC, but we are a remote-first organization (some 90% of our team is remote) and are happy to consider candidates anywhere.

Here are some links where you can apply:

- Sr Data Scientist - https://grnh.se/2850e1a91

- Sr Full Stack Engineer - https://grnh.se/4cd542051

- Sr Backend Engineer - https://grnh.se/bcdd69491

- Sr iOS Engineer - https://grnh.se/8009698e1

- Sr Android Engineer - https://grnh.se/ff4d1d451

- Mobile QA Automation Engineer - https://grnh.se/1677c07a1

Our stack includes Python, React, Kotlin, Swift, and Go, all hosted on AWS.

I'm Noom's VP of Engineering -- feel free to drop me a note if you have questions; I'm mt at noom dot com.

Noom | Data/Backend/Android/iOS/Staff positions from Jr. to Director | NYC or REMOTE | FULLTIME | https://noom.com

At Noom, we use scientifically-proven methods to help users get a handle on chronic medical conditions like obesity, diabetes, and heart disease. We use a variety of technologies, and get to work on hard problems that range from data warehousing to running experiments on mobile devices.

Our engineering team is expanding, and we have openings for a number of positions that include backend and mobile engineering. Our offices are in NYC, but we are a remote-first organization (some 90% of our team is remote) and are happy to consider candidates anywhere.

Here are some links where you can apply:

- Dir of Data and Platform Engineering - https://grnh.se/ce83d4a91

- Data Engineer - https://grnh.se/fa9f2f811

- Full Stack Engineer - https://grnh.se/7ee80e091

- Staff Engineer - https://grnh.se/1c6640381

- Sr Android Engineer - https://grnh.se/98b810ee1

- Sr iOS Engineer - https://grnh.se/1de847dc1

- Sr FrontEnd Engineer - https://grnh.se/e06087021

- Sr Backend Engineer - https://grnh.se/1c8844bb1

Our stack includes Python, React, Java, and Go, all hosted on AWS.

I'm Noom's VP of Engineering -- feel free to drop me a note if you have questions; I'm mt at noom dot com.

Noom | Data Engineer, Staff Engineer, Sr. Android Engineer | NYC or REMOTE | FULLTIME | https://noom.com

At Noom, we use scientifically-proven methods to help users get a handle on chronic medical conditions like obesity, diabetes, and heart disease. We use a variety of technologies, and get to work on hard problems that range from data warehousing to running experiments on mobile devices.

Our engineering team is expanding, and we have openings for a number of positions that include backend and mobile engineering. Our offices are in NYC, but we are a remote-first organization (some 90% of our team is remote) and are happy to consider candidates anywhere.

Here are some links where you can apply:

- Data Engineer - https://grnh.se/fa9f2f811

- Staff Engineer - https://grnh.se/1c6640381

- Sr. Android Engineer - https://grnh.se/98b810ee1

Our stack includes Python, React, Java, and Go, all hosted on AWS.

I'm Noom's VP of Engineering -- feel free to drop me a note if you have question; I'm mt at noom dot com.

Noom | Fullstack, Frontend, DevOps, QA | NYC or REMOTE | FULLTIME | https://noom.com

At Noom, we use scientifically-proven methods to help users get a handle on chronic medical conditions like obesity, diabetes, and heart disease. We use a variety of technologies, and get to work on hard problems that range from data warehousing to running experiments on mobile devices.

Our entire engineering team is expanding, and we have openings for a number of positions that include backend and frontend engineering, data analysis, and product management. Our offices are in NYC, but we are a remote-friendly organization (some 90% of our team is remote) and are happy to consider candidates anywhere.

Here are some links where you can apply:

- Dev Ops engineer - https://grnh.se/c1da8a701

- Full Stack engineer - https://grnh.se/3f36d0b01

- Sr Front End engineer - https://grnh.se/f0a3b8271

- Data Engineer - https://grnh.se/17738f841

- Sr Technical Program Manager - https://grnh.se/94cc07e01

- Sr Product Manager - https://grnh.se/5fd621321

Our stack includes Python, React, Java, and Go, all hosted on AWS.

I'm Noom's VP of Engineering -- feel free to drop me a note if you have question; I'm mt at noom dot com.

Noom | Fullstack, Frontend, DevOps, QA | NYC or REMOTE | FULLTIME | https://noom.com

At Noom, we use scientifically-proven methods to help users get a handle on chronic medical conditions like obesity, diabetes, and heart disease. We use a variety of technologies, and get to work on hard problems that range from data warehousing to running experiments on mobile devices.

Our entire engineering team is expanding, and we have openings for a number of positions that include backend and frontend engineering, data analysis, and product management. Our offices are in NYC, but we are a remote-friendly organization (some 90% of our team is remote) and are happy to consider candidates anywhere.

Here are some links where you can apply:

- Fullstack: https://grnh.se/3f36d0b01

- Sr. Frontend: https://grnh.se/f0a3b8271

- DevOps: https://grnh.se/c1da8a701

- QA Analyst: https://grnh.se/b56b27e51

Our stack includes Python, React, Java, and Go, all hosted on AWS.

I'm Noom's VP of Engineering -- feel free to drop me a note if you have question; I'm mt at noom dot com.

Noom | Fullstack, Backend, Android | NYC or REMOTE | FULLTIME | https://noom.com At Noom, we use scientifically-proven methods to help users get a handle on chronic medical conditions like obesity, diabetes, and heart disease. We use a variety of technologies, and get to work on hard problems that range from data warehousing to running experiments on mobile devices.

Our entire engineering team is expanding, and we have openings for a number of position that range from frontend to backend work. Our offices are in NYC, but we are a remote-friendly organization (half of our engineering team is remote) and are happy to consider candidates from anywhere.

You can see our openings (alongside a brief description of some of our perks, like our on-site chef, flex hours, and much more) at https://www.noom.com/careers-listings/?department=engineerin...

I'm Noom's VP of Engineering -- feel free to drop me a note if you have question at mt at noom dot com.

Noom | Fullstack, Backend, iOS, Data Analysis, Product Management | NYC or REMOTE | FULLTIME | https://noom.com

At Noom, we use scientifically-proven methods to help users get a handle on chronic medical conditions like obesity, diabetes, and heart disease. We use a variety of technologies, and get to work on hard problems that range from data warehousing to running experiments on mobile devices.

Our entire engineering team is expanding, and we have openings for a number of position that include backend and frontend engineering, data analysis, and product management. Our offices are in NYC, but we are a remote-friendly organization (some 90% of our team is remote) and are happy to consider candidates anywhere.

You can see our openings (alongside a brief description of some of our perks, like our on-site chef, flex hours, and much more) at https://www.noom.com/careers-listings/?department=engineerin....

I'm Noom's VP of Engineering -- feel free to drop me a note if you have question at mt at noom dot com.

Noom | Fullstack, Backend, iOS | NYC or REMOTE | FULLTIME | https://noom.com

At Noom, we use scientifically-proven methods to help users get a handle on chronic medical conditions like obesity, diabetes, and heart disease. We use a variety of technologies, and get to work on hard problems that range from data warehousing to running experiments on mobile devices.

Our entire engineering team is expanding, and we have openings for a number of position that range from frontend to backend work. Our offices are in NYC, but we are a remote-friendly organization and are happy to consider candidates from anywhere.

You can see our openings (alongside a brief description of some of our perks, like our on-site chef, flex hours, and much more) at https://www.noom.com/careers-listings/?department=engineerin....

I'm Noom's VP of Engineering -- feel free to drop me a note if you have question at mt at noom dot com.

[dead] 10 years ago

I'm impressed with the clarity of the interview. As it happens, the host sounds like he's been doing radio for many years. I predict this year more radio professionals start to jump ship from radio into podcasting.

I have to agree and this is the main reason why I went extreme and deleted my profile. My life was at a low point and seeing everybody's high point of the day made it even worse; it was a decision that took less than a second and 90 seconds later my profile was deleted. To be honest, I regret it a bit now.

The Muse | Fullstack Engineer, Data Engineer | New York City, Remote, Visa | Full-time | NYC

At The Muse, we offer advice, coaching, and a job experience that's actually engaging and doesn't suck; we reach millions of users every month with an engineering approach that is grounded in data analysis and best practices.

We're looking for full-stack and data engineers. For more info, drop me an e-mail at marco@themuse.com, or apply here:

https://www.themuse.com/jobs?company=The%20Muse&filter=true&....

We use a number of technologies like Python 3, Tornado, Go, React, but are happy to consider engineers with experience in Rails, Java, devops and data platforms like Redshift, PostgreSQL, and ElasticSearch.

Our engineering team is growing all the time, with plenty of opportunities for leadership and mentorship roles, funding for conferences and training, or to pick up new skills if that interests you.

We frequently contribute to open-source, give our engineers a great deal of agency in picking the problems they want to work on, and have a strict no-asshole policy.

why should I read?

Because reading is not just a utilitarian activity. Reading widely—things that may not be immediately useful, things that may be against your belief, things that may just turn out to be completely wrong—is an important step towards forming a critical appreciation of anything you may encounter.

Personally, I've long come to realize that much of my attitude towards everything from work to politics has been shaped by reading materials that often covered wholly unrelated topics. More importantly (and much to my chagrin), it seems that many crucial lessons came from works that I outright hated and was forced to drudge through against my will.

I don't mean to discount your conclusion: Almost always, almost everybody doesn't know what they're talking about. But almost always, almost everybody is a little right, and bits and pieces you pick up from the most unusual places will inform your solution to a problem many years down the road, or at least remind you that every story has more than one side.

The Muse | NYC | Fullstack, Backend (onsite or remote) | Frontend, BI (onsite only)

At The Muse, we offer advice, coaching, and a job experience that's actually engaging and doesn't suck; we reach millions of users every month with an engineering approach that is grounded in data analysis and best practices.

We're looking for engineers across our entire stack—backend, full stack, and frontend. For more info, drop me an e-mail at marco@themuse.com, or apply here:

https://www.themuse.com/jobs?company=The%20Muse&filter=true&...

We use a microservice infrastructure based on Python 3 and Tornado, Mithril, and CoffeeScript. We are happy to consider engineers with experience in Rails, Java, and Go, as well as devops and data science specialists.

Our engineering team is growing all the time, with plenty of opportunities for leadership and mentorship roles, or to pick up new skills if that interests you. We frequently contribute to open-source, give our engineers a great deal of agency in picking the problems they want to work on, and have a strict no-asshole policy.

The Muse | NYC (onsite, remote, visa)

At The Muse, we offer advice, coaching, and a job experience that's actually engaging and doesn't suck; we reach millions of users every month with an engineering approach that is grounded in data analysis and best practices.

We're looking for engineers across our entire stack—backend, full stack, and frontend. For more info, drop me an e-mail at marco@themuse.com, or apply here:

https://www.themuse.com/jobs?company=The%20Muse&filter=true&...

We use a microservice infrastructure based on Python 3 and Tornado, Mithril, and CoffeeScript. We are happy to consider engineers with experience in Rails, Java, and Go, as well as devops and data science specialists.

Our engineering team is growing all the time, with plenty of opportunities for leadership and mentorship roles, or to pick up new skills if that interests you. We frequently contribute to open-source, give our engineers a great deal of agency in picking the problems they want to work on, and have a strict no-asshole policy.

In no particular order:

1. Listen before you speak. The people you manage are prone to giving your opinion more weight than it deserves.

2. Give your subordinates problems, not solutions. People like to own a task, not to be told what to do; treating them like adults and professionals empowers them and brings out their potential. Besides, if one person only ever makes all the decisions, no decision can be better than that one person's knowledge. If you're afraid of delegation, institute a tight review loop to ensure that people don't go off-track.

3. You're a facilitator, not a doer. People will come to you with their problems, and you must be available at all times to help them through it. As someone else has pointed out, your productivity is secondary to that of the team. It's your job, among other things, to ensure that your team has a good working environment, including good tools, practices, and access to uninterrupted “flow” time.

4. Be aware of politics. The moment you manage a team, politics become a part of your daily job. This is not a bad thing—“politics” just means managing interpersonal relations; it becomes a bad thing when you ignore it.

5. Never be in a position to take. Success belongs to your teammates; failure is all yours.

6. Face problems head-on. People don't like confrontation, and let problems fester until it's too late to fix them. Instead, provide frequent one-on-one time with all your teammates, exhort them to confide in you, and show them that you're trustworthy. Also see #1.

7. Offer clarity. Explain what you expect others to do in a measurable way to make it possible for both you and your team to understand how well everyone is doing. You can use a method like OKR[0] to track your goals internally.

[0] https://en.wikipedia.org/wiki/OKR

Won't nail down the customer's actual problem, describe it clearly to you and let you come up with a solution. They will just pass on the customer's proposed solution and insist that you build it.

It's actually a bit worse than that. Customers almost never know their problems; instead, they understand their problems through the accumulated knowledge of their profession, and have a very hard time stepping out of “the way things are done” to nail down their ultimate goals.

One of our biggest challenges as developers is that software engineering is very much a meta-profession: Being fully competent in computer science is only useful if you can apply that competence to real-world problems, and that inevitably means having to become expert enough in a field to which you may never have had any exposure.

A good PM understands this and turns development into an iterative process in a tight loop with customer feedback: You push the project forward a little, check with customers, apply their feedback, and lather-rinse-repeat until you've come up with a good solution—one that typically innovates on the status quo.

A bad PM tries to spec everything ahead of schedule and never really gets off the ground, her best possible outcome being automating existing processes at the tail end of a waterfall-induced nightmare.

A worse PM is overwhelmed and avoids nailing down details, seeks no customer involvement, and leaves things to fester for weeks without any feedback. I don't know anyone who enjoys being on the poor team tasked with dealing with that kind of work.

Incidentally, this is what I've always taken agile development to mean: It's not about stand-ups and kanban boards, but rather about acknowledging and embracing the fact that programming is an inherently inexact science.

I don't think this has necessarily anything to do with engineering competence.

From a business perspective, security isn't a marketable feature until it becomes a problem—you don't install safety belts, or airbags, or protection against malware until after people start suffering from their absence in a vehicle.

Why? Because while you're busy building a well-secured system, your competitors are busy implementing new features that give them an actual advantage in the marketplace. As unfortunate as it might be, consumers tend to understand things like “remotely start your car with your phone” better than “your ability to brake won't be taken away from you while you're barrelling down the highway at 70 mph.”

It's sad and more than a little scary, but it's also nothing really new. Computer security, at least in the consumer sector, wasn't really a feature until viruses started showing up in the Eighties, and Internet security wasn't really a feature until the average Windows user's PC was getting taken over remotely the moment it was connected to the Net. Even Apple has only been able to tout security and privacy as a feature in its products by juxtaposing it to Google's business model—had the latter not existed and its data grab become part of public discourse, I doubt that Cupertino would have been able to make so much noise about it.

So, it's perfectly possible that every engineer and manager who worked on these systems is really quite competent and perfectly aware of the potential for security flaws (indeed, I doubt that they would have been able to make something so complex work otherwise), and still the sum of all the decisions made and market pressures applied caused the resulting product to be so vulnerable despite everyone's best intentions. It's not because people don't care or don't know, but rather because there are only so many resources available, and the market has pushed them all in a specific direction that happens to be away from security.

But this is also why we need this kind of research. Now that these problems are out in the open, and politicians are starting to take notice, security will become a feature that the public will care about, and, hopefully, car manufacturers will start adopting (or be forced to adopt) better standards.

Cost follows complexity, even if it's not always immediately obvious.

A 1TB RAM server is more expensive than 10x 100GB RAM servers, but the hardware cost is often small compared to the business and technical cost of getting a solution to scale across a cluster.

Of course, generalizations are always dangerous—the take-home point here is perhaps that before going to a cluster because “that's the way big data is handled,” it's a good idea to do a proper cost-benefit analysis.

Letting third parties do the hard work of experimenting with user acquisition and engagement, then buying up the best and turning their backs on the rest was a masterful move.

It would have been if you assume that Twitter could thrive on its own. Since they have historically relied on third parties to push their product forward, and then cut them off at the knee, they should have been prepared for the inevitable stagnation that followed, and perhaps they weren't.

The masterful move would have been to carefully augment the base functionality offered by Twitter while encouraging the third-party ecosystem to continue to grow and thrive.

You can see, for example, Apple do this with iOS (albeit at times with a ham-fisted approach) by incorporating some—but by no means all—of the features that third parties come up with into the base OS.

This encourages third parties to continue to participate in the ecosystem while gently nudging them towards innovating instead of stagnating, because that's the only way they will be able to compete with the “free” Apple-provided software and make money.

Twitter was in the somewhat unfortunate position that it was born as a wide-open system that had little in the way of walls, leaving the new management with few options to gain more control over their product but to start restricting what could be done with it.

Instead of recognizing the value of third-parties and commoditizing their complements, though, they went all-out and systematically alienated anyone who wanted to share in their good fortunes. They placed their focus on attracting celebrities and brands (remember when Ev was “excited” that Oprah was joining?) and attempted to create a friendly environment for the average consumer by tightly controlling the user experience.

In itself, I don't think that this is a bad idea—Facebook has done it quite successfully, for example. Twitter's problem is simply that they are about to run out of innovation to acquire because there are no more small timers left who are willing and capable to take a risk on their platform and come up with some unexpected new feature that could later be integrated into product proper.

I would only go to your competitor if you have a really good relationship with them, and you know that your report won't be taken as a threat.

If you don't, you're exposing yourself to many problems for very little upside, and my experience is that, when cornered, most people don't tend to react in a reasonable and logical manner (or even in a manner that caters to their own interests). For example, the competitor could accuse you to have came across this information illegally (whether you did or not in the eyes of the law is irrelevant: once you're faced with a lawsuit, your best likely outcome is that you will only have to pay your lawyer's bills); or, they could think you're preemptively covering your ass before starting a smear campaign against them, and beat you to the punch with accusations and threats of their own, and so on.

On the other hand, as some have pointed out, this is a good marketing opportunity for you—you just need to be careful how you use the information. I would, however, avoid making _any_ references to competitors (even indirectly by referring to “our competitors”), because you don't want to be petty, and you also don't want to ever have to answer the question “Who are these competitors of yours?” in front of a court stenographer.

You do not mention if the PCI violations could flow through to your competitor's clients; are the credit cards those that customers use to pay for the competitor's SaaS, or are they stored on behalf of customers to provide the service itself (e.g.: the way, say, Stripe stores your customers card data for you)? A breach that leaks credit card data in this case would be catastrophic not just for you, but for your customers as well—and these are consequences that have a material impact on the quality of your product over your competitors'.

From a marketing viewpoint, keep in mind that the value this piece of intel is also likely to be proportional to the sophistication of a prospective customer. A potential large client that could is more likely to be sensitive to something like PCI than small fish, and knowing that you can plant the bug in their ear that your competitors might not be as up-to-date on PCI as you are could make the difference between a sale and a missed opportunity.