Photo by Maria Shanina on Unsplash

During these hard times, please remember that human beings are all equal, but not the same.

The Pragmatic Engineer's Developer Culture Test


In my experience, any tech company you'd call decent company should have the 3 basic points nailed, and cover at least 4 out of the 5 points in each area.


  1. Psychological safety and a blameless culture
  2. Fair compensation
  3. Common-sense flexibility on working hours

Clarity, Autonomy and Collaboration

  1. Understanding the "why"
  2. Backlog/roadmap and engineers contributing to it
  3. Direct communication in solving problems
  4. Cross-functional collaboration
  5. Celebrating people taking initiatives

Sustainable Engineering Culture

  1. Distinguishing between functionally complete vs. ready for production
  2. Code reviews and testing
  3. CI and CD or developers deploying to production
  4. Healthy oncall
  5. Internal open source

Career Progression

  1. Technical managers who build trust
  2. Career ladder
  3. Parallel IC & manager tracks
  4. A culture of feedback
  5. Investing in professional growth

What is a software development team?


  • The software they develop needs to be valuable, usable and feasible.
  • There are five properties a team must have in order to be successful in developing working software: empathy, trust, capability, time and feedback.
  • The team needs certain safety levels in order to be honest and productive while working together.
  • Team members need to balance their work with the rest of their lives.
  • Teams have to be empowered to make their own decisions and solve problems.
  • Teams should always be learning.
  • A healthy team is a happy team.

How to Ruin Your Career in 8 Easy Steps


  1. Don't plan ahead
  2. Do the work and wait for recognition to come
  3. All or nothing outlook
  4. Undersell yourself
  5. Who needs a network
  6. Blame others for things you can control
  7. Blame yourself for things you can't control
  8. Get comfortable

Programming is not a goal


STEP 1: Find something you need your computer to do that it doesn't do
STEP 2: Decide some basic details about your goal
STEP 3: Convince yourself that's a possible thing computers can do
STEP 4: Come up with a semi-rational mechanism to implement it
STEP 5: Come up with the most stupid version of the goal you can imagine
STEP 6: sit the fuck down and implement the stupid version
STEP 7: Show the stupid version to someone you respect, and listen
STEP 8: repeat step 5 to 7 with a slightly less stupid version
STEP 9: get help
STEP 10: get stuck

25 ways mindfulness and meditation help in my career as a software developer


  1. Prepare for my day
  2. Helps me manage my stress cycle
  3. Maintain presence in my interactions with others
  4. Makes me a better listener
  5. Recognise when I'm off track
  6. Recognise when I'm in an emotional state that isn't helping me code
  7. Especially frustration!
  8. Have overall better emotional health
  9. Remember to apply "beginner's mind" when I'm stuck
  10. Challenge my own assumptions about a piece of code
  11. Recognise – and deal with – my own inner critic
  12. Take pride in my achievements
  13. Keeps me in tune with my values
  14. Recognise when I'm feeling intimidated by the achievements of others
  15. Know when it's time to step away from the keyboard
  16. Meditation is often when I'm at my most creative
  17. This also helps my learning
  18. I'm less judgemental when I discover confusing code
  19. Appreciate the beauty of a fine piece of code
  20. Decompress at the end of the day
  21. Prevents me from becoming burned out
  22. Helps me recover when I do end up on the burnout spectrum
  23. Be more aware of where on the Flow Cycle
  24. My productivity is generally higher when I meditate
  25. I sleep better

Managing Expectations


  1. Break it down
  2. Write a list
  3. Think about other things you need to do
  4. Add time for research
  5. Ready to work!

Are you Learning, Earning and Advancing?


"In any job I regularly think about whether I'm Learning, Earning and Advancing. I don't stay anywhere if I'm not getting at least two out of three of them."

Rules of thumb for a 1x developer


  1. Rules are good
    Thinking is hard. Making decisions is hard. Having some thought-through rules to guide decision helps us be a bit better.

  2. Most of what I learn is useless outside of its immediate context

  3. Focus "learning time" on things that compound

  4. When to use Java or C#
    Java is ideal for large enterprise applications. I view C# as a the Microsoft spin on Java.

  5. When to use Python or Ruby
    You use them when speed is more important than legibility or debugging. And then Python for ML/AI applications.

  6. When to use a hardcore language
    I would maybe use Go/Rust if I was building a fresh web service where latency and performance were more important than community/library support. Haskell or Erlang maybe I would use if I were doing something that required a very elegant or mathematical functional approach without a lot of business logic. I don't know when I would use Clojure – I thnk it'd be if I really came to know and love Lisp. I know that Clojure is a functional paradigm that compiles to JVM bytecode, but I'd use Kotlin for that. Since Kotlin works with Java and also has nice IntelliJ support. Same deal with Scala – I would take Kotlin first.

  7. How to do Javascript

    • Use Typescript instead. It'll make life saner.
    • Try to push as much logic as possible to the server. If the front end weren't super complex, I would consider something like Phoenix instead which actually pushes everything to the server.
    • Use a framework like Vue or React if you need front interactivity.
    • Don't skip unit tests.
  8. When to use C or C++
    It seems to be useful for applications like robotics and video games and high frequency trading where the performance gains from no garbage collection make it preferable to Java.

  9. Use PHP or Hack if you want to test server changes without rebuilding

  10. When to make a serverless function
    I would use a serverless function when I have a relatively small and simple chunk of code that needs to run every once in a while.

  11. Which database technology to choose
    Choose SQL when you need to do ad hoc queries and/or you need support for ACID and transactions. Otherwise choose no-SQL.

  12. When to write a unit test
    I try to write a unit test any time the expected value of a defect is non-trivial. But every chunk of code should have a trivial unit test around it. I'm not the guy who thinks that every line and branch must be covered.

  13. When to write an integration test
    I try to write an integration test whenever I can't trust the code I don't own

  14. When to write an end-to-end test

    • When I don't fully understand how the product works, and can't fully unit test a change, so I want a way to feel a little better that I didn't break everything. Mostly like a "smoke test."
    • When I need regression test cases to verify functionality in the case of a future refactor.
    • When the results are hard to know ahead of time, for example, doing a complex computation, and I want to test the effects of some code on them.

    Case 1 should be avoided, but 2 and 3 you can't really get around.

  15. When to bring on a dedicated support engineer
    I've come to believe that as a programmer, you should always advocate for having a dedicated SRE if there's any real risk of after-hours pages that are out of your control.

  16. If you delegate all your IT security to the InfoSec, they will come up with draconian rules

  17. Make the design session about input, not approval

  18. Estimates serve more for creating pressure than for project planning

  19. Be explicit about the difference between hard deadlines, soft deadlines, internal deadlines, and expected completion dates

  20. When somebody says Agile, push for Kanban, not Scrum

Thank you for reading, spread positivity!