I am a designer, but I am of the kind that likes to get his hands dirty on the UI and make sure I’m doing the best use of the tools provided by the platform. I spend countless hours playing with UI Kit, game engines and web.
Last couple of jobs I took, the managers were so open to new ways of working that they decided that I could actively and consistently contribute to the codebase. That was a great learning opportunity, both for me and my colleagues. This post is about me, but mostly about them.
Here is a practical guide on how to make sure your PRs engage with coworkers for you. Beginning with, use your PR to:
As my senior developer always says “There is nothing better in the morning than waking up to broken tests on CI.” That’s why you should always try to make amends for your past mistakes (occasionally of other people as well) and fix every piece of code that seems wrong. Once I accidentally enhanced
defaced the animation of a flagship feature trying to make code better.
Reading is fundamental, and there is nothing better than stating the obvious with your documentation. Is there a better way to turn a 10-minute code review into a spelling and grammar challenge than to add all the documentation you like to that asset change on the corner of the screen‽ It can help your coworkers flex those language muscles and ensures that everyone is aware os what you have to say.
I’m sorry, this one was priceless. Simply start using Storyboards, there is no better way to make a small PR turn into a tentacled sea creature than that. They are notoriously hard to merge and will provide an endless amount of hours into XML-land.
Yeah. Keep that game going by adding to how the app works and making sure it is ready for your next PR. There is nothing better than preluding some change you intended to make on future code.
Ever since I came into contact with some very modern protocol oriented stuff, I learned that every single class can have a same-name protocol by its side; for example:
SomeDataType. I went completely overboard with it and decided that every single thing I put on the codebase would have a protocol oriented flavor to it.
These are not actual things you should be doing with your PRs, but a list of honest mistakes that I have made and learned from my inclusion into the development process.
I know satire is not my strong suit, but it’s mine.
A Guide for Designers Who Code
I am a designer, but I am of the kind that likes to get his hands dirty on the UI and make sure I’m doing the best use of the tools provided…
1-click handoff for design assets
Having all your assets up to date on a given project is key to provide the users with the best the design team can offer. It is really…