The crazy thing about this is that it can be purely mental. My most productive coding session this year happened when I had to quarantine and I knew my employer wouldn't mind if I just did nothing. There was no pressure, but I still wanted to move on a little bit with the project. Just a few hours a day. I mai ly did this because I like the project and I would get into a lot stress later if it was not done. I got mor…
"In positive psychology, a flow state , also known colloquially as being in the zone, is the mental state in which a person performing some activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity." You entered this state.
Thats why I think the approach ti estimates and project planning should be: developers are trusted
not to slack off and not to over engineering it. So it takes as long as it takes. But if it might go up an order of magnitude talk to the team to see if it is still worth doing or how to reduce scope.
Instead of the usual estimate, negotiate the dev down, use a mythical man-month then bollock them for not getting it done on time (ok these days microaggressions are in fashion as you can’t outright yell)
I watched my manager fall into the "I'm so busy" trap over a few decades. At first he planned things carefully, allowed extra time, adjusted schedules based on feedback. Then his friends started filling him full of business management ideas that I think they got from magazines. Things like "just ask for more, you'll be surprised that your employees will deliver" and "don't give raises above inflation" and "start the next project immediately after the previous one" instead of giving employees some time to relax. Part of this advice he pickup up from medical professionals, who have always had insane work schedules (80 hours shifts as a resident, really? Why doesn't medicine listen to its own advice?) There are lots of older medical professionals who edit a journal, give speeches, consult with companies, are writing a book, are running a blog, doing research, and are still seeing patients in their practice! They have trained themselves to get sleep in 20 minute increments, to push through when they feel sick, and to always take on any opportunity that presents itself no matter how busy they are. And because they demand this of themselves they also demand it from everyone who works for them. It is completely destructive, after a few years of this my manager could no longer remember anything beyond the last week, was setting ridiculous deadlines ("we can do the experiments and write a journal paper in two weeks, but it has to be world class"), and basically missing all his deadlines because they were stupidly unreasonable. His professional career took off though, which added even more tasks to his work, which gave his employees a respite because he had to reduce the number of meetings with them. So it looks to me like there are some meme's that came out of the management/medical worlds that profess to get the most out of employees and they have been widely adopted, but they do not work and just grind up people. If you can ride it out you become a big important person, but you also become dead inside and can't hear anything anyone says any more.
As a tech lead, when you're asked to deliver more, the first impulse tends to be asking your team "how can we do more work?"
The correct question should be "What can we NOT do?" - and usually there's a long list of things that don't generate business value - from processes, meetings, reporting and overly detailed planning sessions to technical hurdles including slow builds, pre-check in hooks, sign off requirements etc.
I know that most feel that they absolutely HAVE to do these things, since there are part of the business process/ definition of done/company guidelines etc... but here's the thing: If your team delivers value, people stop asking questions. It might take some forceful pushback and even some fights initially, but even if your team is absent from meetings or doesn't jump through every hoop, as long as you churn out value, you make yourself, your superiors and the business as a whole look good and in turn will be cut some slack.
I don't think this is removed from reality. I think people who are in perma-crunch believing that just over the next hump they'll find level ground are the ones who are removed from reality.
This is spoken like someone that has yet to really face any real and lengthy incredibly stressful life events. I really wish I could be this privileged and out of touch to make a statement like this.
If you want to remain functional during lengthy and stressful life events, it is critical to understand your capacity, prioritize the tasks ahead, seek skilled collaborators/contractors, and forgive yourself for the things you simply cannot do.
When a life-crisis turns into an extended campaign, it is essential to know how to prevent yourself from burning out. Burning beyond that level must be reserved for true emergencies, where the goal is to bring things back into a new balance.
If you're operating beyond your capacity for too long, the endeavor will begin to stumble. That's what the article was trying to help the reader avoid.
Often very useful things are never the "next most important" if you don't scope "importance" very carefully. "Slow down to speed up" can capture it, setting aside times for those non-critical maintenance steps that prevent problems or make everything just a little bit faster can make worlds of difference in your work, but never seem to be able to compete with the "next most important" thing on the list.
That reminds me of the military saying "slow is smooth, smooth is fast".
I like that analogy a lot! I've just realised that the same thing applies to racing, for example. The way I tend to play racing simulators is that I try to go full throttle all the time, and then when I stumble upon sharp turns, I just crash into them, losing much more time than I would if I didn't try to go as fast as I can all the time.
As a tech lead, when you're asked to deliver more, the first impulse tends to be asking your team "how can we do more work?" The correct question should be "What can we NOT do?" - and usually there's a long list of things that don't generate business value - from processes, meetings, reporting and overly detailed planning sessions to technical hurdles including slow builds, pre-check in hooks, sign off requirements e…
To piggyback there -- people stop asking questions when counterparties meet or exceed expectations. It is essential that expectations are set reasonably, otherwise one or both parties are in for a world of hurt.
I feel both sides of this one. Yes, creating automated processes would make things easier, but the time it would take to automate the process would take too much time before you have to deliver. So everyone knows what needs to be done, everyone recognizes that it would help things, but no one can put down what they're juggling to handle it. Sometimes it takes bringing on a person just to take on that project as its o…
Regarding a dedicated person to handle the CI, here is my experience. In the small company I am working now, I had setup a adhoc deployment script that was working fine, took less than 5min (with no user interaction) on my dev PC. Since it is not a SaaS, our release cycle was a bit slower than wanted, 1 or 2 times per month, depending on circumstances. A guy was hired and he wanted to speed this up. I explained clear…
Then I don't understand what your issue is.
> We had a few "releases" which needed very urgent hot-fixes because of last-minute changes and not enough testing on hardware.
That sounds like the problem is that the CI is not testing on hardware, or that you're running ad-hoc manual tests on hardware that could be automated or at least formalized.
I've worked in offices where everyone is super busy but seemingly little to no progress is made. It's really maddening. One time I put together a strategy where the recommendation: "watch and wait". The idea was - there wasn't any work to do, what we had was "good enough" and flexible to be a good option no matter if the market shifts, and our job was to watch the market over the next quarter, observe, and collect in…
Reminds me of the Blaise Pascal quote:
> “All of humanity's problems stem from man's inability to sit quietly in a room alone.”
Doing nothing is uncomfortable, because you might accidentally discover a truth about yourself that you've been busy avoiding.
> then you should actually (yes you should, I'll die on this sword) Die on this hill :) You'll certainly die on a sword, but you won't have defended anything in doing so.