Software: what users experience Code: what software developers experience
I prefer to work closely with someone else (or a small team) to achieve a goal. I prefer to get along with that person and have a friendly relationship. I prefer to work right next to the product manager. I believe the best development work is fast and fluid and the best working relationship with the product manager is also fast and fluid. I should not need to explicitly communicate status to the product manager because I am working closely enough with them that they know.
I work best when I am part of a community that I am proud of.
I prefer to discuss the users needs over development methodologies. I do not believe any particular methodology - in of itself - will result in good software.
I believe that it is important to work as closely with the software users as possible. I do not believe in making exactly what the user has asked for unless I can personally confirm that there is not a better way. For me the best way to confirm that is by understanding the user need in depth.
I am mostly conservative in my choice of technology. I prefer tried and proven technology over the latest trends.
I prefer less code than more code. I believe software always has bugs, and the less software there is the less bugs. I have seen a tendency for software developers to start writing code before truly answering the question: does this code need to exist?
I prefer to give users a collection of tools rather than an application monolith. This is because I believe it is so difficult to predict how users will find your software useful for them.
I believe software should be judged on its usefulness to the user and not by the way it was developed. I respect well functioning software over clean code. I recognize the maintenance burden of unclean code but also that all living code has a maintenance burden, and no code is fully clean to all people.
I prefer incremental and constant refactoring over large scale rewrites. I believe that a developer should strike a balance between refactoring and new features as part of their normal process, and there should not be a separate refactoring moment. I believe it an individual developers responsibility to identify flaws and improve code as part of their normal work routine.
I do not like to hold process up as a reason for not doing something. If I am put in a position where someone relies on me and I rely on some downstream process and box-ticking exercise I become very uncomfortable. This is why I do not like corporate environments.
I do not believe in "hand-overs" of responsibility - they never work, they seem to be mostly politically motivated - never triggered for reasons that improve the software.
There are not a lot of people that bother to understand a given situation to a great depth. Either it is not their job to, they believe someone else has done it, there are mistakes that people are embarrassed about and prefer to hide, or they are just not interested in that aspect of the process. Many times I have gone into a situation where there was some complexity that people complained about, where I started asking the "stupid" questions only to find they have mostly never been asked. After digging, taking, reading - it turns out the situation is not very complex after all. These situations will usually have some complex and buggy code, and sometimes some bad software associated with it that came about due to these misunderstandings.