> We are still working to track down an elusive bug which is holding up launch. This bug did not appear in our many weeks of testing and only emerged in the production environment. Unfortunately, it is not consistently reproducible and we cannot launch until this issue is resolved.
Sounds pretty realistic to me. During my 8+ years of programming, I had a lot of pain and sleepless nights trying to catch elusive bugs which can be reproduced only in production servers and only sometimes. Many times, my clueless managers got nervous and demanded estimated time from me. Unfortunately, it's impossible to give realistic estimations. It could take hours, days or weeks. Also, searching for such bugs doesn't scale well. It means if you have 5 devs looking for elusive bug, it doesn't mean they will find a bug 5 times faster.
In a factory, a manager might be smarter than the one doing manual labour. In tech, it's the other way around.
When you explain the issue to me, I’ll ask dumb questions about context I lack, so you’ll explain stuff you take for granted. And it’s answering those questions that will make you figure out where the problem is.
Amateur hour, and if this were a "real" exchange, they'd lose their licence and have lawsuits and government agents knocking down their door (real-money MTFs have strict uptime and infrastructure requirements for anyone who didn't know)
Sounds like their staff has being going without sleep for a few days now.
Given that sleep deprivation has effects similar to being blackout drunk, I'd consider that equally irresponsible[0].
Let's hope they finally fixed their engine and purchased more capacity.
Managers who don't know what a variable is, SQL or TCP or a while loop or whatever, in my experience it is just that: dumb questions.
Best managers I worked for had trust in their developers, and asked for estimates on planning (not bugs). The worst managers didn't trust us, and pushed their own planning on us because they thought it would make us work faster. They thought planning can be negotiated.
I can tell you which projects were within 7% of the deadline, with good quality. And which ones we were always putting out fires, and some never finished.
- put their work in context - remove dumb obstacles for them - ensure that they are working in ways that benefit the team - check they are having an ok time interacting with others and sharing knowledge - check they have not said yes to too many things - ensure they don’t get swayed by better offers - acknowledge their work
Etc etc ... management is not about enforcing deadlines and correcting problems (which you seldom have to do with truly independent people). There needs to be the right level of communication with each employee so you are not in their way but not hanging them out to dry, and this needs to be maintained even in times when there are no problems.
And of course you have things like deadlocks that have to be resolved, ie dba waiting on programmer, and programmer waiting on artist, and artist waiting on dba.
So the manager serves a distinct, and presumably necessary role. And by necessity, he must be invasive: if there was sufficient communication, the deadlock would resolve itself. But if the manager is necessary, there is not sufficient communication: that is, someone is not announcing important information by their own will (perhaps because they aren't aware its worth announcing). It has to be wrung out.
And if you're trying to stop such problems before they occur, then you'll end up asking seemingly redundant or even arbitrary questions. (Because you can't know the correct questions to ask!)