This reminds me of Exist[1], although their inputs are mostly automatic and so the data quickly becomes overwhelming and tautological ("you spend more time active when you work out for a longer distance"). Glad to see another entry into this space.
Ten years in the industry. I was #90 at Twitch and grew it to its $1B Amazon acquisition. I've been successful backend and full stack.
I have a special eye for increasing developer velocity. I thrive in small companies with teammates who trust each other, where I can wear a lot of hats and have autonomy to solve pressing issues without much process.
Ten years in industry. I was #90 at Twitch and grew it to its $1B Amazon acquisition. I've been successful backend and full stack. Very experienced in Go and Ruby on Rails.
I have a special eye for increasing developer velocity. I thrive in small companies with teammates who trust each other, where I can wear a lot of hats and have autonomy to solve pressing issues without much process.
Ten years in industry. I was #90 at Twitch and grew it to, through, and past its $1B Amazon acquisition. I've been successful in backend and low-JS full stack roles, including bleeding edge HTML/CSS. Very experienced in Go and Ruby on Rails, experienced in TypeScript and Python, polyglot otherwise.
I have a special eye for, and experience in, increasing developer velocity and improving developer experience internally and externally. This includes writing documentation, automating its publishing, building command-line tools to capture complex flows, building CI/CD, writing and speeding up tests, building service templates and service generators, and more.
Have spun up and maintained infrastructure in Terraform, AWS CloudFormation and CDK, Docker, and Kubernetes.
I thrive in small (< 100) companies with teammates who trust each other, where I can wear a lot of hats and have a lot of autonomy to solve the most pressing issues without much process. I do however recognize the importance of measuring outcomes and I am self-sufficient at doing so.
I'm a staff/principal level Software Engineer, full-stack for low/no-JS or backend otherwise. I've worked "in the open" a lot so bonus points for working on open source and/or community management. I have a lot of experience moving monolithic apps to microservices, from the Rails → Go move at Twitch.
A desk mat, like the ones by Nordik [1]. It's like a giant mouse pad that also goes under your keyboard.
I can't stand the size of normal mouse pads and I can't go without one because the years wear on my desk. Plus it also serves as coaster, art, and "clean zone" that my cats know to avoid. You can get them custom printed with anything you want.
Yes. European cities were, in general, well-developed before the car was invented.
US cities are built around the car. This means more space dedicated to parking, which means less space for homes and businesses, which means things are farther apart, which means people need cars.
For a little more on these with a focus on CSS and practical issues, I wrote an article a couple years back called Advanced Dashes: https://twos.dev/dashes.html
Love that this starts you right in the terminal and VSCode from the outset. A friend has been on the Codecademy grind as a new developer, and ~1 year in she is continually frustrated with how little focus it places on real-world tools and experiences. It seems they want to keep you in their in-browser interpreter for as long as they reasonably can.
As a consumer who dislikes tipping, here are your ways to deal with it:
1. Find, frequent, and favorably review establishments that do not accept tips.
2. Express desire for policy at local, state, and federal levels. (Listed in decreasing order of ROI.)
There is no option 3. You cannot refuse to tip on a moral basis. You are just punishing the victim. No one will join you in your revolution and nothing will get done.
I am about a month further along than you on this journey. I started with vanilla Emacs and went through the built-in tutorial for a few days, then at the behest of friends switched to Doom.
Using Doom was valuable for me to see what Emacs can be. It is astonishing how much of an upgraded experience it is. However I felt I couldn’t understand where Emacs ended and Doom began, and the number of moving parts was making it hard to find solutions to problems.
For example, Doom keybindings for standard functions differ from normal Emacs bindings, so you can’t just follow any Stack Overflow post—the bindings won’t work. The fact that I didn’t even know why this was the case was getting to me.
I switched back to vanilla Emacs and, armed with the knowledge of what is possible, have been building up my config for a few weeks. I am making a special effort to avoid Evil Mode for a bit so I can learn all the bindings and make the decision for myself whether I like them or not. God Mode helps here as a more idiomatic alternative.
If your learning style is focused on knowing your foundation before building atop it, I’d recommend a similar path. I also have got a lot of value from sifting through others’ configs to pick up gems here and there. With literate programming it’s very common to find fantastically documented configs online.
We did the same when I was a founder, but we doubled the time off received. Working a weekend affects plans, wellbeing, and social life. The company should not feel it can trade those days around whenever it wants.
[1]: https://exist.io