Confidence in your abilities takes time to build. You face a continuous stream of challenges, which tests your existing capabilities. Sometimes you win, but most of the time you fail. That’s the normal flow of things, and it’s important, especially in the beginning to internalize this: coming to terms with the fact that you will inevitably fail. Not all the time, not some of the time, but most of the time.
Equally important is to evaluate and assess the different causes for your failure, learn from them, and get back up on your saddle. This is the only time-proven solution to build grit, experience, and ultimately success with each and every endeavor you decide to partake in your career.
In 9+ years of developing mobile applications, we’ve learned a lot. And we’ve failed a lot, especially in the beginning. There’s no shame in recognizing this, as the sooner you notice it and accept it, you can learn from it and move forward. With time, we got to recognize patterns as we went through the process of developing mobile applications and full-fledged products for our clients.
This pattern-observation skill came through thanks to us going through failures, learning from them and ultimately assimilating them into our day-to-day actions. Sure, the natural tendency is to stray away from failure, but the extreme here is that by not putting yourself out there, by not inquiring and doing stuff that is out of your expertise, you can’t fail. But you also cannot grow.
It’s the well-known dilemma of the athlete: avoiding injuries at the expense of building skills through training. Of course, you can sit at home, comfortably snuggled up with your favorite blanket in your favorite futon, and avoid the uncomfortable and cold weather which you must face in January to reach the gym.
Huh! Not only this but imagine the effort: all that sweat, pain and tears you have to endure once you get there. Bah! You’re going to treat yourself today to a bucket of ice-cream and some doughnuts because you deserve it.
Of course you do, you’ve worked hard. Someday. Maybe yesterday, or last week. Guess what you’re not gonna get, though: the physique you’ve always wanted.
Business analysis – figuring out solutions to business problems
It’s the same with building apps. As a business analyst, my mission is to turn over every rock to find all there is to know about an idea and to transform it into a working, real-world problem-solving business.
It’s not an easy process, but it’s a meaningful one. And, there’s no sweeping under the rug here. If you purposefully avoid a problem, trust me, it’ll come back and bite you in some way or another.
If you decide that you’ll avoid something just because it’s outside your current level of expertise or because you just don’t feel comfortable digging deep into the issue, it’ll be unearthed eventually. On the technical side, this is also known in the industry as technical debt.
To give you an example from my junior days, an app we developed had a screen where there was a list of items. I described it in the specifications document but forgot to mention if it should be paginated or not. To my (then lack of) knowledge, I didn’t even know the importance of pagination, and when I was confronted about it with the development team, I nodded “oh yeah, we definitely don’t need the list to be paginated”.
Of course, they explained the difference, but in the heat of the meeting, I couldn’t wrap my head around it and took the comfortable decision of picking one of the two options at random. Then the workday ended.
The next day, after some other work that needed to be done in the morning, remorse started to creep in: a realization that made me question my decision of being comfortable with giving a quick (and seemingly smart and right, or so I hoped) answer, but which was ultimately improper.
That was the moment when I decided that such things mustn’t be left alone, and you shouldn’t make a decision just for the sake of making one, without knowing it’s implications, for the fear of appearing unknowledgeable.
Because these things come and bite you back, they always do. Eventually, I analyzed what pagination was exactly in that specific case, and I followed up with a rectification. I told the dev team that we should use pagination, after all, and brought arguments to my decision. All in all, it was a case of learning from mistakes and an invaluable and necessary asset that helps you build experience.
Correcting mistakes – paving the way to success
You shouldn’t take this article as an ode to failure, as you should mitigate failure whenever you can. I’m just saying that you will fail, and failure leads to growth. That’s how we’ve learned, and how we managed to improve our process of developing successful apps for our clients.
This process can be found in the new book we’ve written, From A to App Success: How to develop apps that make a difference.
It’s written for everybody, from developers, testers, business analysts and marketing people to shareholders, clients and people curious about how an app gets made. It tackles how to build a successful product, from the initial idea all the way to success.
We hope you’ll enjoy it and find it useful. You can download it for free in PDF format by going to our website, or you can buy it on Amazon.