I don’t profess to have the fastest hands in the west, however I have noticed I move faster when I do certain things compared with when I do other things. Here are my observations.
Upgrade to the fastest/latest tech
The biggest limitation to how much you can get paid is how much you can get done. So why would upgrading to the latest fastest tech ever be a bad idea? In my case, I have an iMac 2017, so I plan on getting the iMac M1 with 2terabytes of ram next week. This should speed my build times by a factor of 3.
Code in your project
Sometimes its tempting when build times are slow, to work on the code in a separate project, like a playground or separate app in isolation away from all the troubles and distractions. Sometimes this works, but if you can manage your discipline away from distractions, then you will save yourself from adding an integration step which might be a pain point.
Avoid distractions
- Youtube, Netflix
- refactoring, one refactoring won’t hurt but it leads to another which leads to another.
- re-architecting.
- Forgive developers (including yourself 🤣) and accept their mistakes and do not get distracted by them.
Start from the beggining
Start from where you can get data, run the app, then progress from the data up to the ui. Its tempting to start from the ui you want to appear, but you don’t have the data to feed it yet, what if you the data structures are different than what you first thought and you have to refactor the ui to accomodate it. Also, you don’t get the total satisfaction of having any part really done that way.
Get Feedback fast.
Its tempting to write out a whole bunch of code, perhaps the whole feature without running the app. In fact it might be more fun this way, coding without the knowledge of how badly you are messing up, free from compiler criticism. This is bad. Seek out the criticism earlier. You will be able to encounter the real issues sooner and give more accurate estimates, as your progress from data to ui could even be represented by a progress indicator.
Time box your architecture strategizing.
Sometimes a little bit of strategizing at the beggining can save you from going down a sloppy path. However, too strategizing, pre-optimization and over optimization or making optimizations that aren’t entirely necessary or only make an unnoticeable difference, can definitely waste time from pure implementation and coding.
Get a fidget spinner for slow builds.
Slow builds aren’t awful because of the 1–10 minutes they take, though that is awful, and you will never get those minutes back. They are awful because they interrupt your momentum. If you start coding something else, it could interrupt your build, if you watch a Youtube video it could lead to another and another, if you leave the room, you could get distracted there. If you aren’t capable of sitting for an unknown amount of time waiting for a build to finish in peace like the Dalai Lama, then you might benefit for some physical occupier.
Make sure there isn’t a corruption in your project file
Sometimes builds take a super long time when your project file is corrupted. Either you accidentally deleted some files but didn’t update the project file, or you ticket too many boxes in the target membership.
Automate breaks
There is an app called Be focused on the iMac store that is basically a Pomodoro timer that alerts you when you have spent 25 minutes working and require 5 minutes in order to refresh your attention span. adhering to this is vital to being able to work productively for a prolonged period.
Before you start your break, write a note to remind yourself where you left off.
Return to your keyboard quickly after your break.
Read your note to remind yourself from where you left off.
