Programming and creativity random thoughts
Creative tasks such as programming, writing, musical composition and art share a lot in common.
It is attractive to upfront think and visualize everything in the mind before writing or drawing anything. Doing so on too large or detailed drawing results with one or more symptoms:
- The image ends up lacking detail.
- You end up with shapes and patterns that are impossible.
- The whole image is just a copy of something specific you saw.
There is an another way to approach creation. This another way reduces your need to visualize everything up-front and allows you to think deeper. If you can do it you will find out you will waste less effort and no longer lumber under complexity.
Proceed to draw and write everything while it visualizes in your mind and keep doing it. No matter how illogical, ugly, wrong, incomplete, unsatisfying, incomplete or crippled it is, let it come out.
No matter how ill-conceived it is, it fills up your mind as you search for possibilities. You have to let it come out.
Actively writing your thoughts out requires active effort and awakening from lethargy. On the upside everything you've written down or drawn is capable of reinvigorating you. This acquired power lets you go much farther than what you could with relying solely on up-front visualization of your mind.
Abstractions
Abstractions are a crucial topic at programming. Capable programmers are creating and utilizing all kind of abstractions all the time.
For example, vector algebra, operations on sequences, garbage collection, iterators, functions are brilliantly good abstractions. They help you to express complex subjects.
Atrocitiously bad abstractions are doing the exact inverse and are easy to come up with. Even a great abstraction can become bad if you use it in a wrong domain.
Use of an abstraction requires you to learn its language and rules so you can use them to express and work with complex subjects.
Cost of inappropriate interfaces
APIs, interfaces and libraries allow programs from different sources to interoperate. It seems difficult to grasp that they have their costs.
Just any program cannot be completely abstracted behind a concept or a barrier that would sterilize the user of the interface from the details of the program.
The interface is worse less the author has understood the subject they attempt to solve. For this reason interfaces created early on, inspired from architecture, designed by committee and freezed down before implemented and tried are often so contraproductive.
This gets worse if your documentation describes the function of interfaces of software, instead of the functioning of the whole software.
I've seen bunch of such documentation, often by Microsoft, that only treats the "user interfacing" parts of the programs. It provides a fantasy that you've done good work and properly abstracted away the details involved in the problem your program is solving.
Documentation lacking in implementation details tends to not provide value to the user.
Your stresshold for creating new interfaces should be relatively high. Interfaces and APIs aren't glitter that you can sprinkle into code without consequences.
Also sometimes when the details of the implementation change you should have to break interfaces. For some libraries it is so apparent that you could write an expiry date on them.