When you’re joining a company as a developer, there can be a steep learning curve, especially if you’ve come from mostly working on small projects. I gathered together twelve tips for new developers who are joining ReignDesign. Some of these are specific for iOS developers, but many apply for all types of developers.
1. Talk to people!
A vital part of your job is to talk to other people. If you get stuck, we don’t want you to spend 6 hours browsing through Stack Overflow trying things and getting more and more annoyed. Almost certainly there’s someone in the company who can help. So talk to other people when you get stuck: other developers, your technical manager, our #dev Slack channel, the PM, the QA, the designers, if needed a rubber duck.
2.Write code that will be easy for other people to read
This is the golden rule. When you’re working in a team you want to make it easier for people who will review your code or maintain it in the future. That includes following standard naming conventions for things like classes, methods and variable names. If I see names like
isAdmin = true I don’t need to read through the code in detail to understand what it does.
Avoid “magic” constants. If someone else sees code like
if category.id == 7 I have to go hunting elsewhere to know what “7” means. Create a constant or an enum defining the “magic” numbers at the top of the class.
Extract tricky logic into computed properties or methods on your model objects.
Be consistent with existing code, if existing variables refer to something as a
newsArticle, don’t create a variable called
3. Use the ticketing system
All work, whether new features or bugfixes should be tracked in a ticketing system. At ReignDesign we use either JIRA or Github issues. If someone asks you to do something, which is not in JIRA/Github, your first step should always be to ask them to add it.
The ticket should capture all the business requirements of the work you have to do. Make sure you read through it in detail before beginning.
The advantage of having all work in a ticketing system is that when you make your commits to Git, you can refer to the ticket number in the commit message. Typically when starting work a new issue, we also update the status of the ticket: assign to yourself, and put it into “Working” state. This ensures your fellow developers and PM know what you’re working on. When you’re finished with a ticket, assign it to QA.
4. Check your diff before committing
When you’re about to commit your changes, take a moment to review all the changes you made to each file. This is easiest using a GUI for Git such as Tower. You should revert any minor changes you made by mistake e.g. whitespace changes. Check you didn’t add any local temporary files or test data by mistake.
Add a commit message. Be sure to mention the JIRA ticket name and at least a brief summary of what you changed. Lots of small commits spaced out through the day is better than one giant one.
5. Understand the branching strategy for each project
Typically we use git flow, but talk to people and understand what branches exist for the project you are working on. Typically you write code on feature branches, named for example
feature/new-help-menu, and then create a pull request to merge back into the
develop branch when your feature is complete.
6. The Boy Scout Principle
Aim to “leave the code better than how you found it“. It can feel strange to edit code that someone else has written, but no-one “owns” a codebase. We have a shared responsibility to make it better. So if you’re already editing a file, it’s always good to, for example:
- fix Xcode warnings
- refactor/rename variables or methods – be sure to use the XCode refactoring tools to make sure you catch all usages of the code
- remove dead code
- fix outdated comments
7. Think before adding a new library
At ReignDesign we use Cocoapods for iOS projects. Package managers make it very easy to add libraries to your code – perhaps too easy. Before you add a new library, be sure to check:
- we’re not already using a library in the project which does what you need – it’s very easy to end up with three different libraries for loading remote images!
- do we actually need to pull in a whole library for this? If it’s a simple utility function, maybe we can just add that one function
- Check the library is up-to-date and has recent activity on Github. Many libraries look useful, but don’t work with the latest versions of iOS.
8. Think about multiple devices
Remember that mobile devices come in all shapes and sizes. Even when developing for iOS, which is less fragmented than Android, you need to consider different sized iPhones, possibly iPads, and different versions of iOS. Be sure to use multiple simulators to see how your code works on multiple devices. In particular:
- Thoroughly test on iPhone X and ensure content works well with the safe areas
- Test on the smallest and largest screen sizes you need to support, e.g. iPhone SE and iPhone 8 Plus. Check for text overlaps and truncations.
- Test on the lowest iOS version you need to support, e.g. it’s common to have issues with scrolling insets on iOS10.
9. Get really good at Interface Builder auto-layout
I think there’s a tendency amongst developers to feel that Interface Builder is not “real programming”. But if you properly understand how to use auto layout and storyboards, you can actually save a huge amount of programming time. Generally try to add the minimum number of constraints you can – take advantage of the implicit sizes of components like UILabel and UIImageView where possible.
Very powerful tools which you need to understand are:
- stack views – these dramatically simplify implementing many types of vertical and horizontal layouts
- how to create set up scroll views properly in Interface Builder
- how to create self-sizing table cells
10. Write safe code
We really want to avoid runtime crashes! Take advantage of optionals in Swift to make your code safer! Avoid force-unwrapping! Exclamation points mean danger!
Every time you write a ! in your code, a little red flag should go off in your brain saying “Do i really need this ! – what would happen if this was
In general use
if let or
guard to safely unwrap optionals.
Also be careful with arrays –
arr will give a runtime crash if arr is empty.
11. Get comfortable with the design tools
Most UI designers are now using Sketch. Designs will often be handed over to you via the web app Zeplin. Make sure you have at least a basic understanding of how these tools work, so you can for example export any assets you need, and measure the size, margins, and colors in a design so you can reliably reproduce the designs for real.
12. Understand the environments for each project
Typically most projects will have multiple environments, such as dev, staging, and prod (production). It’s important you know the difference between each environment. For example, you don’t want to create lots of test data or users on prod. Additionally, you’ll probably need different test credentials for each environment. Again, talk to people and understand if there are any special requirements you need to know about certain environments.
Interested in working at ReignDesign? Apply to work with us!