chrisguitarguy

> Most mature languages have a logging system which allows the internal logging of a library or module to be silenced, redirected or almost any other action. I think there is a lot of value in libraries doing appropriate logging which can't easily be replicated in application code.

Info/debug level logs sure, I don't disagree. As long as there is some built in or community standard logger and not the libraries own custom thing.

Errors, I'd rather they throw and my own app's logging facilities kick in that can provide more context: which server, which container, request info (method, path, request ID), etc. Granted some of that could come from configuring a logger with it.

Log (and presumably) deal with errors if you _can deal with them_ close to where they occur. Otherwise just let them throw and/or propagate them up. An application should have some sort of top level error handling to log the error and actually return a response (HTTP 500 or otherwise) to the client.

For something like a library: no logging, that's not a library's job -- unless it's a logging library! If the language has exceptions, then throwing only subclasses or implementations of a single exception parent/interface from the entire library is nice for clients of the library.

Same for me. Kids are 1.5 and 4. I used to do so much just hacking around, and now it's non-existent.

As far as bedtime/sleep stuff: I pretty much just wind down after the kids go to bed. Meditate if I haven't got that in yet (or maybe do a shorter session if I have and am feeling stressed). Read. Then try to get to bed early enough to give myself an 8-ish hour sleep window.

Seconded, this is a great book.

I think all non-managers should read it as well as it will give you some clarity on what you should expect from your manager and what their day-to-day is like.

I tend to write test cases that re-produce bugs first, then fix the bug. Other than that, I don't stick too hard to test driven development. I did for a while, but you start to get a sense of the sort of design pressure tests create and end up build more modular, testable code from the get go anyway.

> Can you describe the practical benefit?

For a test case that produces a bug, you might find the bug manually. Getting that manual process into a test case is often a chore, but in doing so you'll better understand how the system with the bug failed. Did it call collaborators wrong? Did something unexpected get returned? Etc. In those cases, I think the benefit really is a better understanding of the system.

> Do you happen to rewrite the tests completely while doing the implementation?

A TDD practicioner will probably tell you taht you're doing it wrong if you do this. You write the minimum viable test that fails first. It might be something simple like "does the function/method exist". You add to your tests just in time to make the change in the real code.

Though it may have started as a, "parasite upon reddit," imgur does stand pretty well on its own now. Try out their mobile app and you'll see a pretty active community.

That's advertisers themselves doing a bad job of retargeting. First-party data is probably not going to change that. In fact, it may mean you'll just get those ads across all your devices.

This is how I came to work remotely. When my wife and I had to move for her job, I had built quite a bit of the software my company relied on. Had leverage to go remote and the trust of my boss to do so.

I suspect it's because WhatsApp's backend can be turned into a platform that will run WhatsApp itself as well as Facebook Messenger.

There's a lot more opportunity to do messaging between businesses and individuals (eg. customer service) as well -- see messenger for business.

Not saying Facebook isn't out to sell ads, just that there's probably a lot of reasons that Facebook might want WhatsApp's technology and team. Especially as they try to move more conversations onto their platform and reach out into other markets.

If your objects require dependencies to do their jobs, it should be impossible to create objects without those dependencies. The objects' constructors should require them. Having setters is, arguably, fine (but probably unnecessary) as long as invalid objects can't be created.

That's more along the lines of what a lot of TDD literature says.

Write adapters or facades that wrap external libraries, use those in your own code's unit tests. This makes you less bound to a specific library as well. Don't mock the outside world [0] for testing your adapters/facades/whatever, but do integration tests that cover your adapters using the real outside world.

You'd also do complete end to end tests where the entire system is used as if it were in production (acceptance testing). TDD makes a lot more sense if you think of it in those three layers: acceptance, integration, unit.

[0] Outside world means anything that's not your code -- networking, filesystem, external libraries, etc.