Google. monorepo with almost full visibility, code search/cross referencing/review tools, good infrastructure support, great videoconference and collaboration tools, a culture of written knowledge vs. oral lore, clear strategy in many parts of the business (loosely coupled, tightly aligned). Perks, pay, vacation are excellent. Work life balance is generally good. World experts in relevant subject matter are never far away.
The things you mentioned are mostly true, however the technical culture is very reactionary and the promo process rewards worse engineers on average in my experience. Most of the better engineers I knew there ended up leaving after a while.
Did you work there? The promo process, especially at the higher levels, does reward ability-to-explain-and-contextualize over pure technical ability, but my opinion is that senior engineers need more of the former than the latter anyways. Deeply understanding your product and what is necessary to make it better can be more important than the ability to pump out algorithms and models.
I recommend reading the Cliff Notes for "The Origin of Wealth" (the full book is just too damn long). Sometimes product designs with a devout following still fail the product market fit test. Trying a bunch of things to see what sticks is a pretty valid strategy, it's what nature does. Steve Jobs would just convince you of your folly for wanting anything but a one button mouse, but Eric, Larry, and Sergey would offer you mice with 1-10 buttons, hover mice, eyeball tracking systems that act as mice, a laser pointer mouse, etc. Each is a small fixed cost and if there's product market fit, the winning variant pays for all the others...
Basically, yes; that is, their strategy is not to avoid taking multiple simultaneous efforts at solving the same broad class of problem, even if it is one where in the long term there is unlikely to be a reason to keep multiple solutions, and they also aren't afraid to take stabs at solving problems where they need a solution to exist but don't strategically need to own the solution.
These strategic choices give them the best chances of having a viable solution either for the market as a supplier or for themselves as a user when they need it, but also makes the number of failed efforts they are going to need to kill higher than it would otherwise be. Or, in short, the strategy creates corpses.
I ask if a company uses a monorepo as one of the ways to decide to pass on them if they do. Definitely not an indicator of good engineering practices in my opinion.
One of my former bosses was an ex-Google manager and had the same opinion. I guess Google's monorepo grew out of a historical accident from their early customizations of Perforce, and had nothing to do with any supposed engineering benefits that are used to rationalize it now. Then other companies adopted it for the same shallow cargo-cult copying reasons they also use Google's interview hazing approach. And it became an empty marketing icon, e.g. with the ACM article on monorepos.
Any more, I think monorepo vs. project repos is just a bunch of bikeshedding, and the real value of a monorepo is easier centralized surveillance. I grant this might be an important priority for megacorps, but it still doesn't mean it has anything to do with good engineering practices or culture.
- search engine and combined family of backend and web services for search features (autocomplete, image search, machine translation, session-based personalization, etc.) at an online ecommerce site with a top 300 alexa rank
- legacy code base for large-scale integrated air defense system simulations at a research lab (code spanned from 80s to 00s)
Both projects well into the tens of millions of lines of source code, much of it old FORTRAN and C in the IADS codebase, requiring us to maintain old compiler toolchains, etc.
The defense simulation stuff was one centralized repo for security purposes, with lots of bespoke extra pieces of code on this researcher’s machine or that researcher’s machine. It was exceedingly hard to work with, but obviously is not a fair comparison to a large tech company which has 1-2 orders of magnitude more code and has customized tooling for it.
The search engine codebase was split into over a hundred different component-specific git repos, and despite the occasional CI headaches, was a joy to work with because component vcs history and project workflows were so well separated.
Basically, if you have to deal with local time, this isn't the language for you. If you expect to be able to add to the platform where you find it lacking, this isn't the language for you.
At this point, Typescript has the momentum to make it irrelevant
I've used both heavily. I think paradigm is the key word if you're thinking mind-expanding properties. While immutable types and combinators are less used in Typescript (you've got me there) you can certainly get 80% of the value of strong typing, and there are several variants of Virtual DOM support.
Elm's error messages and semantic versioning are still a class above anything else, though. Sad to see it rotting on the vine like this.
The roadmap priorities always baffled me too.
I mean, what elm needs now to be usable is surely not code splitting... Almost no one really need that, it's a late optimisation for top sites.
It makes sense if their strategy is to try to get at least one of said "top sites" to adopt them—which might, after all, result in development being sponsored or supported by full-time employees of whichever bigcorp runs the site.
How can you blame them? They're playing by the rules, the same rules their competitors play by (Google also uses the double Irish). In that context, isn't it far better to pay single digit interest rates on money when you're backstopping it with overseas cash rather than taking a 35% haircut to repatriate the same? Finally, what odds do you place on the one time transfer of $88B to the US government with a love note ACTUALLY resulting in a better quality of life for US citizens? It seems to me that regardless of regressive policies and hero projects like walls and Mars trips, monetary policy is still trying to get people and companies to reinvest to spur growth vs. sitting on savings.
Also, let's not forget that the offshore pile of money has already been taxed in jurisdictions where it was earned. The world is slightly bigger than US. If Apple sells an iPhone in Germany it pays taxes in Germany. It is a bit silly to then send the money home and pay another huge tax on top of it!
Yes, I'm aware that thanks to various tax shenanigans the offshore tax bill might be artificially low. If that was the case though, Apple would've cheated local governments and not the US government.
As I've mentioned in my comment "thanks to various tax shenanigans the offshore tax bill might be artificially low". It would be up to New Zealand to investigate and make sure Apple pays it's due. But I don't see why US needs a slice of that particular pie.
I can't help but rejoice at the title of this article. I own a BlackBerry Passport and the hardware is phenomenal, but the OS seems designed to put the company out of business. Side-loading APKs is a terrible consumer experience, and as interesting as the Hub concept is, in practice I don't prioritize Foursquare updates the way I prioritize SMS or work email! Gmail and Inbox don't run, Acompli crashes on startup, and Mailbox has unreliable interaction glitches. The Calendar app is frequently outright wrong! The folks saying "another android phone" truly don't get it: the last great keyboard phone was the Droid 4, a slider that's years old and definitely does not have a capacitive keyboard.
I've run into some small issues, but I my Passport is the best phone I've owned; I'm a convert from Android. I think the hardware and the OS are both fantastic; better UX and more stable than my Google Nexus.
Sorry to hear that you have had so many issues, though. I mostly use Hub (primarily text), the fantastic Browser, PDF reader, calls, mobile Hotspot/tethering, and several apps (mostly native).
>as interesting as the Hub concept is, in practice I don't prioritize Foursquare updates the way I prioritize SMS or work email!
A couple things to try: in the Hub, click the menu button in the bottom right corner "..." and select "Settings". Turn on "Priority Hub" and you'll get an additional folder in the Hub for messages that match your priority criteria. Also, under "Hub Management", you can set each account integrated within the Hub to display notifications exclusively in the main Hub folder, the account-specific folder, or both.
My wife works on the playgrounds in Central Park and tells me that monkey bars with over 9 feet of fall height and kids on tire swings right below them (which I cringe at as "collateral damage") are, indeed, a thing of the past. But many beloved spaces are receiving redesigns with the original creative vision in mind -- but also years of community feedback to benefit from. These are some of the most trafficked spaces on earth. From the outside looking in, the Conservancy has always struck me as a great institution; they strive for creative excellence while still seeking to understand the unique needs and constraints that come with maintaining an island of public space in the densest city in America. Just like our industry, great engineering is the art of careful compromise. The fact that it's not one big rubberized parking lot with legal disclaimers posted is a huge testament to their creativity and humanity.
Vendoring always seemed a bit gross to me. On one hand it makes it possible to avoid build breakages when doing "go get" from master, but on the other hand it makes keeping up with master more difficult as it disassociates you from the source.
I think when multiple projects involve vendoring we will end up with cuts at arbitrary places in our dependency graphs, and knowledge and manual intervention will be required to sync with modern/bug-fixed implementations.
Someone gave me a good piece of advice on ethics once: if it's a problem when everyone does it, it's probably unethical.
In this case we want to make life easier on our users, but from those good intentions we may actually make an ecosystem where everyone is less efficient...
I would personally rather intervene once to lock the entire transitive closure in a buildable state rather than manually find and update all vendored cuts in the graph.
The plot will thicken with http://golang.org/s/go1.4-generate as I suspect the generate step will frequently refer to things in $GOPATH/bin.
It's a bit more nuanced than the no-pain-no-gain attitude toward exercise, too. We are fond of the saying, "worksheets don't build dendrites" around here.
I think many institutions are set up as human proof-of-work verification machines, when they should be set up as human brain debuggers. Debuggers show you counter-examples to your mental model. You set the goals and drive the process.
They are one tool, but not sufficient for a real education. For instance, I doubt you could effectively teach social and emotional development in early childhood using a web portal.
I think the problem is a lack of understanding who the customer is.
Many schools make centralized decisions: you either sell the school board or the IT department or both. The people stuck with the decision aren't the people you need to convince for a conversion.
By the time teaching is happening, you are one level removed. By the time learning is happening (or not), you are two levels removed.
If I were being adversarial and trying to design a system to achieve suboptimal results, this is the sales and feedback channel I would set up.
This may be one of the most surprising innovations we've made at AltSchool; it's completely non-technical but running your own school lets you iterate on the metric that matters: learning.
Another perspective: if you are a teacher, your natural habitat is the classroom, not a digital learning conference. That's where user studies should really be conducted, anyway; the learnings are more accurate and relevant.
