jmk1ng

joined 2 years ago
MODERATOR OF
[–] jmk1ng@programming.dev 4 points 2 years ago (1 children)

Google shutting down Google Domains is honestly baffling.

If domains aren't a pure profit center for a cloud hosting company then what is? How does selling the business to Squarespace (?!?!?!) of all companies not do serious brand damage to Google in this space?

[–] jmk1ng@programming.dev 6 points 2 years ago (4 children)

Depends on what you mean by miscellaneous.

Are we talking about things my team calls "chores"? Things like upgrade some dependencies, or fix something annoying about the DX or build, look into that new library the team's been talking about maybe using to replace some jank part of the app?

If so, we have an epic we simply name "chores". We stack the backlog of chores based on priority and we attempt to get at least one done a sprint.

It's not critical stuff. It's not blocking anything (yet). It's just housekeeping and maintenance stuff that doesn't fit into regularly planned and scheduled deliverables.

Whenever someone says something like "man, our version of Node is super old. We should really look into getting onto at least the current LTS". That's when you say "Add it to the chores!" so you all don't forget about it.

[–] jmk1ng@programming.dev 5 points 2 years ago

I've been using a combo of Namecheap and Gandi.net depending on which TLDs each support.

I've been planning on consolidating everything on Google Domains... but my laziness seems almost prescient now.

[–] jmk1ng@programming.dev 2 points 2 years ago* (last edited 2 years ago) (1 children)

The trick here is clearly defining PII. Anything that could uniquely identify you and be linked to other sources tends to be problematic.

So IP address? Not guaranteed to be unique so not super useful as a session identifier anyway, but IP could be used to cross reference data from other sources that could identify a individual.

Dropping a totally random session cookie? Not allowed because cookies from your domain are now blocked.

It's really frustrating to hear from your users in the UK about some problems they're having but you have zero logging, analytics, or anything from sessions in the UK because Sentry, GA, Datadog, whatever are all being blocked because they can't drop cookies that they need to group messages and so on by session. Even if that session is considered totally anonymous to you, that doesn't matter because the whole thing is a scoarched earth policy.

[–] jmk1ng@programming.dev 3 points 2 years ago (5 children)

This is honestly a nightmare for developers who rely on telemetry and metrics to identify issues and bugs that are otherwise "silent".

Just because your app doesn't throw errors doesn't mean the code isn't flawed and trapping users within a part of the experience that they cannot fix or leave.

I cant speak for every team in every company, but there's very little to no interest in "harvesting" your "data" for profit.

We just want to figure out what broke and how we correct it ASAP.

[–] jmk1ng@programming.dev 1 points 2 years ago

I actually winced

[–] jmk1ng@programming.dev 8 points 2 years ago* (last edited 2 years ago)

I think Reddit does have a legitimate argument that the scales have tipped and Reddit eating the costs of "whales" abusing their APIs for for-profit use cases without Reddit being compensated at all is fair.

3P apps using the API at no cost while simultaneously monetizing Reddit's content by showing their own ads does seem to be taking advantage.

That said, the way Reddit approached this was so scorched earth and bone headed.

For example. Reddit gets 10s of millions of dollars in free content moderation services from volunteers. The moderators of all their biggest subreddits rely on 3P moderation tools since Reddit's are so poor.

So with the new API policy, they're asking their unpaid moderators to PAY them for the privilege. It's such a slap in the face.

Finally to address the original question, Reddit should absolutely block API consumers who are just training their glorified chat bots to regurgitate plagerized content.

[–] jmk1ng@programming.dev 3 points 2 years ago* (last edited 2 years ago)

Tip 1: Assuming you are starting work at a company that has a healthy culture, do not be afraid to ask for help! There's a lot to learn and it's going to take time to get up to speed. Don't freak out because you aren't slinging PRs like the rest of the team after a week.

However when asking for help, you should open with what you've done already to help yourself. It's important to respect your peer's time, so trying to optimize for efficiency and help them help you as much as possible.

Part of this is also not spinning your wheels and struggling for so long that they need to spend a ton of time helping digging you out of the hole you dug for yourself.

Tip 2: Next is it's important to pay it forward. Docs are super outdated and you got more current knowledge from a braindump from a more experienced engineer? UPDATE THE DOCS!

Tip 3: Once you find your footing, and ship some projects and get a feel for things, it's important to find your voice. If your most Senior engineer on the team proposes something, don't just follow it blindly. If you see a blind spot in the approach, please raise it! Ask questions!

Truly great senior engineers hate it when the team just rolls over and blindly accepts their proposals/architecture. They want feedback! No one is perfect or sees everything. They want the team's help to stress test the approach.

Tip 4: Make sure you keep an open dialog about expectations with your manager. Never assume your manager knows how you spend your time every moment of every day. Ensure you give your manager visibility into your "invisible work".

Examples of invisible work would be taking time to help a new hire. Having conversations with people on another team you depend on or who depends on you to come to consensus on an approach that is beneficial to both teams. Or something like updating documentation or spending time in meetings to review engineering designs, collaborating with product and designers, etc etc etc

Tip 5: Don't be a dick. Avoid being super defensive and assuming others are out to get you, embarrass you, or generally are operating in bad faith until they prove otherwise.

Tip 6: Respect what came before. You'll surely come across some seriously jank code, or a ton of tech debt, or poor approaches. Due to business needs of the time, crunch time, lack of resources, etc are often reasons people did what they did. They very likely know certain things are bad. Calling out bad code or architecture isn't impressing anyone. They know.

When identifying these things, start by asking for context. Come with solutions that are attainable. Calling out things without fresh ideas on how to solve these known problems is not helpful and a waste of everyone's time. Focus on approaches for how to fit fixing the problems into your team's resourcing.

Tip 7: Learn to communicate in a way that resonates with your audience. Try to understand their motivations and what matters to them. Saying that something sucks and we should rebuild in your preferred tech is not an argument. What's the value? How long would it take? What are the trade offs? How does doing this work achieve the businesses' goals?

view more: ‹ prev next ›