While I did enjoy working for Sparefoot in the beginning, some troubling things started happening and at first they gave me pause, but then as these trouble areas were not really addressed, it started to be indicative of bigger problems that are not so easy to see on the surface.
Sparefoot purports itself to be a very innovative workplace. They have the core tenant "hire better" which basically means they hire people specifically to bring better skills and ideas to the team. And while I was given full support to innovate and improve things on the front end, anything I attempted to improve or innovate on the back-end has been met with much resistance. At first I thought it was because I just didn't understand the history of our back end tech-stack and all its nuances, but after years of learning and understanding the stack, I've come to realize that it's just several developers who are rigorously turf-guarding that territory. At first it would just be a seemingly innocuous comment like "Oh we were planning on doing that", or "That's not a bad idea, BUT...". What these comments eventually lead to is more and more resistance in a weirdly political way. I have seen weeks of planning get thrown out the window because the moment you begin an attempt to engineer something, people come out of the woodwork with this chicanery intended to coerce you to allow them to re-plan your engineering on the fly. It's quite frustrating when you're sold on a company who wants to "hire better", but your peers want you to "fall in line".
A number of Sparefoot engineers are deeply entrenched, and/or set in their ways. While this is not all bad, it is bad that their entrenchment can be characterized by a lot of ignorance of software design principles, and bad coding habits. While on the surface, Sparefoot engineering seems intent on improving their product quality, in practice they are frequently taking shortcuts, carelessly accepting large amounts of technical debt, and overall bad coding habits. The ideal of developing quality products does not play out in daily commits and planning. It's evident in a large number of services, that have been created, to replace the old monolithic application, that they have simply copy and pasted or imported a large portion of the bad legacy code into new services, without so much of a thought about the opportunity to refactor and make things better. For example, moving this functionality presented an opportunity to at least take advantage of PSR-0/PSR-4 namespacing that has been ubiquitous in PHP for the last 5 years, but instead they simply copy and pasted a lot of old code and continue to use old PEAR style namespaces which have been defunct for just as long. That's just one simple example; a LOT of the old terrible code is now baked into new projects and the ramifications of that fact will be felt for years to come, although it's unlikely that most of the engineers responsible will understand that those problems come from laziness and lack of foresight. There is, also, a clear and overall unwillingness to pay back technical debt. So as developers are rushing out bad code, and shortcut solutions, they are also encumbering themselves with a lot of burden that will probably never go away.
Over a period of a number of years Sparefoot's engineering and product turnover rate seems very good, but when you average it over the period of the last 8 months, it's clear that the turnover rate has been rapidly accelerated. While the numbers will seem scary, the story the numbers don't tell is even worse. Sparefoot has lost some of their best developers and product people, only to be replaced by very green and very new warm bodies, or not even replaced at all. It's quite difficult to "hire better" when you're hemorrhaging talent. To compensate for this, Sparefoot product and engineering has had to shift priorities countless times in the past year, and reform their teams a number of times, because not only are they suffering from a net loss in talent, but also the loss of core knowledge of the business policies, history, and engineering has occurred because the people who have left were long-time employees that were some of the few who had experience when the foundational pieces of these systems were being formed. Many people who have had to take over in their wake, were woefully unprepared for the duties they'd have to adopt. Due to attrition many projects just get consolidated into other projects. Over a year ago, when this trend of attrition began, the management held meetings and were conspicuously addressing these concerns before they even started to form, in the way of "Don't worry, it's just a coincidence that a few people are leaving", "We've only lost 7 people in 3 years", "This is normal". Now that this trend has continued for a year and it's clear that there IS a problem, all we hear is deafening silence on this subject. It's quite alarming when you're in the middle of a domino effect, and people refuse to admit or deny that it's happening.
For the past year I've noticed the average demeanor of people, at Sparefoot, has grown colder and colder. It's the sort of Malaise that settles in on a company that had some really meteoric rise, very early, and was struck by a demoralizing period of discouragement that killed the buzz. It's definitely chilling when I think about the place I was hired on to just a short few years ago. Would I accept a position at Sparefoot now? probably not, this doesn't feel like this same place I was hired at. It's going to take a large change in attitude and policy to get this ship right, hopefully we can turn it around before I decide that my time is past. In this new Sparefoot all I want to do is keep my head down and wait for my shift to end; I miss the time when I was eager to jump in and collaborate with my peers.
