One thing that I’ve seen over and over again is that best practices or coding standards that aren’t backed up with some sort of tooling are not consistently followed. I’m sure everyone has been on the team where there is one person that insists on using an ‘m’ instead of an ‘_’ in front of a private field name despite everyone else’s consistent opposite.
Fortunately, there are tools that can red flag this non-conformance and even prevent someone from checking in code that isn’t consistent with those standards. A lot of these tools are known and readily available for use on product code. Less tools and techniques are known for encouraging good testing practices.
One good rule for writing automated tests–unit, functional, or otherwise–is to avoid logic in tests. After all, we’re testing code to validate the logic in our products. We don’t write tests to validate the logic in our tests, so it is best to simply avoid it. Check out Google’s testing blog for a more in-depth treatment: Don’t Put Logic in Tests
So, now that we have agreed on this rule, what metric can we use to ensure we follow it? Cyclomatic complexity. For any of you not familiar with cyclomatic complexity, it is the number of paths through a particular block of code. If there are no decision points (if, switch, etc.) in a given method, then the complexity of that method is 1. You can find static code analyzers that can calculate this metric for just about any language, so what are you waiting for?
“Can’t refactor Swift code. Xcode can only refactor C and Objective-C code.” Ugh. I wonder where AppCode is with this…
When creating a new Tabbed Application from the Xcode templates, one of the first things that you’ll want to do is rename the view controllers that are generated for you to something that actually makes sense. Unless, of course, FirstViewController and SecondViewController describe the scenes you’re building. In a lot of the IDEs I use for other languages, something like this is as simple as Refactor -> Rename. Currently, that isn’t an option in Xcode for Swift projects.
So, what happens when you rename the view controller and view controller file? Nothing. Or, so it seems until you start building out the controller and none of your outlets or actions are available to you via Connections. This can be a bit of a head scratcher for someone who hasn’t encountered it before, so below are the rest of the necessary steps for renaming your view controller without disconnecting it from its scene:
- Rename your view controller class name and file name
- Select the scene that is using the view controller in the Document Outline
- In the Identity Inspector, select the renamed view controller in the Class field’s dropdown
One of the main themes of this blog is learning. A lot of people, including myself, were raised with the understanding that IQ is fixed and that you do the best with what you’ve got. I didn’t realize how limiting that belief was until I discovered that it wasn’t true! More and more research is showing that we are, in fact, able to increase our intelligence.
As it turns out, one of the most helpful things you can do when trying to increase your intelligence is to simply believe that you can. One thing that I’ve observed during my career–and, I am sure is documented by many other sources–is that the people who solve the most insurmountable problems are the ones who don’t know that they are impossible. It seems that the older I get, the harder it is to not quickly dismiss something before giving it a shot. I can’t stress the importance of overcoming this “sad path.” Just try it! You may be very surprised at the result.
Another key factor is learning to embrace failure as merely another mechanism for learning. By pruning the decision trees that represent things unknown to us, we gain a much deeper understanding of whatever it is we’re seeking. In other words, to better understand what is, it is helpful to understand what is not. All those failures start to work like gutter guards (you know, those things that we use to help children learn to bowl) to keep you on a path to success.
Embracing failure as a learning opportunity is a very important part of something called a growth mindset. I first encountered the growth mindset while taking a MOOC taught by Jo Boaler, a renowned professor at Stanford, on learning and teaching math. I highly recommend her course, How to Learn Math. In the course, she talks about some of Carol Dweck’s work, which ended up being a jumping-off point for me. Also, Khan Academy, one of my favorite resources, is also endorsing the growth mindset. Check out their short video about it here.
Do yourself a favor and do a little digging for yourself. Start with the video I linked above and then maybe see what you can find out about Carol Dweck and her research. Check out Jo Boaler’s blog. Get inspired!
It had been my intention for years to create a blog so that I could share all the interesting things I was learning in my software development career. For whatever reason, I never mustered the required energy to follow through. Enter John Sonmez of simpleprogrammer.com and his free email course on how to start your own blog.
John’s course lays out everything you need to know, step-by-step, to get your blog started and on its way to success. Setting up the blog, in the unadulterated words of Saliva, was as simple as “click, click, boom!” (as I typed that, I felt the immediate need to apologize.) After getting things set up, he shows you how to prepare so that it is easier to maintain momentum as you build your content. And, finally, he shares some tips on how to grow your audience. The coolest part, in my opinion, was the personal encouragement I received from John. What a guy!
I am also about halfway through John’s new book, Soft Skills: The Software Developer’s Life Manual, and recommend it to any software developer looking to up their career game. (And who doesn’t want to do that?) The book is very accessible and chock-full of information that I really wish I had 10 years ago; don’t worry, the information is every bit as valuable today.