16 Bell-Curve Opinions on Engineering

ipse se nihil scire id unum sciat
He himself thinks he knows one thing, that he knows nothing

There's a meme format that shows a bell curve – the X-axis depicting expertise or intelligence, and the Y-axis the number of people who share that opinion.

It's used to show when beginners and experts share the same opinion (often the simplest one), but one that goes against common practice.

Here are 16 bell-curve opinions on engineering. Disclaimer: I make no claim on what side of the bell curve I'm on for some of these unpopular opinions.

1. You should always use Kubernetes and other "correct" infrastructure.
   Beginners/Experts: Don't Use Kubernetes, Yet. Use the simplest abstraction you need for now.
   

2. Technical debt is bad and should be avoided at all costs.
   Beginners/Experts: Technical debt can be a good tradeoff between time and effort. It's hard to predict future requirements.
   

3. We need to build an internal developer platform that abstracts cloud APIs away from our developers.
   Beginners/Experts: Just use the cloud APIs directly
   

4. First mover advantage is important.
   Beginners/Experts: You can short-circuit the learning curve and avoid costly experiments by copying others.
   

5. Don't repeat yourself
   Beginners/Experts: A little duplication is often better than a little dependency.
   

6. Jupyter Notebooks should be avoided. They aren't reproducible and promote bad practices.
   Beginners/Experts: Highly imperative programming can be useful in the experimental stage. Presentation next to code can shorten iteration cycles.
   

7. Windows is not a good operating system for developers.
   Beginners/Experts: Windows has a great desktop environment, and WSL is good enough for most things.
   

8. You need a database with multiple read and write replicas.
   Beginners/Experts: Sometimes a single sqlite instance is enough for your data.
   

9. Spreadsheets should be replaced by real software.
   Beginners/Experts: Spreadsheets are often more maintainable, more usable, and more extensible than most software projects.
   

10. Single-page applications were a mistake
    Beginners/Experts: Single-page applications solve real issues and state management is hard. Users expect a higher level of reactivity and state management today. The answer is probably in the middle.
    

11. We need a dedicated configuration language to manage our complex configuration.
    Beginners/Experts: Just write your configuration in the same language as your application.
    

12. Every service should be decomposed into micro-services with sharp boundaries.
    Beginners/Experts: Interfaces are fluid: requirements change, knowledge is gained, and dependencies evolve. Start with a monorepo.
    

13. We should write fully declarative configuration.
    Beginners/Experts: Imperative configuration isn't always bad. Pick and choose what needs strong guarantees.
    

14. Optimize everything you can.
    Beginners/Experts: Optimization is fragile. Optionality can be more valuable.
    

15. GitHub stars don't mean anything.
    Beginners/Experts: GitHub stars might be a noisy signal, but they are a signal.
    

16. Pair programming, agile, and rigid frameworks
    Beginners/Experts: Collaborate freely. Don't over-index on the process.