Transfix Reviews

- Team Process is labeled as Agile, but doesn't have much in common with that practice other than the name. A ton of meetings to appear as if though a process is followed with not tangible result from them. Example: having pointing meetings is pointless if you don't track velocity or use a velocity to plan for your sprints and long term epic roadmaps. - Tasks are poorly documented, unclear, and in most cases imply a ton of information instead of explicitly stating it. Lot's of time is spent trying to decrypt the cryptic titles or single line descriptions filled with logistics industry acronyms. - With all of the planning and meetings make belief once the sprint actually starts, all that goes right out the window. The focus is pretty much 80%-100% the time on implementing quick fixes for unplanned, un researched, un documented issues that come up during the sprint. - While the engineers working there are bright individuals, the code base they work on tells a very different story. Multiple implementations of identical concepts littered all over the code base indicate a lack of architectural thought process. Poor design patterns followed in legacy and new code. While a lot of this could be attributed to to the constant drive by management to quickly fix issues instead of resolve underlying architectural problems, engineers should really strive to keep to a higher standard and say no. - While the software claims to be a SaaS, the code base is just spaghetti code with a ton of client specific conditional if statements. - The engineering culture is very much a "write it once and never touch it again" approach. Which I have heard the CTO say a number of times in technical proposal reviews. This essentially leaves the engineering team with an ever growing legacy code base, with no plan or initiative on any backlog to ever refactor or pay off some of that technical debt. - There is tons and tons of documentation, that is either outdated, unmaintained or serves no purpose. Valuable technical documentation like ERDs, Data Flow Diagrams, and holistic architectural documents simply don't exist. What's worse is that when discussed to potentially include these vital pieces of documentation in the software development lifecycle, the notion would be shut down. - Management...i get it, it's not easy to manage people..but to be a good manager doesn't just mean to tell the people you are managing what to do. Rather it means to empower them to do their job better, by trusting their expert opinion and allowing them to produce the solutions they are being paid to produce. Egos, seniority, and emotions need to be left outside of the work environment, which isn't always the case here. - Career progression for the Individual Contributor is documented on paper, but other than a few exclusive slack channels, doesn't seem to make much of a difference in practice other than title and pay. The everyday work between Senior Software Engineer I and II, and a Staff Software Engineer seemed identical. - Logistics industry is archaic, and enormous. Which means that in order to disrupt it you need to hold the majority of the market, or have enough money to capture the majority of the market. Transfix has neither, well all logistics companies have neither. What this means is that the biggest pain points in this industry from a technical perspective will not, and can not be disrupted. Think vastly outdated mainframe files for transferring data. - Domain Driven Design is not what you would find here. Definitions of specific concepts differ from team to team, and whats worse is that it differs from vendor service definitions of the same concept. You would think a logistics company would be able to clearly define what a "load" and what a "shipment" is.