Sea Foundry is developing hardware and software solutions to address critical bottlenecks in coral reef restoration. We work closely with non-profit organizations and marine biologists throughout the tropics to enhance the efficiency and efficacy of coral restoration.
We are seeking an experienced full stack software developer to join our small team.
Skills and Experience We're Looking For:
- 5+ years of proven experience as a full stack software developer
- Proficiency in React and front-end technologies (experience with Tailwind and TypeScript is a plus)
- Deep familiarity with Rails or similar MVC web frameworks
- Basic knowledge of Python
- Experience with AWS technologies (e.g. S3, EC2)
- Passion for environmental conservation and coral reef restoration
Andrej wrote an interesting post some years back titled Software 2.0 about the direction he saw software engineering going. It's more about changes in software than the changes in the job market, but I suspect you'd still find it interesting. https://karpathy.medium.com/software-2-0-a64152b37c35
The author could share their public key. It's awkward today, but I suspect services will arise to make signing and verification of NFTs more user-friendly for artists and fans alike.
I really enjoyed this article and appreciated the author's sober take. That said I'm a little more optimistic about Web3.
While NFTs can be confusing, over-hyped, or even fraudulent it is clear that they give artists new power. The power to create a scarce resource, prove that they created it, and sell it for substantially more than they could could otherwise sell electronic collectibles. How much of this is due to hype and how much is due to the ability to record and validate the "deed" to the NFT on the blockchain? I think that's an open question that will be more clear over time.
The author also understates the importance of DAOs and smart contracts imo. The real power of a DAOs or smart contracts is not in replacing financial instruments, but in replacing legal ones. I think in a short amount of time it will not be unusual to see wills executed via smart contracts.
I'm sure you're not the only one, but I find multiple monitors invaluable particularly for front-end work.
I might find myself rapidly switching between framework documentation, developer tools, a preview pane, and a similar piece of code that I'm using as a template. I'm infinitely happier when each switch is an eye movement and not a jarring keyboard stroke that redraws the entire screen.
I'm curious if you're unphased by constant cmd-tabbing.
Feastin | https://feastin.com | Oakland, CA, USA | Full-time | REMOTE | React/React Native/Rails
Feastin is a food company. We believe that concepts like grocery stores and take-out will soon seem quaint. We think distinctions between groceries, prepared foods, meal-kits and take-out will be looked back upon as artificial. We're building a better, more efficient way to deliver food into your home. We launched in the Bay area last summer and are now operating with over 30 restaurant and wholesaler partners.
We're less concerned with your familiarity with the perfect set of tech skills and more interested that you can learn quickly, work hard, and work smart. That said if you have experience with React, React Native, or Rails you should be able to hit the ground running on day 1 and that's definitely a plus.
We're not into high-stakes interviews or grueling take-home tests that you "should" be able to do in a few hours. If after a quick chat w/ the team we think you could be a good fit, we will pay you for a 20-40 hour contract job and decide where to go from there.
Email me directly at [email protected] if this sounds like something that you'd be interested in.
Currently I'm using a hacky script that watches the project directory and rsyncs the project whenever anything changes. It works, but it's slow, and I have to manually keep the rsync --ignore flags in sync with the .gitignore file for the project. Hoping someone out there has something better.
It strikes me as a little absurd to say that taking shortcuts is always a bad idea. Let's look at a few shortcuts you might take.
Allow the page to break if the user's browser does not support websockets
If you know that 95% of your target audience uses modern browsers this seems like a reasonable compromise.
Don't write enough unit tests
Maybe you're using a library that is difficult to mock. Maybe most of your logic is happening at the db layer. Eventually you may want to thoroughly test this piece of code, but it's a ton of work to mock a database in a meaningful way.
Write a monolithic service instead of a modular one
While it's bad to let a single service grow too large, when you're starting out, it can be helpful to write it all out, and _then_ see how it can be broken apart. (It's often hard to foresee everything at the design stage.)
Finally, a lot of code ends up being never used. Nobody cares about well-factored well-tested code that isn't used. Sometimes a dirty version is the quickest way to tell if a project makes sense at all.
Installing extensions can dramatically slow down browsers. I wonder if the lack of extensions is responsible for the quickness users experience with a fresh install.