This article does not make convincing arguments to match the strong criticism. Engineering decisions are difficult, especially in high-growth orgs, where one must balance many constraints and risks including opportunity cost. Handling payments is part of Uber's core product.
The financial criticism ('napkin math') appears to estimate DynamoDB costs of USD $8 million for 2017 to 2020. Uber revenue for the same period is roughly USD $42.5 billion, thus this cost weighs in at about 0.02%, or 1/50th of one percent. This is a rounding error for a high growth company, and not something that warrants a witch-hunt and firing. It's easy to blow more than $2 million per year on software engineers in pursuit of an alternative high-scalability solution.
I'm also not on board with the 'resume driven development' criticism as the explanation for solution churn. Perhaps that is actually what happened. I wasn't there and don't know, but if that is being asserted I expect to see evidence presented to support it.
The main site was replaced with a mostly empty blank page earlier today.
The bizarre thing was that the page source at that time had almost nothing except some odd javascript to build a "508 Daily Report" table of Jira tickets or some nonsense.
Taking this concept further one could model in RAML [0] to define both the types (flat or nested) and api definitions. It's based on YAML 1.2 with enough maturity to provide capabilities such as union types, extensions, includes, user-defined facets, etc.
The AMF project [1] can be used to parse and transform to/from RAML, OpenAPI, GraphQL, and json schema. Code generation to languages of choice can be bolted on from there.
I'm using this approach to define canonical data models. Subsequent code generation scaffolds internal application integration apis, master data management (MDM) entities, and SQL/OLAP artifacts for ETL / BI purposes.
This approach keeps overall end-to-end data architecture consistent, in sync, and versioned under source control. Additionally, flat types as required by relational systems are re-used and composed into nested complex types more appropriate for apis. Metadata is layered on as needed to refine the models for system-specific needs, for example to add user-facing field groups, descriptions, and formats for BI datasets, sensitivity levels and other data security controls, business rule definitions for MDM, etc.
I miss electronics retail, even with its issues. Radio Shack had the Forrest Mims engineer's notebooks for learning electronics, and it was great to be able to drive down to a Fry's to pick up a component that you needed in a hurry on a weekend.
Shout out to Anchor Electronics in Santa Clara, San Mateo Electronics Supply, and of course Jameco, which are still alive.
I'm also lamenting the loss of SF Bay area electronics surplus: Weird Stuff, Halted/HSC, and the latest casualty, Excess Solutions. Is there any place left around here to find used/surplus electronics?
One of my favorite economics professors called the second one 'OBSCENE PROFITS!'. His vocal delivery of those two words in front of the class was always highly animated and packed full of energy.
It is intuitive that, as soon as enterprising individuals catch wind of high profits being made somewhere, there will be an inrush of competitors looking to seize their share, which then continues until until some type of equilibrium is reached.
The fundamental breakdown in this type of efficient market mechanism is that it requires a reasonably level playing field: referees and rules. Complex systems without adequate regulation may result in local optima one or a few participants, who achieve regulatory capture, externalize costs, or achieve monopoly, oligopoly, or similar advantage to the disadvantage of all others. Regulation is required to achieve the global optimum for the wider group (i.e. society).
Cancer is an a example of a biological system exhibiting high growth with broken mechanisms of regulation. Similar outcomes can be observed when there is a disruption to a predator population, leading to an explosion of prey species, resulting in an ecosystem that is overrun and exhausted until balance returns.
One initial reaction to the prompting style is how similar it is to a human-to-human interaction. For example, a team lead communicating requirements to a wider team composed of less experienced engineers may also follow this type of iterative exchange, continuing until he or she is satisfied that the team understands the work to be done and has the guide rails to be successful.
I recently heard a description about the way this technology will change technical work that resonated: we will become more like the movie director, and less like the actors.
My understanding is that relocation assistance is not available for this position. I will double-check to be sure, and if it is now offered I will reply here.
XL Construction is an award-winning Northern California general contractor/builder, consistently voted as one of the best places to work in the Bay Area by the San Francisco Business Times / Silicon Valley Business Journal, and is ranked as the fourth largest GC in the Bay Area as of last month.
We are in the early stages of executing a long-term enterprise-wide data strategy and this role is key.
XL is seeking an individual with 5 years of application integration development experience with Mulesoft or similar, and a commitment to software engineering best practices in a team environment. We run a modern suite of applications so you won't have to fight crusty, antiquated, and temperamental APIs and can better enjoy the satisfaction of getting information flowing.
I am XL's interim data architect and look forward building great things together.
Please review the full job posting [0] and apply there if you are the one. Reply here if you'd like to give me a head's up.
The financial criticism ('napkin math') appears to estimate DynamoDB costs of USD $8 million for 2017 to 2020. Uber revenue for the same period is roughly USD $42.5 billion, thus this cost weighs in at about 0.02%, or 1/50th of one percent. This is a rounding error for a high growth company, and not something that warrants a witch-hunt and firing. It's easy to blow more than $2 million per year on software engineers in pursuit of an alternative high-scalability solution.
I'm also not on board with the 'resume driven development' criticism as the explanation for solution churn. Perhaps that is actually what happened. I wasn't there and don't know, but if that is being asserted I expect to see evidence presented to support it.