Welcome to the first edition of console.log(weekly)!
While my previous posts have been deep dives into specific topics, this new series will be my weekly process log. Each week, I'll be documenting the progress, challenges, and lessons learned while building the Apolloview app for my Talent Programme Minor at Zuyd University of Applied Sciences. Think of it as the real-time, behind-the-scenes story of turning an idea into a functional application.
If you're just joining my journey, here’s a quick catch-up on the foundational posts that set the stage:
One small step for Tooncultuur: This post explores the "why" behind my project . It discusses the concept of tooncultuur (show culture) in Dutch design education and my motivation to build an app that gives student work a lasting spotlight.
The Hitchhiker's Guide to Infrastructure Engineering: This is the "how." Here, I break down the intimidating world of back-end development using simple languages and analogies to explain the complicated subject and why the most important first step has no technology involved.
What is a talent programme?
Not everyone reading this will be familiar with the CMD Talent Programme, as only a handful of students participate each year. So, let me give you a quick rundown of the minor I’m about to fulfill.
During my bachelor's education, I have one year dedicated to minors. I was given the option to take on a Talent Programme, a unique track that allows me to design my own specialization in a subject my institution doesn't offer as a standard minor. I chose to dive deep into development, and more specifically, mobile development.
Why mobile development?
I like to think I am an experienced junior developer, with over seven years of experience in a variety of languages like JavaScript, Python, PHP, and C# building applications form A to Z from a simple portfolio to big projects. At my position with 35®, I've been fortunate to apply my skills to projects for key clients like Greenchoice and Sevagram. But in those 7 years i have never touched mobile development.
It's not just that I haven't worked with languages like Swift, Kotlin, or React Native. I've also never had to consider the unique user experience of a mobile app, things like using native functionalities such as notifications, vibrations, and the camera, min-maxing the small processing power of a phone and navigating the small screen compared to a laptop. My goal for this minor is to bridge that gap and master the art of creating a complete mobile experience from the ground up.
Things I did over the summer
A standard minor is a ten-week sprint, but my schedule is a bit different, as I'll be out of office for two of those weeks. To compensate, I elected to get a running start over the summer.
The journey began with a conversation with Vincent from my institution. He was looking for someone to bring an idea to life, and his concept became the guiding principle for my minor. (If you want to dive into the heart and soul of the project, I explore this in my post One small step for Tooncultuur.
I also started programming. An application like this requires much more than just the app itself; there's a whole hidden world that makes it run, read more about that in my post The hitchhikers guide to infrastructure engineering. I've sorted the project into three distinct layers:
The Server: The powerful back-end that processes all the data
The Content Management System (CMS): The interface used to manage all the project content.
The App: The application that users will see and interact with on their devices.
Since the server and CMS are the technical foundation and less dependent on iterative user experience design, I decided to build them in advance. By front-loading this infrastructure work, I've cleared the way to focus all my energy during the minor on what matters most: building the Apolloview app itself.
Some feedback on myself
Overall, I’m a messy person, using the power of dopamine addiction, ADHD and a tendency to do things more last minute then would seem possible many projects I’ve done seen more last “night catch ups” then “early get aheads” combining this with the fact that in programming the last 10% is often harder then the first 90% you’ve got a real recipe for chaos.
But this minor it has not been the case, I made a deal with myself that I would finish the back end before school started and I’ve succeeded at that, sure there are improvements to be made and when it’s attached to the actual app in 10 weeks there are gonna be some modifications required but as of September 1st 20225, the backend stands.
At the end of last year, I also made a deal with my coaches that I would have a finished design ready. Unfortunately, that part of the project did not flow as naturally as the backend development. I have to be honest with myself; I am a programmer, not a designer, and my attempt to force creativity was met with resistance. A task I thought would take a single evening turned into weeks of frustration that ultimately yielded no prototypes.
Now that I have come to terms with this limitation, I can create a more realistic path forward. I am committing to one week to produce a solid prototype. From there, the plan is to enter a cycle of programming, user testing, and design iteration. Announcing this publicly is my way of creating external pressure. After all, I am scheduled to write next week's post in a few days, and I would much rather report on progress than on failure.
The coming weeks.
With the design prototype now set as this week’s goal, the path forward also includes diving into the code. My work this week will begin in React Native, not to build complex features, but to create a simple learning application. By implementing basic navigation and interactivity, the real objective is to deliberately focus on the essentials that are so often overlooked in the rush to build. Consequently, the key learning points for the week are not about the code itself, but about the principles behind it: creating an intentional file structure, internalizing best practices, and building a disciplined foundation for all future development. And did I mention, no AI, learning and AI don’t go well together, despite what student with a 100% AI generated essay want you to believe, far too many times have created complex unreadable code that was the result of many “please fix” prompts, if my goal is learning I need to lock in and go back to the dark ages of 2023 when AI did not exist yet.
Please fix - Me (too many times)