1,120 karma · joined November 22, 2009
t@thintz.com
My non-technical friends are extremely confused by passkeys and if they should use them and how to use them and I honestly don't have very good answers. It is a mess. I don't believe an inherit mess, but one created by the companies and projects trying to take advantage of the new system.
We are a small startup focused on creating optimized health outcomes by connecting patients to doctors and supported by regular lab testing. I'm hiring to build out our core engineering team, which I lead.
* I care deeply about creating a healthy work environment that supports and enables all team members to meet their own goals
* Opportunities for mentorship from a small but very experienced and skilled team
* We greatly value diversity and seek to build and understand from all perspectives
* We value high-quality, sustainable work
* JavaScript, NodeJS, React, Postgres
* You have at least a few years of experience engineering web applications at small companies
* You would enjoy the challenge of helping to improve a difficult codebase :)
* You would be ok working under HIPAA compliance and dealing with health-related integrations
* Salary $130K+
Interested or questions? contact: thomas.hintz at getopt dot com
I'm a Frontend Javascript web consultant specializing in React.js. Whether you're just getting started with a new React app, or transitioning from a different architecture, or in the middle of React development, I can help. Unlike many others I also have product management and founder experience. This helps ensure that the technical side is addressed while also meeting your business goals.
I've worked on Frontend heavy web applications with millions of monthly uniques as well as prototypes for startups. See some of my work here https://thomashintz.org/my-work
More info: https://thomashintz.org
Contact: contact [at] thomashintz.org
* Note that I typically work on a flat project rate with a minimum of $5,000, and most projects in the range of $10K-$70K. If the scope is undefined or the project is openended, I’m open to a weekly rate as well.
Also, shouldn't we be concerned that giving one company's algorithms control over who gets hired will be too much power in too few hands? And algorithms are not neutral. The people that make the algorithms have biases and discriminations just like regular people do but at least if your company does its own hiring you can work on figuring out what those are and how to address them. How can you do that if you depend on some proprietary algorithm?
And what about disabilities? How does your algorithm handle those? Racial bias? So many unanswerable questions.
I have many issues with the way most companies interview but giving up that process to a proprietary algorithm seems like the worst solution. This is not news to be celebrated.
Monopolies are not inherently bad. It's entirely possible to have a monopoly and have a great thing that everyone likes and is happy with and which keeps innovating. But under capitalism the primary incentive is the accumulation of capital which rarely lines up with creating something great long term.
Or her.
And there is no silver bullet. Advice like "Strong typing" or "functional programming" are not always going to be the best code for the task at hand.
* Software development methodologies, things like Mythical Man Month
* Computer Science history and basic theories and concepts
* Compiler implementation techniques.
* Anthropology and related subjects. Programs are written by people and for people so understanding people helps a lot.
The biggest thing is to approach things from all perspectives and an open mind. Learning programming languages of different types is great because the different language families highlight different techniques, concepts, and ways of thinking. No one approach or language is the perfect solution to everything. Try to aim for the largest perspective: functional, homioconic, machine like, pure OO, strict, lose, etc. You can look at the lineage of programming languages and what developed and derived from what and learn one from each group to get the broadest perspective.
Learning CS history and basic theories might not be directly applicable to your life but the knowledge that comes from it will show up in everything you do and knowing how to leverage it makes a big difference.
The value in learning about compilers, GCs, etc comes from being forced to learn, in depth, languages themselves and concepts behind them. If there was anything you didn't learn in depth in other areas they will probably show up here.
Everything you learn about programming and CS is ultimately dependent on humans and how we interact with computers. Understanding how we think will help you develop long lasting programs that are easier to understand and use.
Depending on your goals it may be useful to learn about the basics of how the hardware works, although that is more related to performance optimization than good design and good code.
Edit:
Learning about so much is a long process and never ends but if you want to write solid code long term, and not just do what's popular at the time, it's the best way to go. Just take it slow and do it at whatever pace works. It works best if you have toy (and not toy) programs to make in each language as you go. After you've started getting a broader perspective, in things like programming languages, it all becomes a lot easier and faster. You'll be able to learn completely new languages in a matter of days and be better at them than people that have been doing it for years, because you can break it down in to its fundamental concepts and all you have to do is learn the language libraries and syntax, which also starts coming quickly after awhile.
Put the effort in to learning new concepts, programming languages, methodologies, programming language history, computer science, and even broader subjects dealing with humans and how we think and form ideas. There are countless ways to write code and without having a broad knowledge of them you will only at best reach a local optimum and rarely choose the most effective solutions and designs. The worst thing you can do is stop learning and seeing other perspectives.
Technically it could support C. One of the reasons it is based on Scheme though is that there is a lot of code already, code written in Scheme. :)
Regarding batteries, the real issue there is how often you wake up the hardware from low power states. An OS like 3L could actually control that better than what we have today and give us better battery life.
Generally these are "unseen" features such as adding multicore support or adding support for a power saving feature on your graphics card.
> How are they going to try things out if your OS doesn't support any of the techniques they're interested in (i.e. novel ways of getting at hardware, novel ways of doing virtual memory, etc)
They are interested in a lot more than that. Check the 3L references page for a few examples. [0] Plus you can do many of those things with 3L.
> You realize that this sort of thing is a huge area of current research, right? Because it's a really, really hard problem?
Yes. But it is certainly possible and has already been done to some degree. Genera, for example, did it and a number of other real-world and research OSes have done it. Of course the real challenge is making it as real-time as possible but getting it most of the way there isn't actually that difficult.
Also, 3L runs in two modes: development or secure. In secure mode you can completely disable manipulation of source code (or strip it out) and mark all code as read only and have the system verify the code hasn't been modified when it is run.