Category: Programming Tips

Test-Driven Development with Inversion of Control.

Even if you aren’t testing your code, you should write testable code. IoC enables testable code. Inject test-friendly dependencies or mocks at test time, to isolate the unit-under-test.

Avoid mixing Object Creation with Application Logic

Source

Avoid Code Smells

Source

Avoid creating technical debt.

“Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. … A little debt speeds development so long as it is paid back promptly with a rewrite … Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation …” (Emphasis mine)

Source

Premature optimisation is the root of all evil

“Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”

Source

 

“This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface”
– Doug McIlroy
A Quarter Century of Unix [Salus]. Addison-Wesley. 1994.
ISBN 0-201-54777-5.

• Rule of Modularity: Write simple parts connected by clean interfaces.
• Rule of Clarity: Clarity is better than cleverness.
• Rule of Composition: Design programs to be connected to other programs.
• Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
• Rule of Simplicity: Design for simplicity; add complexity only where you must.
• Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
• Rule of Transparency: Design for visibility to make inspection and debugging easier.
• Rule of Robustness: Robustness is the child of transparency and simplicity.
• Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
• Rule of Least Surprise: In interface design, always do the least surprising thing.
• Rule of Silence: When a program has nothing surprising to say, it should say nothing.
• Rule of Repair: When you must fail, fail noisily and as soon as possible.
• Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
• Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
• Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
• Rule of Diversity: Distrust all claims for “one true way”.
• Rule of Extensibility: Design for the future, because it will be here sooner than you think.

– Eric S. Raymond, “The Art of Unix Programming”

 

When I hear “JUST BANG OUT CODE THAT WORKS” I think of all the apps I don’t use anymore because they gradually lost the ability to iterate.

– Avdi Grimm

Source

Don’t do hard things, do easy things.

• Simple is better than complex.
• Complex is better than complicated.
• Flat is better than nested.
• Readability counts.
• If the implementation is hard to explain, it’s a bad idea.
• If the implementation is easy to explain, it may be a good idea.

– The Zen of Python

Source

Shortlist cut from Jack Diederich’s “Stop Writing Classes” talk

Don’t Write Code

Don’t write code (write new code only when everything else fails) is the single most important lesson every developer needs to learn. The amount of duplicate, crappy code (across projects) that exists today is overwhelming. In a lot of cases developers don’t even bother to look around. They just want to write code.

Source

Reducing the amount of code in your product should be a goal.

“I hate code, and I want as little of it as possible in our product.” – Jack Diederich

Source

Keep Lean Dependencies

The old adage “don’t reinvent the wheel” doesn’t apply when the wheel comes attached to a locomotive engine.

Source

Stop Writing Classes

The signature of “this shouldn’t be a class” is when the class has two methods, and one of them is the constructor. Any time you see these signs, you probably should have just written a function.

– Jack Diederich

Source

Reinvent the Wheel

Inventing your own wheels gives you a deep appreciation and understanding of how wheels work and what makes a good one.

Source

Refactoring > Rewriting

Common Excuses For A Software Rewrite

1. The Code Sucks
2. “We’re So Much Smarter Now”
3. We Picked The Wrong Platform/Language

Why Rewriting Is (Almost) Never A Good Idea

1. It Always Takes Longer Than You Expect
2. Markets Change
3. Existing Customers Become Frustrated
4. Refactoring Can Cleanup The Code
5. You Don’t Control The Rewrite, It Controls You

Source

Rewriting > Patching

If you are changing more than 25% of a class or method, consider simply rewriting it. You will write the code more cleanly.

Forget new features, Just do the same stuff better.

The problem: it is too easy to lose sight of what users often care about more, which is the performance and usability of the applications and features they already use most often.

– Tim Anderson

Source

It is much cheaper to do it correctly the first time than to redo it later on. The sooner a problem is identified and fixed, the cheaper it is to do so.

“The general who wins a battle makes many calculations in his temple before the battle is fought. The general who loses a battle makes but few calculations beforehand. Thus do many calculations lead to victory, and few calculations to defeat: how much more no calculation at all! It is by attention to this point that I can foresee who is likely to win or lose.”

“Plans are worthless, planning is invaluable.”- Sir Winston Churchill

For this to work, everyone involved has to listen, everyone has to be open, everyone has to be responsive. Or we could keep flailing away with the fucked up attitude that “it has to be this way” because the sacred project plan says it’s this way. Because that really is a lot of fun, isn’t it?