/Career Advice

Four Responses To Feedback

- Ed Batista tl;dr: Ed discusses 4 responses to feedback: (1) Express appreciation for the positive. (2) Easy changes you're happy to make. (3) Hard changes you're willing to attempt. (4) Changes that will be too difficult or costly to undertake. “Recognize that every piece of negative feedback contains a request for change and that all change carries a cost.”

featured in #501

The Basics

- Thorsten Ball tl;dr: “Here’s what I consider to be the basics. I call them that not because they’re easy, but because they’re fundamental. The foundation on which your advanced skills and expertise rest. Multipliers and nullifiers, makers and breakers of everything you do.” These include: (1) Keep your change free of unrelated changes. (2) Make sure that your PR is up-to-date against latest on your main branch. (3) Before you comment on something, read the whole thing.

featured in #500

Managing Up: 11 Ways To Get Better Feedback

- Wes Kao tl;dr: (1) Make it insanely easy for your manager to give you feedback i.e. ask for specific prompts. (2) The word “feedback” might feel loaded. Ask what to do differently and what worked well e.g. “What’s missing? Could you mark which parts of this memo are confusing?” (3) Give them permission to rip your work apart and encourage them to be direct

featured in #500

Managing Up: 11 Ways To Get Better Feedback

- Wes Kao tl;dr: (1) Make it insanely easy for your manager to give you feedback i.e. ask for specific prompts. (2) The word “feedback” might feel loaded. Ask what to do differently and what worked well e.g. “What’s missing? Could you mark which parts of this memo are confusing?” (3) Give them permission to rip your work apart and encourage them to be direct

featured in #499

The Builder’s Guide To Better Mousetraps

- Marc Brooker tl;dr: “I tend to be biased towards innovation. Towards building. I think most advice for technical leaders over-emphasizes the short-term risks of innovating too much, and under-emphasizes the long-term risks of innovating too little. However, both sides have good points, and we owe it to ourselves and our businesses to think carefully about the decision. Because of my bias, I force myself to deeply question my motivations when making decisions like this,” such as (1) What could I be doing instead? (2) Do I want to own this? (3) Am I solving a simpler problem?

featured in #498

Getting Things Done In A Chaotic Environment

tl;dr: “One of the first things my CEO told me is that things move fast, so you have to get things done as completely as possible and move on to the next thing. I think about that advice a lot, and I find myself telling people that same thing again and again... I find people make four common mistakes when trying to get things done: (1) Having more than one main focus. (2) Ignoring things you can’t ignore. (3) Not completely finishing things. (4) Taking too long to do things.”

featured in #498

40 Years Of Programming

- Lars Wirzenius tl;dr: “My goal in this essay is to get the reader to think, to research, to learn, to ponder. My goal is not to tell the reader how to think, what to think, how things are, or to give the answer to every question about every aspect of the process of building software.” Lars covers topics such as productivity, questions about projects, planning, estimating, and more. 

featured in #497

Getting Things Done In A Chaotic Environment

tl;dr: “One of the first things my CEO told me is that things move fast, so you have to get things done as completely as possible and move on to the next thing. I think about that advice a lot, and I find myself telling people that same thing again and again... I find people make four common mistakes when trying to get things done: (1) Having more than one main focus. (2) Ignoring things you can’t ignore. (3) Not completely finishing things. (4) Taking too long to do things.”

featured in #497

The Most Important Goal In Designing Software Is Understandability

- Nicole Tietz-Sokolskaya tl;dr: Nicole advises on how to make our code inherently more understandable: (1) Remember your audience i.e. what will other maintainers be expected to know. (2) Isolate the highest complexity. If something is complicated, pulling it into its own unit, such as a module or function. (3) Read it with fresh eyes a few days later. (4) Integrate any code review comments by updating the code and comments. Nicole also discusses how to leverage documentation. 

featured in #495

68 Bits Of Unsolicited Advice

tl;dr: (1) Learn how to learn from those who disagree with you or even offend you. See if you can find truth in what they believe. (2). Being enthusiastic is worth 25 IQ points. (3). Always demand a deadline. A deadline weeds out the extraneous and the ordinary and it prevents you from trying to make it perfect so you have to make it different. Different is much better. (4). Don't be afraid to ask a question that may sound stupid because 99% of the time everyone else is thinking of that same question and is too embarrassed to ask it. (5). Being able to listen well is a superpower. While listening to someone you love, keep asking them “Is there more?” until there is no more.

featured in #495