kylegill

Wasn't familiar with that python doc, but I love it! Bookmarked.

I agree, it's also (ironically) sometimes hard to disambiguate the differences between Next.js/Vercel/modern versions of React. I like the latter two! The former has just given me some whiplash.

I find the ending particularly funny, we have a small team where we're often building things in-house that we should probably just buy, or rely on manual processes for.

The fumbling with "oops, there's some test data in here" and the issues with the service worker hit a little close to home from some of our demos I've been a part of.

I've had good and bad managers, and the best ones were always ones that were good at doing something. Even if it was something less related to what I did on the day to day it's nicest when someone levels me up vs mostly being the communication glue between me and the rest of the company.

> Vercel is easy to use and comes with batteries

On our team, we deploy our web app through Vercel primarily because of this (maybe there is some hype factor bias in there too?..). Everything else we rely on runs on AWS. We don't necessarily need Vercel for any of the edge computing or serverless environments, but the experience of building, previewing, and deploying our app is FAR superior to AWS's Amplify offering because it just works.

Trialing Amplify for a few weeks led to a world of hurt, leftover build artifacts in our accounts, failed builds left and right, unreliable preview environments, etc.

I'd still consider myself a bozo (3 years out of school), but may I offer a humble thanks for your shoulders that many of the rest of us stand on!

At a past startup we had many employees organize a grassroots effort to make pay transparent by crowdsourcing a big spreadsheet of engineering salaries. What was found emphasized the disparity between the extremes of the pay distribution.

I think it resulted in better pay for the under-performer (that was pushed up towards the middle of the pay distribution) and worse pay for the top-performer (that was forced down). There were benefits to knowing we were all playing on a level field, but I'm not sure I'm in favor of it now.

I felt like I could be a high performer, and I also had visibility into exactly what I'd be making for the next few years if I stayed there. With that info, I started fielding messages from recruiters who offered to pay 20 and 30k more.

> we live in an environment which is not perfect, and the code is meant to contribute to the this environment

That's a really delightful take! Makes me feel like the code I throw at the wall to see what sticks does make a difference in my corner of the world.

When you add that the definition of perfect can be subjective, one person's definition of perfect might have evolved into it by passing through what is now their good enough definition.

When I was the first engineer at one job my manager (who joined after I did) anticipated others saying this kind of thing about me, and told me to always remember that "the reason any of us engineers have jobs is because of your code".

It's a good reminder, and I appreciate others taking care to build others up.

Hey,

As I've worked in design and development, I've found resources that have been most helpful at teaching principles are the ones that can present content in multiple formats, especially ones that are interactive.

I worked on Egghead courses focused on building animations in React that resonated really well with users because what is being taught is so visual. Before that, I worked on the docs for Gatsby.js and designed a lot of tutorials and content, including illustrations and interactive components we embedded in our docs that were also very well received by our community.

I decided to combine some of those things that I love and put them together in a course platform where I could organize and store tips and strategies for good UI design, alongside fundamental principles and theories.

I'm having fun with the project and interested to hear feedback! Thanks!

Can confirm, AWS Amplify got 80% of my job done trying to deploy and manage a FE stack.

It's strange to me working at a startup how vastly different the company programs are to support employees at enterprise level companies, the scale of this kind of program dwarfs our entire company many many times over.

Maybe this program will go entirely unused like my $500 yearly education budget though.

> It's a question to approach head-on in the interview.

I like that advice, transparency goes a long way both ways in the interview!

Yeah I can relate. I've only really worked at startups but from conversations I have with friends at larger companies it seems turnover at startups is more the default course and almost expected at times.

I'd say I'm generally not a big fan of the having to opt out approach.

> SLSA, pronounced “salsa”

I wonder if projects with easier to remember names linger in people's minds longer.

Is this kind of phenomenon of fun names more a marketing thing? Or more a software engineers really love naming things thing?

I had a similar experience. I tried installing some of their CLI tools and was met with some undocumented errors I didn't want to bother digging through code to figure out.

> But there is definitely potential.

I agree! It's something I'm watching with eager eyes, but don't feel like is the first option I'd turn to when making a technology choice.

Another technology that gives me this feeling is FaunaDB [0].

[0]: https://fauna.com/

Posts like this remind me how little I fully understand about networking and associated protocols, and how valuable it is to understand them to build things right.

The note about securing static sites with https finally painted the picture for me as to why it's a big deal, even for sites that don't send any data to a db!

> Securing the transport layer isn't just about protecting sensitive information, it's also about protecting the integrity of the content