TLDR; Don't treat your developers as commodities, they are people with feelings, and add tremendous value to your business, so if you don't treat them right, they'll leave, which costs you money.
I've been in the industry quite a while now going on +10 years. which is a shock to most people as I'm still relatively young. In my time as a developer, I have worked at a few of different companies ranging digital service agencies to SaaS companies.
In my time working with these companies, there have been ups and downs. But, yet one thing that has been immutable is the fact that I have never stopped learning. And one of the most important lessons I've learned is that I will never stop learning as long as I am in this industry. You might be thinking what does this have to do with my chosen title, and I'll get to that!
One of my most recent experiences has proven to be one where I've learned a great deal. It's not related to code, but to attitudes which are still prevalent in our industry. And more so in the PHP industry. What I've learned outlined how serious the situation was, and all the possible business ramifications.
It's all to do with developer retention. First a little background on my first experience on developer retention. X jobs ago I worked for a company which had the worst developer retention rate I had ever encountered. Unfortunately, this is not a fact I was given when interviewing for the position.
This company was going through a tremendous amount of developers each year, none ever staying more than 1-2 years and in some cases much less! So what was the issue? why did developers not feel like they could remain and develop their careers at this company? After all they had some fairly large clients, all which would look great on a CV, a vast range of different projects, as they were a SaaS company, so a lot of variation on the type of work.
I'll break down the issues that I observed and experienced which caused most developers to leave.
One of the leading causes for the departure of developers was the tremendous amount of technical debt. All of the primary systems were written in the PHP 3/PHP4 days, and indeed some written over 20+ years ago in with MS fox-pro. Now there are a few issues with this, firstly that, as a SaaS company, you need to redevelop your systems to stay up to date, and continue to be relevant, otherwise your competitors will take all your business away.
No major work had been done on these systems for a very, very, very long time. Most work was client specific, which involved integrating new clients and developing new features. Think about that for a second, this company was still selling 20+ year old software, that in of itself isn't a completely unforgivable sin, a lot of the services we use today run on old software, because the old software worked and there usually had been heavy investment to get that software in the first place, either via a one off cost, or licensing fee. However, the difference is, this company did not have a stable or even secure platform. Some of the servers were still running PHP 4... I'll just let that sink in.
A good analogy to compare the software we were selling to our clients is (for Stargate fans out there) Mark II Naquadah generator
The Mark II series was developed, and it is capable of achieving 600% of the power output of the Mark I; it operates in a state of barely controlled overload
So what I mean by this analogy is, the software performed well, as demonstrated by the fact it had been running for so many years, but tens of botched feature developments, and poor architecture in the first place caused this boat to leak like sieve. It was achieving it's business goals (barely) but it was running in a state of controlled overload, it was very temperamental, and due to the fact that there was literally no testing, it was always prone to break every time a new feature rolled out, which in turn would cause a temporary meltdown.
Combined, these facts made for a very unenjoyable working experience for the modern PHP developer, and the lack of interest in updating these systems ultimately in many cases resulting in the developers wanting to leave in search for more fulfilling up to date work, because as we all (well some) of us know, we need to stay current in our industry, or risk losing a job opportunity to someone else who is up to date.
Unwillingness to get up to date
One major issue was also that, there was a seeming unwillingness to get up to date, to fix the issues this system had to make it easier to maintain, or even to just in parallel invest in the principles of the software and redevelop it using more updated practices and methods, and most importantly bring in industry best practices.
During my time, I did however manage to persuade the head of IT into improving some things namely proper use of Git, I introduced git-flow, I started a company backed tech Wednesdays, where the company allowed anyone who had the inclination to present information of technology they think could benefit the business to us with a proposal on implementation.
Unfortunately they no longer practice this, however it was a good source of progress whilst I was there. Unfortunately since I left, there has been no one else who joined that stepped up to the plate to improve the situation.
Disloyalty to staff
This point links to the first of technical debt, loyalty to your staff to many people is very important in a company, If an employee feels that you do not care about them, and don’t particularly have any loyalty to them, it’s likely it will be mutual. In our industry, this is a huge problem and money hole for companies that don’t realise this. It’s due to the fact most companies now use recruiters to hire developers, and the use of recruiters means a hefty commission payment when you take on a candidate which has come through a recruiter, so you can imagine, if you’re going through 15+ developers a year, these commissions stack up quite a bit!
Now the disloyalty I observed and experienced, was like none that I had seen before, In other companies I’d worked at, if an employee made a mistake, the company did not stand apart from it’s employee and point fingers, it stood by it’s employee and took it’s responsibility as the service provider, then handled the disciplinary process privately. This was not the case with this company, I’ll provide a single example from my pool of examples.
There was an issue with a payment provider that my colleague had integrated, I had also been part of the integration, but was not the primary developer, I essentially took over the project temporarily whilst my colleague was away, when I got to it however, I realised my colleague had in fact done nothing, so with the deadline looming, I had to pull out all the stops to finish the payment provider integration, which I managed to complete the day my colleague came back from holiday.
I then handed it over to him again, which is when he made the mistake, he changed something which caused the system to fail in communicating successful payments to another part of the system which then processed an order which had been taken from a website. As a result the client which the integration was for ended up having after a couple of weeks over £250,000 of money taken, with no orders for the money, we essentially took the money, and left it at that.
The project manager proceeded to inform the client that I had made a grave error, and that I was to blame for what had happened, which the MD then clarified to the client and absolved me, as I was not the guilty party. However the damage had been done, firstly, by the fact I was not responsible for this mistake, secondly, by the fact that I was humiliated by my PM - fortunately I had dealt quite a deal with this client, so they doubted what my PM had reported to them.
Regardless, I had been thrown under a bus, with no remorse, nothing else came of this, I received no apology, no nothing, my PM carried on talking to me as if we were best buds, the issue about the money was fortunately resolved. But I was not happy at all, it was one of the worst shows of disloyalty I had experienced.
One manager in particular, whenever an issue arose, instead of focusing on trying to resolve the issue, was much more content to play a blame game, and try and find someone to blame, at it’s core all of us knew the true issue was this monolithic system which was highly unmaintainable and unstable, however, this manager refused to acknowledge that, and much rather get to blaming someone than resolving issues promptly. This also ties in with the point about disloyalty. (three guess which manager this was).
Unfair pay scales
Our industry is a competitive one, there are more jobs out there than developers at the moment, and thus causes our salaries to get pushed up quite a bit above the average salary in most developed countries. However, there are companies, who unscrupulously just decide on the spot what they want to pay someone, and many times try to pay as little as possible, and take advantage of developers whom are perhaps not so confident in their abilities, and settle for the lower pay, whilst then hiring another developer with equal skill and credentials for double the salary.
This is one of the things that made me most uncomfortable, as I was one of the few seniors at this company, I would usually be involved in the interviewing process, so I saw what was being offered to the developers who would interview with us, it made me very uncomfortable, they were only interested in getting the best help for as cheap as possible.
We had quite a rigorous interview process, and time and time again, I saw developers with equal skill set get widely different offers, at some times to the point of extortion. There was a 20k+ pay gap between some of the seniors, and it was even worse at the mid level.
In development environments, you often find that like minded people usually end up in similar professions and companies, mostly because for each profession it takes a certain gusto, and mindset, and when hiring a company will often try to determine if you’re a good cultural fit, so you end up sometimes making friends, and friends sometimes talk about their pay, and their issues, so the developers started becoming wise to this unfair practice and realised what was going on, unfortunately, this has not made said company change their ways, and a couple of the friends I made whom still work there, have said they are still doing the same thing.
This first experience taught me a lot about how to deal with these issues, and how to try and improve these situations, it also taught me to recognise a lost cause when I see one, now onto my most recent experience.
My recent experience
My most recent experience (I’ve written that a lot in this article haven’t I!) was at the client side, but the location of the sector isn’t really important, just a comment. When I joined we were working on the old system again, a very old system based on a cart package called “CSCART”, it’s still around, but they look like they have rebuilt it. The old system was going to be phased out, a new development project had been approved by our parent company to develop a new system from the ground up, which all of the niches which made this company what it had become, a multimillion pound business. The new system was to become hopefully a standardised platform for the whole group, including some very big names.
A few months passed, I knew that I had to work in the old PHP 4 style procedural system for a while before the new stuff, and I was completely fine with this.
Fast forward to the start of the new system, my colleagues and I are handed a very incomplete basal home-brew “framework”, we were aghast, this home-brew framework, had code in it, which was written 5 years ago, and had not been touched since, had 0 tests, and was terribly inconsistent, and as mentioned incomplete.
We attempted to convince the lead architect to use an existing open source framework to no avail, He was adamant we didn’t need one, he wanted this new platform to be as bare bones as possible for “speed” as if you can’t optimise other frameworks… and as if a framework automatically makes an application slow. Our arguments based on fact, did not matter, opinion ruled over fact.
We begrudgingly gave in and proceeded to begin working on the backend system, however due to the fact the core which we had been provided with was so incomplete, we attempted to try and complete the missing parts, things like a proper router, active record implementation etc… however, the architect did not like us messing around with his “baby”, every time we went near the core, to try and add the missing functionality we needed to carry on with our work, we were met with aggression and patronisation.
This carried on for a while, we tried introducing design patterns which would have benefited the system, we tried making the naming consistent, we tried to get him to agree to some standard coding style, preferably PSR, but any would have done, even a custom one - however, this was not high on the list of priorities, in fact it wasn’t even on the list. We tried to make the code dry, by putting common methods in our active record implementation in the core of the faux ORM we had, to which we were scalded and to just write the same method in every model, e.g. to fetch all records, at the time of me leaving there were over 40 variations to fetch records from a table via this faux ORM.
We brought up that because we were dealing with money, and large sums of it, we should have unit testing for at least all the areas dealing with money, we were shot down, something I find incredibly irresponsible.
I could go on, so I think I’ll leave the issues we encountered at that and get down to the main point of this article, besides being a rant of all my pent up annoyances from these experiences, which is, if as a company you do a combination of any of these issues I have listed, you’re going to have a high developer turnover rate.
Developers are in increasingly high demand, and you need us more than we need you - not to say, that we will leave you at the drop of a hat, but that, if your developers raise any of these issues with you, don’t ignore them, more likely than not, they are not alone in feeling the way they do, and where you have one developer leaving due to these grievances, you’ll have many more, which at the end of the day, means your company will be spending more on constantly recruiting new developers, then training them up in your systems, for them to leave within 2 years.
So it’s not just to the benefit of your developers to try and be fair and just, and at the same time trying to keep your business current, it benefits your business in ways you won’t even imagine.
All opinions are my own, no company or person has been named, no time frames given, the purpose of this article is to underscore a prevalent subculture within our community which goes against industry practices and standards and which denotes the existence of many toxic environments which hinder a developers career. In addition I am by no means a write, but I try, in addition English is not my first language, and have a tendency to write run off sentences, if you notices something I could correct let me know :)