mobjack

That is my preferred style.

If there are many joins, I could also add more indention to show what is being joined to what.

I used to wonder about the same thing then I saw my toddler accidentally hit the downvote button.

Sounds like a needlessly expensive standard. It is not that hard to quit without destroying your career.

Personally, I am satisfied with two weeks notice money.

Nuclear can be competitive with subsidies.

A serious response to climate change would be large government support of both nuclear power and renewables.

Are we going to tell our children that the main reason we did nothing to fight climate change was because fossil fuels were more competitive economically?

First replace every coal and gas power plant, then we can argue about nuclear vs renewables.

In practice, paid websites have much less obtrusive ads.

There are less incentives to ruin the experience for those who are directly giving them money.

Amazon, Walmart and Target were the ones most responsible for Toys R Us going out of business.

They actively ran ads to attract customers away from Toys R Us.

Shorting stocks doesn't cause businesses to tank.

What determines the success of a company like GameStop is whether people go to their stores and spend enough money to cover business expenses. It has nothing to do with the price of the stock.

These lawsuits seem silly.

Are investors suing for the right to be the biggest fool in a pump and dump scheme?

The consequences of not buying GameStop is that the investor has more cash in their account which doesn't change in value. Most of those who would have bought around the peak would have lost a lot of money.

If Robinhood prevented investors from selling their shares or closing their positions then that would be grounds to sue. Investors were exposed to an extremely volatile stock with no means to exit and could have lost everything in that scenario.

You get most of the value from the UA from just seeing if someone is on a mobile phone or desktop device. That is easy to parse.

Most of the other metrics are noise and don't impact business decisions.

Using HTTP methods as verbs is a terrible practice.

It works for simple CRUD APIs, but it becomes too limiting once there are more than one way of updating something.

It ties the API design too closely to the data model and usually means that the client has to implement more business logic instead of handling that on the server.

Good API design should decouple business logic from the HTTP spec.

Market experts have been caught with their pants down many times before because of the actions of uninformed investors.

In 1999, the rational move would be to short tech stocks as they were over valued, but those who tried it lost lots of money because they didn't factor in how crazy investors were at driving up the price.

You can technically be right but still end up losing everything.

From my personal experience, it does have some negative effects especially if you do it daily.

I would be more skeptical of a study that showed that cannabis had no harm.

It is not uncommon in the profession that someone working 3 hours can be more productive than another working 8 hours a day especially in slow pace environments.

Occasionally there is an emergency where you work the full 8 hours being the hero, then it is back to slacking off.

You also need to get comfortable taking out tech debt as a startup. A lot of times you can get away with it at little or no cost.

I wasted lots of time prematurely paying back tech debt only to have that code later deleted or rewritten.

It is important to properly prioritize tech debt and pay back things that the business is currently paying high interest on.

Once the product matures it makes sense to be more proactive in doing things right, but in the early stages, things are changing too fast that you just need to get out a rough prototype.

You need to pay taxes on RSAs when granted so they mainly make sense when the share price is really low on paper.

Once the valuation is higher, RSUs can shield employees from paying taxes until a liquidity event.

As someone with a similar personality, I doubt the employee has any delusions about their organization abilities.

They probably just don't like that aspect of their job and don't think it is that important.

Approach it by saying I know you don't like doing it, but it is important to do. Mention the consequences of not doing it and how you spent hours fixing them.

You might need to micromanage that one part of the job. Sometimes people need reminders on what to do.

Also mention that they a strong engineer otherwise and this is just one thing they need to work on. Don't expect them to be super organized, but they need to do the minimum when it comes to logging time.

It is also really nice to trust a developer enough where I can give a broad tasks and not worry about it. It takes a big cognitive load off of me.

I don't enjoy small tasks as a manager but they can be necessary depending on how much I trust someone.

Quality is overrated when it comes to tech.

A quality product can be written with many different tech stacks. You just need to be able to recognize what is good enough to get the job done.

I can often deliver faster choosing a good enough stack that my team knows compared to finding the best tool for the job.

The real reddit loads them in the same page without a refresh like you are expanding a comment thread. It is one area where a little bit of JS improves the user experience.

You can see the behavior without logging in by going to the old reddit site.

Attackers only need one attempt per username.

They will use a leaked list of millions of username and passwords, then use a botnet to try them all on another website.

Those studies all come from companies trying to sell you something.

They seemed to come from when mobile phones were much slower when there was a valid use for AMP pages. A/B test data is very easy to cherry pick from and you can see a 10% increase in conversation based on random chance. I can see my marketing team misinterpret data like that and use it for promotion. I am skeptical.

I improved the initial loading speed of a website so it was 30% faster on an old mobile phone and it made no difference in conversation based on the analytics.

Most people used faster phones with faster internet that it really didn't matter. After the first page load, most of the bloated assets were cached so even those with slow connections were relatively fast navigating further.

There could be some types of websites where speed matters more like if you promoted click bait articles with high bounce rates. But if you have high quality content, it isn't going to be that important unless you have really terrible bloat.

That brings back bad memories from working with Glue. If the source data isn't 100% clean and compatible with the destination, it is such a pain to get it working.

I eventually got it set up, but for the amount of effort involved, I could have just wrote my own custom ETL solution in less time.

The scheduling jobs and triggers is nice once set up. I do hope AWS makes improvements because Glue has potential, but it doesn't feel like it is ready for prime time yet.

I prefer to say that code is like a Rube Goldberg machine.

While it technically does the job, it is over complicated making it hard to add new features and easy to introduce bugs.

If we rush to add a new feature, it will be like adding another crazy contraption making it even harder to make changes to in the future.

But if we take a little time to clean up the code, it will be like a well oiled machine giving us a solid foundation to build new functionality on top of.

I didn't get the memo that you had to have programming specific hobbies for interviews.

I usually just say something to make me seem well rounded if asked about my hobbies.

Doing all the logic in SQL requires more complexity using subqueries.

It gets uglier if you need to find the contract valid on a certain date based off of a join.

These issues can be covered up with code as it will a easier to have reusable functions, but it makes the job of a data analysts much more difficult and error prone.

I implemented such a feature and thought it was a good thing as we don't want to send marketing emails to those who aren't interested.

People will also enter in junk email addresses so it is to clear them out to keep your list clean.

Those who are interested in the email content and still have images turned off are rare in practice. Even then, I also checked for email clicks and logins for some redundancy.

Manual testing and design patterns that isolate the effects of a change from the rest of the system.

I am going to manually test things anyways, so in practice, unit testing usually takes longer.

I am more likely to add robusts tests to parts of the code that are harder to test manually as it does save time in that instance.

Ironically, I find that well tested code gives me less incentive to refactor it. Refactoring is good for allowing future changes without breaking things. With good testing, I rely on tests to provide those guardrails instead of a clean code structure.

To be fair, traveling with a baby makes you much less likely to attack a plane.

This exception makes the TSA's policy more pragmatic and reasonable.

The harm of denying a baby milk or formula is worse than the risk of terrorism in this case. Not to mention is that it lowers the incidence of crying babies on flight.

The same logic could be applied to hand sanitizer restrictions in a global pandemic. Allowing people to carry a larger size could save more lives than the risk it poses. This is especially true when shortages can make it difficult to buy a travel size.

The "I don't know" case is the most painful to ask for since it feels like I am always second guessed.

If I have the permission, I can tell its value in a few minutes but instead I have spend hours doing due diligence to try to justify my answer and still am not confident asking.

I usually end up getting what I need in the end so the admins don't see it as a big issue, but it is a subtle thing that can kills productivity for anything related to AWS for everyone else.

My issue is that most of the examples in the documentation either have or assume lax IAM policies.