When Persistence Turns Pernicious

Monty Harper - Nov 5 '23 - - Dev Community

Stick with it! Be persistent! Keep after it! Learning to code means facing down challenge after challenge. We must embrace the difficulty.

On the other hand, we also must know when to quit; when to pursue a new plan; when to stop banging our heads against those proverbial brick walls.

As learners, we must learn to recognize when our persistence has turned pernicious...

Top Advice

When I teach songwriting, my number-one piece of advice is this: It's better to write one hundred bad songs in a year than to write one awesome song.

The writer of one hundred bad songs has learned one hundred lessons about songwriting. They have established a writing habit that will move them toward creating awesome songs on a regular basis.

Meanwhile, the person who wrote one awesome song spent their year learning very little about the process of songwriting. Even if they did (against all odds) manage to achieve awesomeness, they will not have armed themselves with the tools to do it again any time soon.

Great Advice is Universal

You see the relevance, right? Replace "songwriting" with "coding" and "song" with "app" and there you go.

Easier Said Than Done

I could have used my own advice, starting out.

My tenacity served me well in the long run - I stuck with my writing and began winning awards. I entertained countless audiences, wrote songs for clients, and made a living as a songwriter for many years!

However, that same tenacity often slowed me down, especially in the beginning. I would spend hours filling pages and pages, trying to find a perfect rhyming word, only to scrap it all later when some other aspect of the song wasn't working.

I easily avoid such pitfalls now, thanks to my experience completing hundreds of songs. I might have gotten to that point a lot quicker, though, had I spent less time chasing perfection and more time perfecting my skills.

Older and Wiser

Today, learning how to code, I'm re-making those same rookie mistakes!

But I'm older now, and wiser, at least in theory - so I'm staging an intervention.

This article is for me, and for anyone else who needs to hear it: Dude, move along! Stop spinning your wheels!

My Situation

I'm working on my final project in Udacity's iOS Development nanodegree. Basically the assignment is to write your own app.

My app is a different kind of calendar for my mom. Her temporal lobe epilepsy messes with her understanding of time. One of the challenges is that I need to build a unique UI. My requirements are not met by Swift's List, Table, Collection, Scroll View, etc. So I'm struggling a bit to get things to behave the way I want. It's actually gone very well, considering.

And then came the thing with the labels...

How Do You Know When You've Crossed a Line?

I'm arranging calendar events horizontally on the screen. Each event has an icon and a text label. The labels tend to overlap, rendering them unreadable. I've been looking for a way to only show a few labels, so when the zoom is tight, they can still be read.

I would need to grab the size and position of each subview, then change the view based on that information. However, it would seem SwiftUI doesn't allow for that - to know the size and position of a subview you kind of have to place it first, and then it's too late to change what it looks like.

At least that's my current understanding. There's probably a way around this. Every time I try and fail, I think of three other things to try. It's so tantalizing, chasing that illusive, brilliant work-around. I spent the entire past week - hours upon hours - struggling with those labels.

When I wrote down my problem to share with my Saturday Meetup yesterday (shout out to Flock of Swifts - awesome group - super supportive and helpful!) I realized...

Text labels might not even be the best way to display this information! Different icons for different types of events would probably work great, plus a tap gesture can open up more details.

This was when I knew - my tenacity had once again led me astray!

Resolutions

If it sounds like I'm coming down hard on myself for trying a solution that didn't work out, it's a bit more than that. I really am mired in the mud. For the past few weeks I've been struggling over a handful of details; I haven't made good progress on my app or on my learning in general.

So I'm catching myself and correcting course with these resolutions:

  • Spend no more than two hours on the app on any given day.
  • Go back to my features list and work on the things I know how to do.
  • When several attempts at a solution fail, rethink the problem.
  • Try to post something new here on Dev at least once a week.
  • Get back into completing 100 Days of SwiftUI.
  • Look at my list of possible apps and decide what's next for my portfolio.
  • Look into finding an open source project I can contribute to.
  • Work on my LinkedIn page and resume.

In Conclusion

Trying to make those labels not overlap is like chasing a rhyme that doesn't exist. My time will be better served changing my approach, completing an imperfect app, and moving on to something new.

. . . . . . . . . . . . . . . . . . . . . . .