Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Search - "timescales"
After months and months of unrealistic deadlines, pulling late night shifts coupled with an insane commute and two very small children at home I had a total burnout. Turned up to work one morning, and stared at the Java code I had been writing for the past couple of days and it might as well have been written in Martian. The more I stared, and the more I tried to keep things together internally the less I was able to make sense of anything - just a random jumble of characters on screen that were as intelligible as the green scrolling lines from The Matrix.
My office manager saw that I was obviously in some distress and took me into a meeting room to have a quick chat - and there I was, a grown man of 35 bawling my eyes out like a two year old. Not the most edifying moment of my life.
However, the company couldn't have been more supportive afterwards; one of my colleagues drove the 100 miles to get me home in my car and took a train back up to the office; my GP signed me off work for six months and treated me for severe depression; the office instituted stricter working policies - not on the developers, but the sales/PM teams that were handing down ridiculous timescales simply so they could get a sale.
For my part, I've learnt to push back and say "NO!" - work is not your life, it's an important part of your life, but my no means everything. Don't feel beholden to a company to meet unrealistic targets that you haven't agreed to. Talk.3
For years I worried I was not a good programmer because of bugs, issues and not giving accurate timescales.
Then I discovered devRant and realised that there’s thousands of us that have the same issues.19
Went into a client meeting to present pricing, timescales etc. for custom web app. After a short period of chit chat they tell me they've gone way over budget. They explain to me that they'll need to close their business if they don't get this thing built (the business consists of him and the other guy at the meeting). They currently have a website that is an e-commerce type deal, apart from the checkout process doesn't work! They basically want me to do it for free.
I may consider if I was going to benefit from new clients etc. but I'm not.
However, the problem is that one of my companies has been (IT) supporting this guy's other company for around 5 years. It's a bit of a shitty situation as that contract accounts for about 15% of our income.
That meeting was last Monday and I told them I would think about it. I have another meeting this Friday and am thinking I'm going to have to break the news gently ffs.3
I thought it worth repeating the wisdom I spotted there:
"That's what the Test Track at Velim is for"....methinks that modern managers, project managers and beancounters need reminding of this.
My experience lately is that when folk of their ilk hear 'apply all the edge cases', what they hear is 'blahhhhh blahhhhh blahhhhhh un-necessary time and cost' and promptly chop those 'edge-ish' bits out of the test and/or approvals plan.
I'm lucky enough to have had a diverse and very enjoyable career testing things for a living, in an organisation where you were *expected* to try and break the thing you were working on (within sensible limits).... the rational being that if it went wrong in-service, it would be seriously inconvenient for users, if not downright Goddamn dangerous (Think national-scale 'phone infrastructure - no 112/911 service=big problems!).
We were well paid to have a negative attitude towards 'Product Whatwever' in those days - actually a realistic attitude from a Systems point of view - which was endorsed by the C-Suite as necessary for product quality. The attitude was that if Joe Public doesn't have an issue then we've done the job right.
Most of the time, we would end up fixing an issue, even the 'Very Low Probability, Medium Impact' ones on the (proven!) assumption that if Mr. Sod can stuff it up, he will.
With this modern 'continuous delivery' way of working, I find the 'edge' cases get ignored as a fix is seen as 'only a software update away' - no matter that the poor sap trying to use the thing has to wait weeks/months/forever for a fix.
Nobody wants to take the time and trouble to create a robust product any more, and it's hard to take pride in your work (About 50% of my output at the moment is crap, because 'timescales' and workload).
The world is increasingly run/managed by people who have absolutely no idea of the technicalities and complexity of modern systems.
Here endeth this rant.
Now that this drama shite is calming down, here's my tuppence on how connections management should be implemented.
We really need something that is in between blocking and doing nothing. This, in my opinion, is temporary silencing. Having the ability to mute a person or rant, or notifications altogether, for a set period of time would be very useful when a situation needs de-escalating. As this social network (let's not beat around the bush, this is a social network) grows in size, this will be a handy tool for calming storms without burning bridges permanently.
To sum up, I think it would be a good idea to have three available options for notification muting:
- mute notifications/this person/rant for 24 hours
- mute notifications/this person/rant for 7 days
- mute this person/rant forever
As for implementation, I'd wrap up the call to the user's notification assembly like so:
And use a date field in the DB to handle timescales.
Also, I suggest the addition of this tag specifically for suggestions, just so we're not all using different tags