You are currently viewing the Mobile Optimized version (AMP), some features may be missing or may not work as expected. Open Full Version.
As a software developer working for an organization or a client for years, we might get habitual to being part of this vast assembly line, where we are just a step in the process.
This is how it works usually, someone comes up with the idea, somebody writes the specifications for it, someone builds the mockups, another person works on the UX/UI, and then it comes to you and you do your thing and then pass it along.
This routine can lead to several biases, under/over-valuation of work of others or even yourself, boredom, frustration or just being stuck to the usual ways and not stepping out of your comfort zone.
Most of us even know all of this in theory but still fail to realize it.
To put things to practice, I picked up a simple problem that I face every couple of months, buying whey protein. So I built this simple app, ( using a tech stack that I don’t usually work with ), over 4 weeks working 30 mins per session. It might be a silly little app but what mattered to me were the re-enforcement of the learnings and probably some entertainment ( for the nerd in me 🙂 )
Here is what building apps can teach you:
Don’t be afraid to start
Working on a project that is already built or using a popular framework like Laravel, you get the huge advantage that several of the core architecture decisions have already been taken.
When you bootstrap a project on your own, you might need to spend several hours just thinking about how you would like to structure a project, standards for naming conventions, patterns, libraries, and packages to use. It will feel like you are just losing time without making any actual progress, if you keep at it pretty soon you will start making progress.
Also, keep in mind that it is always good to spend time in this phase and not rush it.
Good decisions made during planning will make your execution go smoothly and help you go much faster later on.
Refactoring has no end
Refactoring is never complete but it doesn’t mean we should keep pushing it for later. As “The Pragmatic Programmer” book says, “Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired.”.
Once you are done achieving your desired result, look back at your code and think of what things you can improve, it may be about making code more readable, reusable, or just adding some documentation. I did that with this app (and still need to do more).
Write it or forget it
Has it happened to you that you memorized a 4-item grocery list and once you reach the store you can’t recall what was the fourth item? Our memory can fail us sometimes, so it’s best to keep some notes as you go along with the implementation. It will help you stay focused and you would avoid getting stuck in a loop as you can see what you have already tried.
I usually have two things always handy on my desktop a quick note-taking app (XPad) and a journal (Zim). The note-taking app helps me jot down what I am thinking at the moment, and things that I would like to explore, it always sits on top of the second screen so that I don’t have to go looking for it and can quickly dump my thoughts. The journal helps me with organizing and documenting the long-winded versions.
You can even go for apps like Asana, Trello, etc, as long as you are writing, you are remembering.
Things change (always)
Even with a small app like this, I changed several things from the way that I had originally thought. As developers, we love to have concrete specifications but that is hardly a reality. It is said that in software, change is the only constant.
Just keep this in mind and if you hate your manager for changing the requirements always, start forgiving them.
A good way to deal with changes is to, always anticipate changes, keep your code flexible, stick to development principles like DRY, KISS, etc and use the tried and tested (design)patterns, which will allow you to make your changes a little easier.
Learning is immense
Working on your projects gives you the freedom to decide. In your professional projects, you might be restricted by the boundaries of the project like the tech stack, standards, team consensus, etc.
But in your app., you can choose the technologies that you want to work with, build your architecture and try different strategies to see if they work or they fall flat.
All of this adds a lot to your experience and give you a perfect place to practice. Remember, “There might be no glory in practice, but without practice, there is no glory”.
To me, building apps is like playing video games. It definitely stimulates your brain. Next time maybe when you are trying to kill your time by watching a movie or random surfing on the internet, instead try building an app., who knows where it might lead you to.