Pros
Nobody really cares about the hours you work as long as your work gets done.
Cons
Pathetic compensation. From the day I started up until now, my salary has continually been less than 80% that of people in the same area with the same amount of experience. Raises are paltry and few. The year-end bonus is less than a third of a month's pay. Everything is horribly outdated: buggy libraries and tools from 2010 are used and developers are put to work implementing workarounds and reinventing features already present in newer versions because management is too cheap to upgrade. You can't expect basic SQL functions to be present because some of the servers use software from 2008. Forget about using any features from C# 6 (let alone 7). The "next big thing" for the internal framework involves bringing in a practically unknown Python-like language that was already dead five years ago. Despite ostensibly being a software developer position, you will write more SQL than code. You will mostly be cleaning up the mess that resulted from cowboy coding with no style guidelines and no thought given to design. You will not do any major feature development. That's reserved for the "core" team, who is cliquish to an extreme and shuts out all external input. You can try to submit a critical fix for a component- a one-line fix that's been shown to not have any side effects - and they'll stay silent for months before maybe implementing it. One developer in particular is supposed to be working with the core team on the new framework and they blackball him, make large, sweeping code changes without giving him any info, exclude him from meetings and generally discard any input he has. Nobody takes responsibility for anything because most people don't even know how half the system works. There are major system features in place where the person who developed them left years ago and the code is so incomprehensible that no one wants to learn enough about it to modify it. If you do manage to untangle the code, you then become its maintainer and are responsible for any bugs in it even if it was completely broken when you inherited it. Becoming the maintainer of something doesn't mean you'll get permission to check it in to source control, by the way - it's highly likely that you'll have to keep your code offline and manually deploy your modified version as needed. You will not be using Git, Jira, Jenkins or any other modern platforms or tooling at all. You will use a rudimentary batch file to manually push builds to production. Hotfixes involve directly dropping modified code onto production servers via SMB. Tickets are handled with the bare-bones system built into TFS. There is no regression testing. There is no continuous integration. Unless you come in not knowing SQL, you will neither use nor learn anything that has any application at any other job. Three months in, I could tell this was a complete dead end career-wise but I figured it was alright for a first job right out of university. Two years in, I wish I had just kept looking.
