> I don't really understand why some prefer to travel outside of Sweden in June/July/August since those are the best months to be around (and it's high tourism season anywhere else in Europe).
I live in a part of Canada where the summer months are the best months to be here. I used to spend lots of the summer here and travel mostly during less pleasant parts of the year until I had kids. Now they’re out of school for the summer so that’s when we travel… especially to see aunts and uncles who have kids, who are also not in school and thus available to spend time with us when wee visit.
Do a roadmap. Fixed scope small project that you get paid for where you define requirements. Deliverable is a functional requirements doc. It derisks the project for them, and gives you more confidence when quoting a fixed scope fixed price project. You just don’t guarantee timeline. I’ve been doing it for over a decade - it works wonders.
> you have to realize that there will be fewer such startups if a tax on unrealized capital gains is passed, and that VC activity, along with the future startups chasing their money, absolutely will move to countries without such a tax.
That's a bold claim. The tax-averse amongst us say that, but in my experience investment flows to the best ideas / best distribution / best businesses. If those people are in the US because they're citizens, the capital will flow to the US, and investors will take the hit.
I run a one-man dev agency that staffs up a team to help non-technical execs build their v1. Here are some learnings:
1. There are three common dev team models: in-house, individual freelancers who eat what they kill, or agency (where you're sold by a principle and then juniors do the work). I recommend to all my prospects that if they can find a trusted lead dev, they should go that route - it's more economical for them and when I roll off a gig I set my clients up with the senior dev that built their app. Next best is eat what they kill freelancers - more expensive, but faster and incentives are pretty aligned. I would recommend NOT working with a fully staffed agency - they make money by having juniors do the work and incentives are often not aligned - they have staff on the bench they need to feed work to, so their incentive is to keep running the project until the client is out of money.
2. I just wrapped an MVP build in logistics for a European client. There are lots of devs who want to work on interesting technical problems, and for whom the industry doesn't matter. I hired two devs to build the MVP and both were keen on the gig. That said, it's hard to attract and evaluate good talent without at least one of those folks in house, which is what I do when I staff up a dev team to build my client's MVP.
3. Transitioning from third party to in-house - I'd pick the key pieces that are isolated from a business process perspective from the rest of your existing tool, spec them out with wireframes (https://www.reemer.com/consulting/roadmap), and build those. One of the biggest failure modes with building software in general is not enough definition of what "done" looks like when it's cheap to iterate and change (i.e. before code has been written). It's painful to write a long spec and wireframes (I've been doing it for 20 years) but once you've fleshed our your v1 and agreed on ~95% of what the final product looks like, it's generally pretty straight line to writing the code and shipping the product.
4. Re: quagmires - you need someone wearing the product management and engineering manager hats. Product will ensure the app's functional and technical requirements are clear, and an engineering manager will ensure your dev team doesn't get stuck spinning its wheels. In early-stage projects one person often wears multiple hats. Later on you can scale it up to an individual PM and Eng Manager in addition to your devs, if necessary.
Happy to chat more if you like - no sales pitch... just drop me a line a [email protected].
Was looking for one in Canada. Tried this out and it seems like some of the data is missing from where I live (halifax). Got an email I can hit you up at? Mine's in my HN profile - couldn't find yours on HN or your site.
Personally I’d way rather work on that software than some social network. I like unsexy b2b and would state that right out if I was interviewing for that company.
Which I think is the point - it takes all kinds and you’re better off picking the person who wants to be there than who’s just looking for a job.
The broader point is if you care about sports you understand the passion and that there’s often “a way” of doing things in a sport, you learn it, and you move on.
You don’t argue for 10 minutes that your way of displaying a box score is better than how literally millions of fans expect it to be.
Enh. When I interviewed at ESPN the first few questions were about sports knowledge: were you a fan who understood the storylines and stats? Or did you just want a job?
If you had somehow managed to slip through the HR screening without being a sports fan then the day of interviews would root that out and you would not get an offer.
It ensured that everybody who was there lived and breathed sports and would run through walls to create a great product.
Compare to later when I worked at FOXSports.com where sports knowledge was a bonus. The product was worse and the team had to spend too much time (more than 0 minutes) explaining to a front end dev why a baseball box score had an order that stats were always displayed in because that’s the way fans expected it (true story).
I think the value of the question is that, all things being equal, do you want the person who wants to be there because they have a connection to what you do, or do you want someone who just wants a job?
Induction requires a specific type of pots and pans. When we switched to induction we were pleased that we didn’t have to buy a single item to use our new stove.
In other words it really depends on the cookware you have today - it may require new cookwar, but it may not.
Boy would I love an task manager to respect the fact that work happens in other tools, and provide a centralized layer on top of the tools I integrate with.
Agreed re: 18 months. Been using Things for 8-9 years now, tried Sunsama, Todoist, and Amazing Marvin but keep coming back to Things.
Godspeed looks interesting enough vs Things to kick the tires b/c:
1. Speed of date picking and moving todos (choosing dates in Things is a mouse operation and I do it multiple times a day. It's 2024 guys, we don't need calendar pickers when we have command palettes)
2. Image support (super annoying I can't include files in Things. Again... 2024, come on)
3. Sharing lists (can't do in Things which doesn't respect that todos are often collaborative / shared)
I have both Things for Mac and iPhone. The money's trivial for organizing my life. I don't want to spend a second more in my todo app than necessary and would rather pay to have things just work.
Lobsters have been in the Canadian Maritimes for centuries.