A Person, Artist, Software Engineer, Geologist.

When you work with developing UI code as much as I do, you run into the issue of UI as Art.  It's (mostly) subjective.  People have built up mental maps of their life, surroundings and how they expect life should be and why doesn't everyone think like I do? I do it all the time, but now I try to seek out and enjoy the differences instead of working to avoid these conflicts of vision.  Unless a UI design is specified before hand, I have to come up with a visual implementation that I feel suits the needs best.  Sometimes it works, sometimes it doesn't.  It kind of depends on who is playing the bills and what their vision of the issues are. In this sense software is like art.  Not just the UI elements, but the internal design and structure of software as well.  Everyones internal bias get exposed when writing and looking at code.  Different code may do the same thing but be completely different internally.  Look at Android and iOS development, nothing a like but the end re

Software patterns are well know (Singleton, MVC, etc) as are anti-patterns (cut/pasting of code, etc.), but do developers ever think of their own personal patterns or anti-patterns? Just as tool sets can vary from project to project and technology changes over time, personal patterns can turn to anti-patterns based on the project. I know Java but I would not use Java on an iOS mobile device.  The quality of the product would suffer vs using native tools.  The same goes for trying to use Microsoft tools (does Mono come to mind?) on linux servers.  But this is not about tools but about how you (as a developer) think about your role in development and how you personally effect it.  If your pattern is thinking that Java is the perfect tool for any project, then that can become an anti-pattern if the project is on iOS. The interaction between team members can also be effected by personal anti-patterns.  Not asking questions is a personal anti-pattern, so is not making decisions or hid

You may be asking yourself where are the Buddhist teachings in my posts?  Well, I try to hide them in my topics but I don't want to be in your face as well.  The reason for my posts are not to teach you how to be a Buddhist software engineer, but how I've faced software engineering.  Which means facing myself, warts, insights, relationships and all. Here is the "in your face" part: A good understanding of Buddhism can be found at  Wikipedia.org  to start with.  There are so many books and web sites that you can explore that are only a Google away.  The good step to understand Buddhism is The Four Noble Truths and I have found this to be so key to my life.  Don't just read the Wikipedia page, please get a book by the Dala Lama on  Amazon  (or any of his books), read it and see how it relates to your life and maybe, to your philosophy  of software development.  This is one of the questions I like to ask prospective new hires, "What is your philosophy on sof

I've worked in all aspects of code from libraries, DB design, Web/API-services, requirements and everything else, but I've happily fallen into being very strong in the design of User Interfaces.  It's not that I'm artsy (I'm not) but I have a knack of being able to architect UI code so that the artsy presentation skin can be added easily without effecting the functionally of the UI. Unlike other layers of an application / service (or whatever layer), there are discreet operations and parameters with expected results.  Code can be written and tests created to the expected behavior.  It's the same with DB operations but will a bit more complexity based on relationships, triggers and transactions. Not so easy with UI code. Write code to show a form, easy.  Add validation and error handling and it gets a bit busier.   Add related actions, operations, state tracking for enabling / visibility, mix with async operations for data streams and any gee-wiz widget beh

Sad.

Cleaned out the garage this weekend and found some old development software that I had used "back in the day".  The things that struck me were : - The emotions that get evoked when I think about them -and- - The core of development changes very slowly but the tools / technology churns away. The first product was Symantec's "Visual Cafe" (1996).  This was an early Java 1.0/1.1 IDE that was a big hit for a short amount of time.  Back then it costs $299.00 when very few Java IDE's even existed.  Java is still here but Visual Cafe is long gone. The other product (1996) was IBM / Apples "OpenDoc" technology along with SOM and it's implementation of CORBA.  Whew, what a mouthful.  This was a response to Microsoft's COM/DCOM and embedded technology used in Office (think Excel inside of a word document).  Terribly complex stuff that 1) failed to be adopted by a critical mass of developers and 2) supplanted by the internet. Wow, what a time