adwmayer | 2 years ago | on: What I’ve learned from 35 years of wearing computerized eyewear (2013)
adwmayer's comments
adwmayer | 3 years ago | on: Katamari Hack (2011)
adwmayer | 4 years ago | on: Ask HN: Who is hiring? (May 2021)
Getsafe is a fully digital insurance company that allows you to cover yourself and your universe simply from your smartphone. Opt in, opt out, switch it, change it, make it yours. It’s 100% digital, you know exactly what is covered and what is not, and you pay only for what you need when you need it.
Our tech stack is React/React Native and Ruby/Rails running on Heroku. We're looking for engineers to help us build a more scalable frontend and backend so we can keep expanding to new insurance products and markets (we recently went live with car insurance in Germany among others). Insurance is one of those things a lot of people look at as boring, but we're looking to make it easy and fun for people.
More info at https://hellogetsafe.com/career or reach out to a.mayer (at) hellogetsafe.com
adwmayer | 5 years ago | on: Ask HN: Who is hiring? (December 2020)
Getsafe is a fully digital insurance company that allows you to cover yourself and your universe simply from your smartphone. Opt in, opt out, switch it, change it, make it yours. It’s 100% digital, you know exactly what is covered and what is not, and you pay only for what you need when you need it.
Our tech stack is React/React Native and Ruby/Rails running on Heroku. We're looking for engineers to help us build a more scalable frontend and backend so we can keep expanding to new insurance products and markets (we recently went live with car insurance in Germany among others). Insurance is one of those things a lot of people look at as boring, but we're looking to make it easy and fun for people.
More info at https://hellogetsafe.com/career
adwmayer | 5 years ago | on: Why is Apple acting like an asshole?
adwmayer | 7 years ago | on: Billboards are an old but booming ad medium
adwmayer | 7 years ago | on: Confessions of a programmer: I hate code review (2010)
1) Automatic code formatters/linters before the code gets to review. When everybody knows there's a formatter, reviewers can spend less time looking for formatting issues. Generally, people are more inclined to take a quick look at the code then too, because they know their focusing on "just" the logic, which helps with getting a review sooner.
2) Smaller sets of changes up for review. Yes, this might mean more code reviews overall and more process, but it's way easier to catch a bug in a < 100 line change than in a 1000+ line change. This also means keeping the contents of the review as focused as possible. If you want to refactor some major chunk of code because it makes the actual thing you're trying to do easier, go for it, but do it in a first code review and separate the logical changes. This goes to both reviews being more straightforward for the reviewer to get through and them wanting to do it in the first place. I'm way more likely to avoid a massive 30 changed files code review than a quick 5 line change, because I need way less focus to review the latter.
3) (this one might be controversial) Early code reviews where appropriate. If you're making a change that's more likely to be totally rejected, get it into code review as soon as the basic structure and logic is in place and ask somebody to review it as quickly as possible. This is before tests are ready and every todo is completed or whatever else. The review should be quick and dirty, but at least that way you know if you should be proceeding with your current path at all or change course. Again, this means more time spent reviewing, but it's a lot better than getting a review after a week saying what you just wrote has already been done, or it totally misses goal, or it has some critical issue, or whatever. This helps a lot with what to do while you're waiting for feedback too. If you've got this type of code review up then you can keep working on the details while you're waiting on feedback. If your code review doesn't fall into this category, you're probably relatively safe to start working on the next thing, because at most you'll need to make some small changes to what you're working on, not throw it out altogether.
4) Making sure code review is considered a priority on the team. That includes the team lead prioritizing code reviews and encouraging others to prioritize code reviews. If the code doesn't get reviewed, it doesn't get shipped, so it's ultimately more important than writing new code.
adwmayer | 8 years ago | on: How a ’50s-Era New York Knife Law Has Landed Thousands in Jail
adwmayer | 8 years ago | on: How We're Building a Business to Last
adwmayer | 9 years ago | on: Millionaire teachers: a lucrative online marketplace for lesson plans
adwmayer | 9 years ago | on: Show HN: Typeflow – Type-ahead as a Service
adwmayer | 9 years ago | on: Ask HN: Private API Aggregation Services
adwmayer | 10 years ago | on: Show HN: Lion, a fast HTTP router for building modern scalable modular REST APIs
adwmayer | 10 years ago | on: Rediscovering MVC
adwmayer | 10 years ago | on: How to rescue people from deep poverty, and why the best methods work
adwmayer | 10 years ago | on: Ask HN: Any C programming Postgres wizards willing to port 460 lines of code?
adwmayer | 11 years ago | on: How we handle time off