Daniel Petrikin's avatar image.

Badass Pythonista

My name is Daniel Petrikin, An Abstract Version of Myself

Anonymous profile image
  • Why do software companies have such grueling work schedules?

    More software dev. organizations than other types of organizations, Electronic Arts for example, have been accused of not providing a balanced schedule for their employees. Why does this seem to affect the IT sector more than other sectors?

    Daniel Petrikin's avatar image.

    A grueling work schedule is a symptom of a much larger problem. There are actually a couple factors, some of which are more sensitive topics than others, but I'll try to take a crack at giving my take on why the industry seems to think this is "the norm" now.

    In order to analyze this I need to establish some baseline truths. Those truths are:1 - Your boss doesn't actually care how many hours you work. 2 - Software is creative work. Estimating timelines on creative work is a really difficult thing to do, and gets worse with more collaborators.3 - You are not as good as you think you are4 - For every software developer in the current market, there are at least 10 jobs fighting to hire that developer. We're in a talent shortage.

    1) I'll say it again. Your boss doesn't actually care how many hours you work. I recently remember reading a story about a QA engineer who did nothing but play league of legends 40 hours a week and was collecting 95k a year doing it. No, he wasn't a pro gamer. His job was actually doing quality assurance on software. So how does this happen?

    In this particular case he managed to automate the entire process of meeting the expectations for his position though some crafty development. Now, this does mean he could have had a very successful career as an entrepreneur instead of gaming all day, but I digress. At the end of the day he had some responsibilities he was expected to complete in exchange for his paycheck. So what if he did it in 0 hours? Sure, in his case there was probably a bit of the "ass in seat" mentality from the hiring manager, which is why he even bothered to show up to the office, but people are slowly changing their minds on that front. How his arrangement ended I'm not so sure the details of, but keeping that going for 6 years is pretty impressive.

    So understand, when you take a position, you'll be given some responsibilities and expected to deliver on those. No one cares about the hours it takes, in either extreme. Why do you think salaried positions exist?

    It works often in many hourly cases too. One client of mine and I have kind of a fixed arrangement. Fixed meaning there's a definite cap on the hours I can bill in any given period. There have been plenty of occasions where I've obliterated the hours on that cap. I didn't try to bill for the extra, I only made sure the client was aware that I was going to deliver on my responsibilities. How does that benefit me now? Well no one really questions the hours I put in anymore. If I work a half hour or twenty hours on a day, I bill that day. Saves me a lot of hassle of hours tracking as well, which is unproductive busywork if both parties are satisfied. I deliver at or above expectations, I get a check, and hours aren't really factored in all that much. To give you some context on how people feel on this matter, that client will very likely read this article, and will still very likely continue business as usual.

    Which party that benefits the most from this mentality is an entirely different question. Based on your question, I'm guessing you've been on the losing end of the stick more often than not. That doesn't have to be the case, and you'll see why in the other sections.

    2) Software is creative work. Since most software is in the business of task automation, if writing software were a predictable, uncreative task, it'd be the first thing that software writers would automate. In fact, advances in software languages and tools are exactly that, taking the predictable portions of writing software and simplifying them (read: automating them). This is why dev ops is so highly valued right now. We've got people coding processes to replace what system administrators typically were doing. If your software isn't entirely a creative process and you find yourself doing monotonous predictable things over and over, you're doing it wrong.

    Creative work, by nature, is really hard to predict. Businesses HATE that concept. Most businesses still operate in the Ford assembly line mindset. That there are certain predictable tasks that need to be done in order to create a product, and to produce more you simply add more power to any part of the line. The guys up top want to be able to stamp a launch date for a product, plan their marketing and sales campaigns around it, and don't want to hear any fuss from the "assembly line" of developers about missing the target. It's this way in the produce industry, sneaker industry, electronics manufacturing industry, etc etc so they expect the manufacturing of software to function like all the other products they're familiar with.

    The problem with this mindset is they're missing the key concept that in writing software, you aren't working the assembly line, you're *creating* that assembly line once, and only once. They seem to have no problem wrapping their heads around the end result and taking full advantage of it's power, but they have no real understanding of how you got to that end result. In fact, if you show me a company with a software development process with a consistently predictable timeline, I'll show you a company that wastes a boatload of money in their software development process. Remember, predictable data tasks can be automated, and that's entirely the point of what we're doing.

    So we're effectively jamming a bunch of wild guesses based on our experience with similar issues to come up with a timeline to deliver a product. The bigger the team, the wilder the guesses get. Sure, we get more information down the line on how the product is coming and a better idea of when the finish will be as the finish approaches, but it's very likely the rest of your company isn't set up to deal with that. They have expectations for you to deliver, and you've got a responsibility to deliver. This brings me to my next point.

    3) You're not as good as you think you are. I'm not either. In software development you can always count on Hofstadter's law:https://en.wikipedia.org/wiki/Hofstadter%27s_law

    Creative people are often ambitious and can see the big picture of what they need to create. This is a great ability that allows them to actually create the software product when all is said and done, but the problem comes in when they use that big picture thought to estimate their tasks.

    The big picture doesn't take into account that one detail/bug that took you 5 days to work through. The big picture doesn't take into account coworker distractions, shifting priorities based on what's finished, changing requirements as we gain knowledge about the product, new tools/libraries/techniques you need rampup time on, and so forth.

    So unless you're very experienced into taking Hofstadter's Law into account (which as the law mentions is an imperfect practice), you're likely going to come up with a time estimate that is way too small. I often recommend to novices to double or triple their initial instinct for an estimate. If you can paint the full picture though, you can see businesses are planning other more predictable processes and major financial decisions based on these estimates. So you end up with a very tight timeline.

    The common answer to this tight timeline is to simply jam more hours into each day. It's a really crappy answer though, because it's just a band-aid. Not only will your team burn out, but their estimates will subconsciously start assuming 12 or 16 hour days. Eventually you run out.

    The only other option to get more man hours is to hire, which brings me to

    4) For every software developer there are 10 jobs looking to hire him. Many businesses see the benefits of automation, and have started to actively incorporate it into their business models. Unfortunately, the talent pool isn't getting a whole lot bigger.

    So my company is lagging on deadlines it created for itself, needs to get more man hours, but simply is unable to fill the demand because there are 9 just like it jockeying for the same talent. Furthermore this causes offers made to these developers to inflate. And, while salaries are inflating, the budgets these companies have are not. This situation often leaves us with shorthanded teams everywhere.

    Since teams are shorthanded, they're left without much of a choice but to pressure the team to put in "grueling hours".

    All of this could be avoided by setting up the company to work within a creative space, or developers giving more accurate estimates from the door (read: significantly overbidding)

    Of course, knowing the market is heavily in your favor, you could always simply say no. Establishing boundaries is surprisingly easy when companies don't have much of an option. Whether or not you have the courage to do so and "take the risk" is another story.