Introduction

 Once upon a time there was a whole series of interesting books about leaning programming languages that followed the same loose format: a series of related practical tips for using them well and avoiding pitfalls.


This blog is all about Staff+ software engineering and it'll try to follow the same basic format.  Each post will have a concrete tip.  A few things to note:

  • I'll be typing the words here but many of the ideas are from other people.  I'll be linking out to their docs or websites and putting credits wherever I can.  If I miss one then please let me know and I'll fix it.
  • This isn't written by AI, it's just me and a keyboard.
  • This will always be free here.
  • I'm leaving comments off for now as I'm comfortable with this being write-only and don't want to try moderating them.
  • No ads.


For fun, here are a few links to some of the books:

Popular posts from this blog

Influence, part 1 of 4: Communication

What is influence in software engineering? Why is it important? Influence is what happens when it’s not just you any more. One day while you’re blissfully writing code your boss comes to you and says “I need you to lead project MemeShoe. It’s a little complicated, though, as it’s not just our team. It’ll involve these five other teams, who I don’t think you know yet? Oh, and one of them’s in a different office — they’re based in Sydney.” Or, maybe, it’s your idea. This time you’re blissfully coding when genius strikes and you see in front of you a path forward to product excellence, resource savings, and user raptures. But it’s going to need more than just your team. Uncomfortably exciting! Where do you start? Who do you talk to? How do you get them on board with putting Memes on shoes? What are their goals? Do they align with yours? Do the timelines match up? This is important because a single team can only do so much. Background To give some credits first: I'm using some of the s...
Read more