Not the greatest programmer
For the longest time, I struggled with programming because I wasn't at the top of my class.
Throughout high school and college, there were always peers who were way smarter than me. I was able to finish the assignments, but I never solved it the fastest nor earned the highest marks for them.
In my high school computer class, there was the one girl who sat next to me in my computer class who'd aced every assignment. She'd finish her programs in record time and would write her own programs with the time remaining in class.
I felt like I lacked enthusiasm and genuine interest in it. I definitely wasn't coding my own programs.
I barely graduated from Computer Science at my university.
So I commented out programming as a career choice. I felt I could be more useful working in something less technical than programming.
The Shift
Then in 2013 something changed.
I was obsessed with Ruby on Rails. I drank the DHH Kool-Aid and just had to explore this rabbit hole.
After years of working in IT, I saw opportunities for custom web apps to solve legitimate business problems. I found myself using my free time to learn it and tinker with it.
But the pace at which I was going was so glacial. I'd never develop anything if I didn't commit to some sort of learning structure.
So I went to a bootcamp called Flatiron School.
My sister had graduated the previous year and raved about her experience.
I'm so glad I went. I learned Rails, yes. But there was some critical meta I was missing that reduced a lot of stress on the process of coding.
Behavioral Difference
Before
- Write out the entire program/feature/ first and then compile and debug
- Question to myself: "Will this program compile with any errors?" (With nail-biting anxiety)
- Commit gigantic changes to the codebase
After
- Write a few lines of code at a time then compile and debug
- Question to myself: "What's the smallest thing that I can get working?" (The perfectionist in me weeps with shame but I ignore him)
- Commit small, commit often
The Lesson
3 Steps to building an App
- Make it run
- Make it right
- Make it fast
Order matters
You cannot make an app fast if it isn't right.
You cannot make an app right if it doesn't run in the first place.
So your first job - when approaching any feature - is to get it running first.
To hell with making code optimizations to a feature before you can demonstrate it actually works.
Perfection through iteration
Once a feature is running, it's time to make it right.
You can refactor.
Make your code more readable to your future self.
Write documentation.
And once you're satisfied with making it right - and you haven't broken anything else - then you can look at making it fast. These are essentially performance improvements.
What's parts of the app are running slowly?
What can we speed up?
Making it Run Example
When I was building Form Zap, my mentor at the time, Trevor, scoped out my first features perfectly.
- Open and display a PDF document.
- Allow tap gestures on this document. Just put a dot on the screen where the user taps.
Saying "later" to
- Allowing the user to pick any PDF document they want
- Annotations or text input from the user
Just these 2 features alone had me deep diving into the PDFKit API. It required my to think differently from what I had done before. I was guessing a lot in that first week. I'd try something only to see nothing happen. When something did happen, I knew I could adjust parameters.
But scoping these first 2 features so clearly and so concisely was crucial to allowing me to finish the MVP of this app.
What I thought would take me 2 weeks to build ended up taking me 4 weeks. It was challenging, but in the end, it was so rewarding.
Personal Impact
My Enneagram number is 1. They call it "The Reformer." It's also called "The Perfectionist." I couldn't agree more with the feeling that my ego wants to build fast, correct code right out of the gate.
I've maintained this unrealistic expectation to this very day, but thanks to this mantra of "Run, Right, Fast," I'm able to snap out of it and make that small commit.
Iteration gives us permission to write as small and as comfortably as we want. I'm such a happier dev because of it. I can build at my own pace.
The differences between expectation and reality still amaze me - things I thought that were trivial are actually hard. With this approach, I'm not completely lost on where to begin debugging. If I build small units at a time, I'm laser-focused on the issue at hand.
With this approach, my git log is readable and rational.
I'm still not the best programmer by school standards. But I don't care about that anymore. I love the process of building with code and seeing the fruits of my labor. That's what keeps me coming back for more.
Shout out
All credit to my Flatiron instructor Avi who taught me this lesson that continues to pay dividends to this day.