By Lance Eliot, the AI Trends Insider
You have your sleeping bag at the office for those overnight non-stop coding deadlines that require you to work on the AI system until you get the particular component working right.
Turns out, you’ve been using the sleeping bag quite a bit lately.
Furthermore, you often find yourself telling friends that you cannot spare time to go with them to an evening excursion at the local pubs, due to having to stay at work. The moment you get to work in the morning, you are bombarded with tons of very intense coding to be done, and of course eating lunch at your desk is the only means to try and keep your head above water (no time to go out and get food or heaven forbid sit at a restaurant and eat lunch there). It’s a do-or-die culture at the workplace and you are immersed in it up to your teeth.
Welcome to the typical workplace conditions for AI developers doing AI self-driving driverless autonomous car systems work.
Now, I’m not suggesting that there aren’t lots of other computer system developers in lots of other lines of work that aren’t doing the same. There are. In fact, if you were to go from building to building in a place like Silicon Valley, you are likely to find tons of developers all suffering the same fate. Non-stop work. Huge pressures. Deadlines, deadlines, deadlines. And generally, no hope that it will let up.
I think we’re all amenable somewhat to the notion that from time-to-time there is a need for “maximum effort” (Deadpool!) toward doing development work. Those temporary urgencies do arise.
Putting one’s personal life on-hold to handle something truly needed at work is part-and-parcel of being in our profession. In some sense, it can almost even be something that you can later on brag about, hey, I did an all-nighter and lived to tell the tale. Some might even claim that it can make the rest of the time seem sweeter, in the sense that if you pushed hard on something a couple of months or weeks ago, changing back to a more measured pace seems “leisurely” in comparison.
But, the question arises, does an excessive overworking workplace lend itself to properly developing AI-based autonomous cars?
Overworked AI Developers And AI Systems Development
Keep in mind that AI self-driving cars are life-or-death systems.
If we were to compare the normal everyday kind of system to the AI system of a self-driving car, I think it would be fair to claim that the self-driving car system has a somewhat higher onus in terms of being built for high reliability and safety.
Sure, that accounting system you are coding might also need reliability and safety, but if it gets the credits and debits mixed-up due to an error or bug, this seems not quite as catastrophic as an AI self-driving car that rams into a wall or a pedestrian due to an error or bug.
Some years ago, when I started-up a new company for AI oriented systems development, our first major client necessitated that we work night and day to develop the system they wanted. It was crucial that we delivered to this client, otherwise gossip would have spread in the grapevine that we weren’t good enough to be considered for other major engagements. In this case, it was an AI system that pushed the limits of AI at the time. This made it doubly tough since we were trying to invent new Machine Learning (ML) techniques while also figuring out how to apply them to the particular need of the client.
As the founder and head of the company, I was knee deep in helping do the development (it wasn’t until later on, once the company had grown that I was able to step back from the development efforts and take on the more all-encompassing role of leader and also rainmaker). The team that I had hired was surprised that I was sitting there cranking out code with them. They were more used to managers that would assign work to be done, rather than they themselves getting into the weeds. I was at that time willing to do anything and whatever it took to get our first big project delivered on-time and on-target to what was promised.
I felt bad about having my team have to work so hard and non-stop.
Some of them had just started a family and were sacrificing time toward their significant other and their newborn kids. Some of them were eager to do the work and excited about being on the ground floor of something new. There was a wide range of reactions to the crazy blitz of work. I had pledged that it wouldn’t last and that this was just being done to achieve a specific goal. Indeed, after we got the project completed successfully, I paid out a generous bonus to the team members and the next projects were less overwhelming in terms of work time.
Turns out that many companies today have taken the perspective that there is no end in sight for doing overwhelming work.
It is the work.
It is the standard practice at the company.
I know many high-tech CEOs that brazenly tell everyone that they intentionally work their people the hardest of any other company in town. It’s a source of pride to be able to say that you don’t allow your team members to take vacation. These CEO’s are proud to exclaim that they work their people to the bone.
Some even smirk that the appearance of providing perks at the office such as an in-house chef and ping pong tables is actually a “trick” to keep their employees working at the office, done under the guise of claiming to show regard for their people. The minimal cost to provide food at the office is well-worth the added productivity of the developers.
Keep those developers coding and doing so by throwing them a bone of one kind or another is easy enough to do, some sadly seem to think.
Plus, the advent of smartphones and the Internet has made things even “better” for those companies desiring to wring every ounce out of their developers. An employee that leaves the office is still on-the-hook for answering questions and remaining engaged in work activities, via the use of their smartphone and their tablets. Texts galore, phone calls, the use of productivity tools such as Slack, and so on, all of which allow for true 24×7 work activity. In one sense, it doesn’t matter if you are sitting at work or not per se (so-called “butts in seats”), since any moment that you are anywhere, the expectation can be that you’ll respond and keep up with the ongoing work streams.
One company had encouraged their team members to “take a break” by heading to Yosemite (a wilderness area in Northern California, which is about a 3 ½ hour drive from Silicon Valley). Wow, unbelievable that the Attila the Hun leadership would actually encourage the developers to take some time off. Had the world come to an end?
Well, turns out that the company had arranged for the team members to stay in lodges at a camp area that was outfitted with Internet access. Yes, you guessed right if you deduced that the team members ended-up spending most of the time “in the wild” by sitting at the campground and working on their laptops. Furthermore, the leadership went too, ostensibly to also enjoy the outdoors, but more so to make sure that the team members were working and not taking time to go sightseeing. Now that’s a quite a vacation!
So, is it sensible to go ahead and work your people non-stop or not?
Some would say that it has become the default practice.
If your firm doesn’t do this, other firms will, and those other firms will be able to get ahead of your firm. You can’t “afford” to not have a non-stop work environment. Not only will your firm fall behind, there’s the danger that your firm will become known for having slackers. Don’t go to work at that place, it’s the lazy developers that go there. Those wimps. They only produce a fraction of what other firms can get done in the same length of time.
There are many executives that believe utterly in the coding until-you-drop type of work environment. Furthermore, if you do drop, the viewpoint is that it shows your weakness. It shows that you aren’t suitable for the big time. In a Darwinian way, these executives want just the survivors to be at their workplace. Survival of the fittest. And how to determine who is the fittest? Work, work, work. The ones left standing are the fittest. The ones that cannot stand it, they are out. Drop them like a brick. It’s as easy as that.
Sometimes these same executives will momentarily seemingly open their eyes to the situation and maybe, just maybe, concede that things are a bit over-the-top in terms of the workplace demands. Sadly, some of those will then do the Yosemite kind of trips under the false belief it will “refuel, recharge, and reconnect” their developers. They are either deluded into believing that a working “vacation” gets the trick done, or they know it won’t but want to at least seem to be doing something about workplace complaints or qualms by those being overworked.
Overwork Impacts On Development Of Autonomous Cars
What does this have to do with AI-based autonomous cars?
At the Cybernetic AI Self-Driving Car Institute, we are developing AI systems for self-driving cars, and, as such, we keep tabs on what other like firms are doing, and we’ve had many of their AI developers that have eyed coming to us, based on the excessive overwork taking place at those other firms and the more measured tone that we take.
This brings up some important points about excessive overwork.
Though at first glance it might seem “wise” to overwork your AI developers, since it would appear to gain you some kind of efficiency and productivity gains, the surface level perspective can differ from the reality of what actually turns out.
Let’s consider some of the downsides of the excessive overwork situation.
First, let’s agree that people can get burned out at work. I’ve seen this happen many times at the numerous companies that I’ve worked at over the years. For AI developers, you can pretty quickly see them become less productive. They become more irritable and less collaborative. Since many computer people are already a bit cynical, you start to burn out one and I assure the cynicism goes through the roof. This can have a very negative result on their coding and development efforts, including the fostering of an “I could care less” attitude of whether some AI component works right or not.
This is a dangerous thing to ferment when you are developing AI software for self-driving cars.
I challenge you to demonstrate that a burnt-out AI developer is somehow highly efficient and productive, which is what the excessive overwork pundits might claim. Sure, you are getting those developers to work longer hours than someone in a less obsessed work-hours environment, but going toe-to-toe, does the additional hours really translate into being more efficient and productive. I’d say it does not.
For my article about burning out AI developers, see: https://aitrends.com/selfdrivingcars/developer-burnout-and-ai-self-driving-cars/
For my framework about AI self-driving cars, see: https://aitrends.com/selfdrivingcars/framework-ai-self-driving-driverless-cars-big-picture/
See if you follow this kind of thinking. Suppose I have a worker that can produce 10 widgets per hour. Let’s assume that after some number of hours Q, their productivity falls to 8 widgets per hour due to fatigue and other factors. Then, after some number of hours S, it falls to 4 widgets per hour. And so on. Also, after an accumulated number of hours T, the normal productivity of 10 widgets per hour falls to an ongoing lower level since the burn-out is having a sustaining and permanent productivity drain.
You can calculate out the aspect that over some length of time of being in an excessive overwork situation, the worker is eventually going to drop their productivity levels such that they become ultimately less productive than the not-so-overworked worker.
That’s what some of these excessive overwork pundits fail to see. They think that the productivity remains high, regardless of whether you work one hour, 40 hours, 60 hours, or 80 hours. There’s not much credence for such a belief. If you were working on an assembly line in a manufacturing plant, maybe this could be shown to somehow workout, but when you are doing sophisticated work like AI development, it’s not the same as an assembly line (though at times it feels as merciless!).
Burnout Consequences And Churn Too
So, the first principle here is that by working your AI developers toward excessive overwork you are burning them out, which will undermine productivity. Thus, you are falsely believing that by your people working more hours than other firms that you are somehow getting ahead of those other firms. It’s a myth.
Second, the odds are pretty high that you’ll have those AI developers seeking to leave your firm, doing so in hopes of finding a work environment of a more measured nature. This seems especially true for the millennial generation that is aiming to have a more balanced work/life portfolio. It’s not that they aren’t willing to work, it’s that they are desirous of having work that can allow for life outside work too. One might claim that the prior generation(s) were taught to do whatever was needed for work, no questions asked, though this was also in a work climate of having companies that were more determined to provide career-long opportunities. This doesn’t seem to be the case anymore. It’s a mercenary work world nowadays, for both employers and employees.
I realize you might be thinking that having AI developers leave due to excessive overwork is just fine because they were the “weak” ones anyway. You might want to reconsider that belief. There’s lots of really good AI talent that knows they can command what the market will bear. There is a low supply of such talent. There is very high demand for such talent. Indeed, they are likely the first to leave since they know they can get something better elsewhere. If anything, it could be that the ones that stay are the “weaker” ones – though, I shun this whole idea of the weak versus the strong and don’t want to get mired in that debate herein.
Third, if you have a high churn rate on your AI team, it will definitely adversely impact the systems being developed for an AI self-driving car.
Each time you have one of your AI developers leave, the odds are that whatever portion they were working on will now suffer falling behind or have other maladies. Plus, whomever you hire has to initially go up a learning curve of whatever is being worked on. Therefore, you are going to take a big productivity hit during the time that the AI developer was gone after leaving the firm, and until the new hire gets fully up-to-speed.
These could be significant chunks of time. From the moment that an AI developer leaves your team, until the time that you’ve found a suitable replacement, and brought that replacement on-board, and given them a reasonable amount of time to figure out what the predecessor was working on, I’d dare say it could be many weeks and in some cases months to do so.
You also need to consider the impact to the AI development team. The odds are that you’ll use some of them to aid in the interviewing process. Count that as lost productivity towards their AI development tasks. Once you hire the replacement, the odds are that other members of the team will need to aid bringing that person up-to-speed. More lost productivity for them. Imagine too if the replacement turns out to not be conducive to the rest of the team, and so it could be that you might have harmed the overall productivity of the entire team for a long time.
Error Rates And Higher Likelihood Of Shortchanging Validations
Another factor of excessive overwork involves error rates and can severely undermine the safety and reliability of the AI self-driving car systems.
Suppose I can produce 100 lines of code per hour. A colleague, Joe, let’s say he also produces 100 lines of code per hour. We seem to have the same productivity rate. Imagine that my code is completely error free (yay!). Imagine that Joe has 1 error per every 20 lines of code. To deal with the errors, there will be time needed to find them and correct them. And, that presumes you can even find the errors.
This is illustrating that you need to consider the error rates and other such factors and not fall into the trap of relying upon some other simplistic measure of however you count productivity. AI self-driving cars need to have highly reliable systems. There needs to be overt and ongoing and insistent efforts toward making the AI system be as reliable and safe as feasible. Not doing so will likely produce AI systems that are more so error prone, leading to a possibly disastrous result for all.
For my article about software neglect, see: https://aitrends.com/selfdrivingcars/software-neglect-will-impede-ai-self-driving-cars/
For my article about norm deviance dangers, see: https://aitrends.com/selfdrivingcars/normalization-of-deviance-endangers-ai-self-driving-cars/
I’d like to also toss into the excessive overwork scenario that it can lead to bad decisions about crucial design elements of an AI system. It can cause the members of the team to become so stressed that they make take out their frustrations by purposely undermining the AI system, maybe even seeding something dastardly into it. Some at times have turned to drugs to try and maintain the non-stop work efforts, which then can lead to an undermining of their lives both inside and outside of work. Etc.
For my article about security backdoors, see: https://aitrends.com/selfdrivingcars/ai-deep-learning-backdoor-security-holes-self-driving-cars-detection-prevention/
For the dangers of co-opting sleep, see: https://aitrends.com/selfdrivingcars/sleeping-ai-mechanism-self-driving-cars/
Dilbert-Like Reaction Can Be Faking Overwork
Here’s another sometimes shocking surprise to those leaders that think they are doing the right thing by promoting a company culture of excessive overwork, namely the fake work approach.
An AI developer can be clever enough to appear to be making progress when they are really just doing fake work. If you come to me and ask me for an estimate of how long it will take to setup that ML portion for a particular component, I might sandbag you by giving you a super high estimate. I do so to protect myself secretly from the overwork. This seems sensible to the worker because they feel that if the firm is being unfair to them, why not be unfair in return.
I am guessing that some of you might be thinking that this discussion about excessive overwork is a plea to go toward being underworked. Lance, are you saying that my people should lounge near the pool during the workday, drinking margaritas, and having a good old time, and punch the clock once and a while. No, I’m not saying that. If that’s what you think I’m saying, please take off those rose-colored glasses about the fantastic advantages of excessive overwork that you seemed to believe in. Time to smell the coffee and wake-up to what’s really happening by your approach.
Notice that I’ve tried to carefully phrase the nature of the overwork as “excessive” in the sense that I am saying taking overwork to an extreme is the problem.
Conclusion
As I earlier mentioned, doing overwork is often a needed element when facing particular deadlines. This though is typically temporary in nature and the AI developers can stretch to cope with it, knowing that they will not be mired in it permanently.
For some high-tech leaders that romanticize excessive overwork, I think if they really looked closely at the impact it is having on their teams, they might reconsider whether their high-level perspective matches with reality. Others in the firm will often act as “yes men” to go along with the excessive overwork philosophy, since the top leader won’t consider anything else but it. For those firms headed by the “excessive overwork” demanding take-no-prisoners leader, it’s hard to get those kinds of personalities to see anything other than the advantages of insisting on excessive overwork.
Let’s just hope that the AI self-driving cars under their tutelage don’t come back to harm us all if those AI systems are “wimpy” in comparison to the stronger and safer such systems developed in a more measured work environment.
Copyright 2019 Dr. Lance Eliot
This content is originally posted on AI Trends.
Ai
via https://www.AiUpNow.com
Benjamin Ross, Khareem Sudlow
