beebs93

How to let others make mistakes so they learn more efficiently during work hours without crashing production.

Yeah, I noticed that a bit, too. I originally meant the megathread post itself. I try not to read too many comments in such threads on Reddit; regardless of the topic ;)

Agreed.

Said family member mentioned in the parent thread keeps a handheld radio (I don't know the exact tech specs, sorry) for such occasions. That said, they mostly use it to just listen for any logging trucks calling out checkpoints so they can avoid getting in their way when travelling to their remote campsites.

Coupled with a Garmin inReach w/ backcountry maps installed, it gives us peace of mind in case something goes wrong out in the bush.

They frequently go camping with their family in the interior of BC so they always have one for emergencies. I agree they can be pricey, but it obviously paid for itself just in this situation alone :)

One of my family members has been stuck just east of Hope, British Columbia[1] for almost two days now. There is currently no cell service, but luckily they have a Garmin inReach so we can communicate via its SMS feature.

For anybody with friends/family in the area, the BC subreddit megathread[2] on this is a good starting place to get information on evacuations, power outage status, road closures, official relevant Twitter accounts, etc.

1: https://goo.gl/maps/CXcNEUmAx8gpF5CTA

2: https://www.reddit.com/r/britishcolumbia/comments/qubkc6/flo...

Each AWS partition can have its own browser support SLA. China's AWS console has its own [1], although it almost overlaps completely with the "classic" AWS console [2].

For the government/secret partition, I have no clue what their SLA is, but it wouldn't be a leap to assume they may something different.

1: https://www.amazonaws.cn/en/management-console/faqs/

2: https://aws.amazon.com/premiumsupport/knowledge-center/brows...

Yeah, good questions that I'd also love to see see answers to!

My favorites for retro-like discussions (if you think it will be beneficial):

1. What did you worry about the most in the beginning that later turned out to be silly/inconsequential?

2. What did you intentionally put off in the beginning thinking it wasn't a big deal that you later regretted not spending more time on?

It's an internal tool developed at Amazon so it's not available to the general public.

That said, it's nothing super fancy. Simple collaborative sticky note app that supports Markdown and has the ability to vote once per sticky.

Yup, same here. Not sure how I was ever on their list :/

Another nice add-on to this format within my department is that we utilize an internal retro tool for people to post their questions for discussion.

After the 20ish or minutes of silent reading, we give people ~5min to post their questions for all others to see in real-time. We then give people a set number of votes and the presenter goes through the list answering the questions in descending order of votes.

I was hesitant at first when they introduced this (since it felt like more red tape), but I've found it helps focus the discussion on the most important feedback while avoiding one person bikeshedding the discussion time right at the beginning.

Congratulations Dalia! Best of luck with your new adventures in and outside of Google!

Your story motivated me even more to keep nurturing my niece's interest in programming :)

I especially do not envy the UX designer & copywriting staff that may have to address this across of all AWS' consoles/public documentation.

I've worked with UX/UI designers across multiple companies for over a decade, and the simpler something seems (i.e. making a new logo) the more time & resources it usually takes to do properly.

If this truly comes to pass, then I couldn't imagine the difficulty of having to re-brand AWS in China that'll make both the CCP and AWS' leadership happy.

Heh, when I started working in the payments space, I had fleeting moments early on where I caught myself thinking something similar.

I soon realized, however, head-in-the-sanding the other current use cases and their complexities would be an amateur mistake.

I'm doubtful browser vendors could ever properly encapsulate the various international payment use cases behind their abstraction, but I would love to be proven wrong.

Bank accounts (ACH/SEPA), EU's relatively recent push for MFA for credit card transactions, India's mandate overall for MFA, China's gov't regulations around customer payment data not leaving the GCF, validation of China Union Pay cards in North America, etc., are all complex instruments/workflows that are no small feat to handle and handle well.

Managing. Expectations.

Easily took away 75% of the stress at work and stopped from it bleeding into my private life.

This can manifest itself as: - being upfront with what you do and don't know when asked to do anything so if delays occur, it won't be b/c you overpromised == lose trust - keeping stakeholders in the loop with any significant developments so there are no surprises down the road - estimate normal project work as if you can only work ~8 hours a day/5 days a week (while taking meetings, vacactions, other normal overheads into consideration)

This, IMHO, is a pre-req to properly implementing any of the other common helpful tips others have listed.

synthetic in the sense of synthetic traffic, since it isn't traffic from genuine users.

Yup - I think that lines up.

what is the master aggregate "switch" ? what does it do?

We have a hierarchy of aggregrate monitors (or "switches") that watch n amount of either specific metrics or other sub-aggregate monitors.

In the case of production deployments, we watch a specific rollback aggregrate monitor for either a fixed amount of time or customer traffic that will auto-trigger a rollback if it goes into alarm (aka switches on).

We also have a master aggregrate monitor that will switch on if any sub-monitors get swtiched on for any reason. We typically watch this master aggregate alarm to auto-disable any promotions in our code pipeline.

Yeah, I concede the common lingo within the company (or team even) may not align with either proper definitions or mainstream usage.

Every company I've been with seems to re-invent the terms or swich their definitions slightly.

For me, currently, "canary" means a set of basic automated integration tests that are continually running in production with alarms that feed into a master aggregate "switch". Wether the dedicated canary accounts end up hitting a one-box prod host or real prod host in the end isn't a factor.

The important thing is we incrementally expose our latest code commit to prod hosts via one-boxing to reduce the customer exposure if an acute problem somehow gets past the previous code deploy stages/tests.

Yeah, very useful strategy. I've heard it go by various names (e.g. toe-dipping, one-boxing, etc.), but it's always been one of additional methods of helping ensuring safe prod deployments at any company I've worked for.

One downside - depending on your setup - is you may not have an easy way to hit the hosts directly/deterministically via any UIs in case you wanted to do any manual verification/debugging yourself.

They're also more likely to steal from you, hurt or harass other employees and more.

Not disagreeing with you here as I have zero experience with this, but in your experience are there any attributes that ex-cons typically exhibit better than the other employees?

Worked for a small design company and one day everyone but me and the office manager was laid off.

It was pretty weird and despite reassurances from the partners, I took it as a hint that it wasn't the most stable of jobs.

Started looking right away and found a more stable dev position within a few months.

Agreed. I almost always dial into any large scale events at my company - regardless if it concerns me directly - to listen how ppl critically evaluate data, triage errors, and determine how to mitigate the problem(s).

Whatever skill level I have in this area, I cannot nail down if it's from multiple "baptism by fire" situations, learned naturally via university courses in the scientific field, strategy video games (half joking), or other sources I cannot think of.

I've listened to some very impressive people handle serious crisis situations and I'm both in awe and curious how they achieved that level of deductive reasoning.

Not a manager, but I meet with my engineering manager once a week.

We set the ground rules early on that we'd avoid the two extremes of the topic spectrum: project status updates and venting about issues that neither of us can take action on to address.

I'm given free reign to choose a topic and drive the meeting. Unless there's some pressing matter, I fallback to reviewing the work I did the past week and how I feel it helps (or doesn't) my career goals.

I try to give good examples of gaps I'd like to address so he can look for such opportunities in future projects, conferences, or in-house training.

My goal is that my manager will have a good understanding of the type of specific tasks I like to do and/or that will better help my future.

Agreed. I use FE frameworks a lot so I was hoping for a more detailed summary of what worked and what didn't.

If the OP has a more in-depth analysis I would love to read it.

This is good news - looking forward to it!

I'm hoping this will eventually speed up my tests during deployment a bit as I currently have to pipe my ES2015 code through a Karma transform to have it readable by my PhantomJS instance.

Be reliable (never, ever go dark)

+1 to this point. At a previous agency job I found this to be the biggest pain when hiring/dealing with contractors.

As long as they gave decent notice on days off I never complained about their availability.

When approached to work for my current company I met with my future manager and asked:

Will I be able to have a more senior developer act as a mentor?

Will I have direct access to more experienced devs on my team?

What opportunites will there be to try something new and get it reviewed?

Are there any tech stack absolutes I will never be able to stray from?

The answers I received were great and ended up being accurate.

It was the first time I had ever decided to choose a company based primarily on the potential for growth and not money/perks/etc.

Smartest decision ever.

...with the only big advantage jQuery has now is if you're animating.

While you can probably get away with using $.animate for very simple animations, you'll run into jQuery's animation performance problems before too long.

See: - http://wilsonpage.co.uk/preventing-layout-thrashing/ - http://velocityjs.org/

My advice is go on interviews you don't even care about in hopes to get rejected.

This was an immense help when I recently decided to switch companies. I applied to places I didn't really want to work at so that I could either:

1. Get rejected and get used to hearing/reading those words while not taking it personally.

2. Work on my negotiation skills if I actually got an offer.

Either way it was a win-win for me in terms of what I was really trying to achieve.

You may come across a dream job posting one day and if you can block out the worry of rejection you'll have a higher chance of success.

This.

Though, depending on the font (and how many), its glyphs, etc. you can get pretty bloated CSS files so while you do load the fonts earlier, you could be waiting just as long in the end.

I sometimes put them on a CDN to help alleviate some of the potential delay to download and/or render.