This content originally appeared on DEV Community and was authored by Callum Connolly
What I learned spending 6 months making my first app I can now make in 6 hours.
I've finished my first mobile application which took me 6 months to write. I've started many projects that took maybe a few weeks but this was the first side project I did which persevered over the course of months, in an area I previously knew nothing about.
A bit about my situation; For my shiny new graduate job I was put onto a Front-end Engineering position and had to self-learn JS, HTML, CSS, React etc. as well as how to navigate working professionally for the first time. Before this, I had no knowledge of Front-end Engineering whatsoever. How people got boxes of all shapes and sizes to appear on a screen was beyond me. Moving any of those boxes was part of the mystic arts. This mobile app was a way of consolidating all that knowledge as I learned, as well as trying to find a way to help people. Here are 6 of the most important things I learned along the way.
The hardest part is letting go is figuring out what to do exactly
A lot of time when creating the application was spent figuring out what exactly I need to actually develop. This included item such as: a broad roadmap of where I wanted it to go, wireframes and mockups, and more specific requirements written down at each stage as I went along. The time spent figuring out what those exact requirements were, paid dividends later. The fuzzier the requirements were, generally the more issues and roadblocks they caused later. It can be difficult to figure out which steps will require more time over others but that intuition will come with practice and being able to recognize similar situations you've dealt with before.
Personally, and I would recommend this to most people, is to write down, draw, make a note of whatever you must do and the steps to get you there. It makes forgetting important steps more difficult and gives your brain a way to process and work through things more easily with a more defined structure. Furthermore, if you're like me you have only a fairly limited experience of agile processes, using certain tools can limit the effectiveness of the process. Don't take my word for it though, take Uncle Bob's word. For this reason, the intensely manual approach of post-its on a wall was used to keep track of work items, which worked for my dissertation project and this project likewise.
Worse is better, until it isn't
This is a play on the common mantra in software acceptance. If your goal was, like me, just to make something then the mantra of worse is better you should stick to. Just get something out; Learn enough so you kind of know what to do then go with it. Even if it's a little messy, you can find a brute force solution first which will help you understand the problem more clearly. Then you can find the eloquent solution afterwards.
However, if your goal is to make something that won't be a royal pain in the arse to maintain, or something you want to potentially put to market, then the time spent understanding the right processes and procedures will make your life factorially easier. This means researching file structure, testing (at as many levels as you can), version control, CI, deployment and figuring how to get them to all integrate together into a proper workflow will pay exponential dividends later, especially if you have others join onto the project.
Understand the fundamentals, even if that takes time
"What I cannot create, I do not understand" - Richard Feynman
Understanding the fundamentals and building up mental models, as well as the context of where things sit in the development process are key tools to not solidifying knowledge that you learn. To learn React, I first had to learn JavaScript, HTML, CSS, which meant understanding web frameworks. Break things down into their most atomic parts, so you can build the knowledge up again on a strong foundation. One really good idea from a post by Raymond Gan's is to create whatever you're learning. If you're learning React, code your own mini-React. Learning Java? Write your own Java-jr. This gives you a much better appreciation and understanding of what you're learning. Learning how to learn, and pairing the above steps with practice, and you're in a better position than the vast majority of others and it will make you a better and much more productive engineer.
Equally important as well is continuing the process of learning, even if you know how to do something. There's a hundred different ways to scare a cat, cook an egg, or write a sorting algorithm. There is always room for improvement, especially in software which constantly changes and shifts, maybe less so when it comes to cooking an egg though. So it's important to keep up to date with the latest trends, releases etc.
Have a couple different avenues to pursue
When I did some across some impediment to development, mainly due to lack of knowledge, sometimes due to not being in the right zone, I felt like bashing my head against a wall; A feeling I'm sure that's common to anyone who has ventured further than printing "Hello World". It is not a sustainable feeling to have, especially in personal projects where your only motivation is yourself. This is one of the many reasons why, even in small, personal projects, using branches for your VCS is important. Having the ability to switch between problems was something I learned later in the process, but which made things a lot easier.
Oftentimes coming back to a problem after having spent time elsewhere, on another part or just having a break, will give clarity on the issue and you'll be in a better place to figure things out.
Roles in Software Engineering are there for a reason
Tester, team lead, project manager, developer, UI/UX, intern who fetches coffee are all key roles in the software engineering process. Having the independence to decide exactly where a project goes in it's entirety is intensely liberating. Wearing all the hats yourself, however, can very tiring. This requires a lot of context switching and is where we start to see how each of the roles, with their own specific target, work together. The team lead who is able to tell a developer what to do next and keep them deeply focused on the next feature. Testers who has no ego associated with a piece of code are able to test that code to oblivion and uncovers bugs we would not be able to. As someone new to a team, it's an enlightening experience to be able to understand up close that multiple people, when working together cohesively, really make a project succeed more than a single person could, and create something greater than the sum of its parts.
Keep going
Standard motivational advice, I know. The satisfaction from finally making a project is something that is going to stay with you. It's important to know that your first draft won't be your last, and it shouldn't either. It's also important to know that it is okay to take a break when you feel like you're hitting a wall; Some walls are there for you to rest against for a time, some are there to break through. Oftentimes, it's when you break through these walls that you'll do your best work.
What's the App?
You can find the app here, it's a super simple tool for tracking habits and, I hope, will be able to help people make some changes in their lives. I am working on a new app, similar to this one, with more features as well as a proper workflow and taking into account all the lessons learned. If you could try it out and give some feedback that would be great.
This content originally appeared on DEV Community and was authored by Callum Connolly
Callum Connolly | Sciencx (2021-10-03T10:24:16+00:00) 6 Things I Learned Writing My First App. Retrieved from https://www.scien.cx/2021/10/03/6-things-i-learned-writing-my-first-app/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.