Living or working with less-than-ideal conditions
EditHint: Please could someone take the time to read this page, understand what's being said, and turn it into a decent document? I'm sure there's much here that's worthy of a proper DocumentMode page.
(Note for the grammatically confused: In this context, "Play Hurt" might be more accurately termed "Play While Hurt", referring to the idea that sometimes professional sports players will continue to play the game even when they are in physical pain. Not to be confused with PlayDead?
, a programmer talked about how he sees his productivity multiplied by 10 when he feels inspired versus when he feels bored.
This was one person's reply:
- You have to PlayHurt. Part of being a professional is having the discipline to produce even when we don't want to. Anything else is basically stealing.
Is this true? Are we capable of turning productivity on like a switch, regardless of the moment's creativity quotient?
Or is the opposite true? Is productivity is a more mystical force, one that depends on unforceable factors, such as motivation?
Maybe it's different for each person, or maybe it truly is an issue of professionality. All comments are welcome.
The book FlowThePsychologyOfOptimalExperience
describes how to "switch on" the productivity by changing boring tasks into interesting ones.
No, the real issue is that someone quite simply cannot comprehend programmers or programming in general. You have ignorant incompetent idiots hovering over you, and the only way they can see to ameliorate their paranoia that you're "not really giving 110%" is to go down the checklist: 1) in cubicle, 2) typing furiously, 3) eyes locked on the monitor, 4) action items being ticked off of the working schedule at hypnotic regularity, 5) putting in full 8 hours every day, 6) cheerful disposition when speaking with management, etc etc etc
Invoking the word "stealing", especially in the context "StealingFromTheCompany", is a good way to obtain ProductivityThroughGuilt?.
Answer: Get a new boss.
professionals in some
contexts need to PlayHurt
. In most contexts, though, the professional thing to do is to stop and fix the hurt, rather than playing on in a diminished capacity. Building software is not like playing football.
Here is a situation based on a recent reality: What if a programmer, we'll call him Bob, gets a job with some company Foobaz. Let's say that Bob is a very good programmer. He's fast, accurate, and able to understand just about any kind of business problem thrown at him. Let's further assume that Bob, who really likes to be productive and hates to waste his time or that of his employers, always strives to produce the optimum solution for any given problem. Now, Bob is paid by the hour, and his rate is 100USD (because I just know
that someone will bring up currency). One last thing: Bob is a very ethical person, and feels that if he has a slump
he should go burn it off somewhere other than work - like playing pool or reading a good book.
Now, within this framework, let's give Bob a task: Produce an inventory management system for Foobaz. Since Bob is a really productive programmer, he reviews the requirements and producing a gameplan for his management. He tells them that, through his research, he has found that these kinds of systems usually around around 20KSLOC, and he feels very confidant that he can build this himself. He does. It works with very few flaws. It goes into production.
However, the company - Foobaz - isn't happy. Why? It turns out that Bob, who is extremely fast and accurate - a professional programmer - didn't work 40 hours every week. In fact
, on some days, he worked less than two hours. But he still managed to get the inventory management system built in record time and under budget. Foobaz's management explained to Bob that they felt it wasn't very professional
that he leave early on some days, or that he - overall - worked less than 40 hours every week. Bob wondered why this was so. Hadn't he built the application exactly as they had said? Yes, indeed he had. Hadn't he built it on time and under budget? Yes, indeed he had. Hadn't he trained the support staff and help roll out the new system into production? Yes, he did this very well indeed. So, Bob asks them, why are you upset?
Their response: Because we control you Bob. You're our asset. When you're not here, we can't see you and therefor do not know what you're doing. Why, you could be -
gasp - doing work for a competitor at the same time as working for us! In fact, how do we know you're working on
all the time''?!
This is derived from a true story, and I dare say that the definition of professional
varies considerably from company to company. However, in the end, I feel this boils down - in most circumstances - to control. If your employer
you, you're doing great
work. If not, well - you're a slacker. Even if, in all honesty and integrity, you were trying to avoid charging them because you were: sick, tired, braindead, comatose, or otherwise impaired - or even done; albeit, ahead of schedule. -- JeffPanici
I don't think it's possible to PlayHurt
in software development. Rather, I think the professional thing to do would be to identify and fix the cause of the problem. If that's not possible, at least fix the symptoms. Didn't get enough sleep? Maybe pairing with someone else will keep you focused... and tonight, go to bed on time. -- JimLittle
isn't about producing when you're bored. Sports players are not better
when they PlayHurt
, they are just dedicated. IMHO, the software equivalent of PlayHurt
is to produce reasonable code when you are hindered by a CubeFarm
(especially a low-walled one), SeagullManagement
, and other escapees from ProgrammerHell
. -- PeteHardie
Development can not be individualized art. When I have someone paint my house I expect them to paint my house. I don't particularly care how they feel. As an employer, I expect you to address your ennui on your own time. Software is like playing football in that you are expected to show up and do your work. If you are seriously hurt then you have an out. Being bored is not.
If you want someone to design your house, you might care a little more about whether they have their heart in it, or are just "phoning it in". Software development is not an assembly-line-like process. Like it or not, creativity/imagination is a part of it, and sometimes people can't just turn it on like a switch.
The picture I'm forming of developers is not good. They don't have to produce when they don't feel like it. And software is difficult so they don't have to have a high level of skills and expect a methodology to fix their deficiencies.
I think you are drastically overstating things. I don't think anyone claims that they should be paid for doing nothing, or that they cannot get anything done without following methodologies. Rather, everyone recognizes that there are circumstances that are more conducive to good work than others, and we should seek to make those circumstances come about more often.
Cloned from GrandMasterProgrammer in reply to the comments at the top...
Invoking the accusation of stealing is rather provocative and inappropriate. For one, it presumes a sizable amount of value judgment, context, culture, etc. Nowhere does Luke say that he is working for someone else, so from whom is he supposedly stealing?
For another, it seems to equate software development with unskilled labor. If you are washing cars, then maybe eight hours of car washing can be treated as such regardless of who is doing it or when. If I come to work and don't feel like washing cars, then my standing around can perhaps be considered stealing.
But software development is far more like oil painting - progress is based significantly on the artist's mood and other intangibles. At least, it is more like that than many people are willing to admit. When it is all said and done, it is impossible for anyone to measure our productivity over time or between people in a manner that makes such accusations appropriate (unless one is obviously and simply not trying to be productive at all, e.g. asleep).
Actually, I do work for someone else, but I think I was misunderstood. What I meant is that when I'm doing really cool stuff, I hack on it all night and have a great time, and this is when I get the most done and do my best work. But other times I'm working on something that involves sitting in a lot of meetings, or coordinating with people in other time zones, or wrestling with Windows, etc, and at those times I can't keep that sort of momentum. In the extreme cases of each, which can last for a while, there would easily be a factor of 10 difference in how much I get done. If the same is true for a lot of other people, then it could help explain the big numbers from "grand master programmer" studies. -- LukeGorrie
Ditto. I totally agree, Luke. Stuff that gets me pumped up is stuff that I know will improve my/team's productivity going forward - like, refactoring, and better frameworks. Like, organizing and recording requirements, and test suites around them, for posterity. And stuff that I know will help me avoid stress in the future - like, making the investment now to avoid future performance and scalability crises. And stuff that I think will dramatically improve the value of the product to the market - like, more powerful, flexible models of the problem domain, and much more intelligently-designed user interfaces, and setting up consistent ways to do application integration. Stuff that bums me is when I see no commitment to doing things well; no commitment to process improvement; no appreciation of RealValue. Arrogance, ignorance, and greed are at the root of a lot of evil. -- RandyStafford
I would separate developing for fun and developing as a profession. For a professional your attitude indicates what is wrong with our industry. We are not engaging in art. Your mood is under your control. It takes discipline though. Part of being a grown up, part of being a professional, is to do stuff, to produce when we don't feel like. Only of divas, children, and artists do we expect a surrendering to whim. It is very possible to make measure productivity over time. Who gets done on time while meeting metrics like quality. We all know who does and doesn't. It's perfectly measurable. There are skills to learn and master. I would say grow up and take all this more seriously. This isn't a hobby or an art. There are jobs, peoples futures, stockholders, industries, etc all depending on what developers produce or don't produce.
- But what if it isn't whim? A manager sees a lack of progress. He cannot explain it. He concludes, "the programmer must not want to make progress." He will always be able to believe that, and never have to confront the real nature of the difficulty.
Whether software development is art and/or science is not dependent on attitude or consequences. The issue depends on the nature of human beings and the characteristics of their development activity. Software development is inherently unpredictable, unmeasurable, and unforceable because it is, not because we want it to be. The fact that our society stakes so much on software development, and then suffers when it fails, does not change the nature of the activity. It does make the issue worthy of discussion, though.
If it is perfectly measurable, then show us some perfect measures.
About the only "perfect" measure I know of is that about 95% of all software projects fail (do not deliver planned functionality on time and within budget).
For another, it seems to equate software development with unskilled labor.
It is a very skilled labor. Which means there are skills and techniques to follow whose output can be measured.
Right. And which, exactly, of the N worthless metrics are you a fan of?
It must be great to have a job where you get paid a lot and don't have a way to tell if you've actually done your job or how well you did it. You might try... How many bugs does your code have? How well does your code meet the requirements? (related to bugs) Did you meet your schedule? These are worthless? Some people historically miss their schedules, have bugs, don't implement requirements. These people are not good at their job. Why? An intervention is necessary. Maybe they just suck? Maybe they can improve.
These aren't metrics, they're contractual obligations. We're asking what measures can you put on someone's creativity?
Isn't a manager supposed to help make things happen properly? What is your metric for the amount of improvement you get for a particular management style?
If you want someone to design your house, you might care a little more about whether they have their heart in it, or are just "phoning it in".
Wrong. I expect them never to phone it in no matter how they "feel."
My point is that if a worker is doing work when they are in an especially creative and inspired state, you'll get a better result than if the worker is simply being "professional". And so you'd probably want to get them into that sort of state as often as possible.
But how should the worker behave when s/he is not
in that state? I think that is the subject of this page. -- BrentNewhall
The fact that your architect is a professional means they never have to phone it in and never have to justify fluctuations in productivity. If they don't work Tuesday and work half an hour on Wednesday, you don't care - as long as you get the design by Friday. The story above reflects that companies often place bigger restrictions on their programmers than they would other professionals that they deal with. Only a peer is qualified to judge the performance of a professional beyond the metrics of "Is the job done on time?" and "Is the job done right?". Forcing people into incompatible work ethics is not the road to productivity. -- DanielSheppard
This is derived from a true story, and I dare say that the definition of professional varies considerably from company to company. However, in the end, I feel this boils down - in most circumstances - to control. If your employer can see you, you're doing great work. If not, well - you're a slacker. Even if, in all honesty and integrity, you were trying to avoid charging them because you were: sick, tired, braindead, comatose, or otherwise impaired - or even done; albeit, ahead of schedule. -- JeffPanici
Yes companies suck. If you don't like your company then try and change it, or move, or suffer. The action of others does not change your responsibilities. This is called integrity, morality, professionalism. In the end you can't blame others because in the end it's up to you. You know what you have done and why. If other's don't recognize that or can't be made to see it, then so what?
Obviously. However, my point in telling the story - in the context of PlayHurt - is that indeed it is the
suffering that most people feel is worthy of compensation and not the end result. This is crazy and pointless. How is it ethical or professional to
know you have nothing productive to do and sit in a chair and surf the web - all the while getting paid?
The bottom line, I guess, is that - at least in our culture - people
seem to respect those who limp to work and who may not be the most productive. Many years ago I worked with a person who would get into the office and immediately
empty all of the contents of their desk drawers onto their desk in an attempt to look busy. This person would then go smoke all day long outside and return spuriously to their desk to make phone calls and talk with people. DeliveryIsNotTheGoal seems to be a very pervasive social pattern. -- jp
The arguments on this page are typical of TheoryXx
types who think that there is no creativity involved in the programming of software. Over on ProgrammingOutsideTheCube
a comparison is made between artists, scientists, and programmers. The conclusion is that programmers are part scientist and part artist. This is about as close to the truth as you can get. The GrandMasterProgrammer
uses the logic of their scientific mind to govern the creativity of their artistic mind. No matter how you slice it though, you can't get away from the fact that creativity is required for programming, as it is a creative discipline.
Creativity cannot be summoned or invoked, it must be nurtured. GrandMasterProgrammer
s are indeed exactly
like artists. The fact that instead of smearing pigments on a canvas, they manipulate electrons on silicon does not change the fact that creativity cannot be rushed. True Grand Masters realize and plan for this. The unenlightened ignore it to their detriment.
Artists have to be professional, too. Very few successful writers of fiction wait for their Muse to inspire them. They write no matter how they feel. -- BrentNewhall
[How many professional authors do you know? The ones I know do exactly the opposite. However, they know that they rely on the "muse" and engineer their environment to support it as much as possible. How many publishing houses have teams of writers on staff who are required to be there 9-5 and work in cubicles? Even in more professional careers, obviously creative work gets slack. Look at the working conditions for your typical ad agency vrs. your typical corporate programming cube farm.]
However, very little of what those writers produce is sold. They winnow through the piles of chaff for the one good novel.
All of which is to say, that PlayHurt
does not apply to programmers doing creative work for the simple reason that creativity cannot be quantified or measured.
'''So, if you are at work and do not write a line of code for a year or all you code is completely buggy that
is OK because programming is creative/art? You would expect everyone around you to applaud your creativity
and support you in your self-exploration? If it's not OK, then you do indeed need to PlayHurt
That seems rather extreme. If you had a programmer working for you who hasn't produced
- One expects a GrandMasterProgrammer to write code, that is a given. Furthermore, one expects that a GrandMasterProgrammer's code is superior to that of a lesser programmer. As such, it would not be buggy. The point is that sometimes the GrandMasterProgrammer staring out the window for an hour accomplishes more towards the successful completion of a software project than an entire legion of CookbookCoder?s ever could. This is the power of creativity.
- This is not to say that not "finding your muse" is an acceptable reason for missing deadlines. Part of being a Grand Master is keeping your promises. Many times Grand Masters find themselves in situations where "failure is not an option". In these situations you might say that they must PlayHurt, meaning that even if they have a little cold or a headache, or have been on DawnPatrol? every night for a week, they must complete their task.
anything in that length of time, then you need to find another programmer. On the other hand, if you expect 8 hours a day, 40 hours a week of 100 percent productivity, prepare to be very disappointed. If you're concerned about 40 hours worth of work a week, why do you care when during the week it is done? I don't think your customers care particularly much where your programmers are sitting, provided they get the product they're looking for.
Many technology companies are going through layoffs at the moment.
After a layoff, the remaining staff are left feeling like walking wounded.
Everyone comes to work. Everyone sits at their desk. But how much work gets done?
How much work should one expect to get done in this context?
How long must this state persist before you wonder about leaving the job and finding a new one?
: "Layoffs will continue until morale improves."
Parts of this page seem to have been invaded by AssholesFromManagement. Because only AssholesFromManagement would equate productivity and professionalism with sitting in a cubicle, staring at a CRT for 8 solid hours a day.
Learn your profession. This is not a Taco Bell assembly line.
It makes sense to PlayHurt
in sports because each game has a limited duration. If you are going to win this game then it is important to play now. Of course, you have to trade off the cost of winning this game against the possible cost of permanent injury. People are much more likely to PlayHurt
in a championship game than in a practice game. In fact, it is foolish to PlayHurt
when it is just as important to play well tomorrow as to play well today.
In the same way, when programmers approach a deadline, they are much more likely to put in overtime, to work when they don't feel like they are doing a good job, and to cut other corners. Otherwise, it doesn't make sense. See SprintToTheDeadline
. -- RalphJohnson
Great insight. I can't help thinking this subject has parallels (or at least some relevance) to the advertising industry. Advertising creatives are nurtured, cared for, even spoiled by their employers. Whatever it takes to get the best out of them.
Used to be work was controlled by skilled artisans. Then industry put control in the hands of the people who owned the machines. They took the money and power they got from this control as if it were their natural right. Interchangeable parts, replaceable workers. They've gotten used to the ability to tell disgruntled employees "You don't like your working conditions? Tough shit. I own the plant."
Now a cube farm of unoccupied, rapidly depreciating PCs is just junk for the liquidator. If your company makes software, the machinery that makes it is in your employees heads. The real situation has changed. No amount of lawmaking, money, or tantrums is going to make things all nice and industrial again. You don't like my working habits? Tough shit. I own the plant.
You may own the plant, but the company signs the paychecks.
Fair enough, but there are plenty of other companies out there who are perfectly capable of signing paycheques!
Actually, as of mid-2003, there aren't. Employers know this and are screwing their programmers on conditions and rates because they know they can.
I don't want my surgeon, my airline pilot, or my psychologist to PlayHurt
either. Playing hurt for people who have to think and remain aware ranges from useless to dangerous.
Then you probably only want them to play when they are capable of their peak performance. So maybe maybe your surgeon could do one or two operations a year because they aren't at their triple peak. Of course not. People must be able to perform when they don't feel like. This is a professional. This is what it is to be an adult.
PlayHurt doesn't mean you are not at your peak - it means you are working with some significant impairment - which has a significant chance of dropping performance below an acceptable line. And I'd prefer people doing jobs that are life-threatening not PlayHurt. I am less worried when my garbageman decides to PlayHurt, because the downside is just a messy lawn.
I started this page and that's not what I meant by PlayHurt
Perhaps a different metaphor would server better, then - at least, it would remove the confusion between lowered performance from injury/impairment and lowered performance from boredom/spring fever/etc. PlayHurt seems strongly sports-linked.
You included in the definition "significant impairment" which pretty much presupposes, because it is significant, that it is impossible to perform. Of course every one judges significance differently and everyone feels pain of all sorts differently. If you PlayHurt
you perform if it is at all possible. Feeling bad or not being up to peak performance standards isn't a good enough excuse.
I'm just seeing a large gap between PlayHurt and PlayWhenBored?.
Hurt implies (to me, at least) that there is a big distraction, like continuing to code while suffering from carpal tunnel syndrome. Continuing to code when you are bored with the job (but otherwise not injured) just doesn't seem to be the same level of task.
This whole thing about "boredom" has too many negative connotations. To me it's more like PlayingThroughaSlump?
. Even superstar professional athletes go through slumps. Baseball players can't see the pitches and their batting averages go down. Hockey players miss the net. There's a lid on the basket for basketball players. But they play though it, and eventually they get hot again, and that's when we know they're superstars. What causes slumps? As I said above, there are certain things that give me maximum inspiration, and others that remind me that we're merely "polishing intellectual turds" as Katie so aptly puts it, or busting our asses to fatten the trust fund of some investor's heirs. -- RandyStafford
I'd say that boredom (or rather the lack of inspiration) counts as hurt for someone who is a knowledge worker.
Lets put it this way; I can program completely fine with a broken leg. Two days after having it put back together I could have gone to work if I could have found someone to drive me there. I wasn't anything like a handicap to the team (bar the inability to carry coffee while on crutches). Not getting enough sleep of a night or having something more immediate to fret about than the project does stop me doing productive things the next day.
Turning up unable, for some reason, to form clear concepts from the woolly crap that people think constitutes "specifications" will always be rather more of a handicap to knowledge workers than, say, inability to walk. Polishing intellectual turds, which is what our industry basically boils down to, requires that one be able to think.
People aren't allowed to drive when they can't concentrate for some reason and the obligation is upon the individual to ensure that they are in a fit state to do so. Doctors whose mental state renders them unable to work properly risk be charged with negligence. Car workers who turn up too hung over to hold their tools are going to get sent home. Lorry drivers are made to have breaks so they don't lose concentration on what they're doing.
Only in the knowledge industry is it permissible to turn up, still drunk from last night or with too much else on one's mind to concentrate and basically piss the day away at one's desk breaking code because you can't think properly knowing full well that one's input to the project is negative.
Being able to type is a minor thing for a software engineer (carpal tunnel syndrome??? What in the hell are you writing that much code for?)
The essential criteria for a software engineer is that they be able to think clearly and concentrate. I mean it depends how important quality is at the end of the day. If you're OK having a software engineer turn up in a state not fit to write perfect code, that's fine. It's just then that you shouldn't be surprised if the code turns out imperfect. That's companies all over though. If they applied the same panache they use for hiring IT staff to their production lines, they'd happily hire blind people to paint cars if they were cheaper and then be surprised if they missed bits.
If your car painter tries to turn up one day with eye infections, is it worthwhile having him paint cars when he can't see properly? How many unsalable part-painted cars makes a properly painted one?
How many badly written lines of code (that need fixing way down the waterfall) that you make your developers turn up and do when they're not capable of concentrating properly are worth a well written one?
I think that being able to PlayHurt
is most important in a release or other major deadline situation. If the team needs something tomorrow, you need to make yourself do it today even if it's near-impossible to concentrate.
When you're not under major deadline pressure, trying to PlayHurt
may just mean that you'll be hurt all week. If I really can't focus on code because I'm not feeling well or I've got significant outside-of-work stress, I take the time to catch up on some less intensive work-related stuff. It's a good time to do some paperwork or technical reading, clean up the computer's hard drive, or go through code and make sure that the Javadoc comments are complete. There's usually something that needs to get done that doesn't require peak brainpower.
Always being under deadline pressure is one of the things that "hurts". In BeyondSoftwareArchitecture, LukeHohmann describes the need for PostReleaseEntropyReduction. -- RandyStafford
Is it possible that few of us have ever done anything but programming for a company while playing hurt? Companies seem to put most programmers into unproductive situations most of the time. Without properly supporting a technical developer, then developers PlayHurt
and probably fail (the 95% of software projects fail rule again). For example if the marketing is not in place and we don't have and never will have any real customers then we are playing hurt no matter how good a job we do on the code.
I have a plea- I won't list every detail, but the short story is that a deadline is coming up, the code just reached the out of control point last week, and despite trying to get enough sleep, I'm still feeling really tired. I'm (temporarily) in ProgrammerHell
and would be grateful to anyone who can place some kind words on PlayHurtSupport
. Some day it may even help you...
BTW I nominate this as one of the ReallyValuablePages. Thanks to whoever started it and to all that have contributed to it.
I think the PlayHurt
type of programming would actually hurt the project. It's probably not a coincidence that the managers who demand "I don't particularly care how they feel. As an employer I expect you to address your ennui on your own time." usually can only lead lame dead-beaten projects. If they are given a good project, they will tend to turn that also into a lame one.
Good managers can keep people enthusiastic and involved. Lame managers can't, and must therefore resort to making demands and accusations.
"Push the stone"
There's some astonishing caricatures of both managers and programmers on this page. Those pushing the fluctuating productivity line portray bosses as slavemasters expecting assembly line productivity; those arguing for playing hurt use words like "stealing" to describe the effect on the employer.
Every programmer (and good manager) knows that productivity fluctuates. The point the PlayHurt
people are trying to make is that a professional's attitude towards less-than-peak productivity is to fight against, not to indulge the ebb. A programmer who stares out the window because he knows that a bit of noodling will help restore him is a good programmer; a programmer who stares out the window because he just doesn't feel like coding, for whatever reason, is a bad programmer.
My own method for playing hurt is to keep a certain number of small jobs around me (in my job, not too difficult). If I'm having trouble pushing forward on a large project, I switch to striking things off my 5 minute list, the things I can do easily while 'hurt' (bored, distracted, bothered by something). That way, I'm not injuring the big project with reluctant code, I'm taking care of stuff that would otherwise distract me, and I'm building the habit of always doing something useful, which is a virtuous circle.
The habit of continual productivity is the mark of a professional. It's not about gritting your teeth or lashing your own back. It's about knowing how to keep your (real) productivity up over the long run with tricks or dodges or just discipline.
I can write code when I'm bored, uninspired, unmotivated. Or when I'm dealing with people that create a "challenging" work environment. It's not going to be what I call good code. It will be bigger (more lines of code per functionality), uninspired, and inelegant. It will be representative of my mental (or psychological) state. And it won't be internally fulfilling to me, I won't be proud of it. But I can do it, and I think part of being a mature professional is being able to shuffle those bits around even when it's not motivating work, or I am in miserable working conditions.
When I'm working that way, am I 'productive'? Yes, for some indeterminate value of 'productive'. But I'm not working very effectively/efficiently. For me to "be the best I can be", I need to be motivated, enthusiastic, interested, and have the freedom to work to the best of my ability. In this mode, I will often appear to be working less efficiently. And, in the short term, I am. But in the longterm, I am working very efficiently indeed, because I'm not accumulating cruft, hacks, kludges and other detritus that will impair my future progress.
However, I make a distinction between these states and playing hurt. My definition of programming while hurt is trying to write code when I am excessively tired, stressed, burned out, or otherwise in a condition where I am likely to put in "too many" bugs (where, of course "too many" is a definition that is different for everyone and every situation). In other words, I'm not being productive, I'm writing buggy code. This is what I call programming while hurt. And I can be in this state regardless of the working conditions or my motivation level.
All that being said, and despite my definition, it definitely feels like I'm playing hurt when I am unmotivated and uninspired or working in an unpleasant, challenging environment that makes it difficult to be effective. And, being in that unmotivated, uninspired state lends itself to not caring about quality, which leads to buggier code. So in practice it's not as simple as my clear-cut descriptions about would imply.
And, being in that unmotivated, uninspired state lends itself to not caring about quality, which leads to buggier code. So in practice it's not as simple as my clear-cut descriptions about would imply.
In practice it is clear cut, which isn't to say it is easy. You act like you are not conscious being in charge of your brain. If you stop caring about quality then it is your choice. The implication is that you are not a professional if you don't have the discipline to overcome your moods.
I don't PlayHurt
. When I'm not in a 'productive' mood, because I'm bored, distracted, tired, irritated, or for any other reason, I do other things. If I can't concentrate on code, I'll go and chat to someone. There's usually someone doing something somewhere in the company that will get a productivity boost from bouncing ideas off me, or discussing a shared issue, or even working out their frustrations with a good whinge so that they can then go back to being productive. If I'm productive mood, I stick my head down and produce; other times I do all the other things that add value to the company but that don't really feel like real work.
Being "hurt" is not a free pass! You have to get yourself unhurt!
Yes, exactly - for example techniques and concepts for encouraging MentalStateCalledFlow
- this is the responsibility of the programmer who should be supported by management in achieving it! If, given the right support the programmer cannot achieve MentalStateCalledFlow
and be productive on a regular basis they should consider a career change. But if they are not supported by management in this they should just look for a new job. if they PlayHurt
they are just being cynically professional and ultimately contributing nothing to humanity in general.