Hacker News new | ask | show | jobs
by manmal 3106 days ago
„Every mathematician has only a few tricks“

I think the same is true for programmers. My trick (in mobile dev) is to use state machines everywhere. State management has become my mantra, and it’s helped me tremendously in making sure my apps don’t end up in an undefined state. Swift is especially great at this because it can store values in enum cases. Now, most of my bugs stem from overlooking potential substates and not propagating state changes correctly to other parts of the app; the 2nd of which can be fixed by having proper boilerplate code.

Other tricks I‘ve encountered so far, partly from other programmers:

- Make it work, then make it better (awesome for very rapid prototypes that evolve into mature products over time)

- Go as low level (eg C or C++ for iOS; examine OS internals with Hopper) as possible (superior performance and awe-inspiring source code, leading to wider community recognition)

- Ask other people first if working on an unfamiliar problem (only works if your network is strong; can speed you up x100 though vs googling and digesting yourself)

- Use Reactive style deliberately (if done properly, only semantical bugs are left; bonus: streams are very natural abstractions of app IO)

Those are in part orthogonal to each other, but I feel that you (or just I) can’t use more than 1 or 2 tricks at once.

2 comments

My trick for fixing software is "If you can't fix it, break it more and use effects of your damage to learn about the system and see what you can affect."
That’s often my approach to diving into performance problems too. When a client says “it starts to slow down a bit at 2 requests/sec”, my first thought it “what happens at 20req/sec?”

I call it “turn it up to 11 and see what breaks”

> Make it work, then make it better (awesome for very rapid prototypes that evolve into mature products over time)

This! So very true. Or as Donald Knuth says: `Premature optimization is the source of all evil.‘