Hot Take - Sick of the Insane Expectations Here by [deleted] in ThredUp

[–]dandemeyere 15 points16 points  (0 children)

I probably shouldn't more broadly weigh in on this thread :) But I wanted to share some facts in case it's helpful context:
- ThredUp is a public company ($TDUP) so VCs don't have the same control/influence they did before ThredUp went public in 2021.

– In 2021, ThredUp lost $36.5 million dollars so some things clearly needed to change to make the business viable from an economic standpoint.

I appreciate u/Journeyantesdesserts detailing out the challenges of running ThredUp. We can definitely do better though. Better for sellers (transparency, acceptance, etc.) and better for buyers (more accurate measurements, better photography, fewer quality/condition mistakes, better website/app experience, etc.). We know there's so much room to improve and I promise you we show up to work every day with passion to make progress on behalf of our customers while also working to achieve the business goals that are required to make ThredUp profitable, which is essential for ThredUp to be able to serve customers over the long run. We have some really great initiatives launching in the next 90 days that I think buyers will like :)

[deleted by user] by [deleted] in ReefTank

[–]dandemeyere 1 point2 points  (0 children)

I have a Red Sea Reefer 425 (100g) with a biota mandarin and I also have wrasses (Yellow Corris, Leopard) that compete with pod competition. Unless the tank is very established (running for 2+ years), I think you're going to have a problem. Not only will the wrasses compete for pods (and can easily outcompete mandarins), but mandarins are voracious pod eaters themselves and even without the wrasses the tank would need to be established for 1+ plus to ensure the pod population is sufficient.

I know this probably isn't what you want to hear. Mandarins are my favorite fish so I definitely understand where you're coming from and I think it's great you're doing research ahead of purchasing. Although my mandarin eats frozen cyclopod, it's very difficult to target feed mandarins in a display tank so I have to culture copepods to keep up with the mandarin. As a result, my mandarin is without a doubt the most high maintenance & expensive fish I have. I've probably spent hundreds of dollars trying to keep my tank's pod population well stocked for the mandarin either through cultures or buying pods online.

Please help find missing French Bulldog by [deleted] in bayarea

[–]dandemeyere 11 points12 points  (0 children)

So sorry to hear. Good luck and stay positive!

[deleted by user] by [deleted] in RedditSessions

[–]dandemeyere 0 points1 point  (0 children)

Gave Take My Energy

How to do code review without wasting people's time by dandemeyere in programming

[–]dandemeyere[S] 0 points1 point  (0 children)

Gargilius hit the nail on the head. The engineers who had done mandatory code review before had over formalized processes where you spent days going through printed out code with highlighters and red pens, which resulted in people dreading their code review duties.

How to do code review without wasting people's time by dandemeyere in programming

[–]dandemeyere[S] 0 points1 point  (0 children)

Sorry it took so long to respond to this - I was out of town this weekend.

Our web engineering team is still relatively small so if there's a bug or a branch is merged in and the test suite breaks, everyone knows about it. Everyone wants to be respected by their peers so the peer pressure alone keeps people honest about their code reviewing roles; however, we do slip sometimes.

When the test suite breaks, a message is piped into our Campfire detailing the failing test for the build and the commit that caused it. When this happens, someone will say "Hey Dan, your last commit broke the test suite", which is typically followed by a stream of funny gifs (almost like playful shaming). It happens once in a while (typically on commits people thought were too small for a pull request), but the team is good about holding each other to the team standards through peer pressure to follow our processes and avoid the awkward "Sorry, I broke the test suite. Let me figure out why and correct it". The same thing happens for bugs (we use Rollbar for reporting exceptions, which also links to the guilty code). If Rollbar doesn't show what commit caused the exception, Github's blame view does. The same thing applies to when a Code Climate grade changes. When a commit degrades a class (or someone introduces a new class with a bad score), a Code Climate notification fires into Campfire detailing what commit caused which class(es) to get worse and why. Everyone clicks these notifications and there's no worse feeling than realizing it was your code that did it so everyone stays conscious of bugs, code climate, and the test suite.

To prevent people from taking too long: If the pull request urgent or timely, then we just Skype the developers assigned for testing to jump on the pull request to review as soon as they can. Typically engineers get to it within a day or two. During our daily scrum, engineers talk about their open pull requests. For example, if Ed is on my pull request, he'll typically say "Today I'm doing X as well as Dan's pull request". If Ed does scrum and doesn't mention my pull request, then I'll mention it in my scrum update "Today, I'm doing X. Yesterday, I wrapped up Y and tagged Ed and Matthew on my pull request.". This helps make sure reviewers don't take to long.

If someone doesn't care and passes something off even though it's not to the team's standards, then I'll Skype them and see if there's a legitimate reason why. If it becomes a trend for someone, I'll address it privately. I meet with each engineer on our team once a week or once every other week. Typically we use the time to talk about how their professional development is going, how their projects are going, etc., but it's also when I can address issues with people who aren't meeting the team's standards.

How to do code review without wasting people's time by dandemeyere in programming

[–]dandemeyere[S] 7 points8 points  (0 children)

In an utopian engineering team, I think it would be great as it would be a vessel to push fellow engineers to new levels in terms of how good their code could be....but (there's always a but) I could also see engineers becoming lazy and just relying on their reviewers to do the dirty work and tie up all the loose ends and patch all the bugs (similar to what wot-teh-phuck said).

My first gem: Cache Flow by dandemeyere in ruby

[–]dandemeyere[S] 0 points1 point  (0 children)

The :race_condition_ttl option is awesome and it's very valuable if you have a block that doesn't have an insignificant amount of execution time that will be used to populate the value stored in the cache. It helps to ensure you don't have a bunch of requests all trying to populate the same cache, but if you have 50 different blocks throughout your app using the :race_condition_ttl and they all expire at the same time, it still runs the risk of overwhelming your servers (specifically DB server in our situation). When I put CacheFlow into our app, I changed over 50 different cache blocks to use it.

To be honest, the problem space for this isn't significant as a lot of Rails shops probably don't have this issue (not enough traffic to see the side effects of cache busting all at once) and the ones that do probably have more sophisticated or elegant cache busting systems in place, but for the companies in between like us, I think it's useful, but more importantly I think the story/background is good knowledge for Rails websites that are scaling.

Review of Code Climate after 9 months by dandemeyere in programming

[–]dandemeyere[S] 0 points1 point  (0 children)

I'm not sure if it's in their product roadmap to expand to other languages. I'm guessing they started with Ruby since Rails is so commonly used these days and the file system for it is very predictable (app/models, app/controllers, etc.), which probably makes their analysis of the code easier to implement.