While I thought about how nice but lonely this one little nxtOSEK guide looks on the left, there was a thought running through my mind: do I have coding guidelines or development philosophies? Well, yes - implicitely. I never wrote them down and tend to adapt them to the team's style I'm working with. Although I prefer the "perfect code" for private projects, I never though about what kind of principle lives behind that. So as always in case of doubt, I wrote a few lines about thing I like and things I actually do. It happens that I praised the things which hold me back from getting productive. I have this massive melon on my shoulders, but nothing in there tells me that developing the stuff you're working on is easy to combine with what you as an "ultimate" philosophy. In fact, I praise purity, efficiency, simplicity and generalisation. Seen as single components, they give solid guidelines to follow. Purity is also consistency, efficiency is never wrongl simplicity makes your life easer and generalisation brings it's custom flexibility. But all together? Quite a dream in reality. These four things are what makes me design new stuff on and on. I question tought techniques, try to improve or perfect them - I do all this to make my mind peace happen and yet I can't follow these guidelines without sacrificing productivity. Out of a sudden I wondered how exactly the famous Unix philosophy was. Shortened to "do one thing and do it well", it becomes something I do when working in teams. I have a task and try to archieve this as good as possible. When it's done or the time is right, I help out others by the same way. Interestingly, I've never given out advices that don't live up to the essentials of those very few and stretchable lines (except in this blog, which is more a valve and freetime thingie). No wonder why I prefer seein the Unix philosophy applied. I believe that I can keep my "ultimate" philosophy goal by following the Unix principles (interpreted of course). The magic lies in "do it well", which is what I shall look out for. Doing something well can range from using a primitive bruteforce approach to implementing an event-base GUI layer system. It can depend on so many things that I'll ultimate be possible to see advantages where my original "guideline" didn't work. It's not always necessary or possible to do something as efficiency as doable. So, what is doing it well, then? Depends on whether it works well with everything else I'd say.

These moments are what this blog is made for: dumping shit no normal person would listen to.

No comments: