claudiusd

It's great to see how others are doing serverless development. It's definitely not something you learn to do well overnight. I'm glad to see someone get past the learning curve and write about what works for them.

I've been experimenting with serverless for some time now and came to many of the same conclusions written about here. The biggest takeaway for me is that there are pitfalls to an overreliance on lambdas. You really need to offload as much as you can to the other serverless solutions AWS provides.

I've been using Appsync for my graphql API instead of API gateway + Lambda, and I have had a good experience with it. A lot of logic can be offloaded into mapping templates, making lambdas unnecessary in many cases. Debugging is still a bit of a pain for me, but the end result is fast, cheap, and reliable.

The privacy risk of installing extensions that have full access to every page you visit is enormous. It includes the risk of exposing passwords and credit card numbers.

Using a bookmarklet is a much better idea since users can control where they run.

As someone with experience as a startup employee and founder, having negotiated startup offers from both sides of the table and seen several unfavorable and favorable liquidity scenarios play out, here is the advice I give people:

Treat stock options in an early stage startup as if they are worthless. Don't make salary/equity tradeoffs and instead, negotiate for both the "high salary" and "high equity".

Stock options have a number of "gotchas" that may not be immediately obvious:

1. Exercise price and exercise window. It takes a lot longer for a startup to exit than than most people would like to think (if it exits at all). 10+ years is my experience. You're probably not going to stay with the company that long, so when you leave the company and want to keep your shares, you only have so much time to exercise them (this is the exercise window - typically 3 months). It could cost you many $thousands to exercise and there is no guarantee your stock will be worth anything. You are essentially now an investor in the company and you are afforded none of the protections that the company's venture investors received.

2. Liquidation preference. In a liquidity event, the company's venture investors get paid back some multiple of their original investment (typically 1-2x) before any common shareholders get paid (which includes options holders). If the company is not valued above a certain threshold at liquidity, then common shareholders get nothing. As the company takes on new investors, this liquidation preference starts to add up, and as an employee you are not going to be told what this amounts to. You could exercise your shares, pay the company money, have the company exit for an apparently attractive amount, and then get nothing because the liquidation preference threshold wasn't met. The company exits, and you lose money.

3. Tax treatment. Assuming the company exits while you are still an employee (i.e. you have not exercised your shares) or the company has an attractive exercise window (10 years is not uncommon nowadays), and the valuation is high enough not to trigger liquidation preference, then you will make some money. Unfortunately, the amount you earn will get taxed as income, not capital gains, and the difference is significant. To be taxed as capital gains, you have to exercise your options and hold on to the shares for at least a year before selling them. Some companies offer early exercise benefits, but if you do this then you could potentially lose money as I described above.

RSU's on the other hand (essentially just plain stock like founders get) do not have to be exercised and are taxed as income on their value the moment they are vested (or on the value of the entire grant on the data of issue, assuming you file an 83(b) election with the IRS). These have value, and I would be comfortable with a salary/equity tradeoff for them. This is something you should ask about during negotiation. If RSUs are off the table, then you can try asking the company to pay the [early] exercise price for you as a signing bonus.

Thank you for saying this. Despite taking all precautions, I was infected in Jan 2021 before becoming eligible for the vaccine. Once I recovered, I was comfortable venturing outside again and doing some traveling but there was practically zero information about natural immunity following infection. As states easing travel restrictions, these only applied to people who had been vaccinated. There was no exception for folks who were previously infected (at least for the states I researched). At a time when vaccine appointments were scarce and there were long waiting lists (my how times have changed), I still got the first appointment I could so I could get my vaccine card.

The lack of guidance for those who were previously infected was strange. When I'd read about immunization rates and progress towards "herd immunity", previous infections also weren't included in these stats, which again was strange.

I'm in Europe now, and here it seems like natural immunity is essentially as valid as vaccination, at least for travel.

I can't explain why previous infections seem so widely discounted in the US. It feels like an intentional omission, which makes it hard for me to trust at face value what I hear and read about the pandemic.

Completely agree. Most of the criticism I've seen comes from people who don't have a good grasp of the platform or tools, or haven't adapted their style to the "serverless mindset".

There's definitely a new technique I've had to teach myself in order to build serverless systems effectively. Today I'm getting great results from the approach.

Ugh, these arguments frustrate me, but here I go getting sucked into another...

> Actually, I am setting up a serverless app now. 4-5 lambdas, s3 buckets, RDS, IAM roles, and 6 weeks (easily) getting everything into CFT's and Ansible so that I can deploy this relatively small app.

I'm sorry but if this took you 6 weeks then you're doing it wrong. To be fair, I haven't tried using CFTs and Ansible for my serverless deployments, but then again these seemed like big time overkill to me. Your experience seems to back that up.

Look, I don't want to say infrastructure-as-code is a bad thing, but don't blame the infrastructure when it's your choice of tools that is the problem. The AWS CLI makes it so easy to write a bash script to deploy a small project. But hey if you think an extra 6 weeks is worth it to use Ansible, then by all means...

LOL. I guess I was being a bit conservative with that estimate!

I've worked for myself as well and know what you mean. In my situation, I was able to save myself from testing by telling my customers "this is a prototype so expect some issues".

I have only done a little bit but I know exactly what you're talking about and it's great.

My point is that OP is in step 1 of 5. It's not to say there aren't any good thoughts there, but the overall diatribe comes from a place of inexperience so take their advice with a grain of salt.

I can't believe I'm wasting my time on another testing debate.

Speaking as a formerly young and arrogant programmer (now I'm simply an arrogant programmer), there's a certain progression I went through upon joining the workforce that I think is common among young, arrogant programmers:

1. Tests waste time. I know how to write code that works. Why would I compromise the design of my program for tests? Here, let me explain to you all the reasons why testing is stupid.

2. Get burned by not having tests. I've built a really complex system that breaks every time I try to update it. I can't bring on help because anyone who doesn't know this code intimately is 10x more likely to break it. I limp to the end of this project and practically burn out.

3. Go overboard on testing. It's the best thing since sliced bread. I'm never going to get burned again. My code works all the time now. TDD has changed my life. Here, let me explain to you all the reasons why you need to test religiously.

4. Programming is pedantic and no fun anymore. Simple toy projects and prototypes take forever now because I spend half of my time writing tests. Maybe I'll go into management?

5. You know what? There are some times when testing is good and some times where testing is more effort than it's worth. There's no hard-set rule for all projects and situations. I'll test where and when it makes the most sense and set expectations appropriately so I don't get burned like I did in the past.

> > Start with the book: “Head First JavaScript Programming”.

> Please don't. 6yo book doesn't worth it. Even one year is a lot for modern tech.

I'm sorry, I know you're parroting conventional wisdom here, but have you read a book? Did you look at the table-of-contents? It looks like a great introduction to me, covering the basics that I think would be a prerequisite to learning any of the more recent language features. "Don't judge a book by its cover", as they say!

> We believed that it was poor time management and that if we just worked a bit harder and had more self-discipline, we could do the job

It's frustrating that the "experts" still see things this way. As if it's some moral defect that people are too lazy to overcome.

Can't stop procrastinating? "Just work a little harder and get started already"

Depressed? "Just cheer up and get over it."

Addicted to drugs? "Just look at the negative consequences and stop using them"

I guess I could see this article as a step in the right direction, but it's still frustrating to see how the casual stigmatization of behavioral health and its symptoms continues to linger.

> considering all s-curves are exponentials at the beginning

Sorry, but I hear a lot of people saying this and it's driving me crazy. S-curves are S-curves from the beginning, not exponentials. It can be useful to use an exponential growth model at the beginning of the curve for short-term forecasting, but these two models will diverge dramatically at the S-curve inflection point.

Not that we shouldn't plan as if exponential growth will occur in a crisis like we're in now, but many people I know don't understand these dynamics and it has lead to a lot of undue panic.