cross-posted from: https://lemmy.ml/post/33319577
- 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.
- 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.
- 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?”.
- 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.
- 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.
For style problems you should have a linter. If it cannot be solved by a linter is not a style problem.
I’ve said this before only to hear “we don’t have time to set that up and agree on a common style” and “that’s team B’s responsibility since we’re contributing to their code base.” Guess what kind of issue we kept wasting time on?
There are a couple of takeaways here. I think the main one is acknowledging that many technical problems are deeply human problems and the existence of a technical solution doesn’t mean we shouldn’t apply the human solution as well.
I value choosing between two styles by feel for improving readability and conciseness.
For example, allowing one-liner early-returns if they are concise enough. If they are not, they must be multi-line with a block with curly braces. There’s no linter rule that defines what “simple enough” is, and most linters don’t do rules with condition either.
I usually use whatever the formatter does by default. Most are reasonable by default, and I might prefer things a different way personally, but I find that my job is easier when everyone else’s code is checked by CI to conform to the formatter’s style rather than being an unreadable mess of random newlines and weird mismatched indentation.
The guideline that I follow is that if a tool doesn’t enforce a rule before the code can be merged, then it’s not a rule. Everyone, myself included (if I’m being particularly pressured on a feature), will overlook it at some point, whether intentional or not.
For early returns, I think most reasonably configurable formatters support optional braces in those cases. This of course is assuming that’s a thing in your language, since many don’t have a concept of one-line unbraced returns (Python doesn’t use braces, Rust always expects them, etc). For consistency and just to have a rule, I usually just brace them because I know everyone will if it’s enforced rather than it varying person-to-person.
Good guideline. One of the first things I did when starting a side project with a friend was to figure out how to run a code formatter triggered by git (I think?) that reformats code into a common style. If we didn’t like it we could apply our own styling when we pulled.
I don’t always love every line of automatic styling even if I have free reign over the rules, but it saved so much time and effort in code reviews.