Programming Wisdom

Working software > comprehensive documentation.

The best way to predict the future is to invent it.

Simple things should be simple, complex things should be possible.

Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.

The computer revolution hasn't started yet.

Perspective is worth 80 IQ points.

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Controlling complexity is the essence of computer programming.

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.

Do one thing and do it well.

It's OK to figure out murder mysteries, but you shouldn't need to figure out code. You should be able to read it.

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

The Principle of Proximity: Keep related actions together.

Managing complexity is the most important technical topic in software development.

Good code is its own best documentation. As you're about to add a comment, ask yourself, "How can I improve the code so that this comment isn't needed?"

The cheapest and fastest way to find a defect is at the point when it is created.

A working program is not sufficient. It must be readable and understandable.

When you start coding, the design should be as complete and as error-free as you can make it.

Code should be written for humans first, computers second.

Code comments should explain WHY, not WHAT. The code itself explains what.

If you need to add a comment explaining your code, consider if the code could be clearer instead.

Delete code > Write code > Refactor code.

Things I don't know: many computer science concepts, algorithms, functional programming, assembly, etc. You don't need to know everything.

Don't compare your inside to someone else's outside.

The best way to learn something is to build something with it.

Every popular library started as someone's side project.

You don't need to know everything to be productive. Focus on what you need to solve the problem at hand.

Convention over configuration.

Optimize for programmer happiness.

The best way to predict the future is to implement it.

You don't have to work 80 hours a week to build a successful business or create great software.

Fast software, the best software, is software that does less.

The majestic monolith can do most things you want to do, and do it simpler.

The heart of software is its ability to solve domain-related problems for its user.

Model the domain, not the database.

Use the language of the domain in your code. If you can't say it in the domain language, you probably shouldn't be building it.

Make implicit concepts explicit.

The ubiquitous language is the foundation of domain-driven design.

Bounded contexts are a central pattern in DDD. They define the limits of a model and keep it internally consistent.

Premature optimization is the root of all evil.

Beware of bugs in the above code; I have only proved it correct, not tried it.

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times.

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.

Science is what we understand well enough to explain to a computer. Art is everything else we do.

Programs are meant to be read by humans and only incidentally for computers to execute.

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

Companies want to hire senior engineers but treat them like junior engineers.

Experience gets you a higher salary, not respect. You still have to earn respect.

The best way to get a raise is to switch jobs. Company loyalty is a one-way street.

Being right is not enough. You need to be persuasive.

Your manager is not your friend. They can be friendly, but their job is to make the company successful, not you.

Performance reviews are not about performance. They're about justifying your salary.

Nobody cares about your elegant solution. They care if it works and ships on time.

The most valuable skill is knowing when to say "no" and when to say "yes."

Politics is part of the job. Learn it or suffer.

Your job will replace you in a week. Your family won't.

The code you wrote 6 months ago was written by a different person. Document everything.

Production is the only environment that matters. Staging is a lie.

Never deploy on Friday unless you want to work the weekend.

Technical debt is like financial debt - a little is useful, too much will kill you.

The best engineers are lazy. They automate everything and find the easiest solution.

Meetings are where productivity goes to die. Make them short or don't have them.

Your estimates will always be wrong. Double them, then add 20%.

The last 10% of any project takes 90% of the time.

Burnout is real and it sneaks up on you. Take your vacation days.

The person who wrote the terrible code you're fixing was probably doing their best at the time.

Walking on water and developing software from a specification are easy if both are frozen.

Program to an interface, not an implementation.

Favor object composition over class inheritance.

Design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.

Consider what should be variable in your design. This approach is the opposite of focusing on what will cause redesign.

Encapsulate the concept that varies.

Design patterns help you choose design alternatives that make a system reusable and avoid alternatives that compromise reusability.

The cheapest, fastest, and most reliable components are those that aren't there.

It's easier to ask forgiveness than it is to get permission.

The most dangerous phrase in the language is: "We've always done it this way."

Humans are allergic to change. They love to say, "We've always done it this way." I try to fight that.

If it's a good idea, go ahead and do it. It's much easier to apologize than it is to get permission.

Leadership is a two-way street, loyalty up and loyalty down. Respect for one's superiors; care for one's crew.

Complexity is the apex predator of developers. Complexity very, very bad.

The best weapon against complexity is the magic word: "no".

Don't factor your code too early. Wait for good cut-points to emerge naturally.

Good cut points have narrow interfaces that trap complexity like a demon in a crystal.

When in doubt, use the 80/20 rule: build 80% of the value with 20% of the code.

Sometimes the best thing you can do is not tell the project manager and build the simple solution anyway.

Write tests after the prototype phase when code has firmed up, not before you understand the domain.

Integration tests are the sweet spot: high-level enough to test correctness, low-level enough to debug easily.

Unit tests break as implementation changes. Don't get too attached to them.

End-to-end tests show the system works but drive you crazy when they break. Use sparingly.

"Test first" is fine, but "test along the way" works pretty well too.

"Yes" is the magic word for more shiny rocks and getting put in charge. "No" keeps you sane.

Learn to say "no" early. It gets easier over time, even if the shiny rock pile isn't as high.

How many shiny rocks does grug really need anyway?

Senior developers should be willing to say publicly: "This is too complex for me." It gives juniors permission to admit confusion too.

Fear Of Looking Dumb (FOLD) is a major source of the complexity demon's power. Take that power away.

Big brain developers have big brain! Need only be harnessed for good.

Call early versions "prototype". Sounds fancier to project manager.

If senior dev says code is too complex and confuse, it ok for junior dev to admit too!

Recursive descent is the most fun and beautiful way to create a parser. Ignore parser generators.

Parser generator tools generate awful snakes nest code. Impossible to understand or debug.

Parsing is not big brain only magic. So can you!

Demand working demo tomorrow. Forces big brain to see reality on ground more quickly.

As all sane developers know: fear concurrency. Keep it simple with stateless handlers.

Good APIs don't make you think too much. Bad APIs require you to understand implementation details.

Layer your APIs: simple api for simple cases, complex API for complex cases.

Put common operations on the object itself, not hidden behind abstractions.

Nobody cares about your clever abstraction. They just want to filter a list.

Splitting front-end and back-end means you now have TWO complexity demon lairs.

Front-end complexity demon is more powerful than back-end demon and has deep spiritual hold on entire industry.

Not every website needs to be a SPA with GraphQL talking over HTTP.

Keep it simple: HTML and minimal JavaScript. Avoid becoming an acolyte of the complexity demon.

React is good for jobs, but you become an acolyte of complexity demon whether you like it or not.

Lots of fads in front-end development. Take revolutionary new approaches with grain of salt.

Nobody is an impostor if everybody is an impostor. It's the nature of programming.

Grug is always in one of two states: ruler of all survey OR no idea what doing. Mostly the latter.

Even experienced developers feel like impostors. You'll do fine anyway.

Make thinking face and look big-brained when admitting confusion. Then use sense of humor.

Be strong! No Fear Of Looking Dumb!

Club not work on complexity demon. Also bad idea to hit developer who let spirit in, sometimes yourself!

Logging is more important than most developers think. Should be taught more in schools.

Print statements are better debugger than actual debugger 80% of the time.

Make log level dynamically controlled. Even better: make it per-user.

Include request ID in all logs if request spans multiple machines.

Worth investing time in getting logging infrastructure "just right". Pays off big later.

Debugger is good for when code not even run. Otherwise log statements usually better.

Always have concrete, real-world perf profile before optimizing. You'll often be surprised!

Don't only focus on CPU. Network hits cost millions of CPU cycles.

Inexperienced devs see nested loops and panic about O(n²). Complexity demon smiles.

Minimize network calls if possible. Much bigger impact than that nested loop you're worried about.

The goal of software is not working software. The goal is to solve problems.

Software development is a learning process. Working code is a side effect.

The system is not the code. The system is the people plus the code plus the runtime environment plus the deployment plus everything.

Symmathesy: learning together. Teams that learn together, succeed together.

When you automate something, you don't eliminate the work. You change where it happens.

Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it.

The cost of adding a feature isn't just the time it takes to code it. The cost also includes the addition of an obstacle to future expansion.

It is not that uncommon for the cost of an abstraction to outweigh the benefit it delivers.

Low-level programming is good for the programmer's soul.

If you aren't sure how something should work, code it both ways and see which is better.

First, solve the problem. Then, write the code.

Sometimes the best way to solve a problem is to stop participating in the problem.

Configuration is code. Treat it like code.

The best place to store secrets is in your head. The second best place is a secrets manager.

Kubernetes is a platform for building platforms. It's a better place to start, not the endgame.

If you can't explain something simply, you don't understand it well enough.

Make it work. Make it right. Make it fast. In that order.

I'm not a great programmer; I'm just a good programmer with great habits.

Optimism is an occupational hazard of programming: feedback is the treatment.

For each desired change, make the change easy (warning: this may be hard), then make the easy change.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

I'm not a great programmer, I'm just a good programmer with great habits.

Talk is cheap. Show me the code.

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.

I'm a huge proponent of designing your code around the data, rather than the other way around.

If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

Intelligence is the ability to avoid doing work, yet getting the work done.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.

I'm not a great programmer; I'm just a good programmer with great habits.

Before you start refactoring, check that you have a solid suite of tests. These tests must be self-checking.

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

The true test of good code is how easy it is to change it.

There are only two hard things in Computer Science: cache invalidation and naming things.

If you're not embarrassed by your first release, you waited too long.

Simple is not easy. Simple means one thing, not multiple things braided together.

Programmers know the benefits of everything and the tradeoffs of nothing.

We can make the same exact software we are making today with dramatically less complexity.

Simplicity is prerequisite for reliability.

If you want everything to be familiar, you will never learn anything new.

State is never simple. It is the new spaghetti code.

Free software is a matter of liberty, not price. To understand the concept, you should think of "free" as in "free speech," not as in "free beer."

Sharing is good, and with digital technology, sharing is easy.

Software is like sex: it's better when it's free.

If programmers deserve to be rewarded for creating innovative programs, by the same token they deserve to be punished if they restrict the use of these programs.

Proprietary software keeps users divided and helpless.

Clean code is simple and direct. Clean code reads like well-written prose.

The ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code.

Truth can only be found in one place: the code.

You should name a variable using the same care with which you name a first-born child.

A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment.

Functions should do one thing. They should do it well. They should do it only.

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

Master programmers think of systems as stories to be told rather than programs to be written.

Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code.

It is not enough for code to work.

Professional developers are responsible for their own career, and for their own skills.

Test code is just as important as production code. It is not a second-class citizen.

Duplication is far cheaper than the wrong abstraction.

Prefer duplication over the wrong abstraction.

The trick to getting the most value from an abstraction is to recognize when you have the wrong one.

Your code should be SOLID: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion.

Make the change easy, then make the easy change.

The code you write should be transparent, reasonable, usable, and exemplary (TRUE).

Don't live with broken windows. Fix bad designs, wrong decisions, and poor code when you see them.

DRY: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Good design is easier to change than bad design.

There are no final decisions. Be ready to change course.

Prototype to learn. Prototyping is a learning experience. Its value lies not in the code produced, but in the lessons learned.

Estimate to avoid surprises. Iterate the schedule with the code.

You can't write perfect software. Accept it as an axiom of life.

Design with contracts. Use assertions to prevent the impossible.

Crash early. A dead program normally does a lot less damage than a crippled one.

Use exceptions for exceptional problems. Exceptions can suffer from all the readability and maintainability problems of classic spaghetti code.

Don't program by coincidence. Rely only on reliable things. Beware of accidental complexity.

Test your software, or your users will.

Legacy code is code without tests.

The best time to refactor is before you need to add a new feature.

When you break dependencies in legacy code, you often have to suspend your sense of aesthetics a bit.

To me, legacy code is simply code without tests.

The key to working effectively with legacy code is to understand what you need to change, and to understand the risks involved.

If you want to make a change, you need to be able to understand the code first.