I think I mentioned it briefly, but Focuses is built mostly with SwiftUI. Overall, I'm very impressed with SwiftUI. I don't think I would've been able to build the first version of Focuses as quickly as I did had I not used SwiftUI.

Focuses is my first "real" iOS app. My first app, Send To Nowhere, is a simple app using UIKit, Swift, and no storyboard. I'm still a novice when it comes to the iOS ecosystem. I'm a full-time web developer by day, so using SwiftUI felt familiar in ways. However, the declarative nature of it still feels quite foreign from time to time.

SwiftUI: The Good

I was worried that SwiftUI wasn't going to be mature enough to complete my app. I was surprised at how capable it currently is—despite it's many shortcomings—and I'm very excited to see it develop. It's not perfect, but I was able to use it for about 95% of my views. Even in the short time I have been building Focuses, I've seen great bug fixes and improvements come to SwiftUI. I'm very optimistic for it's future.

SwiftUI made some things in Focuses a breeze to implement. Take the animation when filling up the circle. That whole view, including the animation, took me about 10 minutes to make. Again, I'm not a UIKit expert, but I have no idea where to start if I had to make that same view without using SwiftUI.

Creating complex layouts like the calendar was relatively straight forward as well. I think my first implementation had too many nested views, which were being rendered too often, so it took a long time to load. But it was easy to go from idea to implementation quickly. I was able to iterate and make a much more performant version fairly quickly.

I also like how easy it is to use CoreData with SwiftUI. There were times that things weren't updating when I thought they should've, but I found ways around it. This was my first time using CoreData, so for all I know, I could be doing everything wrong and that's the source of my problems. Hopefully not though.

The main issue with CoreData and SwiftUI, in my opinion, is previews. I could not find a way to adequately seed that database for previews. So for much of the project, I did not use previews. Maybe I need to take another look at this.

SwiftUI: The Bad

SwiftUI is great at hiding complexity and implementation details, like when using @FetchRequest. However, once you want to do something that is more complex, like pass in params to your fetch request, things can get messy.

Here's a couple things I needed to use UIKit for:

1. Text fields that I wanted to become the first responder (i.e., receive focus when the view appears and show the keyboard).
2. UITextView. There doesn't appear to be a SwiftUI equivalent of this. I needed a multi-line text input for notes. I also wanted an input accessory view, and I believe this can still only be done using UIKit.
3. I wanted to set the scroll position of the calendar view so you would start at the bottom. The only way I could find to do this is by using a UITableView. I was still able to use my SwiftUI view for the cells.

There's also some things that just don't make a lot of sense. Action sheets do not work on iPad. You have to use a work around. iPad support in general seems kinda weak. I’ve found it tough to make layouts for iPad, part of the reason the first version of Focuses doesn’t have great iPad support. I need to spend more time figuring it out.

I also had a lot of trouble embedding forms inside other views, like on the privacy and about views. My solution is hacky and doesn't respond well to changing the system font size, but it works for now. Essentially, I have to give the form a set height based on my best guess using the font size. Additionally, I have to use .fixedSize(horizontal: false, vertical: true) on all the text so it would wrap properly.

I also wish there was a way to customize the navigation bar. As far as I can tell, you're stuck with it's color and font.

I'm hoping all these things will be addressed in iOS 14, or possibly even point updates of iOS 13.

Conclusion

The best resource I've found for SwiftUI is Hacking with Swift. The examples are fantastic.

If I were starting a new app today, I think I would still start with SwiftUI. I feel like I'm faster when I use it, and it's pretty simple to use a UIKit view if you need to. I think I've only scratched the surface of what SwiftUI is capable of. I need to delve deeper into animations and transitions.

I'm excited for the future of SwiftUI. I feel like it allows me to create things I would've dreaded to try a year ago.

If you're curious about how I did anything in Focuses, let me know on Twitter, or use the contact form. I can dig into the nitty-gritty specifics.

Here are a few numbers related to making Focuses that may or may not be interesting.

130 hours

This is the first project I have time tracked. The first commit for Focuses was on December 13, 2019. About 13 weeks later I submitted it for review. So that's about 10 hours a week. Some weeks were much less and some were much more. This also doesn't include times when I was thinking about the app when I couldn't sleep or showering and stuff like that. A lot of the work on Focuses was done early in the morning before I started work for my full-time job. 130 hours seems like a lot to me, but it's about 3 weeks of full time work.

147 tasks complete

I'm using Things to keep track of everything I'm working on for this app. This probably isn't that useful of a number since my tasks ranged from "iPad" to "Fix accent color on focus edit sheet". But 147 sounds kind of impressive.

183 commits

A commit is every time I make a change to the code and save it to version control. Only about a dozen of these were of the "Uncomment code I commented out" variety. My build number is based on the number of commits on the master branch. Again, this number doesn't mean a whole lot because some commits were changing a single color and some were adding multiple views and data models at the same time.

19 minutes spent in "In Review"

This surprised me. I submitted it for review about 7 am on March 9. About 6 hours later it moved from "Waiting for Review" to "In Review". Then about 19 minutes later it moved into "Pending Developer Release".

Let me know if there are any other numbers you're curious about on Twitter, or use the contact form.

Focuses is my take on goal and habit tracking. It is inspired by Myke Hurley's daily themes and Marshall Goldsmith's daily active questions. The idea is to have a simple and flexible system for scoring yourself on how you do towards your goals each day. There are 3 options, an empty circle, and half-filled circle, and a filled circle. What these mean is up to you.

When SwiftUI was announced at WWDC 2019, I began thinking of projects I could try it out on. An idea for a daily questions app kept coming back to me. It would be an app that asked you the questions you wanted each day. Stuff like "How did you do towards eating healthy today?" You would respond with some like "Bad" or "Good". I started a version of this app, but abandoned it. I didn't like that approach. It felt too constrained.

While listening to Cortex, I heard Myke talking about his system of rating himself on a scale of 0, 1, or 2. Those scores would add up to a daily score. I really liked that approach. It felt flexible and easy to track. I tried it on paper, but it didn't stick. So with the New Year fast approaching, I thought why not try to make a simple app to do it for me? I'm a novice iOS developer at best, so what I thought would be simple was not so simple for me. But after about 3 months of slow and steady work, I'm excited to release the first version of Focuses!

I made the app for myself. I use it everyday. Tracking my effort towards my goals has had a tangible effect on my life. It's helped me and I hope it can help others.

You can find Focuses on the App Store.

For about the last year and a half, my daughter and I have made a podcast. My daughter is currently a toddler. It's not always easy to produce a podcast with a toddler, but I have found the end product to be priceless.

Disclaimer: Because every child is different, this is going to be less of a how to and more of a "my experience with podcasting with a toddler."

Motivation

Toddler's are not always the easiest to work with. So why would I bring it upon myself to try to make a podcast with one?

Like many of my cohorts in the millennial generation, I’m really into podcasts. Like many podcasts listeners, I’ve thought “I should make a podcast.” Should might be a stretch. But I definitely could record audio and post it on the internet.

A couple buddies and I tried starting a podcast called Average of Averages. Being the tech nerd I am, I loved doing all the technical stuff of a podcast—recording, making a website, generating a feed, etc.—but I had trouble figuring out what could make out show different and engaging. Three white guys talking about nothing? How original. We never did figure out our niche. Finding time for three people to record also wasn’t easy. It fizzled out after two episodes.

I still wanted to make a podcast though.

Around this time, my daughter started putting multiple words together in cute little 18-month old sentences. I’m terrible at writing a journal. I’m also terrified that I’ll forget all the adorable things my daughter says. Then it hit me! Here’s a tiny human being, in my own house, whose schedule I have small amount of control over (more on this later), and I want some way to record her so I can remember how cute and little she was. There’s the podcast. The Lily & Sam Show was born.

Making the Podcast

After about a year and a half and a couple dozen episodes, I feel like we're finally at a place where recording and editing is a smooth process. It's taken a lot of trial and error to get to this point though.

Starting with One Microphone

We started recording with a single microphone, the Audio-Technica ATR2100-USB. I chose this microphone because it was recommended both by Jason Snell and Marco Arment (#4 on Marco's mega review). It’s a great USB mic. My daughter would sit in my lap and I’d move the mic up and down depending on who was talking. I quickly realized this was not going to be a great long term solution. She kept wanting to turn around and look at me and moving the mic between us often missed what she or I would say. Not great.

Upgrading to Two Microphones

I later purchased a second mic, the Pyle PDMIC58, a cheap XLR mic also recommended by Marco Arment (#5 on Marco's mega review). Since this was XLR only, I needed an USB audio interface.

I was able to borrow a Zoom H6 from a coworker. I was considering buying one because it would double as a recorder and an interface. I thought we might have an easier time recording if I could follow her around and record her in a less controlled environment. My microphones weren’t suited for that at all. So we tried the Zoom H6 as an audio interface. Turns out she loved having her own chair and microphone.

So I knew that was the direction we needed to head. My wife bought surprised me with a Behringer UMC404HD audio interface after I had to return the Zoom H6 to my friend. The Behringer was the most affordable decent audio interface that had more than 2 XLR inputs I could find. (I wanted to be able to have at least 3 inputs because my wife occasionally joins us on the podcast.)

I don’t know if you know this about toddlers or not, but they don’t stop moving. The problem with my daughter sitting in her own chair and having her own microphone, is she kept moving and touching the mic! So. Much. Noise. My daughter also liked switching seats with me for a while. That made editing a pain.

I also got a couple heavy mic stands to set on my desk (these ones). This lets us sit on opposite ends of the desk and face each other. In addition to being able to put the mics in the right place for both of us, this reduces the amount of noise bleed there is.

Editing

I edit in GarageBand. I don't love it, but it's free! I've gotten faster at editing over the months, but it's still a chore.

If you've listened to any of our episodes you know they are short, like 2–3 minutes. In order to get 2–3 of content, we now typically record for about 10+ minutes. At the beginning it sometimes took 20+ minutes to get 2 minutes of material. Most editing is cutting out the parts where it's quiet, she's running off to play with her LEGOs, or she is being too grumpy. Occasionally I move stuff around to make the conversation more coherent. It used to take me about an hour to cut 17 minutes of recordings down to 2 minutes. Now I can edit an episode in about 20 minutes. With 2 mics you get 2 tracks, which makes it easier to see who's talking where and what can be cut out. I always listen through once or twice with my eyes closed to make sure it all sounds decently coherent.

I tried so hard at the beginning to remove all of my daughter's mic bumps and the noise of her moving in her chair. Eventually I kinda gave up on that mission. I began to see it as the charm of recording with a podcast; hearing how lively she is while we record. I personally think it gives the podcast a bit of character.

One of the hardest parts of editing has been adjusting levels. Because my daughter moves around so much, sometimes she's too quiet and sometimes she's too loud. So I have to go through and a bunch of volume automation points all over to help it sound a bit better.

As she has gotten older and her language skills have improved, the editing process as gotten easier and easier. So the future is bright.

The Website

I will write more about the technical aspects of the website in another post, but lilyandsam.show pulls in data from my custom CMS at verygood.fm and generates the RSS feed. It's built with NuxtJS and is hosted on Netlify. Netlify made it simple to add a form for people to ask questions for the show. Those questions are emailed to me.

The Future

We're now recording the podcast about every other week, sometimes once a month. I love having these recordings. I love when my daughter runs up to me and asks if we can record the podcast. I love seeing her grin when she listens back to it.

Sometimes it's real tough to make. My daughter gets grumpy and hungry and doesn't want to record. Or she'll say she wants to record just get into my office and play. But on average, I'd say it's worth it.

I'll keep making it as long as she wants to.

A Message From My Daughter

My daughter wanted to help me type this. So the following is typed by her:

/.l  l., ÷¬;l¬…÷ln,no.,,;/,jllj

,g.,/on/j

Thanks for reading!

I've been working full-time as a software developer for almost 2 years now. I’ve learned a lot. I’ve messed a bunch of stuff up too. The question I’ve been struggling with is how do I know I’m actually becoming a better developer? Over the last couple of years, I feel like I'm becoming a better developer. But is feeling better enough?

What makes a good developer, IMO?

I haven't worked with or known a ton of developers, but I've worked with some great ones. Besides the actual code a developer produces, there is lots that makes a developer great. There is lots that make a developer great, but here are a few things that I think make a developer (and people in general) great:

1. They are approachable. They always have time to help the junior dev like me and give helpful feedback.
2. They know how to find answers. Because of this, they seem to have a super-human ability to know everything.
3. They volunteer to work on the hard stuff. This leads to them learning more because they stretch themselves.
4. They admit when they don't know something.
5. They are not afraid to admit they were wrong.

Unfortunately, all these things are hard to measure. I think most people can agree that the easy things to measure (number of lines written, number of tickets closed, etc.) have little bearing on whether a developer is great. So that's where I get stuck. I want to get better, I know what I think a good developer looks like, but how do I know I am better than I was a week, a month, a year ago?

Can getting better be measured?

I like numbers. They are easy to compare. But how do I compare something like being approachable? I could maybe find a number to represent it, like number of questions I get a day. I could ask people to give me a rating on how approachable they think I am, but I'm guessing the people who like me would rate me highly and the people who don't would rate me poorly, and that it wouldn't change much over time.

Let's assume I do find a number or a couple numbers to represent approachability. Over time, I think I would subconsciously, or maybe even consciously, find a way to game that number. I'd want to chase that good feeling that comes from seeing a number improve. My point is, numbers probably won't work very well. Are all metrics bad? No. Are most? Maybe. It's hard to find the useful metrics. But they do exist, I think. But I also know from personal experience that it is incredibly easy to focus too much on the number and not on the end result the number is supposed to measure.

So, is feeling better enough?

I'm now thinking yes, just feeling like you're a better developer is probably enough.

The hosts of one of my favorite podcasts, Cortex, talk about yearly themes. Instead of making yearly goals or resolutions, they have a theme. Whenever a decision or opportunity comes up, you can just look at your theme determine if the decision is on or off theme. I think a similar tactic can be taken with becoming a better developer. Instead of creating specific goals or measuring (pointless) metrics, just keep what you think makes a developer great in mind, and when situations arise, just ask, "How would a great developer act in this situation?". Sounds cheesy, I know. But that's the best I can come up with right now. It's not just wanting to be a better developer that makes someone better. It is knowing what you want to be like and acting more and more like that until you become that.

If you have any ideas or thoughts, let me know. I’d appreciate it. This is all still forming in my mind. What do you think makes a developer great? How do you know that you're getting better?