You're in a desert, walking along in the sand, when all of a sudden you look down...

Ask them how they would market a new cat food.

What’s your favorite editor?

Lol that’d tell me a lot about a person

The way they answer it might...

Next to Microsoft Word, headphones might be second on my hate list. It takes like 7 consecutive miracles for a pair to work right. I order them in groups of 3 just praying one works right.

My last half dozen pairs or so:

1. Bluetooth (but wired between them) - everything worked great. Naturally I dropped them working out and in some freak accident the wire pulled out of the headphone.
   
2. No problem just order another pair right? Same company, same model - but they changed it. Not the same shape or size, didn't sound good, didn't stay in my ear.
   
3. Don't fit my ears at all.
   
4. Don't work with my phone - bluetooth constantly going in and out.
   
5. Fancy Arctis gaming headphones for work. Work great but they're over the ear - and since my ears are gigantic the ear pad starts rub against the edge of my ear and hurt unbearably after a half hour of wearing. Also makes my ears hot.
   
6. Bluetooth headphones - never even turned on. Complete dud. I could return to Amazon for my $22 back but bleh.
   
7. Bluetooth headphones - work but the buds don't stay pinned in my ear so everything sounds dim. On top of giant ears apparently I have very small ear canals - even the smallest nubbins fall out. I just hooked these up at work and a) for some reason with all volume blasting on my mac, they're still pretty quiet and b) I put them in once, then one of the little rubber ear nubbins disappeared and now I can't find it. It's dark, small and bouncy - so who the hell knows. I just hope it's not lost inside my ear.

I’d take MS word a million times over google docs, what a trash piece of software

Two really good articles in Hacker Newsletter today:

You Are Not Google - on the subject of choosing hot technology X created by Google or Amazon or whoever to solve your problems, without stopping to consider that the reason hot technology X was created was to deal with scaling problems that your use case absolutely 100% does not have

Startup Stock Options – Why A Good Deal Has Gone Bad - on the ways that startup options have changed over the last ~20 years and how that's made it much worse for early employees than it used to be, particularly in these two areas:
- founders and employees used to get the same type of stock, nowadays founders get preferential treatment and opportunities to cash their stock out pre-IPO that employees don't get
- companies are staying private way, way longer, and the article gets into why - VCs realized that a company going public and exploding in growth on Wall Street over the following ten years is growth that those VCs could have kept for themselves if the company remained private during that time

My boss is absolutely set on turning our simple CRUD app which is never going to have more than 100 users at once from a basic synchronous API into some kind of event-driven asynchronous microservice architecture - even though even the people who espouse those say it's not really needed for apps like ours.

User signs up/logs in through AWS Cognitio. User looks at their giving history. User sees and possibly updates their bio data. That's the entire app at the moment. We may add stuff to let them donate through the app in the future.

How am I going to make that some kind of event-driven asynchronous flow while the user is waiting for a response the whole time? Pub/Sub back-end and push back to the front end with websockets? Ugh. REST to the first lambda - then that fires events and listens for the eventual event telling it to respond to the user? Why?

Lol my company keeps trying to throw stock at me and i am having to have uncomfortable convos about why i just want salary.

I think the company can make it but i know that a lot of times these stocks are just trash in the end and you’re better off with salary unless you’re working on the next snapchat or something.

Company stock has been pretty good to me. RSUs and ESPP money doubled at my last company, and current company is up over 50% since beginning of December.

Not sure how I would feel about non-publicly traded stock.

Well yeah, I love stock now that I'm at a public company. Meanwhile the options I vested in my previous job at a startup over 4 years are probably all expiring worthless in a few weeks.

Lol suzzer just make it fire a polling ajax call every second and he won't have any idea

Websockets falls back to polling half the time anyway.

No my boss is pretty technical. She read a lot about microservices and wants the fanciest version. Everything is just a big data lake receiving events. Nothing is ever waiting on the line for something else. Or something.

eh first off sorry for assuming your boss was a man that's not cool but yeah I mean socket.io stuff isn't really that hard. Thats like a 1-2 week ask.. If you were you using a node passport auth setup. Which you're not, so thats like a 2+ month ask. I'd let her know that.

Yeah it's not about socket.io at all. I've worked with it before - probably not coincidentally on a prototype for a big shot architect who absolutely had to have "websockets" on his power point slide even though that app didn't need it either. I love websockets if I really needed them.

It's about fundamentally changing the whole architecture to make it 10x more complicated when we essentially have the simplest CRUD app imaginable, with no need for crazy scaling.

So instead of our current flow: front end -> API Gateway (which strips off REST and invokes lambdas directly) -> node or C# lambda -> possibly another lambda -> Dynamo/Cognito/Our CRM system -> returns response to user through the same chain.

In the new event-driven architecture world it would be something like: front end calls -> API Gateway -> some kind of step function which fires off an event -> something is listening for that event, does something, fires off another event -> something somehow queries the CRM system over SOAP, but still asynchrously fires off an event -> something somehow knows to be listening for that and to relay to to API gateway -> which somehow pushes it back to the browser - where the user has been tapping their fingers waiting for a response the whole time

As opposed to say some kind of real-time panel that needs to update whenever the underlying data changes - which is a perfect use case for push/event driven.

It just makes no sense for what our app needs. The true event-driven ideal has no databases - all state is just some sum of events. Which is cool and super scalable if you need Netflix-level performance. But we're talking about university donors browsing their giving history, printing receipts, and updating their bio information.

At my old job we had a meeting with the guys from Lagom/Lightbend - which is the first I heard about this approach - which is pretty radical but seems to solve a lot of problems with microservices. https://www.lightbend.com/lagom-framework

The thing is though - these only become problems when you have to wrangle 1000s of microservices and worry about managing state or stuff like transactions across them.

We're gonna have maybe 3 dozen lambdas when we're all done - which is cool - we can test, deploy and scale them independently. Lambda is awesome. But I don't think we have the kinds of problems that 1000s of microservices cause, or the need to add crazy complexity to solve them.

Man suzzer your job situation is so crazy to me. There's so much complexity and new tech going into something that seems like it could be built by a couple junior devs in a week or two using whatever boring mvc framework.

Pretty much. But I'm learning a ton of AWS/DevOps so that's cool. But now I'm invested in building this thing well - so I'm not interested in making it more complicated for complication's sake.

Just to be clear - the front end is kind of intense. The giving history has a bunch of lazy-loaded nested stuff like recurring gifts, pledges and planned gifts. We're using a react-table with nested react-tables inside.

The back end has to talk to a CRM system over SOAP (hence the C# lambdas) and that's also pretty intense with tons of weird rules.

For saving bio information - nothing is committed immediately. It goes through a potentially human-reviewed batch job - which adds a lot of edge cases and complexity.

The node-lambda middle layer integrates with Cognito for authentication - and does other glue code stuff. We're trying to design it to be an IDM solution for a bunch of other sites at the university - so that adds a lot of complexity.

I'm currently reconstructing a decompiled Java app which acts as a client to a server via a TCP socket and a custom protocol. The client gets values of enums via a lookup of the enum's name property, i.e. there might be a Websites enum with a Websites.GOOGLE option and it gets "GOOGLE" as a string from the server and converts to the enum. The problem? Under decompilation, all the enum option names got lost. So I'm running this thing, it complains that it cant find option X of some enum, I try to figure out which option name out of "a, b, c, d, e" I should refactor to that, then run the app again. Fun stuff!

This sounds fun if unnecessary.

It would be if I was just started. But now this thing is my baby and I'm not going to mess it up by making it unnecessarily complicated.

She should immediately say no for wasting a whole line with an opening curly brace.

I would ding him for using a variable width font.

Also, it doesn’t really make sense to have Hannah be a string and then an object. And really comparing to the string “yes” doesn’t make a lot of sense either. Someone should work on their typing.

I guess askToProm is a factory that creates girls - which would make sense for a teenage boy to design.