Fail as an iOS developer
Success in Failure
In that first job as a Swift developer, I made a commit without testing the code properly (hey, using test driven development is one property of a great software development company) and panicked as I couldn’t remember the changes that I’d made. I’ll have to rewrite great sections of the App just to get back to where I was at the beginning of the day. The worry didn’t help me much although I powered through some longer nights in order to keep my job.
I struggled on like this not just because I didn’t know better, but I didn’t realise Git could help me out. There is even a website that tells you what to do in that situation — https://dangitgit.com.
When you come into the industry you’re going to make mistakes, but learning does not have to be this stressful.
This article is about how to find the root cause of a problem, learn from it and work in a more efficient way in the future. The golden rule is this:
Everyone makes mistakes.
Seniority does not help.
Everyone makes mistakes.
So let us run through a strategy for these mistakes, and how to get the most out of them.
Stage 1: The mistake
You’ll realise that you’ve messed up through a pulsating pain behind your eyes. Many will sweat profusely. Your heart will beat faster than you’d really like.
It doesn’t help.
The file is still deleted / the compilation error is still there / the bug seems unrecoverable / the machine won’t start / it just won’t work
You need to breath deeply.
Acting in a rash manner can make things worse or leave you spending hours trying to fix a problem that isn’t broken.
Equally, people are seldom fired over a single mistake. People have bad days. Your manager will be used to things not working, and developers breaking things.
Your strategy is to take a step back, and think about the best strategy for solving the issue you’ve encountered.
You might notice that this is the problem-solving strategy for your job as a developer anyway. You really need to take the emotion out of the situation and not jump to blame yourself for the situation so you can make progress on the problem.
Stage 2: Break Down the Problem
Breaking down a problem into it’s constituent parts is a fantastic problem solving strategy.
This isn’t about debugging, although if you are debugging you really need to find out what the thinking was when you wrote the code, and why the output is not as you expected. The underlying cause can often be insufficiently tested code (Test Driven Development — often known as TDD — can help you here) and by Unit testing you are able to break down the code to where the issue actually is, or even be able to know where to look for your bug.
Always remember that debugging is only one tool in your Arsenal. Lots of coding is about understanding your IDE and getting your configuration right.
The alternative? Writing questions on StackOverflow actually can work, but you risk getting voted down. Plus isn’t it better for you in the long to be able to identify and solve your own problems?
Stage 3: Communication
Sometimes the problem isn’t even your fault. I tried to push my code to the pipeline this week, and it didn’t work. Why? The slave was offline.
How would I ever know?
I didn’t have access to the logs. It was possible that something on my machines configuration had changed. It was possible that something had happened.
Ask the right guy!
The point is that the solution has probably been seen before in your organisation. The only way you can find this out is
What if you are the only iOS developer, and your issue is iOS specific?
You still need to talk to others as defining the problem and talking about it with another person can really help you out. You need to look at the bigger picture and share tools, techniques and strategies to improve your code.
What if you are the only developer in your organisation?
It would be better to not be in this position. However, there are developer meetups. There is the Twitters. For specific problems, there is the Rubber Duck Debugging strategy of explaining the issue line by line as if the duck will help you.
Just by covering the problem in this way you move towards a solution.
Engaging people in both your opportunities and problems can provide guidance and stop you repeating the same problem over and over. Building relationships with people isn’t wasted time, but can help keep you focused and moving forwards through not just the current problem but your whole career.
Stage 4: Tools
When you’re typing code you may think that you don’t make mistakes. As you grow in experience, you see that using SwiftLint you can be assisted to write clean and readable code.
Clarity of thought and code is essential while writing great Swift. From planning out a strategy to solve a problem through choosing appropriate variable names everything should point to the same goal — not just solving the problem, but solving the problem in a maintainable way that can be changed in the future.
Stage 5: Knowing oneself
Your logical fallacies will keep coming up. If you want the true mathematical modulo (% in Python) you keep using the wrong function in Swift. You then decide to add your own framework with this and other functions that you often use.
Failure is the first step to success. Learning from our failures gives us a real-life basis from which to grow and improve.
In the end it is this pattern of learning and improving that we should focus on rather than individual iOS skills themselves as it is transferable between jobs and even through different non-working contexts.