plicense

Curious - why did you move from google to aws? How has it been after the move?

I've not reverse engineered the FB app. I also don't think I'm legally allowed to.

I'm simply "speculating" that a large number of reimplemented classes might not be the reason for the increased binary size from anecdotal experience of building similar app binaries for iOS.

FWIW, I think this comment gives a pretty good reason for why the binary size is large - https://news.ycombinator.com/item?id=17996161

I think this is a totally baseless comment.

1. Have you worked at Facebook as an engineer before? Do you first hand know that most engineers working on FB iOS app lack the experience and interest?

2. Have you reverse engineered the FB app and verified that the app lacks signs of proper system or application development?

There could be a good enough reason as to why the app re-wrote core iOS libraries - most popularly performance and missing features. Also, tens of thousands of classes don't directly translate to increased binary size - its usually the dependencies of the code that results in such large binary sizes.

Overall, if Facebook wanted to optimize its app size to be less than 491MB, they would have.

Maybe its on their roadmap, maybe they decided most of their userbase have the ability to download 491MB and it isn't impacting the growth funnel, heck maybe some of the engineers actually wanted to work on optimizing the app size but it was shot down by management. Slamming engineers who work at Facebook and calling them inexperienced is just mean.

I've started shaving myself regularly to stop myself from doing this.

Totally in sync with you. I used to work for Zenefits, and if there's one technical reason I could point to for the company's failure to calculate accurate insurance rates (and eventually get a lot of support cases leading to lesser margins leading to an eventual failure in the insurance space), it was the blatant abuse of Django models.

> The Visa lottery system keeps workers locked into lower paying wages that what they could get as full citizens under the same exact circumstances.

FYI - you can switch jobs in H1B. I don't live in the USA, but everyone I know who is from my home country (India) and is on a H1B and in tech, have switched jobs atleast once (mostly between FB, Google, Twitter, LinkedIn, Microsoft and Amazon).

OTOH, if you're talking about L1 Visa (which is NOT a lottery system), then everyone I know who is on L1 (interestingly they are all at Amazon and Microsoft), then I agree - none of them have switched jobs so far.

> For example, one reason why many corporations push really hard on having 100% unit and integration test coverage is because they have such high employee turnover that they can't rely on their engineers to maintain their own code

I'm in a similar situation as yours and have switched between big corporations and startups and now at a big co again. I used to have the opinion that unit tests are a time sink, but what changed my mind was the iteration speed unit tests gave me. Without them, to test that my code actually worked, I would either deploy to a test environment (or prod in the worst case) and if it didn't work, then that just meant a longer feedback loop. What I realized after starting to have solid unit tests was that I catch issues much earlier in the pipeline and when I finally release code to test, it works 99% of the time. The only time I've had bugs in test env was because of some implicit assumptions in my mocks in the unit test. If you think about it, that lets me iterate faster by pooling in lots of changes and releasing with confidence.

I think its natural to be biased towards testing in a real environment as opposed to unit tests, as it is more rewarding to see your code work and do what its supposed to do versus seeing it work in a stubbed out environment.

Unit tests to me are more about iteration speed and release confidence, than about corporations not trusting engineers (which is also true).

"Unlike Apple, which only allows apps to be downloaded from its own storefront, Google’s platform is more open."

Oh the irony. Android is more open than iOS and yet its Google that EU found to be at fault with Android. How is this not a classic example that, if anything, Android provides a more open platform?

Can you give examples of why its bad? While it isn't as contextual as it can be like web-search, I haven't found it to be "bad". Slack's search is what I call bad

There are certain things in the original comment that I agree with(in certain situations I too have found Alexa to be better performing than Google Home), certain things maybe not so much(like this statement "Google used to under promise and over-deliver. Now it has been taken over by marketers who tend to over promise and under deliver.")

One of the things I've decided to do these days when I find things that make no sense when I read them, is to figure out if the commenter had any pre-existing biases.

Sorry for the irrelevant comment - I've just been looking at your past comments. Looks like your gripe with Google started 4-6 months ago and been continuing ever since. What happened?

Pardon me for the stupid question, but how is bringing the speed down to 0 milliseconds before landing by firing the rocket thrusters different from just letting the capsule hit the ground? I thought the thrusters were there to make the passengers not feel the inertia due to sudden arrest of speed from 16-17mph to 0mph. Firing the thrusters milliseconds before landing seems to have the same effect as just letting the capsule hit the ground? Or is it to protect the capsule itself?

Mind naming the 4 big failed projects?

Speculatively, No comment. And this was a really badly thought out comment.

Will you be able to refer me? I applied last June via the jobs page but haven't received a response so far. Thanks!

Fantastic work! The UI looks really slick! How long have you been working on this project?

Our version of shell_plus was trying to handle aliased models that were defined in settings.py.

In order to do this, it was maintaining a map of {appName: [list of imports]}.

When constructing this map, for some reason, it n^2 the imports - i.e., if an app "foo" had models "Bar", "Foo", "FooBar", then the import strings were, "from foo import Bar; from foo import Bar, Foo; from foo import Bar, Foo, FooBar" instead of "from foo import Bar, Foo, FooBar". Some apps had 50+ models, so instead of 1 import line for these 50 models, it was executing 2500 import lines. I fixed this so that it executed only one import line instead n^2 import lines.

I've come to the realization in my short career that 90% of my time will be spent on activities that produce 10% impact and 10% of my time will go towards activities that have 90% impact. But the 10% time producing 90% impact stems from the fact that I spent the other 90% doing mundane work and understanding the environment/product/whatever problem am working towards solving.

As an example, my company uses Django and the first 6-8 months I have spent hours debugging what would be a stupid issue like misconfigured Django or missing url. Eventually, that led me to optimizing the version of shell_plus that my company was using improving its bootup time by 200%(this was a rather large codebase). That's an instant 200% gain per developer/per django shell load and is probably the most impactful thing I've ever done. We estimated it would save around 6.67 hours of developer time per day(2 minutes saved - was originally 2.45 * 200 developers * 1 shell load every day)

My thoughts precisely. I mostly use rebase, except when I know multiple commits in my feature branch will cause merge conflict with master - in that case, I save myself the trouble, do a merge and be done with resolving all conflicts in one go.

My ideology is - prefer rebase first, resort to merge if it will let you do the gnarly merge fast. Of course this is because of the development environment I work in where we just don't use bisect and the workflow is different. I also keep in mind that if I work on a different repository with differing testing/development processes this ideology will change.

The first few days I work on any new project(due to a job/project transition), I figure out how I can iterate as fast as I can and see what my time saving points are. How to best use the git I know, on the current repo, is also a minor part of this poking process.

This is very interesting - back when I joined Amazon, one of the new hire on boarding questions was about how to deal with bad reviews and the principle was to just leave them as it is and not delete it - I am not 100% sure about it though - can someone confirm? If so deleting these reviews seems opposite to that

PDFium used by Chrome internally uses Foxit PDF library to read and extract information from the PDF.

Google basically bought Foxit's library and open sourced it - but looks like the open source version isn't keeping up with the upstream commercial version of Foxit because the latest Foxit reader doesn't seem to have this bug.

I worked at Amazon for a while and the point to note is that the Fire phone, despite being a public failure, led to a lot of things at Amazon. For ex: 1. The computer vision and machine learning stuff behind the 8 cameras on the Fire phone has been repacked and reused at multiple places. There's also a object recognition service in AWS if I remember correctly. 2. The FireOS, which powered the Fire phone, is being used on all Kindles except the older e-ink Kindles.

While the hardware division was indeed shut down, Amazon did manage to salvage as much as they can.

The cloud service didn't take a life on its own - in the very early days there was just EC2 and S3, nothing else. It took a lot of focused investment, commitment and trust from the management to give the AWS experiment more time so that it could succeed and eventually it did.

Fire phone was one of Amazon's many experiments. It failed sure, but hey you miss 100% of the changes you don't take.

I definitely wouldn't call AWS, Echo from Amazon occasional. I think companies come in all shapes and sizes - some focus 90% on their core, some try to spend more time and diverge out to other business segments. Its upto Apple to figure out what to do and what would make it successful.

LOL, genuinely laughed. A developer with a title a level below mine makes more than me - I was recently promoted but the raise I got with the promotion didn't match his salary without the promotion!

Consider using \b instead of printing a new line every time. I've a huge scrollback configured and it can silently crash my terminal given a large enough wake time!

Woah you're in Vancouver? If you don't mind me asking, what does the pay package look like?

Yeah, if he had waned to make money he had plenty of opportunities before Facebook even went public. He has a vision and he is executing it in all his power, never worrying about how much he earns.

This reminds of something Vij Rajarajan(big boss in MSFT) told about - "I have realized almost everything in life is a paradox. If you want to grow in your current role you might think you have to not help out others and worry only about your job but in reality you grow by helping out others".

I think this also applies to Mark Zuckeberg - if he had wanted to make money the company would not have grown so much. He focused on the vision and now he has made money.

Not immediately. But I've seen people who are 2/3 years into the company do it. We have an engineer who does this. It all comes down to the team and how your peers value you. If you are really good and a valued member, the company will go out of its way to retain you.

Great. I actually work in one of Amazon's satellite offices as an SDE-1. Is it possible to move to SEA while being an SDE-1?

How are the working conditions?