OsrsNeedsF2P

cross-posted from: https://lemmy.ml/post/33319577

1. Running Good 1:1 Meetings

"I don't know how to start", "This solution won't work" and "I'm going to do X" are all bad examples of how to talk to your manager (or anyone). When you're talking with other people, you are having the privilege of leveraging their experience to solve your issues.

Problem --> Solution --> "What do you think?"

First, clarify the problem. If you tell (i.e. your manager, but it can be anyone) a solution, they won't know if it's the best way to solve the problem.

Second, tell your manager what your current plan is. Having an existing plan makes the next step much easier for your manager, and makes you look somewhat competent.

Third, ask your manager what they think. Maybe they'll tell you, "Yep, makes sense". Maybe they'll tell you to tweak it. Maybe they'll give you a completely different direction. Maybe they'll ask you why you're even solving that problem, and to go do something else.

I used to hate 1:1s. I had no idea what to talk about. Now, I gather a few of these questions throughout the week, and add it to an agenda. My manager regularly thanks me for having a productive session.

2. Make a Good Plan (& Real Prioritization)

What is the problem you're solving? Why is this an important problem? How do you know when you will have solved it? How are you solving this?

Start every project with a doc explaining these 4 things in under 2-3 sentences. Until you communicate this, you do not have a plan, and you do not have a project.

It's an uphill battle if you cannot do this. I run the System Design Club at Meta. My skip told me it counts as E4 (not Senior level) at best - because it's not solving a real problem.

3. Review Work Better

Everything we talked about above is applicable to how you review other people's work too.

First understand the problem, then understand the solution. Ask questions that make it clear the solution addresses the problem.

When reviewing plans, ask how you know they will be done ("How do you know when you will have succeeded?"). Be sure it's clear how it will be done (no "draw the rest of the f**king owl" memes) - Ensure all the steps, if followed, will resolve the problem. Ask for timelines so you can hold them accountable.

When reviewing code, your goal is to make sure the new code solves the problem, and doesn't add new ones. Don't nit about style, instead call out a problem that arises from their style ("If someone changes ABC, they won't know this breaks"). Don't assume a bunch of logic you don't understand works; ask "How do you know this is going to work?".

4. Being supportive in your messaging goes a long way.

Any time someone asks a question, I preface by saying "Good question - [...]" (ofc I change up the style). This keeps them asking more questions. Whenever giving critical feedback, I start by calling out the good work that was accomplished. This keeps the other person motivated.

I first learned this trick when developing in open source, but saw it pay dividends at Meta. I had one contributor who was writing 90% of the project code - I would continuously praise their PRs and talk about how great they were. When I stopped doing that for about a month, that contributor noticeably dropped off. For some people it's support, and for others it's ego. But it keeps them working hard.

5. The Reality of Looking Good - and Failure

If you are doing well, people will want you on their projects. If you're stuck or confused, they will assume you tried your best, and it's the problem that is hard.

A good engineer might fail a project from time to time, but they have clear and notable success stories too. If you have only failed projects, you are a bad engineer.

Not only do people enjoy helping good engineers - Bad engineers get the plug pulled.

Despite a supportive culture, I have been explicitly told to stop helping person X, because person X is not worth helping. Person X is later removed from the company.

The advice here is to start strong. If you start strong, you will get the support you need to thrive. If you are currently weak, you need to do everything in your power to get strong - Things will naturally feel easier when things are going well, since other people will be helping you.

This post is dense information. Do not expect to walk away remembering all of it. But pick one that applies to your weakness the most - Think deeply about how it can be applied. Then get better.

1. Running Good 1:1 Meetings

"I don't know how to start", "This solution won't work" and "I'm going to do X" are all bad examples of how to talk to your manager (or anyone). When you're talking with other people, you are having the privilege of leveraging their experience to solve your issues.

Problem --> Solution --> "What do you think?"

First, clarify the problem. If you tell (i.e. your manager, but it can be anyone) a solution, they won't know if it's the best way to solve the problem.

Second, tell your manager what your current plan is. Having an existing plan makes the next step much easier for your manager, and makes you look someone competent.

Third, ask your manager what they think. Maybe they'll tell you, "Yep, makes sense". Maybe they'll tell you to tweak it. Maybe they'll give you a completely different direction. Maybe they'll ask you why you're even solving that problem, and to go do something else.

I used to hate 1:1s. I had no idea what to talk about. Now, I gather a few of these questions throughout the week, and add it to an agenda. My manager regularly thanks me for having a productive session.

2. Make a Good Plan (& Real Prioritization)

What is the problem you're solving? Why is this an important problem? How do you know when you will have solved it? How are you solving this?

Start every project with a doc explaining these 4 things in under 2-3 sentences. Until you communicate this, you do not have a plan, and you do not have a project.

It's an uphill battle if you cannot do this. I run the System Design Club at Meta. My skip told me it counts as E4 (not Senior level) at best - because it's not solving a real problem.

3. Review Work Better

Everything we talked about is applicable to how you review other people's work.

First understand the problem, then understand the solution. Ask questions that make it clear the solution addresses the problem.

When reviewing plans, ask how you know they will be done ("How do you know when you will have succeeded?"). Be sure it's clear how it will be done (no "draw the rest of the f**king owl" memes) - Ensure all the steps, if followed, will resolve the problem. Ask for timelines so you can hold them accountable.

When reviewing code, your goal is to make sure the new code solves the problem, and doesn't add new ones. Don't nit about style, instead call out a problem that arises from their style ("If someone changes ABC, they won't know this breaks"). Don't assume a bunch of logic you don't understand works; ask "How do you know this is going to work?".

4. Being supportive in your messaging goes a long way.

Any time someone asks a question, I preface by saying "Good question - [...]" (ofc I change up the style). This keeps them asking more questions. Whenever giving critical feedback, I start by calling out the good work that was accomplished. This keeps the other person motivated.

I first learned this trick when developing in open source, but saw it pay dividends at Meta. I had one contributor who was writing 90% of the project code - I would continuously praise their PRs and talk about how great they were. When I stopped doing that for about a month, that contributor noticeably dropped off. For some people it's support, and for others it's ego. But it keeps them working hard.

5. The Reality of Looking Good - and Failure

If you are doing well, people will want you on their projects. If you're stuck or confused, they will assume you tried your best, and it's the problem that is hard.

A good engineer might fail a project from time to time, but they have clear and notable success stories too. If you have only failed projects, you are a bad engineer.

Not only do people enjoy helping good engineers - Bad engineers get the plug pulled.

Despite a supportive culture, I have been explicitly told to stop helping person X, because person X is not worth helping. Person X is later removed from the company.

The advice here is to start strong. If you start strong, you will get the support you need to thrive. If you are currently weak, you need to do everything in your power to get strong - Things will naturally feel easier when things are going well, since other people will be helping you.

This post is dense information. Do not expect to walk away remembering all of it. But pick one that applies to your weakness the most - Think deeply about how it can be applied. Then get better.

I've got some great Linux swag from Ubuntu Korea, but I've been looking to buy new clothes lately and would love to rock more FOSS.

I see a couple websites that sell FOSS branded clothing, but does anyone have good experience buying high quality hats/tshirts/sweaters/active wear from any of these online retailers? Bonus points if the retailers donate proceeds to development

Like 75% of the candidates are cheating, and it's so obvious. It's a shame because even if I know they're cheating, it raises my subconscious bar on quality I expect from candidates.

"Oh I see you used Kafka in this design, but it appears to be pushing to your workers. Can you talk to me in a bit more detail about how this works?"

(note: You're only getting this question if you used Kafka to solve my problem. The answer is the workers pull off Kafka and store their own offset, or Kafka stores it in the case of consumer groups)

proceeds to read off the encyclopedia for Kafka

"that's great.. but explicitly, how are your workers using Kafka..?"