/Career Advice

Using A Dev Diary Seems To Be Worthwhile

- Mike Hogan tl;dr: “An experiment for devs to try. I started keeping a "dev diary". It was prompted by a statement by Stuart Ervine when I asked how others keep broader context of decisions behind code that are not visible in code, tests or comments. He said that at Apple, developers on teams keep diaries, and each team member can browser what others are thinking.” Mike shares his diary. 

featured in #519

How Does AI Impact My Job As A Programmer?

- Chelsea Troy tl;dr: “It’s how human programmers, increasingly, add value. Figure out why the code we already have isn’t doing the thing, or is doing the weird thing, and how to bring the code more into line with the things we want it to do. Chelsea argues that this “conveniently comprises most of the job these days: read code. Analyze it. Understand it. Repair it.”

featured in #519

Three Laws Of Software Complexity

- Mahesh Balakrishnan tl;dr: Mahesh discusses the implication of each: (1) A well-designed system will degrade into a badly designed system over time. (2) Complexity is a moat filled by leaky abstractions. (3) There is no fundamental upper limit on software complexity. 

featured in #519

Three Laws Of Software Complexity

- Mahesh Balakrishnan tl;dr: Mahesh discusses the implication of each: (1) A well-designed system will degrade into a badly designed system over time. (2) Complexity is a moat filled by leaky abstractions. (3) There is no fundamental upper limit on software complexity. 

featured in #518

How To Read Error Messages

- Simon Tatham tl;dr: “There’s a lot of juice to be squeezed out of error messages if you know what to look for. It’s worth learning the skill of extracting all the detailed information you can. That gives you a head start on debugging problems yourself, and a better chance of writing a good bug report for somebody else – and perhaps even a better chance of deciding which of those things to do. In this article, I’ll try to give an overview of the kind of things you can tell from the details of an error message – right down to things as trivial as the punctuation.”

featured in #518

Separation

- Jason Fried tl;dr: “In my experience, a key skill to develop is the ability to separate one thing from another. To prevent the small from becoming the all... Developing the ability to tease things apart helps you compartmentalize the less desirable from the more desirable, and see the whole map, with all its separate states of like and dislike, favorable and unfavorable. There’s a very good chance that when you do that, you’ll like a lot more than you despise.”

featured in #516

SWE Laws Of Power

- Eliran Turgeman tl;dr: “Have you ever noticed how some software engineers seem to rocket up the career ladder, while others, just as talented, barely move? It’s not always about how good you are with code; sometimes, it’s about playing the game smartly. This got me thinking when I was reading “The 48 Laws of Power.” I chose the 5 laws that I think are most relevant and impactful for software engineers.” (1) Never outshine the master. (2) Concentrate your forces. (3) Win through your actions, never through argument. (4) Make your accomplishments seem effortless. (5) Always say less than necessary. 

featured in #514

Communicate Like A Senior: Use Clear Deltas

- Jordan Cutler tl;dr: Communicate using quantified before and after states and see the benefits in performance reviews, influence, and clear expectations. Jordan shares explicit examples of how to put this into practice.

featured in #514

Programming Mantras Are Proverbs

- Luke Plant tl;dr: “I believe that many of the arguments we have around software development practices could be avoided by the simple understanding that all of our mantras need to be understood as proverbs and not laws. If you understand proverbs, then you’ll know that every proverb has an equal and opposite proverb.”

featured in #514

How To Understand Things

- Nabeel Qureshi tl;dr: “The smartest person I’ve ever known had a habit that, as a teenager, I found striking. After he’d prove a theorem, or solve a problem, he’d go back and continue thinking about the problem and try to figure out different proofs of the same thing. Sometimes he’d spend hours on a problem he’d already solved.” 

featured in #514