I loved this recent tweet from Russ Shanahan, and it inspired me to write about why I agree with him.

I vividly remember when I started feeling this way. It was caused by me regretting rushing something into Curated before we launched. We were deciding the initial feature set, and one feature I had on the list was a sponsorship scheduling system. I had written some thoughts on how it might work, and it was a feature I needed to run this newsletter, but I hadn’t put enough thought into how it’d affect the product. We rushed in a primitive implementation, but I felt uneasy about it as soon as we finished it. I should have put it behind a feature flag and re-thought it after release, but I didn’t. I shipped it.

The reasons I regretted it weren’t all technical either. Yes, it was a fairly rough, half-baked implementation, but it also fundamentally changed the external perception of the product. Instead of primarily seeing it as a tool they could use to make a great newsletter, many people started to see it as a tool to make money. That wasn’t my intention at all. Making money with a newsletter is about so much more than just having a sponsorship scheduling system! 😱 If we had launched that feature more carefully, I think we could have avoided that being the focus.

That experience permanently aligned me with Russ’s thinking, and I now err on the side of caution when releasing features. For example, there are two enhancements to search in the Swift Package Index (#1228 and #1320 specifically) in progress right now. Filtering package search based on metadata and expanding search to include keywords and author results. Both features are working but are disabled in production because they’re not quite right. I held back the metadata filtering feature because even though it works, I wanted people who use it to understand what they’re doing with visual feedback. Same with author and keyword search. It works but currently only matches one author or keyword result and doesn’t support partial matches.

I’m confident that both of those features are good ideas, and you can certainly make the argument that both could ship as is without hurting the product. But I’d much rather enable them with a bit more polish.

It’s not just about what the feature does either. It’s about momentum. Shipping something gives us a dopamine hit, and if you’ve completed the fundamentals of a feature, it can be hard to get motivated to tweak it afterwards when you could move on to something entirely new!

The best time to stop development on a feature is before writing any code, of course. You can also make a good argument that shipping features early for feedback is worthwhile, but there have been more times when I’ve regretted shipping something I wasn’t happy with than regretted not releasing something.

Dave Verwer  






Software Engineer @ Runway – We're a team of former mobile engineers, now building a tool that makes mobile teams' lives better. If you're up for changing stacks to build the future of mobile tooling, working closely with awesome mobile teams across the industry in the process, you'll fit right in! – Remote (within US or European timezones)

iOS Mobile Core Engineer @ FAIRTIQ – FAIRTIQ offers a great company culture, and you get the chance to work on the core product and have a real impact. Your co-workers are smart and fun too! And we offer flexible working hours and remote work in the countries where we are based. – Remote (within European timezones)

Lead iOS Developer @ Loop – We believe there are accessible, impactful mental health solutions outside of therapy & medication. We are building just that, starting with a focus on Social Anxiety, a condition with no dedicated solutions impacting some 25 million adults in the US. – Remote (Anywhere)

iOS Engineer @ sengaro GmbH – We offer an exciting position in the heart of the Alps (Innsbruck) with technical responsibility and conceptual refinements of our long-term products. They are used in the medical field by paramedics and doctors to help saving lives every day. Become part of it and support people in emergencies! – On-site (Austria) with some remote work (within European timezones)

iOS SDK Developer @ Stream – You will write and maintain our open-source SDKs that are used by hundreds of our customers and consumed by hundreds of millions of their users. – Remote (within US timezones)

iOS Developer @ Kiva Microfunds – Our organization combines the culture and technological passion of an internet start-up with the compassion and empathy of a non-profit to create impact and opportunity at a global scale. Our team is growing as we pursue exciting new opportunities to create a financially inclusive world. – On-site (United States) with some remote work (within US timezones)

Senior iOS Developer @ Komoot – We love Tech. We love Nature. We work hard to make it easy for everyone to explore the world’s most beautiful places. Today, millions of people explore nature with our apps. Their experiences are what drive us and make us smile every day. – Remote (within European timezones)

iOS Engineer @ Fjorden – We are a small team and you would be our first iOS engineer, next to Florian our CTO. Together we will build & ship our camera app (around 60% done today), and design an SDK other camera apps can integrate to take full advantage of the Fjorden grip. – Remote (within European timezones)

iOS Engineer @ Branch – Branch is on a mission to help working Americans grow financially. We do this by helping companies accelerate payments and empower working Americans with accessible, fee-free financial services. We’re committed to building and delivering more inclusive and transparent financial products. – Remote (within US timezones)

Senior iOS Engineer @ onX – Are you an iOS developer who loves the outdoors? Join onX! If you’re passionate about writing great software, love playing outside, and believe in protecting access to public lands – then join our team, where we empower millions of outdoor enthusiasts to explore the unknown! – Remote (within US timezones)


Are you hiring? Let's keep this simple. You should post your job for free over at iOS Dev Jobs.


And finally...

What if you didn’t need a real rubber duck to explain your problems to? 🦆