I knew I was going to nod my head in approval before I even landed on Itamar’s website:

Imagine you’re training to become a chef. You will need to learn how to use a knife correctly, to chop and dice safely and quickly.

And yes, you need a sharp knife. But when you’re starting out, it doesn’t matter which knife you use: just pick something sharp and good enough, and move on. After all, the knife is just a tool.

The people eating the food you cook don’t care about which knife you used: they care how the food tastes and looks.

After six months in the kitchen, you’ll start understanding how you personally use a knife, what cuisines you want to pursue, what techniques you want to vary. And then you’ll have the knowledge to pick a specific knife or knives exactly suited to your needs.

But remember: the people eating your food still won’t care which knife you used.

I’ll just leave this right here.

If you’re not careful your manager and teammates will expect you to be available at all hours, on weekends, and when you’re on vacation. Here are some suggestions on setting boundaries so you don’t set those bad expectations.

Itamar Turner-Trauring:

How do you get a programming job with work/life balance when it seems like everyone else is willing to work long hours? By realizing that long hours are the opposite of productive, and that employment is a negotiated relationship.

When you’re looking for a programming job, there are dysfunctional companies you’ll want to avoid. This article will help you recognize one warning sign: a particularly problematic phrase.

Do you love programming for its own sake, or do you just program for the outcomes it enables? Depending on which describes you best you will face different problems in your career as a software developer.

Enthusiasts code out of love. If you’re an enthusiast you’d write software just for fun, but one day you discovered your hobby could also be your career, and now you get paid to do what you love.

Pragmatists may enjoy coding, but they do it for the outcomes. If you’re a pragmatist, you write software because it’s a good career, or for what it enables you to do and build.

Which is your camp and why?

How do you balance delivering on time and the frustration of seeing messy, out-of-date code? In this article you’ll learn a set of heuristics to help you decide when—and why—to cleanup to your code.

This is a must-read for any software engineer wondering how they can move up the ladder without falling pray to the Peter Principle.

Career progress for programmers doesn’t require giving up coding to become a manager. You can get more autonomy—and stronger negotiation leverage—by going from implementer, to problem solver, to problem finder.

I really dig Itamar’s writing style:

It’s time for another deep-dive into Python brokenness and the pain that is POSIX system programming, this time with exciting and not very convincing shark-themed metaphors!

There’s a lot to learn here, and it’s not all Python specific. Hop in, the water’s warm (but filled with sharks)!

200 years ago, John Stuart Mill had a bout of what today we would call burn-out. The lessons he learned are still valuable: he discovered that happiness requires more than just rational, logical thought.

Itamar went deep in the history books to pull out this gem. 💎

“There’s always more work to do” is a common excuse for why programmers need to work long hours. But a little bit of planning and prioritization will do far more to help you ship your product on time—with the features that really matter.

💯 times yes! Everything Itamar is saying in this post aligns with my experience.

Itamar hits the nail on the head:

If you think of yourself as a Python programmer, if you identify yourself as an Emacs user, if you know you’re better than those vim-loving Ruby programmers: you’re doing yourself a disservice. You’re a worse programmer for it, and you’re harming your career.

I’ve been preaching the gospel of generalization for many years. This industry moves fast. Today’s new hotness is tomorrow’s old and busted. Learn specific skills, yes. But always keep yourself above the fray. I am not a Rails Developer. I am not an Elixir Guy. Heck, I don’t even consider myself a web developer. I solve problems; sometimes by writing software.

Back to Itamar:

The technologies you use, the tools you build with, are just that: tools. Learn to use them, and learn to use them well. But always remember that those tools are there to serve you, you are not there to serve your tools.