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.

I would bet that modem is using a phased antenna array [1] (I'm guessing this is what "solid state, no moving parts" means on the product page). With the right sensors (gyros, etc), a solid-state system like that should be able to keep a pretty tight lock on the satellite even in the roughest conditions.

1. https://en.wikipedia.org/wiki/Phased_array

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.

Yes! And it works on remote machines too! SSH somewhere and give it a try

I did the same experiment as OP and ran into the same issues, but eventually realized that I was "doing serverless" wrong.

"Serverless" is not a replacement for cloud VMs/containers. Migrating your Rails/Express/Flask/.Net/whatever stack over to Lambda/API Gateway is not going to improve performance or costs.

You really have to architect your app from the ground-up for serverless by designing single-responsibility microservices that run in separate lambdas, building a heavy javascript front-end in your favorite framework (React/Ember/Amber/etc), and taking advantage of every service you can (Cognito, AppSync, S3, Cloudfront, API Gateway, etc) to eliminate the need for a web framework.

I have been experimenting with this approach lately and have been having some success with it, deploying relatively complex, reliable, scalable web services that I can support as a one-man show.

TDD is a technique for accelerating delivery by focusing your coding efforts on only what is necessary to deliver a feature (i.e. pass the tests). You get high test coverage as a result, but having to maintain a large automated test suite has its downsides.

It sounds like the problem has more to do with lowering defect rates, which TDD can certainly help with, but so can pair programming, code reviews, and QA testing.

If TDD is your goal and you know how to use it well, just use TDD to improve your own process and throw away your tests before you deliver (or stash them locally). Seems silly, but you don't want management breathing down your neck for writing all of that "non-valuable code". Wait until they notice how productive you are then show them how you do it. They'll be like, "why the hell aren't you committing those tests?" Maybe you'll get a small slap-on-the-wrist, but from then on you'll have leeway to spread the TDD practice.

As a technical founder having gone through a few VC rounds, I was initially surprised by the lack of technical diligence but eventually came to the same understanding as the author: product-market-fit and sales/marketing execution make-or-break most companies.

I would add though that the impact the technical founder has on the design of the product and the quality of execution is immense and often hidden behind the non-technical founder selling the company to VCs. Good technical founders do a lot more than code. If I were a VC, I would look for teams with technical founders that have skills extending into product management, people management/recruiting, and operations.

I hear you. We're giving the British people a lot of crap for exercising their rights. I wish folks would respect this fact rather than sensationalizing the result and causing a lot of negative attention and guilt.

What typically happens is that people are screened into a hiring process on the basis of what’s on their resume... That already throws a lot of the baby out with the bathwater.

In my experience, about 80% of the candidates who send in their resume will not come close to working out. If you've never run a hiring process before, you'd be surprised how many people look decent on paper but somehow can't write a line of code without some serious hand-holding. The OP points out that sometimes the opposite is true (a candidate with a mediocre resume ends up being stellar), but this is an exception and you'll waste a lot of time trying to find these people.

I've honed my resume screening skills over time and I've gotten pretty good at filtering out most of that 80%, and I know I'm likely to screen out plenty of talented folks, but it's well worth being able to focus my time and my team's time interviewing more exceptional engineers than mediocre ones.

In other words, I think it's OK to throw out a lot of the baby with the bathwater as long as you're left with mostly baby.

Hmm. They can now have a path to obsolete cmd. As long as they ship a decent ssh client with the system, users will become accustomed to ssh-ing to their own box instead of using cmd.

Baby steps! SSH is a transport protocol, not a shell. If you SSH to your own box, you're just going to get PowerShell.

Holy crap, great idea! Imagine if adding a "monitor" (virtually speaking, of course) to your setup was no more difficult than splitting a Vim window... that would be pretty rad.

An Oculus Rift is much less expensive than your typical multi-monitor setup too, FWIW.

You basically nailed the problem: the generally-accepted status quo is based on flimsy evidence. Our metabolism is complicated and it will likely take decades before we fully understand it, not to mention that different people process calories differently.

Luckily, it's very easy to detect when your diet is having a negative impact on your health and you have time to make changes before heart disease or type 2 diabetes strikes. There's no excuse for not keeping track of your weight and not getting regular blood work to look for risk factors. When these risk factors emerge, very simple changes like eating more vegetables and spending more time walking can be enough to reverse them. Easier said than done of course, but we do have reliable science that shows this.

The OP clearly has Social Anxiety Disorder, also known as "social phobia". The result is introversion, but the cause is a psychiatric issue. You joke, but the OP is likely legitimately afraid of making eye contact.

It's too bad people with Social Anxiety (like me) are just told their "introverted" or "shy" their whole lives. Social Anxiety is a very real psychiatric disorder that should be identified and treated in people like this.

Hmm... it seems like the data captured from a service like this would be very valuable to Google's venture arm. Even if they can't inspect the details of your environment, I'm sure they're still privy to metadata like resource utilization, deploy frequency, what stack you're on, etc. They'll be able to sort a bunch of early-stage startups on this information and cherry-pick the ones with the best characteristics without holding a single meeting.

maybe the author has simply not worked with people who are good at refactoring

I agree with you 100% but this line got me thinking... shouldn't a methodology/process in principle lower the skill level required to be effective? I understand that Agile does to an extent, but perhaps the fact that "refactoring" is hard means the process has shortcomings?

In general, the only "binding" part of the term sheet is the "no-shop clause", which doesn't let you solicit additional offers from investors, usually for 3 months. It otherwise represents a handshake on terms so that the VCs have time to perform diligence and produce the paperwork (which is substantial) while the founders find strategic investors to fill up the round.

Either party can still back out of the deal at any time, and this typically only happens when something bad emerges during the diligence process. It's important that startups can trust this fact because agreeing not to solicit investment for 3 months while (presumably) running low on cash is a pretty big risk. KPCB broke this trust in our case.

Feel free to email me at the address in my profile if you'd like to chat more.

I'm not surprised to see this coming from KPCB. They have a reputation for using underhanded tactics and this is just the latest example.

I unfortunately learned about their reputation too late... they pressured my company into signing a Series A term sheet only to pull it 3 months later (at the end of the no-shop) after THEY messed up a partnership negotiation. Needless to say we were out of cash at that point, but luckily we had some great seed investors who re-upped and a month later we signed a term sheet with another VC. What a nightmare though.

If you want to dedicate 100% of your energy towards solving tough technical problems then you're actually not a good fit for a startup. Team sizes are small and resources are constrained, so you have to be well-rounded enough to solve any problem that comes your way, technical or not.

I don't think my original comment had the impact I was looking for. Sorry if I offended anyone... I don't want to imply that ageism is OK.