-
- Pay off technical debt as soon as possible. It would be imprudent to do otherwise.
-
- Spending an hour watching users is more informative than spending a day guessing what they want.
-
- Make sure code formatting is part of the build process, so that everybody runs it automatically every time they compile the code.
- Use static code analysis tools to scan the code for unwanted antipatterns. If any are found, break the build.
- Learn to configure those tools so that you can scan for your own, projectspecific antipatterns.
- Do not only measure test coverage, but automatically check the results, too. Again, break the build if test coverage is too low.
-
- Beauty of style and harmony and grace and good rhythm depends on simplicity.
- There are a number of things we strive for in our code:
- Readability
- Maintainability
- Speed of development
- The elusive quality of beauty
-
- The best approach for restructuring starts by taking stock of the existing codebase and the tests written against that code. Avoid the temptation to rewrite everything.This will waste a lot of time, effort, and knowledge gained over the years.
- Many incremental changes are better than one massive change.
- After each development iteration, it is important to ensure that the existing tests pass
- Personal preferences and ego shouldn’t get in the way.
- New technology is an insufficient reason to refactor
- Remember that humans make mistakes
-
- Always leave the campground cleaner than you found it.
-
- There is one inescapable fact: great designs are produced by great designers dedicating themselves to the mastery of their craft. Code is no different
-
- The purpose of code reviews should be to share knowledge and establish common coding guidelines.
- Sharing your code with other programmers enables collective code ownership.
-
- An API should provide an expressive language, which gives the next layer above sufficient vocabulary to ask and answer useful questions. A consistent and well-thought-out API vocabulary makes for expressive and easy-to-understand code in the next layer up
-
- Mixing technical exceptions and business exceptions in the same hierarchy blurs the distinction and confuses the caller about what the method contract is, what conditions it is required to ensure before calling, and what situations it is supposed to handle.
- Separating the cases gives clarity and increases the chances that technical exceptions will be handled by some application framework, while the business domain exceptions actually are considered and handled by the client code.
-
- You do deliberate practice to master the task, not to complete the task
-
- In summary, when writing any text in your code—whether comments, logging, dialogs, or test data—always ask yourself how it will look if it becomes public. It will save some red faces all around.
-
- If you explore new languages to expand your mind and get fresh ideas on how you can solve things in different ways, you will find that the code you write in your trusty old language gets more beautiful for every new language you’ve learned.
-
- When you aren’t actively involved in things, there is an unconscious tendency to assume that they are simple and happen "by magic". While the magic continues to happen, all is well. But when—it is usually "when" and not "if" the magic stops, the project is in trouble.
- You don’t have to understand all the magic that makes your project work, but it doesn’t hurt to understand some of it, or to appreciate someone who understands the bits you don’t.
- Most importantly, make sure that when the magic stops, it can be started again.
-
- "every piece of knowledge must have a single, unambiguous, authoritative representation within a system".
-
- It’s not enough to write tests for an API you develop; you have to write unit tests for code that uses your API.
-
-
A "guru" is simply a smart person with relentless curiosity.
-
We don’t need gurus. We need experts willing to develop other experts in their field. There is room for all of us.
-
-
-
If you are trying to be focused and "productive" for more than 30 hours a week, you are probably working too hard.
-
Avoid embarrassing yourself, and our profession, by behaving like a hamster in a cage spinning the wheel.
-
As a professional programmer, you should know that trying to be focused and “productive” 60 hours a week is not a sensible thing to do.
-
Act like a professional: prepare, effect, observe, reflect, and change.
-
-
- A good bug report needs to convey three things:
- How to reproduce the bug, as precisely as possible, and how often this will make the bug appear
- What should have happened, at least in your opinion
- What actually happened, or at least as much information as you have recorded.
- Remember that a bug is not a standard unit of work any more than a line of code is a precise measurement of effort.
- A good bug report needs to convey three things:
-
- What are you working on right now? Is it all needed?
-
- When you’re designing an application, be mindful of the number of interprocess communications in response to each stimulus.
- When analyzing applications that suffer from poor performance, I have often found IPC-to-stimulus ratios of thousands-to-one. Reducing this ratio, whether by caching or parallelizing or some other technique, will pay off much more than changing data structure choice or tweaking a sorting algorithm.
-
- Keeping the build clean is not just about keeping it free of compilation errors or test failures: warnings are also an important and critical part of code hygiene.
-
- "look under the hood" and understand what your IDE is doing for you. The best way to do that is to learn to use command-line tools.
-
- If you cannot finish, throw away your changes, then define a new task you believe in with the insights you have gained.
- Do speculative experimentation whenever needed, but do not let yourself slip into speculative mode without noticing.
- Do not commit guesswork into your repository.
-
- "The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them."
- Thus, the purpose of estimation is to make proper project management and planning possible, allowing the project stakeholders to make commitments based on realistic targets.
-
- The best way to overcome interim solutions is to make them superfluous, to provide a more elegant and useful solution.
- May you be granted the serenity to accept the things you cannot change, the courage to change the things you can, and the wisdom to know the difference.
-
- Remember that interfaces exist for the convenience of their users, not their implementers.
-
- Lack of visible progress is synonymous with lack of progress.
- It’s best to develop software with plenty of regular visible evidence.
- Visibility gives confidence that progress is genuine and not an illusion, deliberate and not unintentional, repeatable and not accidental.
-
- Instead of using threads and shared memory as our programming model, we can use processes and message passing.
- Process here just means a protected independent state with executing code, not necessarily an operating system process.
- We can go further and introduce dataflow systems as a way of computing.
- In a dataflow system, there is no explicitly programmed control flow. Instead, a directed graph of operators, connected by data paths, is set up and then data is fed into the system.
- Evaluation is controlled by the readiness of data within the system.
- Definitely no synchronization problems.
-
- Used carefully, polymorphism creates tiny localized execution contexts that let us work without the need for verbose if-then-else blocks.
- Being in a context allows us to do the right thing directly, whereas being outside of that context forces us to reconstruct it so that we can then do the right thing.
- With careful use of alternate implementations, we can capture context that can help us produce less code that is more readable.
-
- The rule is simple: Build a single binary that you can identify and promote through all the stages in the release pipeline.
- Hold environment-specific details in the environment.
- This could mean, for example, keeping them in the component container, in a known file, or in the path.
- And one more thing: keep the environment information versioned, too.
-
- Reduce the “truck factor.”
- Solve problems effectively
- Integrate smoothly
- Mitigate interruptions.
- Bring new team members up to speed quickly
-
- Understanding how users think, interpret information, make decisions, and input data will help you debug the interactions between your software and your users.
-
- The single most important trait of a professional programmer is personal responsibility.
- Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their workmanship.
- A professional programmer does not pass that responsibility off on others.
- If you are a professional, then you are responsible for your own career.
- Professionals take responsibility for the code they write.
- Professionals are team players.
- Professionals do not tolerate big bug lists.
- Professionals do not make a mess.
- Professionals are responsible. They take responsibility for their own careers. They take responsibility for making sure their code works properly. They take responsibility for the quality of their workmanship. They do not abandon their principles when deadlines loom. Indeed, when the pressure mounts, professionals hold ever tighter to the disciplines they know are right.
-
- The next time you hit a nasty problem, do yourself a favor. Once you really understand the problem, go do something involving the creative side of your brain—sketch out the problem, listen to some music, or just take a walk outside.
-
- Reinventing the wheel and getting it wrong is more valuable than nailing it first time.
- There are lessons learned from trial and error that have an emotional component to them that reading a technical book alone just cannot deliver!
- Learned facts and book smarts are crucial, but becoming a great programmer is as much about acquiring experience as it is about collecting facts.
- Reinventing the wheel is as important to a developer’s education and skill as weightlifting is to a body builder.
-
- The single-instance requirement is often imagined.Requirements will change. Good design embraces this. Singletons don’t.
- Singletons cause implicit dependencies between conceptually independent units of code
- Singletons also carry implicit persistent state, which again hinders unit testing
- Multithreading introduces further pitfalls to the singleton pattern.
- There is no support for explicitly killing singletons.
- There is no order to the implicit cleanup of singletons at program exit.
-
- The code should be simple. There should be a minimal number of variables, functions, declarations, and other syntactic language necessities.
- Extra lines, extra variables…extra anything, really, should be purged immediately.
-
- Gather together those things that change for the same reason, and separate those things that change for different reasons
-
- Starting from yes means working with your colleagues, not against them.
-
- To be effective, tests need to state contractual obligations rather than parrot implementations.
- They need to take a blackbox view of the units under test, sketching out the interface contracts in executable form. Therefore, align tested behavior with required behavior.
-
- Using concrete examples eliminates accidental complexity and opportunities for accidents. In specifying behavior, tests should not simply be accurate: they must also be precise
-
- State machines are not particularly hard. Visualize them to make them simple to understand and easy to talk about.
- Test-drive your code to unravel valid and invalid states and transitions and to keep them correct.
- Study the State pattern. When you feel comfortable, read up on Design by Contract. It helps you ensure a valid state by validating incoming data and the object itself on entry and exit of each public method.
-
- Single wrongs can be easy to spot and easy to fix. It is the problems with multiple causes, needing multiple changes, that are harder to resolve.
- There is no simple advice for how to address faults arising from sympathetic defects.
-
- It is not about the code, the artifact. It is about the act of creating that artifact. The next person that touches your code, in whatever way, will be a better person and a better developer.
- Zen is about the individual. Ubuntu is about Zen for a group of people. Very, very rarely do we create code for ourselves alone.
-
- A cluttered log is an indication that the system will be hard to control once it reaches production.
- If you don’t expect anything to show up in the error log, it will be much easier to know what to do when something does show up.
-
- The antithesis of DRY is WET (Write Every Time).
- Our code is WET when knowledge is codified in several different implementations.
- The performance implications of DRY versus WET become very clear when you consider their numerous effects on a performance profile.
-
- The code you wrote many years ago still influences your career, whether you like it or not.
- You leave a trail of your knowledge, attitude, tenacity, professionalism, level of commitment, and degree of enjoyment with every method, class, and module you design and write.
- Take care of your career, of your clients, and of your users with every line of code you write.
-
- Using domain-inspired types can often make our functions much smaller. One way to find out what those types should be is to find the examples to check in problem domain terms, before writing the function.
-
- Good tests act as documentation for the code they are testing. They describe how the code works. For each usage scenario, the test(s):
- Describe the context, starting point, or preconditions that must be satisfied
- Illustrate how the software is invoked
- Describe the expected results or postconditions to be verified
- Good tests act as documentation for the code they are testing. They describe how the code works. For each usage scenario, the test(s):
-
- The real difference between adequate programmers and great programmers is attitude.
-
- Just interact with them more.
-
Read the book. A summary is never enough
Last active
November 27, 2023 22:16
-
-
Save jonnyjava/caaae696ab35deb4403b1555e41a6a6a to your computer and use it in GitHub Desktop.
97 Things Every Programmer Should Know: Collective Wisdom from the Experts
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment