/Career Advice

The Cult of Best Practice

- Dominik Krejcik tl;dr: "Many best practices in programming don’t meet the definition. They spread, not based on merit or evidence, but thanks to authority bias and social utility. As they spread, they lose nuance. As they lose nuance, they become easier to evangelise. Combined with lack of experience, they can lead to cult-like behaviour."

featured in #223

Do Less And Do It Better

- DJ Adams tl;dr: As a developer advocate, there’s always something new to learn or adopt. The price of which is limited comprehension. DJ compares this to seeds planted loosely in the ground that don't grow properly, as opposed to mastery where seeds are deeper and more rooted.

featured in #223

My Third Year As A Solo Developer

- Michael Lynch tl;dr: Michael quit his job at Google to go solo three years ago, focussing on his own projects. This is his annual report of what he's learned - (1) Product/market fit is magic. (2) You can build a successful business without being available 24/7. (3) Success is more stressful than failure.

featured in #223

How To Become A Better Developer By Asking Questions

- Steve Gordan tl;dr: Don’t fear asking questions." Seeking knowledge is a good thing - it leads to growth. There are no stupid questions but badly formed ones. Ensure the question is concise, you provide context, the person knows exactly what you're asking, and communicate you've done research beforehand.

featured in #222

What I’ve Learned in 45 Years in the Software Industry

tl;dr: Joel Goldberg retired from BTI360 and outlines what he's learnt: (1) Beware of the curse of knowledge (2) Focus on the fundamentals (3) Simplicity (4) Seek first to understand (5) Beware of lock-in (6) Be honest and acknowledge when you don’t fit the role.

featured in #221

Fostering A Culture That Values Stability And Reliability

- Drew DeVault tl;dr: "Software projects can, and often should, draw a finish line. Or, if not a finish line, a curve for gradually backing off on feature introduction, raising the threshold of importance by which a new feature is considered." This creates stability.

featured in #220

My Engineering Axioms

- Martin Rue tl;dr: 25 ideas things Martin has "come to think of as generally true and useful to have in mind when writing code, building things, and working with others" including: (1) Change is constant and how we respond is crucial. (2) Your product is an asset, but code is a liability. (3) Duplication is less costly than premature abstraction.

featured in #219

Recommendations To Write (Slightly More) Readable And (Thus) Robust Code

- Jan Schaumann tl;dr: Jan compiled a list of recommendations for writing readable and robust code after grading his students' work, including (1) "Don't write the damn code in the first place." (2) "Use descriptive variable and function names. You are not charged per character, and vowels don't cost extra."

featured in #219

How To Make Your Code Reviewer Fall In Love With You

- Michael Lynch tl;dr: Many tips, including review your own code first, write a clear changelist description to provide context, conduct your review after your code passes all automated tests, and more.

featured in #218

In Defense Of Blub Studies

- Ben Kuhn tl;dr: The chance to study what goes on in the "guts of boring, everyday systems" - how Git stores data or why pip install failed - is often ignored or circumvented. However, it's helped Ben. It's become easier to track tricky bugs, learn languages and libraries by pattern-matching, improved software design skills and provided confidence in understanding complexity.

featured in #218