Discovering Best Practices in Swift

The Swift community has the opportunity to make a difference

The rules are really just opinion informed by experience.

Hey, everybody. Today, we're going to be talking about emerging best practices in Swift. So lets get started. When we learn a new skill, anything, but in particular, Swift, 'cause that's what we're all here to talk about, we crave rules; we want more than anything for an expert to come along and tell us how to do something. We want a recipe for success, specific steps to follow in order to be successful in doing something. Something really magical happened last summer, Swift was released and there were no experts. There was nobody. There were certainly experts at Apple in writing Swift compilers. I would say there are far many more of us than there are of the Swift experts at Apple, and we didn't really have anyone to tell us what to do; we didn't have anyone to tell us what to think. And the interesting thing about beginners is as people get more experience with something, we realize that there are no rules, and that the rules are really just opinion informed by experience.

We're going to be talking about best practices, specifically, how we find new ones

Today, as a community, we're no longer developers, but we're not experts either; we're something in between. What are we? And what do we do next? Well today, we're going to be talking about best practices, specifically, how we find new ones. As a community of Swift developers, we're all sort of figuring it out as we go along, and that's totally fine, but there are ways that we can be smart about that, too. We're going to talk about three things today. First, learning is necessary, but it's not sufficient to find new best practices. Second, like coding, learning is a skill that can be refined and practiced over time. Third, if you want to find new best practices, if you want to be awesome, you can, it's really actually pretty boring. There are very specific steps that we can take to do this, pretty banal. That's all about reaching our full potential and it's something we can all do.

...if you want to find new best practices, if you want to be awesome, you can.

Learning: Necessary, but insufficient. Something that we need to do in order to find a new best practice, but it's not everything we need to do, but it is necessary. We have to learn in order to find a new best practice. It seems obvious, but I thought it's important to start with this first. Learning, I believe, is part of our job descriptions. Software development, software engineering if you prefer that term; it's a profession like law or medicine. We expect lawyers and doctors to stay up to date on the state of the art of their profession, and I expect the same of software developers too. It's fundamental to what we do, and I really believe that it is super important because we're not just individuals, we're a community. We are a community of individuals that is larger than the sum of its parts, and all of our individual actions and decisions affect the whole in a small way.

We need to maintain this perspective because if we see that the community is taking a direction that we like or don't like, we need to be aware of it. If we see that there is a new idea, that is a new best practice, functional programming for example, then if we're not aware of the community we won't be aware that this is becoming a best practice in Swift. I really do believe that programming is fundamentally, a social activity. Computer programming is a social activity. In 2007, Jeff Atwood wrote, ”What good are nifty coding tricks if you can't show them off to anyone?”.  What good are Swift best practices if you don't share them with anyone? 

What good are Swift best practices if you don't share them with anyone?

We need to look for new ideas in order to get to new best practices. Not all of the new ideas will become best practices, obviously; there are some bad ideas out there, but we need to find the new ones in order to find the best practices. The funny thing about learning is that it is not comfortable. We may enjoy learning, but it is not a pleasant experience. Picasso said, "Every act of creation is first, an act of destruction.” I think that applies to learning as well. When we learn something new, we destroy a little bit of ourselves in the process. We destroy our innocence and ignorance of something when we learn something new, and that destruction, that death, hurts a little bit. It hurts to die, but it's a natural part of learning and it's a natural part of being human. We need to seek out new ideas and learn new things.

Wait a minute, what does that mean? What does new mean? Well, in reality there are actually very few new ideas. I mean, there are very few things that are thought up and are original. Someone else has had an idea somewhere, some place. Invention is not enough. We need to look at existing ideas that are new to us. Embrace them; especially new ideas, and don't throw the old ones away. Functional programming, again, is becoming very popular in Swift; does that mean that we should forget everything about object-oriented programming? I don't think so. I think that there are things to be learned from object-oriented programming. I think that we should keep it around, just in the back of our heads, at least. Be willing to change our minds. New ideas come up and we have new preferences. That's okay. It's totally fine to change your mind later, to like object-oriented programming or even Objective-C, and then decide something else is better later on.

Learning new ideas is how we discover new best practices

Learning new ideas is how we discover new best practices. How do we actually learn those new ideas? Well, learning can be learned. Learning is sort of a meta-skill. It's something that no one really teaches us, and society expects us all to figure out for ourselves. And I understand why. Everyone learns slightly differently. But there are things you can do to learn that are pretty universal. For example, practice, practicing. It takes practice to master a skill. Learning is a skill, therefore, it takes practice to master learning. Small actions repeated often enough become second nature. When a new tool or a new library comes out, be on the lookout for these. When they come out, try them. If you think they're stupid, please try them. I really want you to go out and try things that you think will fail.

In the scientific community, there's this idea that science is people in white lab coats who have an idea and they make an experiment in order to verify their idea. That's not science. Science doesn't happen when an experiment is done, and we verify what we thought before. Science is done when it turns out we were wrong. Learning is done when we try something new and find out that we were wrong. So where do we actually find these new ideas? Well, there is actually a ton of open source code. There's this awesome website called GitHub, and you can actually browse coding, as sort of a social platform. I think it's gonna take off. There are a ton of blog posts out there. There are books and podcasts and screen casts and conferences, and all sorts of places and venues that you can go to learn new skills and expose yourselves to new ideas. I really like programming newsletters because going out and looking for ideas is a lot of time and energy, and I'm a very busy person. So I'll let other people aggregate it for me and just send it to my inbox. It's great.

Follow people on Twitter. I mean, people who aren't just iOS developers. Follow Ruby developers, JavaScript developers, Erlang, Haskell, Java, whatever. There are other programmers who don't write iOS in the world. Amazing. Why don't we take a look and see what they have to say. What are their best practices? Why do they work for them? Would they work for us? I don't know. We won't know until we find out. Maybe we should follow people who aren't programmers at all. Importantly, when we're looking for new people, and new ideas, we must not dismiss them. Dismissing an idea or a person is as bad as throwing an idea away. It's worse, even. Don't discount people for their ideas. Their ideas make sense to them. Newsflash: People who make decisions, make decisions based on their context and you really can't know what that is. People are allowed to disagree with you. Deal with it.

How do you know if it’s a best practice?

So you have a new idea. What now? How do you know if it's a best practice? Well, there's really not a satisfying answer to this. Sorry. You'll know it when you see it. It's a feeling, it's an intuition, it's something that you recognize after you have enough experience, after you practice enough, you just see something and you're like, "That is awesome!" So what do you do? You found one of these things, and you're like, "Hmm, I think this is a best practice. I think that this pattern is something that is a best practice in Swift." What do you do? Ask yourself why. "Why this? Why is this awesome?" And write your answer down. Either physically write it down on paper, or type it into a text editor and actually save the file somewhere that you'll be able to find it later. Collect these answers. Look for things that are common. If there are a bunch of different ideas that you think are best practices, what do they have in common? What sorts of things make them best practices? 

With this, you'll be able to form a set of principles that you can measure best practices by, measure ideas by. And once you have those, you can do something really cool with them. Those principles become a measuring stick that you can use to determine where an idea is appropriate. Not if it's a good idea, but where it's appropriate. This isn't a framework for you to measure, "Is this a good idea or a bad idea?", it's really much more complicated than that. Basically, we want to use principles to get better at recognizing best practices faster and earlier. Prune the best practices, add to them, refine them over time. This is all very philosophical and whimsical. What are the actual physical steps you need to take? I mentioned at the beginning of the talk that it's pretty boring, and it is. There is a banality of awesome. The steps that we need to take as a community and as individuals are very straightforward and a bit dull.

Make learning and discussing new ideas a part of writing software wherever it is that you work.

Techniques can vary, but I like the standard how to achieve a goal technique. Step one, use the buddy system. Find someone or several people, a manager, a colleague, friends, a Slack channel, work, or in the community. Brainstorm, discuss ideas. If you find an interesting blog post, share it with them and debate the merits of the blog post's ideas. Critique it, modify it. How can you make it better? How can you make it more suitable for your needs? Formalize this behaviour into your day-to-day jobs. Make learning and discussing new ideas a part of writing software wherever it is that you work.

Next, we need to write down some KPIs. This is a marketing term that gets a lot of bad rep, but it's actually kind of a useful item. Key Performance Indicators, things that depend on your goals, which we'll get to in a moment. KPIs are things that are important, things that matter, and it's really important to know what they are before you start learning this process. There is a saying, "You cannot manage what you do not measure,” and I think that is very true. We won't know, individually, or as a team or as a community, if we're progressing if we don't actually track our progress. It seems obvious when I say it out loud, but it's something that we often neglect.

So we have our KPIs, Key Performance Indicators. Next, we need to come up with goals around them, things that we want to achieve. In high school, I learnt about the SMART goals. Did anyone else learn this acronym? I thought it was the stupidest thing in the world. I threw it out, and here I am 10 years later, discussing it on stage. SMART goals are specific goals. They are measurable, achievable, relevant, and time-bound. Let's discuss each of these specifically.

 Be realistic, but ambitious.

Specific, you need to be specific about what you want to accomplish. It's just answering the question, "What do you want to accomplish?" Read 10 blog posts, try one new library, give a lunch and learn, read a book. Very simple things. After you're specific, you need to make sure it's measurable. How will you know when you've accomplished a goal? Come up with a definition of done. Now, it needs to be achievable. Be realistic, but ambitious. This shouldn't be something that's easy to do, but it shouldn't be impossible, either. Take it seriously. This is part of being a software developer, and I expect us to take it seriously.

Next, a goal should be relevant. I don't know if it applies much to coding, specifically, because we're building abstract machines in our heads and turning them into numbers that a computer can understand. I'm not sure what isn't relevant to coding. If you want to study poetry or athletics or math, I think all of those things can be relevant to software development. If you want to read TS Eliot in order to improve Swift coding, that's amazing. But you should reflect on the lessons that you learned from those experiences, for sure. Reflect on why it turned out to be relevant even if you didn't know so when you started.

Set yourself a deadline.

Finally, time-bound. Humans are really great at procrastinating, and if we don't give ourselves a deadline, if we don't say that we're gonna achieve something by a specific time, then it won't happen. We need deadlines. Use Google Calendar with reminders. If you're going to meet monthly with your colleagues in order to discuss things and measure your goals, then make sure you add a reminder a week before, three days before, the day before in order to make sure that everyone is prepared for this meeting. Awesome. Set up recurring events. Discuss your progress at these meetings. Those are the SMART goals. That's how you find best practices. It sounds so boring because it is. 90% of finding best practices in Swift is just being good at using Google Calendar. Soon we will develop an intuition.

So let's wrap up. We talked about learning and how it is a part of our job, it's part of our profession, part of our community. I said learning isn't easy, nor is it comfortable. So we need to hold ourselves accountable, hold each other accountable. As people learn a skill, they advance through beginners, competencies, expertise. It's a progression that is actually studied in psychology. As beginners, we seek out new rules, and new rules, and new rules. And then, we have so many rules that we realize that different rules apply in different situations. And then, we learn that there aren't really any rules at all, that expertise is really just informed opinion, and rules are only opinions. As a community, Swift developers are no longer beginners, but we're not yet experts; we're in between. We are competent. We're being crowded by new ideas. There are so many things to try, so many ideas to learn, that we're starting to form opinions on them. We're starting to think some ideas work in some situations better than others. Soon, with practice and more experience, we will develop an intuition of what is a best practice. Until then, as the saying goes, "Wax on." Thank you.

Q&A (18:51)

Q1: Hey, thanks for the talk. Do you think the surface area of best practices in Swift is the same as it was in Objective-C? I'm thinking in specific of how Swift has a much more opinionated compiler. So for example, the initialization process in Objective-C was a best practice, right? In Swift, it is enforced by the compiler.

Ash: Yeah, I said earlier that with enough practice, things become second nature. We don't have to worry about making sure we assign self to super init. That's amazing. And that frees up our brain to think about other things, about more interesting problems. I don't know if the surface area of best practices is bigger, but I think that with a more... It's hard to say. Swift isn't more sophisticated than Objective-C, but with a more capable language like Swift, I think that frees us up to come up with better ways of writing software in general. I think that even if the surface area is the same or different or whatever, then we still have an opportunity, more so than we did with Objective-C.

Q2: I think everything you said is great, and I feel like a lot of people in this room are already passionate about software craftsmanship. What I'd like to ask is kind of the devil's advocate question of pragmatism, and how do you prevent bike-shedding on best practice discussions, especially during things like code review? 

Ash: Sure. I believe that the dichotomy between pragmatism and idealism is sort of a false dichotomy. We can be pragmatic when we need to be, and we can be idealistic when we can be. I think that, as software developers and as members of a team and a company, it's our responsibility to make sure that we can be both. During a code review and during crunch time, maybe that's not the best spot to bring up tabs versus spaces. But in general, I think that programmers attach too much of themselves to their code. We are not what we build. We are not what we type. And I think we should be able to critique each other's code without it being personal, because it isn't. It's just part of our job. Does that answer your question?

Audience: I think so. I think you alluded to it with finding the best place, the best venue for those kinds of feedback.

Ash: Yeah, exactly. Obviously, that's gonna depend on your specific team and what you're working on at the time, your current deadlines and things like that. It's hard for me to stand up here and say that you should be thinking about high-level concepts when you may have been in crunch time for the past six months, and I know that sucks. I hope that, as a profession, we can start moving towards a place where toxic work environments like that, where you're perpetually just scraping by and you don't have an opportunity to learn, I hope that we can make that a thing of the past.

Q3: Hi, thanks. I enjoyed the talk. I just had a quick one about finding the time to have a learning experience with other colleagues. How can you help push that in your workplace, to get other people involved in the learning process, rather than just an individual thing? 

Ash: Totally. I really am an advocate for teaching as a way to learn, either through writing blog posts or discussing something with a colleague in a one-on-one. If you want to try and foster this educational environment at your workplace, be an educator. Orta, my colleague, and I, we taught a course for Swift at Artsy, and we had two tracks. We had a track for people who had never programmed before, and Orta led that in I TA'd. And then, there was another track where it was for people who could explain what object-oriented programming meant, and that was for the informed developers. People on the web team mostly attended that one. And I led that; and Orta, I TA'd.

We did this during a really slow part of our cycle in August, and it's been amazing. It took about a day to prepare one of the lectures. It wasn't really a lecture; it was sitting down for an hour with people in coding. They got out their Xcodes and then typed away and stuff, and it was really great. So a day of our time, times five, that's how many of these we did. We open-sourced all the materials online. Someone took that and translated it into Chinese, so now, other people can benefit from it too. I know at least one person in New York who is taking that and turning it into his own guide for how to begin Swift as a new developer. So if you want to foster this idea of learning as a part of your workplace, then teach others. I know that's a very reductive answer, and I'm not trying to be condescending. Earnestly, I think that you can benefit from teaching other people Swift too.