Being correct, quicker

updated 10 months ago; latest suggestion 10 months ago

This proposal has been withdrawn...

Abstract

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.

Less abstract

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.

Suggestions

  • The proposal author responds 10 months ago

    Updated, I don't want to spoil it for you :)

    Does it sound clearer?

  • 007dca74c613a8f4ab1ed47c7562a1cae68df25a?size=100x100 007dca74c613a8f4ab1ed47c7562a1cae68df25a suggests 10 months ago

    Could you flesh this out and tell us how this is going to be a talk?