Structure Studios Reviews

Let’s focus on the technical portion of the job for a while. The code base was an example of almost every single anti-pattern possible. Technical leadership built the code base using undocumented and unenforced paradigms which caused incessant instability and buggy behavior. The worst part is not even that the code base was hacked together, poorly written, minimally commented, weakly architected, tightly coupled, extremely unstable, leaked memory and had sluggish performance. The real problem was that technical leadership refused to acknowledge the problem. There was active disapproval of time spent refactoring or improving existing systems. Several employees made various attempts to correct blatant flaws in the code base, but their efforts resulted in one employee being singled out, yelled at, and formally reprimanded. Developers had to constantly prove to management that they were earning their salary. As management had no background or training in software development, the only efforts that were valued were those with some obvious visual effect in the software. Technical improvements or architectural enhancements were not understood and thus frowned upon. Twice weekly developer scrum meetings were instituted, but these only served as a sort of performance review of what each employee had accomplished since the last meeting. Management even went so far as to inform one employee that they should put more effort into embellishing their update. Several standard systems that most development studios take for granted were not in place when the group of new hire developers first started. Eventually, the engineers implemented a continuous integration solution, functionality to help analyze and correct software crashes, a streamlined repository directory, and other enhancements. This was all done on their own initiative despite technical leadership’s continued attitude that such core technologies were a waste of time. Basic programming practices were not observed or valued. The only coding standard was to maintain the existing style of any given file, yet technical leadership regularly violated this tenet. Comments were extremely sparse and only spelled out the obvious. Code reviews were rarely performed, and only on employees management perceived as problematic. Even then, the code reviews focused on topics like “What was the most difficult part of writing this code?” rather than indicating specific recommendations to improve the submission. Other reviews were performed on code submitted three or more months before, long after the requirements and direction for that portion of the software had changed. Any attempt at dialog over the negative feedback in the code review was met with open hostility and interpreted as disrespect towards leadership. It was reiterated multiple times that the technical leadership was beyond reproach and alternate viewpoints were unacceptable. Meanwhile, technical leadership demonstrated extremely lax coding habits, and actively encouraged engineers to not waste time compiling for multiple variants or doing much in the way of testing. Tech leadership instead preferred to leave all but the most basic and cursory of testing to the customer support staff which doubled as a part time QA team. Management demonstrated that value was placed on speed of implementation over quality, and when new features from technical leadership resulted in program-wide bugs, other employees were blamed for the errors and forced to fix the problems. Beyond the issues an engineer faces when working at Structure Studios, there are multiple other concerns. If you are looking for a place where you can allow your skills and career to stagnate and simply rely on your ability to praise and stroke the egos of management, you may do well at Structure Studios. If, on the other hand, you take pride in your work, value a sense of ownership in the resulting product, and are eager to actively work towards the improvement of both the company and your own skills, look elsewhere. Performance reviews of employees were far from reliable. Development employees would receive glowing feedback during their twice yearly review, yet only a month later management would claim that employee had a poor attitude and failed to meet expectations. Employees that suffered from management disapproval would receive reprimands, but such reprimands rarely gave specific examples of poor performance, or clear and quantifiable means to improve. In the rare instances when specifics were given, leadership would dig for any excuse they could find, such as citing lines of code written as a metric for performance. Management claimed that they were open to feedback and improvement, but stressed they were only interested in ‘positive’ remarks. The post-sprint retrospective meetings originally gave the development team an opportunity to express concerns about the newly implemented Agile methodologies. After two months, however, management was furious with the perceived negativity in these meetings and required that all comments be strictly positive in nature. It was made explicitly clear that management was incapable of handling even the most gentle of constructive criticism in any form, whether written, spoken, presented as a group, or individually. Any efforts to help improve processes or facilitate communication were met at first with passive aggressive silence. A month or more later management lashed out with open hostility at those they perceived as the instigators of the supposed insubordination. In reality, there was no insubordination. All the developers genuinely had the best interests of the company in mind and wanted nothing but to help make things better. Negative attitudes only set in after management’s incompetent and bungling attempts to root out the imaginary disturbance. When an employee was singled out for a reprimand by management, criticisms leveled at the employee did not focus on specific events, incidents or professional shortcomings. Instead, the meeting focused on an employee’s personality flaws. For example, one employee was informed they had a tendency to “one-up” coworkers in casual conversation, and another was instructed that they needed to stop being overly analytical. These reprimands, given to each member of the development team about once a month, were given with a complete disregard for professionalism. Official disciplinary actions were sometimes conducted with another employee present from a different part of the company. HR was seldom present, but it would not have made a difference as there were blatant conflicts of interest between management and HR.

Some of the challenges of working here include management who constantly asks you what you are working on even directly after twice a week "scrums" which consist of software engineers justifying their work to management instead of just quickly telling each other what they are working on. As a software engineer, you will be told to implement a feature, exactly how to implement it and have very little to no room for discussion because all the design of features is done by a tag team of management and QA, none of which have any software design experience. In fact, the collective knowledge of computer science is often disregarded, and it has been stated that, "Just because everyone does *that* a certain way, isn't enough reason for us to." As a new employee you will be forced to "prove yourself" with none of your opinions holding any weight regardless of your experience. If you are looking for a place to make a difference, this is not the company for you. At Structure Studios, different is bad and needs to be eliminated anywhere it is seen. If you have ideas on how you could make processes better (and you should), keeping them to yourself is the best course of action because anything other than praising the way things are done is seen as undermining the company. This is even true on processes that are only created or initiated since you have started working there. In fact, past accomplishment, no matter how rose colored, is weighed more heavily than anything else. Including expertise, experience, common sense, and standards. In short, your opinion will never be as valuable as someone who has been there longer than you, despite the quality of the work presented. Management defers to QA in every design decision, even when opposed by the developer working on the feature, modern software design principles, and common sense. Management also often gives developer direction through QA, making QA appear to be above dev, causing internal conflict. The salary is below par for Las Vegas, especially when you add in the inadequate health care. Management counts potential bonuses as part of salary, except when you are given raises. The cap on bonuses never changes. Management goes above and beyond to never make a decision. During a period of 3 months in 2013, development crunched up to 100 hours a week. Crunching was never acknowledged, no comp time was offered, and no meals were offered during that time. It wasn't until after the team complained, several months later that it was even acknowledged. Don’t expect backing from the the senior dev team members either. They hate managing just as much as upper management and chooses not to get involved in any decisions or fight for any new tools or processes, and rarely even sees the need for them. You get 19 vacation days per year, and you need them since any time you want to take off is deducted from PTO. Need to go to the doctor? PTO, need to pick up a prescription or meet the cable guy? PTO. Very rarely it isn’t if you can squeeze it into your lunch hour, but you still have to make up the time. Meanwhile, management will disappear from the office on a whim for days at a time. Everyone else is required to log time off in the company calendar. You are also required to give several days notice for things like going to the doctor. Management is also incredibly inappropriate, disparaging former employees in front of others. They will also praise you in private meetings and then talk about your lack of performance with your co workers when you aren’t there. Management convinces themselves that employees are out to destroy them and systematically targets one after the other trying to cleanse the company of evil. Management has also been known to yell and scream at hourly employees, call them stupid in front of their co-workers, and encourage them to quit, presumably, to avoid paying unemployment.