/Career Advice

Should Engineering Managers Be Technical

- Charity Majors tl;dr: "If you want to coach a team, you gotta know the game." Charity wouldn't recommend becoming an EM without 5-7 years engineering experience. You don't have to be the best engineer to be a great manager. The key is to have both social and technical skills.

featured in #225

Why Is It So Hard To See Code From 5 Minutes Ago?

- Austin Henley tl;dr: "Java developers backtracked every 6 minutes, meaning they reverted their code to a previous state." Austin has developed a few years ago as an Atom plugin, letting you swipe through your code history on a timeline.

featured in #225

Tools For Effective Delegation In Engineering Management

- Jason Wong tl;dr: (1) Know what to delegate (2) Identify desired outcomes and restraints and give full business context (3) Remove yourself from the project, but find the right cadence for updates and label your feelings when asked for feedback.

featured in #224

How Hard Should I Push Myself?

- Dan Shipper tl;dr: Stress is a biological reaction to danger. As humans, we're able to induce it at other times, which can be harmful. Ways to combat stress are to increase your sense of control and predictability of a situation, create outlets for frustration e.g. exercise and increase social support.

featured in #224

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