gnahckire

Last I checked Valve is a game company with a pretty flat org structure.

They have their own problems but, last I checked most people like working there.

This is false. GH Enterprise, although the moneymaker, did not have a lot of devs on the project.

Source: MS employee now works at GitHub

SQLite is so awesome. I love how python has a library built-in for it.

That SQLite plus SQLAlchemy makes hackathon code so easy to port to another RDBMS after finishing the initial PoC.

Also makes it super easy to run unittests; just load data into sqlite with the memory connector and go!

> If you want to grow and push yourself you're going to need some new coworkers.

I don't think it's necessarily that clear-cut. Some individuals are capable of pushing themselves. Those who can't, may have managers who are able to. Or, perhaps they rotate to work on a different project or problem space.

One dosen't necessarily need to leave a company to experience change or extraordinary growth. Granted, the extra push/pressure may assist a bit.

It sure is but, I believe the ultimate goal is to become an interplanetary species which would be pretty cool.

When discussing this with my friends, an interesting question came up: Who owns the music this produces?

Couldn't one generate music and upload that to Spotify and get paid based off the number of listens?

That's funny b/c we have that in our EE version.

GCP, Azure, Oracle, Alibaba ... just to name a few.

Fair point. Although one shouldn't discount statistics altogether. Security experts lean on skepticism to help minimize exposure and discover new things.

Race and nationality aside, the transfer of ownership to an entity that has zero open source contributions in the js space does look very suspicious. I'm just surprised that an open source author didn't provide that disclosure to users of his work.

> that code in Python can fail at a huge number of points even in a small function

This is why unit-tests are really important in Python.

> We should have language-level mechanisms for being explicit about what's supposed to happen when unexpected situations happen.

That's implemented as a try-except block. You're not supposed to catch errors at the low level unless you're explicitly handling them. If there's an error, bubble it up to the main().

Python's try-except can catch classes, sub-classes, and/or groups (tuples) of classes. It's important to categorize your errors.

I partially agree w/ you. One can always delete the test and then it's like you have no tests at all.

> And then there's a number of issues with test coverage giving you a false sense of security, with things like reaching 100% for a given piece of code, but only thinking about the happy path.

Yup, and this is why one writes tests against well-defined interfaces/boundaries.

I have. Worked at a large networking company that is rampant w/ low-skilled H-1Bs IMO.