• A good engineer never assumes the perfect reliability of the components of the system. He or she builds in redundancy to protect the integrity of the total system.

  • Software engineering is what happens to programming when you add time and other programmers.

  • Engineering is figuring out how to do what you want with what you’ve actually got

  • You can’t guilt yourself into doing things you want to accomplish. You’ll always resist and make excuses. The only way is to enjoy the act of doing them.

  • C programmer’s motto: “Build upon the work of others”

  • "Premature optimization is the root of all evil". This can result in a design that is not as clean as it could have been or code that is incorrect, because the code is complicated by the optimization and the programmer is distracted by optimizing. This applies more broadly than just for code. Abstraction is a form of optimization and shouldn't be done before the space has been properly explored to know what abstractions should be built.

  • Integrity compounds infinitely, and capability always decays.

  • Would I ever leave this company? Look, I'm all about loyalty. In fact, I feel like part of what I'm being paid for here is my loyalty. But if there were somewhere else that valued loyalty more highly, I'm going wherever they value loyalty the most.

  • Typically, the more expensive the product the longer the sales page needs to be.

The steady stream of new issue trackers

I think the reason we see a steady stream of new issue trackers is that teams are trying to fix with software what are people problems.

New issue trackers feel faster for the same reason switching browsers tends to feel faster—you're getting rid of all of the crap you piled up in the old one. Don't migrate your backlog, start with only a couple engineers in a new issue tracker, and suddenly, wow!, this new tool is so much better!

But I don't think it really solves the problem. For most organizations, tracking tickets is a solved (by many products) problem. Starting with a new tool has the appearance of making things better, but leads to the same place. The problem is not the tool, it's the structure of the organization.

Why Learning to Code is So Damn Hard

When you first start learning, the set of things you need to understand is narrow. Everyone, regardless of goals or language or background, needs to figure out what a for loop is, how to build conditional logic, and other basic structures of programming syntax. There ultimately aren't even that many of these fundamental concepts so the Scope of Knowledge during that phase is very narrow.

As soon as you get away from the basics, you see a rapid broadening of the Scope of Knowledge as you need to begin picking up things that are more difficult like understanding errors and when to use the code you know know how to use. This is different because there is no "correct" answer to a clear question... things get fuzzy.

When you progress into the third phase, the scope of knowledge balloons wider. You now need to understand what tools to use, what languages to learn, underlying CS fundamentals, how to write modular code, object-orientation, good style, and how to ask for help (to name just a few). Every trip to Google or Hacker News takes you down another set of rabbit holes and overwhelms you with more things you don't know but feel like you should.

You don't know what you don't know.

Single worst strategic mistake that any software company can make: decide to rewrite the code from scratch

Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We’re not excited by incremental renovation: tinkering, improving, planting flower beds.

There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming: It’s harder to read code than to write it.

It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.

Procrastination is driven by our desire to avoid difficult emotions

Words of warning from a not so young (36) chronic procrastinator with a rather messed up life: Take it seriously. I'm not talking about reading HN in your 7th work hour when doing stupid Excel sheets. I'm talking about messing up years and years of your life. I believe it's a symptom of some deeper issues and it won't go away from alone. Lack of sleep, stress, work overload, information overload amplify the effects but once it crept into your life outside of work it really can wreak havoc. Simple things start to become complicated and you are in a constant negative feedback loop. The worst is that you procrastinate not only work but rather your own existence because you'll constantly attempt to catch up but just can't.

The greatest of all weaknesses is the fear of appearing weak.

Tai viena iš priežasčių, kaip programavimo srityje dažnai apima Impostor sindromas. Vienas iš svarbiausių React kūrėjų straipsnyje rašo:

First, there is often an unrealistic expectation that an experienced engineer knows every technology in their field. Have you seen a “learning roadmap” that consists of a hundred libraries and tools? It’s useful — but intimidating.

What’s more, no matter how experienced you get, you may still find yourself switching between feeling capable, inadequate (“Impostor syndrome”), and overconfident (“Dunning–Kruger effect”).

We can admit our knowledge gaps, may or may not feel like impostors, and still have deeply valuable expertise that takes years of hard work to develop.

I’m aware of my knowledge gaps (at least, some of them). I can fill them in later if I become curious or if I need them for a project. This doesn’t devalue my knowledge and experience. There’s plenty of things that I can do well. For example, learning technologies when I need them.

Law of Software Envelopment

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”

Coined by Jamie Zawinski to express his belief that all truly useful programs experience pressure to evolve into toolkits and application platforms (the mailer thing, he says, is just a side effect of that).