219 karma · joined May 25, 2012
hnchat:5qq3iyf9THYLESV6bHsR
1. If you're severely burned out take some time off, as much as you can. A few weeks would be nice but a month or more would be even better. I've found that after spending the first few days (or even the first entire week) being a sloth on the couch I'll begin desiring to program again. Working on personal projects or just learning something new without worrying about work often helps me out of these valleys you're describing.
2. If you're moderately burnt out you may want to consider joining a smaller company or startup. The need for code is much greater and the agency you get at a smaller company is incredible. No need to ask for permission, they want you to code.
3. Finally if you're not quite burned out or if switching to a new company is not an option I'd honestly recommend reading some books like Peopleware, Mythical Man Month, Coders at Work and others. This will give you some respite as what you're experiencing is not uncommon. Learning how others have experienced what you're experiencing and how they push back or fight against cruft like this will embolden you to hopefully make change within and push back intelligently.
I hope you feel better and that the joy of coding comes back. And if it doesn't I hope you ultimately find happiness, wherever that may be.
Others have already mentioned this but I think it's important to reiterate sleep quality. I learned I was not getting enough oxygen at night due to congestion when I went to the doctor for problems with tiredness and brain fog. Taking nasacort each night before bed completely changed my life.
Status Meetings Are About Status
A real working meeting is called when there is a real reason for all the people invited to think through some matter together. The purpose of the meeting is to reach consensus. Such a meeting is, almost by definition, an ad hoc affair. Ad hoc implies that the meeting is unlikely to be regularly scheduled. Any regular get-together is therefore somewhat suspect as likely to have a ceremonial purpose rather than a focused goal of consensus. The weekly status meeting is an obvious example. Though its goal may seem to be status reporting, its real intent is status confirming. And it’s not the status of the work, but the status of the boss.
When bosses are particularly needy, the burden of ceremonial status meetings can grow almost without bound. We know of one organization, for example, that runs daily two-hour status meetings. When participants are off-site during a meeting, they are expected to call in and participate by speakerphone for the whole duration. Nonattendance is regarded as a threat and is subject to serious penalties.
Outside of that I agree. It's unclear what data TikTok is supposedly gathering that other apps aren't already and why that's a cause for alarm.
xhyve is wonderful but still needs some work and it seems like the main dev isn't interested in continuing work on it at this point[1]. Hopefully Docker's usage will spur more work on xhyve.
[1] Last commit on xhyve is December 28th, 2015 https://github.com/mist64/xhyve/commits/master
It seems if you lose any 32 bytes though you've lost the trail of encryption as you can't decrypt any subsequent pieces.
After reading other comments I think the only reliable solution is chacha20 where each packet can be encrypted/decrypted independently of others.
Let's say you're using a 20/40 erasure encoding. You break a piece of data up into 20 pieces and create 20 extra parity pieces. Now you only need 20 out of the 40 to recreate the original data.
Are we encoding the encrypted data? Ok well we need at least 20 good pieces, and that's to decode the original data. This method doesn't allow for seamless degradation but allows for some data loss in the transmission (while effectively doubling the amount we're trying to push in the first place).
Let's say we're breaking up the original data, creating parity pieces and encrypting each little piece. Then it could decrypt each piece it got and use it and if it couldn't decrypt a piece just throw it away. This could potentially work but parity pieces are useless unless you are trying to recreate the original file neglecting the ability to degrade quality. So redundancy is more important in this scenario than parity.
But, if we make the encrypted pieces small enough, say each packet body, then that could probably work but be resource intensive. Encode/decode every packet, if successful insert into feed, else throw the packet away. This would work a lot like the existing technology just requiring some middle step of decrypting each packet body.
Are there different or more efficient probability calculations that can be done other than the provided algorithm? It seems somewhat simple.
I've found Hope and Help for Your Nerves by Claire Weeks to be the most helpful book on dealing with the physical symptoms. Once you're able to remove or at least tame the physical aspect you can better fight the mental manifestation.
This book literally changed my life and I'd recommend that you don't hesitate to check it out if you suffer from anxiety in any capacity.
http://www.amazon.com/Hope-Help-Nerves-Claire-Weekes/dp/0451...