Pluspunten
The low level office staff are all very friendly and helpful and easy to work with. The company gives very good benefits to its full time staff, and the office environment is very quiet. Compensation was at market value and very reasonable. Office hours were flexible. The work was very challenging and interesting.
Minpunten
The office building in Grenada is quite old, and the central heating and cooling is in poor condition. At times, the building can get unbearably warm, and the air conditioning seems to be broken quite often, which seems ironic considering the company's manufactured product is heating and cooling coils. The bathrooms are very small and are in poor condition. The rest of the cons are related to the job title - as a software engineer. The job involved supporting a tremendous amount of legacy code. However, there was very little documentation provided, and almost no training was given before being thrown into the work environment. This was not intrinsically a problem, except when combined with unreasonable expectations and a lack of patience while employees learned the system. A lack of understanding about how long it takes to learn new and complex systems that have been in place for over a decade created a boiler room of stress and disappointment on all sides. The amount of meetings and stat tracking for work being done was overly excessive, and used more as tool for controlling and monitoring employees than for keeping lines of communication open. Reports were regularly made regarding the status of work, but were rarely read, leading to confusion about the status of tasks or what someone was working on. Job tracking software was used as a replacement for actual face-to-face communication, which often resulted in poor communication. The web-based code was in terrible condition, which made it very difficult to complete tasks in a timely manner. It was not uncommon to find multiple broken items on a section of code while working on a "simple" request. Pointing out these issues would result in denial and a fantasy that the problems never existed in the first place. The "lie" that the software was working perfectly was upheld to the bitter end, even in the face of a mountain of evidence to the contrary. Working in an environment where no one faces reality made the job incredibly difficult to do, as one needed to make fantastic leaps in logic and maintain multiple personalities with multiple fictitious states of the software depending on who you were talking to. There is a culture of not finishing work within the software department. Work is assigned a time value, and then work stops when that time value is reached, regardless of whether or not the task is completed. This resulted a long-standing culture within the programming department of turning in work that had a facade of finish, but with no polish and little substance. Once a task was "completed," it would rarely be visited again, creating a situation where many elements of the software were broken, but believed to be working and finished. Old tasks could not be reopened, even if they were unfinished or broken, because it would draw back the veil of lies that had been placed over the software. This also created a situation where you would routinely have tasks and projects canceled out from under you if you didn't finish them quickly enough. This culture had been in place for so long that at some point the people carrying out the farce started to believe the false past that they had created... it made communication very difficult between users and management and co-workers because there was extreme confusion about what had been finished and what hadn't, or what was working and what wasn't, etc.. There was a very thin margin between being a "good" developer and "completely sucking." As far as I could tell, in order to be a "good" developer, one would have needed to have a genius level IQ, a photographic memory, and ESP. Yet also they would need to be incredibly humble and never outshine senior programmers, ask for help occasionally just to show that they are using the resources provided, but not actually need that help too much because then they would end up looking incompetent. As near as I could tell, the company has spent the past 7 years milling through employees in a never-ending recruiting process trying to find such a miracle employee. When they couldn't find one, after repeated failures, it was just chalked up to bad luck and the poor state of the job pool in the software market. There was a culture of bullying within the software department that ran very deep. New employees are made to do training, debugging, general helpdesk complaints, and any other unsavory work that the senior programmers don't care to do because they are too busy doing "real programming". It was quite common to have projects handed to you that were about 50-70% complete, and be told to debug it or present it for training, etc... You would then serve as a middle man and "go fer" between the users and the programmers. This role was pretty much indefinite once you got on it, and although it was presented as you being a "team player" it felt like a form of establishing boundaries between "real" programmers and non. Once you were relegated to this type of work, it became very difficult to get out of it, as you would get type cast into it, especially if you did a good job at it. This made it difficult to get experience doing other types of programming. Communication within the department was very poor. It was not uncommon to have a "conversation" that would leave you puzzled for hours afterwards as to what was said or what was meant. Management seemed to have no understanding that you could not read their mind, or magically absorb 10 years worth of corporate knowledge within the span of a few minutes. This created a sort of "cognitive dissonance" where someone would give you a task that they considered quite simple, then would completely lose their mind not understanding why you had not been able to understand and complete the task as quickly as they could have. Any attempts to clear up this misunderstanding or to create more effective means of communication would result in gaslighting tactics, head games, or complete dead silence in communication. This again would create a situation where you couldn't do your job effectively. All of the above of course factored into performance reviews, and the overall general level of stress being generated while working at the company. My impression of the previous 7 to 9 software programmers who left is that they all dealt with this in their own ways - from leaving, to giving up on the job, to being fired... many of the employees cited a lack of training when they left, but after working with the company it is my opinion that this cited reason was more a symptom of a larger problem. That being that employees were overworked and overstressed while dealing with poor communication and an overall lack of understanding of the programming challenges that new hires faced. Most "sane" people would feel that having more training might result in these things being avoided. However, no amount of training would fix the underlying issues, and thus the reason why providing more "training resources" doesn't actually work when new hires are brought in. I will not say that no software engineer would be able to work for Luvata, but I will say that it would take a very special person with a very special collection of personality traits in order to thrive and do well there. I wish anyone who comes in after me good fortune and good luck. You will need both - you have been warned.