/Career Advice

Career Checkup Template

tl;dr: (1) Fork this template. (2) If there are any sections that don’t resonate with you, remove or edit them. (3) Fill in the sections. Feel free to jump around to answer the parts that you have the most energy for. (4) Revisit a few days later: is there anything you want to change? (5) If possible, find peers to discuss each others checkups together. (6) Review a year from now.

featured in #326

The Fallacy Of Splitting Time

- Ben Northrop tl;dr: "There are two projects, both deemed important by the business, and both need a UI developer. Unfortunately, only one UI developer is available. Why not let the UI developer split time across both projects?" Ben explains why this doesn't work using the equation: Productive Time = Total Time - Overhead.

featured in #326

Advice For Engineering Managers Who Want To Climb The Ladder

- Charity Majors tl;dr: "We have been interviewing and hiring a pile of engineering directors at Honeycomb lately. In so doing, I’ve had some fascinating conversations with engineering managers who have been trying unsuccessfully to make the leap to director. Here is a roundup of some of the ideas and advice I shared with them."

featured in #325

Why, Oh Why Was This Added?

- Žiga Miklič tl;dr: "While not commenting event calls is usually not a big deal, it may be a problem in situations like mine where I had to go over many ambiguous use cases at once. This resulted in a lot of wasted time that could be otherwise avoided if the original author added a comment."

featured in #324

Start Test Names With “Should”

tl;dr: Reasons include: (1) It removes redundancy, because the function name should already be in the call stack. (2) It is falsifiable i.e. a person reviewing the test can decide to which degree the name agrees with the actual test. (3) Encourages testing one property of the function per test.

featured in #323

Master Your Questioning Skills

- Murat Demirbas tl;dr: Murat committed to asking "crazier" left-field questions in each post he wrote. After 70 posts, he learned that these: (1) Are useful as they took him out of "default mode." (2) Keep the brain more engaged. We tend to ask easier questions. Harder ones feel uncomfortable or seem impolite. (3) By calling them "MAD" questions, they give him the license to be more uninhibited. 

featured in #322

"Change"

- Chris Kiehl tl;dr: '"What if it changes?" isn't just a question. It's a powerful heuristic for software design that can be used to justify almost anything. Everyone should use it more. It's great precisely because it's rooted in pure speculation.' Chris provides a guide for how to navigate this thinking. 

featured in #321

Learnings From 5 Years Of Tech Startup Code Audits

- Ken Kantzer tl;dr: (1) You don’t need hundreds of engineers to build a great product. (2) Simple Outperformed Smart. (3) Our highest impact findings would always come within the first and last few hours of the audit. (4) Writing secure software has gotten remarkably easier in the last 10 years. (5) All the really bad security vulnerabilities were obvious. And more.

featured in #320

How To Feel Engaged At Work: A Software Engineer's Guide

- Jason Tu tl;dr: 1) Make time to be curious e.g. schedule 30 mins to jot down questions that spark curiosity. (2) Imagine you were the CEO and ask yourself how the business would work, and let your mind guide you through the web of questions a founder might ask. (3) Frame your career as a series of questions to create a sense of ownership of your career. (4) Try something new. 

featured in #319

Intelligent Brute Forcing

- David Koloski tl;dr: "In this article, I will present a new puzzle game and demonstrate techniques I used to write a fast, practical solver for it. Topics covered will include breadth-first/A\* search, memoization, optimization, and strategies specific to NP-hard and NP-complete puzzle games."

featured in #319