Software Professional Personal Development

I’m a huge fan of “The Clean Coder” by Uncle Bob Martin. I really like how he describes the “software professional” responsibilities that we have as software engineers. A key takeaway from that book is that we must always be working to improve our skills in the craft of software engineering. Additionally, Uncle Bob advocates that it’s our responsibility to “sharpen our axe” outside of our “billable hours.” Meaning, we as software craftsman should reserve the critical, and limited time available, for actually building software for our employer for just that, building software, and that it’s our responsibility to spend our own time to get better at our craft. I agree with this.

Improve Your Self Improvement

I caught this article in issue 246 of the iOS Dev Weekly newsletter, “Improve your self-improvement” and it was right up this alley. The author, Arkadiusz Holko, makes some great points that compelled me to write this post. Specifically, he challenges us all to “improve our after-hours work.” I love that he even goes through the math to calculate that outside of a 9-5 job, one would have 70 hours a week of “other time.

software professional

That sounds like a lot, right? Well for me, I know it gets spent really quickly. And I struggle to find 1-2 hrs a night for “axe sharpening.” The point he makes in the article is that one should recognize that the time available to study your craft is precious, there isn’t much of it, and you should actively take action to make it more and more efficient. This totally rings true for me. Furthermore, he goes on to suggest a couple ways to help drive the efficiency of this time. I like the distinction he makes between “active” and “passive” learning. Personally, I get so much more out of “active” learning. Pardon the pun, but I learned this lesson in high school. If I’m taking notes, or actively engaging in the topic I’m learning, it sticks with me much better than if I just sit there and listen to a lecture. I want to apply this to my learning that I continue to work, so I ask myself, “how can I make this active learning?” One answer to that question that continued to come up, was that, just write about it. As I learn new things, it’s great fodder to use as something to write about. So that’s a prime reason why I’m writing on this blog. To bring a sense of active learning to my journey to improving my skills as a software engineer.

You Don’t Find Time, You Make Time

I recently read the book, “Extreme Ownership.” It was a book on leadership written by two former Navy SEALs. I loved the book and highly recommend it. One mantra they advocated in that book was that you don’t find time, you make time. As I’ve become a father, and a husband, and a software professional, and someone with personal interests, those 70 hours of “free” time a week have more and more contention. That’s where the authors are like, “make time.” This is often in the form of waking up early, staying up late, sacrificing on watching that TV show. Focus on your goals and what’s important, and eliminate the waste. That’s how you “make time” because you’ll never consistently “find time.” I read a great post on Medium titled “Always Eat Alone.” The essence of the post was right along the lines of this, “make time” mantra. I relate to this big time. Enhancing my programming skills aside, there are other things important to me like working out. As a result, I “eat alone” so that I can make time for working out over lunch during the work day.

Pomodoro Technique Works Well

I can’t recommend the pomodoro technique enough for the software professional. It works so well for me. The keys to success are: timeboxing your work sessions, and literally eliminating ALL distractions. Quit all programs on your computer that aren’t related to what you are working on. Put your computer on “Do Not Disturb.” And give it 110% for the timebox pomodoro. Then leverage the break well. Move around. Catch up on chats. Get a drink. Use the restroom.

Kindle Your Fire

To wrap this up, I guarantee you that if you “kindle your fire” consistently, day after day, above and beyond what you are “paid” for, you’ll reap dividends that you can’t even perceive. Things beyond what can be quantified by monetary value. You’ll grow personally and as a software professional.

Happy cleaning, and happy weekend.

Blending Cultures: The Best of Functional, Protocol-Oriented, and Object-Oriented Programming

realm.io recently posted a video that really resonated with me. The video was of a presentation by Daniel Steinberg at the 2016 try! Swift conference. His presentation was titled “Blending Cultures: The Best of Functional, Protocol-Oriented, and Object-Oriented Programming.”

What I Liked

I’ve been having some self doubt lately, specifically around what feels like an overwhelming mountain to climb to re-program my mind to think in a functional way.

blending cultures

I’ve certainly made progress, and as I’ve written before, one of the main reasons I started this blog was to capture my learnings along the way in that area. A year ago, reading Functional Swift by Chris Eidhof, Florian Kugler, and Wouter Swierstra I kind of had my world turned upside down. It was really what first opened my eyes to this new way of programming. Fast forward to today, as these new functional techniques gain more and more appeal in my mind, I start to wrestle with the question, “Well what about all that object oriented stuff I learned and have so much experience with?” I spent many many years in Object Oriented languages (Java and Objective-C). It’s where a lot of my go to tools in my toolbox are still based. So, are those all just obsolete in this new way of programming? While no one is saying so specifically, I do hear a lot of things like “Try to write code in the Swift way.” Or I see sample Swift code that is heavily functional. And I’m still unsure what a monad is, and forget about a monoid. It quickly becomes over my head.

It was very refreshing to hear someone I respect, Daniel Steinberg, present a compelling argument that these programming paradigms not only can live together, but also lead to a more compelling system design. Each tool should be appropriately used.

When all you have is a hammer, everything looks like a nail. And maybe that’s where, before really making the functional (or even protocol-oriented) shift, you see a problem and immediately think: composition! Or, inheritance! Watching this video, now I feel reassured that there’s room and even good purpose for some of those older trusty tools (object oriented programming).

I Owe A Lot To Daniel

Back in 2008, when I was just diving into iOS programming, I attended a course by the Pragmatic Studio taught by Daniel Steinberg and Bill Dudney. It provided a critical foundation of learning, and really introduced me to the community of iOS development. I loosely maintained a relationship with Daniel too. About a year later, I hired him through Pragmatic Studio to come teach a similar course on iOS engineering at my employer for others to learn as part of our efforts to kickstart mobile development. Then fast-forward about five years, and we crossed paths again at CocoaConf 2014 in Boston where he put on a spectacular day long introduction to Swift, and then gave an incredibly passioned keynote during the conference. Thank you Daniel for everything, if it wasn’t for you, I wouldn’t be where I’m at right now. I continue to learn from you.

Happy cleaning.

TDD in Xcode – Can’t Refactor Swift Code

Red. Green. Refactor. That’s how I’ve memorized the steps for test driven development. Uncle Bob breaks them into a little more detail if you’re interested in something a little more long form. TDD in Xcode is pretty seamless, until you get to the refactor step. Xcode can’t automatically can’t refactor Swift code.

Refactoring Is Broken For Swift Code

Xcode does not currently support any refactoring of Swift code. If you attempt to use Xcode’s builtin refactoring tools, you see this:

Can't Refactor Swift Code

. From my earliest days of writing Swift, this has gotten under my skin. This is friction to my flow. I want my IDE to make it feel like I’m coasting downhill, rather than going up an incline.

Can't Refactor Swift Code

Additionally, I also take this as a sign at Swift’s maturity. I’ve since come to see the light, and no longer question Swift’s long term viability, but either way an error message like this should be embarrassing for Apple. And then the fact that it hasn’t changed in almost 2 years…

For more context, if you right click in Swift code to bring up the context menu, any of the options in the Refactor menu show that error message.

Can't Refactor Swift Code

Consider An Alternative – AppCode

This weekend I downloaded App Code by JetBrains. I’ve never tried it. Recently it specifically caught my eye that two people I respect, Orta Therox and Jon Reid, evangelize it and use it. JetBrain’s IDEs are renown for the abilities to support test driven development and refactoring. I’m looking forward to giving it a go. I’m in the 30-day trial right now, and I’m committed to learning all it has to offer to make my own impression. So far, I’ve been able to open a non-trivial project and run it in the iOS simulator, no issues. Next, I’m going to do some research about how to best use it, what it offers, and immerse myself in it. I’ll report back here along the way with my findings. I’m just hoping that while Xcode can’t refactor Swift code, I have better luck with AppCode.

Happy cleaning.

“Real World Mocking in Swift” talk by Veronica Ray

Today I watched a talk “Real World Mocking in Swift” by Veronica Ray hosted on realm.io. Mocks are something that I have found a TON of use for while striving to reach that elusive 100% code coverage from my unit tests. I have conflict on my mind on what the “right” amount of mock usage is, and I think Veronica hit a lot of important points in her talk.

A Tradeoff of Using Mock Objects

When using mock objects in your unit tests, there’s certainly a point at which readability and maintainability of your tests suffers in exchange for reaching 100% coverage. The tradeoff in my mind though, which is where I end up okay with these sacrifices, is that I rarely find the need to go back and change the code under test in such a minor way that the resulting changes to the tests are either minor tweaks, or major surgery to rewrite the tests. To say that another way, I feel better about the higher code coverage, despite less maintainable tests.

I Miss You OCMock

I used the hell out of OCMock during my days as an Objective-C developer. I loved how easy its API enabled me to quickly mock out 3rd party classes in order to test edge cases in my own code. I was bummed when I learned that the runtime hackery that enables OCMock simply isn’t possible in Swift. Since then though, I’ve come around to making my own mocks. It really isn’t that hard, it does take a little but more time, but I think it forces me to make some more protocol oriented choices in your code than I would otherwise have thought about.

Benefits of Mock Objects

Veronica specifically calls out three benefits of using mock objects that I totally agree with:

  1. It will make your tests faster.
  2. It will increase the coverage of your test suite.
  3. It will make your tests more robust.

Regarding #1, imagine you have a complicated method that runs a time consuming algorithm to tell you if some model object matches some criteria. When writing a unit test for a class that uses this algorithm, you don’t want to have to rely on this slow processing each time your tests run. By using mocks, you can simply force a response of true or false depending on what you’re trying to test, BOOM, FASTER!

As #2 states, mocks will increase the coverage of your test suite. I find this to be true especially with testing error handling. Often, some third party code I’m using will provide hooks for custom error handling in the event that things go wrong (imagine a failed object initialization). Without needing to reverse engineer the third party code, and intentionally code up a scenario in which the error handling will be triggered, you can simply code up a mock that forces the specific error scenario to trigger so you can write tests for your error handling code, BOOM, MORE TEST COVERAGE!

Along the same lines as writing a mock to simulate an error case for a failed web service connection, simply using a mock to provide a static API response is a great way that the #3 benefit is realized. You can then write tests that don’t depend on making a slow network connection and instead use the 100% reliable mock to always simulate expected response.

I don’t think anyone would dispute the value of mocks. I think it’s more of a cost/benefit tradeoff in one’s mind to buy in that the additional amount of coding is worth it.

Going Deeper on Mocking in Swift

There are a couple other topics that jumped out at me in this video that I’m going to save for dedicated posts throughout the rest of the week. Here’s a teaser:

  1. My reaction to Veronica’s claim that partial mocks are an antipattern.
  2. Veronica gives some guidelines as to “what makes a good mock.” I agree, and I’ll give you an anecdote of a time that I learned this lesson the hard way.
  3. Veronica talks about dependency injection. I learned of a cool way to do this with protocols when needing a different implementation per target.
  4. My opinion of using the term “mocking” to mean anything that is a “test double.”
  5. Veronica references some Swift mocking frameworks. I’ll provide getting started examples.

Hi, I’m the Clean Swifter

Hi, I’m the Clean Swifter. I’m setting out on this new adventure for a couple reasons:

  • I want to learn how to write better Swift code
  • Figuring out something to write about will compel me to learn something new
  • Writing about something requires a higher level of understanding, thus I learn more
  • I like helping others learn
  • I want to understand what it’s like to be a content creator on the web

At this point, I have it in mind to focus this blog on certain aspects of Swift: how to test it, how to automate delivery of Swift apps, and design patterns that help write better Swift code. I work on an awesome team of mobile developers, and several months ago we took the dive to write all new code in Swift. A year or two ago, I read Uncle Bob’s, “The Clean Coder: A Code of Conduct for Professional Programmers” and it was life changing. One thing in particular that really stuck out, was the sense of responsibility that Uncle Bob conveyed on us software professionals. Just like a professional athlete practices, trains, watches tape, programmers should mimic this discipline. At some point in our day, we are getting paid to write code. This effort should be of the absolute highest quality that we are capable of. To be the best that we can be, we must learn, practice, and polish. That’s where this site comes to help. I want it to be a resource where readers can learn. I want readers to provide feedback to me. I want to learn more, and share it with you along the way.

A quick sampling of topics I want to focus on here at Writing Better Swift include:
– Test automation
– Automation of app release and delivery
– Test driven development
– Writing Swift in the functional way
– Software engineering best practices

Cheers to this new journey!