How We Work Smarter, Not Harder

“Work smarter, not harder” is one of GoodNotes’ mottos. You can find it deep down in our values, there is even a section talking about this on our careers page! But what does it mean exactly for an engineer? How can we achieve the “work smarter” ethos when, for example, we start a project or we work on a feature? In this post I would like to review with you some tools and tips we use here in the GoodNotes’ engineering team to work smarter, not harder.

Keep It In Mind Since Day 1

When we start a new project, no matter what technology or stack we are using, there are always a bunch of tools we configure in order to simplify some tasks. Linters, code formatters, code coverage tooling, etc. Configuring all these tools takes time, but it’s time well spent because it helps us to avoid repetitive tasks in the future — from formatting in our code to checking whether our build and tests are passing. That’s why you should keep it in mind from the very first day. The usage of certain tools enables us to work way faster and get a development pace we couldn’t achieve otherwise. In this post you can find a list of tools we use in different technologies/stacks and why we find them interesting.

Automate Linters and Formatters

These are the keys to success if you want to avoid comments like this on your pull requests:

Swiftlint, ESLint, Prettier, or PyLint are just some examples. These tools help not only to automatically format our code but also to ensure we follow the coding convention the team specified.

Another example is the configuration of rules to avoid common patterns in our code, like the usage of the famous JavaScript “console.log” or force unwraps on Swift. You can even create your own custom rules if needed to automatically break the build if there are any rules the new code doesn’t comply with.

CI & CD

It is fundamental to ensure the changes we’ve done in our codebase make the build and tests pass automatically. But what about deployment? If you, my dear reader, are an iOS developer, how long have you been waiting for XCode to build archive your app on your own laptop? Our suggestion is to start every project working on CI & CD tasks. We are using GitHub actions and Circle CI right now, but any custom Jenkins configurations or any other tool will work for you as well.

For every new PR, there are some jobs we’ve configured to build our projects, evaluate our linters, run our tests and deploy new versions if needed. This automated process empowers us to spend our time on what really matters: building the best possible GoodNotes app for our users.

Best Tools For the Job!

There are tons of open-source tools you can use when building your project. Some of them can speed up your development process significantly. That’s why we spend time looking for the best tool for the job whenever we are working on our app.

There are some libraries, quite similar between platforms, that we always use on our projects. Here you have an interesting list:

There are some libraries, quite similar between platforms, we always use in our projects. Here you have an interesting list:

• Screenshot testing libraries: Swift snapshot testing library + cypress and the visual testing tooling are our favourites. It helps us to ensure our app shows the expected UI using pixel-perfect precision!
• Data serialisation tooling: We heavily rely on Swift protobuf implementation. It makes our life way easier and the performance is awesome!
• Dependency management libraries: CocoaPods, Swift Package Manager, yarn, and npm, are just some of them. We couldn’t work with these tools, literally.
• Loggers: DataDog’s logging tool hidden under an adapter or connected to loggers like CocoaLumberjack.
• Styling tools: StyledComponents and Auto Layout are two great examples. Best tool for the job on two different platforms, React and iOS. Combined with a design system, it will make your UI shine!

Plan Ahead

However, this is not only about libraries and tooling, working smarter is an attitude as well! That’s why we work using a 6-week development cycle with a dedicated planning period in advance. Planning before coding, thinking before writing a single line of code — that’s our best tool! You think way faster than you code, so we recommend taking the time to think and plan before tackling any task. Review the requirements, take notes, design your solution and ask for feedback before implementing anything. If you plan, it serves as your first iteration, so you’ll be able to work more efficiently later on as this will speed up the feedback process and you can iterate again as soon as possible.

These are the tips and tools we use in our Engineering Team for working smarter, not harder. Are there any of your favourites we didn’t mention? Please, write a comment below and let us know!

This article was written by:
Pedro Gómez is a Senior Software Engineer focused on new technologies, open-source, clean code, and testing. He is now working as a Senior Software Engineer in the cross-platform team at GoodNotes.