danthemanvsqz

I guess they don't have db snapshots.

The benchmark doesn't reflect how I would use asyncio. Instead of simply hitting a DB I'd like to see adding an API call to the middle of the request.

Microservices are good for scaling teams not hardware. If you don't have more than one team then there is no reason to break up your monolith.

They do different things but in the wild are used in the same way. Data classes are not immutable so it would not be ideal for what I used named tuples for.

Prefer using named tuples over enums in Python.

You schedule tasks very easily with the Celery Beat Scheduler. I've used it in production system to kick off big jobs and notifications.

https://docs.celeryproject.org/en/v2.3.3/userguide/periodic-...

I don't use them on prototypes because I will throw away that code. But IMHO TDD is at it's best when your design is highly likely to change. The only protection you have against a moving target is your test suite. The requirements or our understanding of the requirements change so we change the code. In large code bases we can only be certain that the code change doesn't break anything if we have good tests. TDD is the only realistic approach to achieve 100% test coverage. You can certainly write good tests to cover your code at 100% but I've never seen it done by anyone consistently without TDD.

I've always relied on unit tests with mocks with the rule that I only mock modules that are tested and I mock or stub all db and network calls. I also like integration and end to end tests but not may of them. I rely on unit tests for regression and should be able to run the whole suite in less than an hour. I set my precommit hook to run unit tests with coverage and static analysis.

So there is a tipping point when the technical debt you acquire from not testing catches up with you and cripples the project. I think this tipping point comes much faster than people realize. Most people have no idea how bad their tech debt is until it's too late. Then you see one failure after another while management tries to fix the train wreck. At this point any good Eng is going to bail in this market and you're stuck with the scrubs.

In TDD you don't build a wall of tests, you build your tests as you build your code. Test a little, code a little, refactor, repeat.

I think the only unethical thing is holding back on the results. It's great to automate tasks and the company doesn't need to know about it unless it is explicitly stated. But your obligation is to deliver high quality results as fast as you can.

Interesting read from the POV of the staffing agency and hiring company. But why should I jump through those hoops when I don't even know if I'm interested in the job? I really think the hiring companies need to sell me on them before they ask me to spend an hour of my time.

Wrap the double loop in a function/method and return from the inner loop.

I think they missed Google's launch of Spanner their distributed strongly consistent DB.

+1 I was thinking the same thing myself. Pie charts are for elementary school kids.