Actian reviews

The company is large and has many products and teams. I can only speak to the particular product I worked on and the particular team I was a part of, from the perspective of native code. The team suffered that age old scenario were one or more members had been there since its foundation, had tenure and clout, and as a result, had little to no oversite and free reign. The codebase was obviously decades out of date, was assuredly written by a rogue programmer, and chalk full of some of the worst software development patterns one could imagine. It would be a great struggle to even convince someone to perform the most basic and fundamental modern good practices. Do you believe in one class per file? Encapsulation? OO in general? Single responsibility principle? Self documenting names? Commenting documentation for classes, methods, and variables? Unit testing? How about something as simple as building and running the same output that CI/CD does? If you answered yes to any of these, you will be disappointed. Common problems included: * Code reviews were auto approved. I rarely saw anyone comment on anything at all. When I did leave items, they were largely ignored. * Bugs were knowingly checked in * Unit tests were skipped, even on bug tickets * Merges weren't checked for successful build before being merged to shared branches, often breaking the build on one or more operating systems * CI/CD pipeline used a different environment and had different results compared to developers * Every member of the team had custom scripts to setup their dev environment, their own tools, used different versions, build systems, directory hierarchies, etc. Finding why one person's build fails and another's succeeded was a week long effort. * Variables were named with single letters and generic names where every line of code was a chore to understand. c, j, k, pcontext, data, manager, arg, param, etc. * Classes frequently had their data exposed, dozens of statics, friend declarations, etc. ....All the C programmer writing C++ things. * Most of the files were 5,000 lines or more. * Custom classes were created to replace things that were in the standard libraries. If you google "How to write unmaintainable code and have job security for life", 3/4ths of the items you find listed will be what you experience on this particular product on a daily basis. The excuse I heard, for all, of it is "legacy product being decades old." However, I'd argue that it is one thing to have started writing a product 30 years ago, but it is another continue to write code exactly the same way it was written 30 years ago, today. Unrelated to software engineering practices, you will also find that this company, as a whole, is HUGELY political. Diversity and inclusion is one thing, but getting daily emails from HR on any political related news happening with soapboxed paragraphs telling you what your position should be on it, who you need to donate money to, what bills to vote for and how to vote on them, who your political enemies need to be, etc. is way up beyond the boundaries of what an employee employer relationship should entail. I'd much rather work for someone whom focuses their concern on their product, their customers. and their employees.