/Career Advice

Contributing to Complex Projects

- Mitchell Hashimoto tl;dr: 5 step process outlining how Mitchell approaches a complex project: (1) Become a user of the project. (2) Learn how to build it. (3) Learn the hot-path internals using “trace down, learn up.” Trace down starts with a feature and trace the codepath that the feature follows. Learn up is about understanding how the various mapped subsystems work. (4) Read and reimplement recent commits. (5) Make a bite-sized change.

featured in #300

Some Tiny Personal Programs I've Written

- Julia Evans tl;dr: "Here are a few examples of small personal programming projects I’ve done. I’m not going to talk about “learning projects” where my goal was to learn something specific because I’ve already written a billion blog posts about that. These are more about just doing something fun with no specific learning goal." 

featured in #298

Editing Stuff In Prod

tl;dr: "This was someone who had been asked to give haircuts to hyperactive children and had only been handed a chainsaw, and still managed to actually DO it without harming or scaring anyone. That takes some serious effort (and skill)." The author discusses working with another individual who had to edit in prod.

featured in #297

The Thirty Minute Rule

- Daniel Roy Greenfeld tl;dr: If anyone gets stuck on something for more than 30 minutes, they should ask for help. Why? (1) Simply formulating the question to ask allows us to answer the problem ourselves. (2) We are stuck because of something we don’t know, making it impossible to proceed. (3) We don’t get frustrated. (4) Reduces costs. 

featured in #296

Practical Guide To Solving Hard Problems

- Frank Krueger tl;dr: Here are the steps I take when I’m stumped. No huge revelations here, just hard-earned advice. First 3 steps: (1) Think hard about the problem for a few weeks before typing any code. (2) Type in a function or write a class that has the inputs and outputs you need. (3) Break the function down into multiple steps with clear objectives. You may not know how to achieve those objectives, but that’s a problem for your future self. Right now, you’re just trying to write out the high-level algorithm. Frank guides us through another 6 steps in this post.

featured in #295

Ten Rules For Negotiating A Job Offer

- Haseeb Qureshi tl;dr: Haseeb explains each of the following in detail: (1) Get everything in writing. (2) Always keep the door open. (3) Information is power. (4) Always be positive. (5) Don’t be the decision maker. (6) Have alternatives. (7) Proclaim reasons for everything. (8) Be motivated by more than just money. (9) Understand what they value. (10) Be winnable.

featured in #294

How You Can Tell If The Company You're Interviewing With Is Rotten On The Inside?

- Charity Majors tl;dr: Charity presents strategies, such as backchanneling with contacts, effective D&I practices, and also maintains that how the interview is organized is telling: (1) Was the interview conducted in a timely fashion? Were you given detailed information about what to expect? (2) Were you compensated for your any take-home projects. (3) Did they get back to you swiftly at each step of the way to let you know where you stand and what comes next?

featured in #293

On Owning A Software Problem

- Vicki Boykis tl;dr: What is a low-friction small thing that most will not notice, but that when they do, is a sign of craftsmanship, expertise, and pride in one's work? Vicki has created a list relevant for ML and Data Science: (1) Python code has type annotations. (2) Accurate documentation of a repo and an easy, reproducible way to run the project. (3) Formatted and linted SQL statements. And more.

featured in #293

Returning Values And Errors

tl;dr: "If you agree with the notion that you need to be able to tell the difference between the absence of a value and a value itself, then this has some impacts on the code you write. If you want to keep 'em separated (so they can come out and play), then it gets you looking at your API designs in certain ways." The author shares her reactions to some of the ways a value can be returned.

featured in #293

Lessons Learned From My 10 Year Open Source Project

- Steve Micallef tl;dr: (1) Writing open source software can be very rewarding in ways you can’t predict e.g gratitude from users, improvement as an engineer, etc... (2) Be in it for the long haul. "If you are consistently working on improving the project, it will get noticed and used over the flash-in-a-pan software that appears and eventually gets abandoned." (3) Ship it and ship regularly. And more. 

featured in #291