Posting both on your own blog and others is called "blog syndication", it's a common practice that's googleable.
358 karma · joined May 7, 2020
@canardivore on twitter
My take is that the standard is too lenient and the cables aren't color coded.
Lenient standards mean that "usb-c" could support 1W or 10W and your phone plays footsy to figure out how high it can go. Pick a standard, pick a level, don't exceed the standard even if you can.
Color coding? Yup. Colors. A human must be able to visually determine what specs a cable matches and doesn't match. Before, different standards had different ports, so color didn't matter. But usb c wants to be the same port for multiple standards. Fine. Color code it. It can even be a small dot by the plug, as long as it doesn't wear off.
Work tracking isn't just about figuring out what work needs to get done, it's about helping management get a picture for the state of work.
Developers and other line workers don't care about obsolete vs won't do. But management does. They want to know if they're being requested for work that will be rendered useless in a few weeks. They want to know if too much work isn't getting done because work is floating up to the CEO and it's not worth his time.
There's a terrible principal agent problem here where management, the principal, decides how to track work, and can put the heavy lifting of filling in values onto the developers. This happens when management's more worried about losing their job than improving their team's output.
2 - Log hours programming whatever it is you like programming to build your resume and skills. Since you need money and you're remote, your resume is what will land you an interview. Your skill important because that'll land you an offer. The number of hours you log will matter most and that will depend on how much you like what you're doing. You want to have the "oops I worked too much again" problem, not the "oops I forgot to work again" problem
Finding a job: Find a remote engineering job. You may find luck in crypto, check out https://cryptocurrencyjobs.co/engineering/
DM me on twitter, @code_faster if you have more questions.
It's more that people like building features and people don't like saying no to features.
The original unix guys had a rare culture that was happy to knock off unnecessary features.
Refactoring is the same as rewriting, just on a smaller scale, which increases certainty.
Joel's advice assumes you will overestimate your certainty.
When convex this is good When concave this is bad So if all else is equal, the convexity breaks the tie.
In concave payoff distributions, where risk has a negative expected value, inaction is favored.
One trick I found helpful was using JSON to serialize test results instead of unstructured plain text.
Test results stored as JSON are much easier parse and therefore process. You can quickly whip up programs that verify the tests satisfy invariants, diff the tests and filter out expected test changes from unexpected test changes.