With payroll taxes and benefits, an employee is ~2x TC. Since startups underpay frequently, let’s say the average salary was ~150k in TC for early employees within SC. That’s 300k*5 = 1.8 million gone per year. Over two years that’s 3.6M. 1.4M left over for finance, legal, rent, and other expenses is kind of tight and you definitely won’t make it a 3rd without any kind of customers or other financial infusions. That’s why a company has to find some kind of product market fit quickly - you have to show there’s a there there so you could continue growing either through revenue growth alone or raising another round.
2x TC seems high. For one direct example I know of, benefits package (including all the insurances with all premiums paid by the employer) costs around $25k/yr. I feel like at $150k salary, it’s probably like $200k total cost? Payroll tax employers are responsible for seems around 7-8%. $30k benefits, $12k extra payroll tax leaves $8k for equipment and other expenses. That would be about $1M/yr for 5 employees.
I think the 2x number is a rough ballpark that includes total cost of employment (eg HR salaries / outsourced HR etc). It’s entirely possible that this overhead is smaller for startups and it may have shifted over time (this is a rule of thumb I was told by a few people 10 years ago)
How long ago was this? AFAIK the `rm` command in almost every linux distro these days will NOT let you delete `/` unless you add `--no-preserve-root` parameter.
# rm -rf /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe
There's still lots of ways to screw up a rm, like "rm -rf /*" or deleting your entire home directory, but a space after the initial / was apparently common enough that they eventually put a big failsafe for that in the GNU version.
I don't recall which one it is (u for unset perhaps?) but I cover this by starting every (bash, E and pipefail are not POSIX) script with `set -eEuo pipefail`. All should be the default IMO, I don't understand - other than back-compat - why you wouldn't want them.
You can also prevent this by never using $VAR, and instead always using ${VAR:?} to exit with error if VAR is unset (or use one of the other options to provide a default).
The whole problem seems to be bizarrely defined when it comes to data structures.
Basically the input is `data+config` merged into one object and the return value is `data+config+tranversal_properties` merged into one object with lots of solutions mutating the original input data.
> GitHub was flakey, some things didn’t have error responses
That just seems like API problem rather than GraphQL problem. The equivalent would be REST API that just returns 500 without any additional info. You can be lazy in both stacks, I don't think any one of them particularly prevents you from being lazy about handling errors / typing useful error messages.
> Mutations would screw up encoding “ character and it was just painful.
Interesting, haven't heard about this. Also cant come up with how this is related to GraphQL, as you are just transferring string, just like you would do with REST. It seems more of an problem with some proxy/grapql framework layer that didn't handle the character correctly?
> REST api was much more deterministic and easier to work with. POST/PATCH/PUT/DELETE map well.
I don't see this as a big win, in GraphQL you just have `somethindUpdate` `somethingCreate` `somethingDelete` mutations, it is true that it is up to you to keep the naming consistent but nothing really that would be big trouble, or win for the REST.
> I wish graphql didn’t invent its own quirky language and stuck to good ol json.
If they did that you would end up with some quirky JSON query and schema syntax that would look like json schema or the mongo query schema. It is true that if you do new syntax you lose some json tooling that could be used (eg syntax highlight) but I don't see that much stuff transferable to the problems that GraphQL is solving.. so you would still end up with bunch of custom tooling on top, and when you need that you might as well go the way they did, with new syntax, that is not as quirky as whatever mongo/json schema like thing they would come up with.
> There is a lot of over complication.
This is definitely true and one of the most overlooked things by GraphQL evangelists, the "additional complexity layers" are non negligible.
Cars don't suffer feature creep. We've optimised them - removed the horse, switched to steel construction, added electrical subsystem - but really there's been no major functional change in cars, ever.
...added electrical subsystem, replaced combustion engine with batteries and electric motors, we're adding various degree of autonomy.
In parallel, we've replaced sane controls with frustrating and dangerous touchscreens, we've added countless types of comfort features, we've improved security, we've computerized engine controls, we've DRMed the car - ostensibly to prevent theft, but actually to route more money from aftermarket towards the manufacturers. Etc.
Cars do suffer feature creep, and not all of the features are beneficial to their owners. Just like with the web.
Our expectations about cars have definitely changed over time. I don't think it's even legal to sell new cars without seatbelts, something that did not exist when cars started. Even low end cars in the US have added features compared to low end cars of the past, such as power windows, power steering, power mirrors, and so on.
It's true that adding features is slower in cars, but that is because cars are partially hardware. It takes much longer to add features to hardware, because making copies is not free. But that does not mean they are unchanged.
Nope. Cars have advanced, but if they were webtech, we'd be wondering why they've not implemented OrbitalMechanics support yet. OceanMechanics would be old hat.
Actually, just a few days ago, I got fed up with Apple and tried to switch to Microsoft, and make it my main development machine, and so far I have to say I am impressed.
Twitter thread describing the experience: https://twitter.com/PetrHurtak/status/1314854634394185728
Windows 10 is a surprisingly good OS, with a thin layer of crap spread over it (the tracking). But it's still surprisingly easy to remove that layer, and the underlying things is pleasant to use, with wsl as a real game changer, wsl2 even more so.
I was always a windows person on my main computer and I liked 7 a lot but it still didn't quite feel right for devs, but windows 10 really makes us feel at home.
Also you went with a surface pro, which has been a genuinely top of the line hardware serie from microsoft
I was always a Windows native due to hobby game development. Back in the 2000-2010 times, that meant you were using Windows.
The dev tooling on Windows for things that aren't .NET has gotten much, much better in the last 10 years. Sometime in the last 4 years I stopped feeling like I had to have a Linux installation available to switch for my programming needs, and I've mostly just been using WSL instead. I still keep the Linux installation around, but now it's months in between when I boot it up.
