Agreed. I was writing a port of the redis protocol to erlang for a personal project that's a server using said protocol as an interface for distributed MPSC "locking", and it was incredibly simple to implement because of erlang's binary strings and pattern matching. Same with base64/hex/etc. manipulations of strings into binary data. I've read a fair bit about how erlang is great for protocols, but hadn't experienced it myself (professionally or personally) until I decided to implement this project.
- you aren't defined by who your employer is
- your intelligence isn't defined by who your employer is
- you can't control what other people say or think about you
- you're worth a hell of a lot more than what you do or what you make per year (emotionally, intellectually, spiritually)
- life is random, do the best you can and don't hurt yourself doing so
At the risk of sounding morbid, we're all just apes on a flying rock trying to figure out what existence means to us. Reach out if you need help, there's nothing wrong with that.
I guess you could consider border states of Mexico as the same geographical region as the southwestern US, but those too. Anecdotal, but I've seen routine thermal throttling on macs in a border state with outdoor temperatures of 45, ambient indoor temperatures of 30-33, so you basically need either AC or some other external cooling system to manage more performance than a web browser and office apps.
I have heard anecdotal stories of the adhesive on rear-view mirrors of cars literally melting in the Phoenix sun (which can hit 120 F / 49 C or worse). So your story is not surprising at all, sadly
Would a nationalized bug bounty program help here? Along with some compliance enforcement that the bounty is actually addressed, fulfilled, and payed by the vulnerable entity or the government (funded through some form of corporate tax). I haven't really thought out the details, but likely some kind of practical and effective threshold exists where a business entity in the US enters into mandatory participation.
Genuinely curious, would love to see others' thoughts.
> Would a nationalized bug bounty program help here?
A nationalized ransomware team would.
I'm serious. Just like how NSA said "we can't beat em so we'll join em" and started buying zero-days with both fists. If, back in the 1990s, you tried telling people this would happen you would get shouted down by everyone in the room. But it did happen.
If you get owned by Team Fed you get a phone number. You call the phone number, get informed that you got hacked, and get the decryption key immediately. The ransom is added to your company's next annual tax filing. Ransom levels are slowly jacked up until morale^H^H^H security improves.
That's a pretty unfair characterization of people who prefer to work remotely.
However, your last point about letting remote employees stay remote and letting people who prefer office-work to come into the office, I optimistically agree with. It works when everyone knows how to work with remote employees, and that the option is exactly that: an option. This last year and a half I hope has been helpful in getting everyone up to speed on that. It requires a cultural dedication, and assuming people have learned something from this remote experience, they'll carry that knowledge and flexibility with them going forward.
Adding on to what others have said, it's also that some non-US countries have much better internet infrastructure than telecom (which might've affected pricing, can't say for sure), so people flocked to internet-only messaging apps to avoid their telecom's faulty SMS/call handling.
Honestly, depends on the company and the state you're working in. It's all anecdotal, so take the following with a grain of salt.
I've worked for startups in Washington and California. In Washington, there was an invention clause in my contracts, but in practice it was a) practically unenforceable and b) as long as you divorced your work identity from your personal identity, nobody cared. This meant not having a way of tracing an anonymous handle or email to you working for the company. In California, I've never seen an invention clause in my contracts, but they were also much better at divorcing your work and personal identity systematically (forcing you to use a github account specific to the company, not mentioning this handle on your personal account, etc.).
In any case, keeping your work and personal work completely separate (no competition between work and individual ideas, no shared hardware) is a good idea and won't raise as many eyebrows. Some companies will be more aggressive about owning what you do, so if it matters to you then ask about the clause before signing the contract.
> In California, I've never seen an invention clause in my contracts, but they were also much better at divorcing your work and personal identity systematically (forcing you to use a github account specific to the company, not mentioning this handle on your personal account, etc.).
California has a state law that covers this. Any work you do on your own time, with your own resources (so, not your company laptop or photocopier) is your own and the company cannot force you to assign it - so long as the work is not connected to your employers current or reasonably anticipated business.
In practice, though, even in CA, I would suggest employees always get something from their company, in writing, disclaiming any ownership of any project they decide to start or work on (in any large capacity), especially if it's a software project and they work for a software company.
Even if you truly believe what you're working on has nothing to do with your employer's line of business, they may disagree, and even if they're wrong, they can make your life difficult and expensive while you try to prove them wrong.
It makes me sad that this is a thing I feel I need to suggest, but I think it's the prudent move, and many companies will even have a fairly painless, well-defined process for doing this.
That's a great call-out, and one that's particularly relevant when you work at bigger companies. For instance, what can you confidently say isn't part of Apple's reasonably anticipated future business?
as a young developer in California Silicon Valley area, I saw companies try to create 24-7 blanket enforcement of IP rights, solely to increase control and profits; I also saw coders definitely steal company IP and try to start new companies. That State law you are referring to was passed long after this battle was underway, and I can tell you that companies definitely denied that the law existed, said it was unfair, and also paid lawyers to write contracts that tried to take employee IP anyway, and use sales tactics on new employees to accept it.
Can't speak for the commenter, but I used to work for a team couple years ago that used rust and tokio extensively, and some projects were just not a good fit. At the time, futures were well fleshed out but the community hadn't caught up, so we were lacking a futures-compatible postgres and redis client. We wrote the redis client ourselves, and for the main project using rust that was sufficient. But for postgres, that was a show stopper for any other projects we were working on. So we ended up deciding between typescript and go for those.
I think there's a case to be made that there's nothing novel in an API itself (emphasis on the interface). The novelty comes from the implementation, whereby competition actually kicks in (novel algorithms, data structures, storage techniques, etc.). But maybe I'm missing something? I come from a distributed systems background, so my bias is likely titled.
Naming decisions are pretty inherently creative, I don't this this argument works. "Stack", "push" and "pop" are obviously novel imho. The inventor of the stack api could have instead called them "LIFO", "Put" and "Take" for instance.
I agree, I'd never argue that there isn't creativity involved. It's essentially language. And someone said before that there's a base level of competency involved in making API decisions. It's more the argument of what's actually making you money or providing competitive edge. I can see edge cases where, with matching feature sets for two competing products, the API matters a great deal. API and functionality definitely influence each other, I just see it as a weak argument that copyright is broken when the interface is copied, not the implementation.
> It's more the argument of what's actually making you money or providing competitive edge
This would factor into the fair use analysis and the damages analysis, but not the analysis of whether or not the material was copyrightable in the first place.
PS. For what it's worth I agree with you that this isn't copyright infringement, I just think it's important to get the arguments for why it isn't copyright infringement right. The two arguments I like best are "the merger doctrine" (If there is only one way to write something, in this case a API that existing java libraries can use, then it isn't copyrightable) and "fair use" (Vaguely speaking an exception for copying we as a society don't mind, defined in the law here https://www.law.cornell.edu/uscode/text/17/107).
yep, APIs are a work of art. the API you chose would vary a lot by the individual who designed (and Acceptance tests they were required to pass) as such, there is a novelty in them. whether it is worth patenting or copyrighting is separate matter.
I agree there's nuance to the issue, and thst's where the argument is to be made. But I think it'd be a bad faith application of copyright or patent law, as your competitive edge largely doesn't come from API design but the product being interfaced with.
Exactly. And even then, database choice faces some of the same selection criteria. What's better supported, does it have well tested and documented client implementations (or do I have the time to write it myself), what features do I need, what features should I anticipate needing, is the performance good enough for what I plan on doing.
