/Career Advice

Does The Title Even Matter?

- Will Larson tl;dr: Title gives a sense of seniority amongst peers, a seat at the table of higher engineering discussions, a bump in compensation at larger companies and potential access to interesting work. Pursuing title alone can be counter-productive, and "focusing on developing your approach and skills will be far more impactful."

featured in #215

Surviving Disillusionment

- Slava Akhmechet tl;dr: Engineers are seduced by the romance of technology & its "power to transform the human condition," and repelled by the "drudgery" of corporate politics, bureaucracy, envy and greed." The latter can be overcoming. Slava encourages us to keep a daily tangible, ritual that reminds us of this romance.

featured in #214

Questionable Advice: The Trap Of The Premature Senior

- Charity Majors tl;dr: Charity is asked for advice by an engineer who has "accidentally" becomes the most senior on a team. Her advice is to leave. A "real senior engineer" has managed 2-3 teams, stacks, languages over a 5-8 year period.

featured in #213

Early Work

- Paul Graham tl;dr: "We just don't have enough experience with early versions of ambitious projects to know how to respond to them. We judge them as we would judge more finished work, or less ambitious projects." Optimism and imagination become urgent.

featured in #212

Talking, Typing, Thinking: Software Is Not a Desk Job

- Daniel Fone tl;dr: For Daniel, the 5 physical activities of effective software development are talking, typing, writing, reading and thinking. "My times of greatest clarity are invariably when I’m moving, often when I’m exercising."

featured in #212

How To Waste Your Career, One Comfortable Year At A Time

- Apoorva Govind tl;dr: All "great engineers have a sense of adventure," and complacency in a job means it may be time to change. Apoorva uses the following to evaluate complacency - accomplishment, impact, growth, challenge and community - each outlined in a framework.

featured in #211

Four Principles Of Software Engineering

- Drew DeVault tl;dr: Software should be (1) robust, handling edge cases, various user inputs (2) Reliable, working for an extended period of time "under design conditions," and outside those conditions too. (3) Stable, not changing in unexpected ways. (4) Simple enough to meet the other 3 goals, nothing more.

featured in #211

Stage Of Company, Not Name Of Company

- Nikhyl Singhal tl;dr: When choosing your next company, first determine which stage - pre-product fit, post-product fit, growth or scale - is the best match. Usually only 1 or 2 stages make sense for any given job search.

featured in #210

Motivation And Why Finishing A Personal Project Is Hard

tl;dr: There are several reasons this could be true but, to finish a project, you need to be a "mad hatter." You need a broad skillset i.e. systems architect, db admin, backend developer, essentially all the roles in a team.

featured in #209

Things I Was Wrong About: Types

- Chris Krycho tl;dr: Chris undervalued types until he discovered specific use cases along with their value - type inference, soundness, sum/tagged union types - all of which are explained here.

featured in #208