Being correct, quicker
updated 12 months ago; latest suggestion 12 months ago
This proposal has been withdrawn...
If something in your project wastes time or effort, why allow it to happen? By thinking about code in terms of reducing how many things can go wrong, you can tame spiraling tech debt and ensure you and your team can ship better products, faster - all whilst avoiding arguments about tabs vs spaces.
We'll look at two key parts of iOS development, and how to make each one better and less likely to cause you and your team problems:
Feedback on code: what is the best way to get feedback about your code? How can you make feedback quicker, more actionable, and less opinionated? You'll see how linting can reduce feedback times, style guides are a bad idea, and how PR reviews can be a blessing and a curse.
Code correctness: what is it? How you can make architectures and write code well enough to be usable in 5 years time. Using the principles of clean coding, refactoring, and thinking about creating compile time errors from runtime errors.
Updated, I don't want to spoil it for you :)
Does it sound clearer?
Could you flesh this out and tell us how this is going to be a talk?