I came into tech for the joy and the wonder. You don't measure joy. You enjoy joy.
I came into tech for the joy and the wonder. You don't measure joy. You enjoy joy.
Otherwise we're going to just keep burning more and more people out. And for what?
I don't see anyone in this thread asking for that
even productivity cannot be min-maxed, save for the short term, for the simple reason that we don't know what productivity is. technological revolutions are the prime example of this, where each turn of each revolution shifts the entire idea of what being productive is.
Another question, why does a work-place need to provide "ample space to play?" I have trouble knowing what this means. At a hack-a-thon, rather than building some throw-away project that was going to be a space to "play", I opted to see if I could decrease the test run time from its current 25 minutes. Obviously this was not a popular hack-a-thon project, but it was by far the most useful (all the others while cool, were never fully integrated).
I somewhat wonder if the "ample space to play" is reflective of an attitude where engineers need to be managed, and like children they need some recess time to burn off excess energy and to be made happy. Is that your take at all? What benefits does this "ample play" provide, and what does that look like? A very important element of job satisfaction is to not have your work thrown away. A "play" project seems exactly something like that. Given this, my impression of providing space to play means: (1) the developers are not taken seriously, are things to be managed, and are not partners in identifying user and business needs, nor are they drivers of identifying business process value [eg: hey, we could automate this, we could optimize that, what if we tweaked this thing a little bit and could then solve a few user-needs at once; vs just building what you are told exactly how you are told]. (2) the 'space to play' is going to be demotivating. "hey, the regular stuff is soul sucking, so here is some time to do something that is not soul-sucking, but it's 'play' and whatever you choose to work on is just a toy and like a toy we'll throw it away.
So, I'm really curious what this "play time" or "play space" looks like. If a developer chooses to work on something, either they are picking projects that do nothing, or they are picking projects that arguably should be already integral to the business development process (and hence should not be 'play' projects at all). Overall, it is work, and if you tell someone that has spent 3 days debugging J2EE configs or YAML configs that they should not expect 100% joy and wonder, or spending a week trying to fathom what the previous time rushed (time-boxes & project focused) developers jammed into the system, & you'll probably getter a rather curt 2 word response rhyming with 'no pit'. That is to say, it is work, I don't think the development profession expects for there to be "space to play", and if so, why are we bothering with wasting time like that? (which seems to be a good way to boost productivity, cut out this throw-away play-time. If developers want to play, as in boost productivity by developing their personal skills, that is for off-the-clock [find an OSS project]).
Sorry the rant-like nature. In sum, I do have these questions: (1) Why is work-life balance pertinent to productivity at work, as related to development process? Asked another way, how does a work-life balance interact with any "Agile" development process such that the efficacy of that agile process is changed by 'work-life' balance? (2) What is "ample space to play" - what does that look like? What artifacts come out of that? If useful things are being built, then why isn't that just part of the work? If useful things are not being built and are being thrown away, how does that help anything?
Perhaps if "providing value" is something you have to be conscious of and not something that comes about naturally from doing what energizes you then that's a signal to pursue a different line of work.
And this very site is built by that VC.
It's not that money and output are not important for a business, but obsessing with productivity may cause the opposite effect.
I'm still trying to figure out how to better regulate myself away from those extremes (how to put my work down for the sake of other aspects of my life when I'm excited on the one hand, and how to push through and 'reset' when I am frustrated by something outside my control on the other). But one of the things I've already learned is that focusing on productivity in terms of sheer discipline doesn't really work. I get a lot farther working with self-reflection on my emotions and carving out space for joy and freedom in the formal structure of my work week than with sheer mental effort.
On the other hand, most days I'm just too mentally exhausted to work on programming when I get home. So I rarely get to scratch that itch on my own time.
To get around that, every now and then I take some time while working on some issue to do something new, like play around with programming language constructs and exploring the limits of the language.
It's not always easy to do though, with deadlines and whatnot. So can be a real struggle at times.
Any trillion dollar capital outlay will invariably measure performance, irrespective of the motivations of sector's people.
Yes. And that is a Bad Thing. That kills joy and wonder.