Several weeks ago I started as close to a dream job as a software developer as I could have wished for. It is a relatively small company with a casual dress policy, frequent on and offsite happy hours, close to 0 bureaucracy, so far unnoticeable office politics, and lots of intelligent and interesting coworkers. Most importantly, it is a software product company (I was getting tired consulting in financial services or other organizations where software is means to an end -- here it is the actual end in itself) and I love both the product as well as our application technologies. Getting up in the morning does not feel painful any more. For the most part, I get along with all my coworkers (four developers, CM, boss etc.) and I feel that the sentiment is reciprocated. And below I will try to explain why I say "for the most part".
I have somewhat different alternative cognitive and learning styles and patterns compared to most people. They do not necessarily slow down my learning process and productivity but they necessitate different methods when working towards objectives. Even though I have never consulted a mental health professional about it, I could say, with a reasonable amount of confidence, that I have a very narrow attention span (popularly referred to as A.D.D.) which, over the years, has led me to devise my own methodologies for learning, working, and general cognitive functioning. E.g. I make an extremely extensive use of
Evernote (I'd be lost without it), I split almost the smallest work unit into small digestible tasks and manage them in lists, and I have 0 tolerance for chaos and disorder. I get sensory overloads in hectic and chaotic situations and, if found myself in one, I must first get involved in cleaning things up and establishing a systematized rule of order before proceeding with any kind of work. For the illustration sake, if I were a plumber and you brought me in to fix your toilet, if the bathroom were messy, I would have to clean it up before being able to focus on my task at hand. I am also a very tactile, hands-on learner, I like getting my hands on the concrete implementation.
In light of my cognitive paradigm as explained in the paragraph above, I have interpreted some clues from my boss and coworkers that my habits are causing me to be slower in getting up to speed than they expect and that perhaps "I should be doing things the way regular people do". One example is our developer setup. I am of a belief that each local development environment should be very flexible to allow each developer to customize it to their own needs, styles, and preferences. While I love our product and all of the tiers of our application stack, the developer environment as checked out of VC is not very ergonomic and flexible so I spent somewhere between one and two weeks making modifications to my own setup to make myself comfortable at work (IDE preferences, being able to run some modules and not others, etc.). I have a feeling that my team was expecting me to take things out of the box and go on with them, doing things they way they do and spend less time customizing. But I just really value UX of my work environment and I tie it directly to productivity in much the same way I regard the chair I sit in.
In another instance, I was assigned to work on a bug that came from one of our customers who have a server cluster implementation of our product. Our standard developer setup is designed to support only a single server and, since our product makes heavy use of Java concurrency and that feature appears to be central to the issue at hand, I suggested that diagnosing the problem may warrant simulating an environment comparable to what the customer has. In other words, amid a lack of such build options in my local environment, I should first work on modifying our environment to provide for it and be able to reproduce the bug, then diagnose it, and finally issue a fix that is locally tested in a reasonably similar environment as the production setup where it originates. I was told that that is unnecessary and that I "should be able to follow the code to find where the race condition occurs between multiple servers and devise a solution in my setup as is without even reproducing the occurrence". I was quite at a loss faced with that suggestion because I have never in the past worked like that. It is almost like suggesting I should write code in production, making sure my it compiles and works as intended the first time I write it. I have been told numerous times that I should simply "follow the code and not try to reproduce the bug because it will be impossible in development". That reminded me of this quote. One of the teammates told me that he had fixed a multithreaded bug in a single server setup and never tested it before it was migrated into the QA environment, which does have a multi-server setup. To me, that is either reckless or undoable or at best haphazard, in all instances impractical. With my cognitive style, it is virtually impossible to get a mental picture what a blueprint (code) does without building a concrete, hard, tangible, runtime manifestation of the scenario. Moreover, I really think that's a better, safer, and more conservative method to go about doing work that will ultimately yield a stable and reliable assembly line of our software shop. UX matters, whether you are an end user of a simple web site or a software engineer designing or testing applications.
So I have a feeling that my coworkers regard my working and learning style as "high maintenance" and very needy of special and very ergonomic accommodation. What they do not know yet, because I simply have not been at the job that long, is that once I sink into my position comfortably enough and get immersed in the product, tools, and environment, I become extremely productive and resourceful. But considering my style, the ramp-up stage may take awhile or at least a bit longer than expected.
To be honest, I have fears they may never gain an understanding of my different approach and needs, mistake me for lazy or stupid because of them, and let me go. The reason I am posting this is to reach out to many of you out there who come from different backgrounds and who may have seen similar situations or been in one yourself and ask for advice how to proceed in my situation to get my boss and team mates to extend more understanding for my working style and cognitive model. I am confident that I can be as productive and instrumental to the company as them and then some, only if I am afforded such an understanding and support for my somewhat different methods of working and learning. I really love my job and the technologies used and I like the people so it would disappoint me to not be accepted because of this condition.