preface

Hello, I’m googoo (I’m the king of pigeons), long time no see.

Our company has been on holiday for the Chinese New Year recently, so I can’t help wandering around some “strange” websites at home. Through ruan Yifeng’s weekly news, I found a relatively good English article.

I agree with most of the views inside, and I have made a more down-to-earth translation here to share with you.

The body of the

After six years in the software industry, some of my ideas about the software industry have changed.

Here are some of the things I used to be conflicted about, but now believe:

  1. When you work on a team with a large number of developers at different levels of development, using a strongly typed language is obviously more appropriate.
  1. Stand-up meetings (standing meetings in Agile development) can be very useful for following up on the progress of new members of the team.
  1. Iterative review sessions in Agile development make sense if they are designed to correct the mistakes of previous iterations (such as “That was stupid! Rather than waste everyone’s time under the dogma of some ‘agile guru’.
  1. Software architecture is more important than anything else. A good abstraction, even when implemented, does very little harm to the code. But without a good abstraction, even if the implementation is beautiful, it’s crap and does a lot of damage to the code.
  1. Java isn’t that bad after all.
  1. Showy code is usually not good code, and a clean code is better than any code.
  1. You have no idea how weird junk code can be.
  1. The so-called “Best practice” usually has a specific context and does not have wide applicability. Blindly following them makes you a fool.
  1. Trying to design highly scalable systems when you don’t need them makes you a bad engineer.
  1. Code static analysis is useful.
  1. DRY (Don’t Repeat Yourself) Don’t build wheels: Usually used to avoid a specific problem rather than as an end goal, so Don’t blindly pursue without repetition.
  1. In general, RDBMS (relational databases) are superior to NoSql (specifically, non-relational databases).
  1. Functional programming is just another programming technique, not a panacea.

Here’s what I’ve learned and endorsed along the way:

  1. First, YAGNI (don’t add new code unless necessary), second, SOLID (object-oriented design), third, DRY (Don’t duplicate the wheel), write code according to this priority.
  1. Pencil and paper are the best programming tools, and they’re used a lot.
  1. Trading purity for utility is often a good choice.
  1. Adding more technical frameworks to a project is usually not a good option.
  1. Talking directly to customers always exposes more software problems with greater accuracy in less time.
  1. The word “scalability” has a mysterious and startling power in the minds of software engineers. This one sentence alone can make them tired.
  1. Despite being called “engineers” by outsiders, most developers make decisions based on personal preference or “mood” without data to back them up.
  1. Ninety or even ninety-three percent of the project managers could disappear tomorrow with no impact or even productivity gains. (Translator’s Note: I don’t know what I mean.)
  1. After more than 100 interviews, I still have no idea how to make them better. (Translator’s Note: It’s hard to really see a person’s level of development in an interview)

Here are my views that have remained constant through the years:

  1. People who overemphasize code style, rules, or other details are extremists and pointless.
  1. Code coverage does nothing to improve code quality.
  1. In most cases, large applications (Monoliths) work well and don’t necessarily have to be broken down into very complex microservices.
  1. Mindless believers in TDD (Test Driven Development) are the worst, their fragile little minds unable to handle the presence of different workflows.
  1. In 10 years, let’s see if those views have changed.

The original English

Software development topics I’ve changed my mind on after 6 years in the industry.

Things I now believe, which past me would’ve squabbled with:

  • Typed languages are better when you’re working on a team of people with various experience levels
  • Standups are actually useful for keeping an eye on the newbies.
  • Sprint retrospectives have their place so long as they’re for actual course correction (i.e. “holy shit, that went poorly!” ) and not some god awful ‘agile’ / ‘scum master’ driven waste of everyone’s time
  • Software architecture probably matters more than anything else. A shitty implementation of a good abstraction causes no net harm to the code base. A bad abstraction or missing layer causes everything to rot.
  • Java isn’t that terrible of a language.
  • Clever code isn’t usually good code. Clarity trumps all other concerns.
  • Bad code can be written in any paradigm
  • So called “best practices” are contextual and not broadly applicable. Blindly following them makes you an idiot
  • Designing scalable systems when you don’t need to makes you a bad engineer.
  • Static analysis is useful

DRY is about avoiding a specific problem, not an end goal unto itself. In general, RDBMS > NoSql Functional programming is another tool, not a panacea.

Opinions I’ve picked up along the way

  • YAGNI, SOLID, DRY. In that order.
  • Pencil and paper are the best programming tools and vastly under used
  • Trading purity in exchange for practicality is usually a good call
  • Adding more technology is rarely a good call
  • Talking directly to the customer always reveals more about the problem, in less time, and with higher accuracy
  • The word “scalable” has a mystical and stupefying power over the mind of the software engineer. Its mere utterance can whip them into a depraved frenzy. Grim actions have been justified using this word
  • Despite being called “engineers,” most decision are pure cargo-cult with no backing analysis, data, or numbers
  • 90% — Maybe 93% — of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency.
  • After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better.

Old opinions unchanged:

  • People who stress over code style, linting rules, or other minutia are insane weirdos
  • Code coverage has absolutely nothing to do with code quality
  • Monoliths are pretty good in most circumstances
  • TDD purists are just the worst. Their frail little minds can’t process the existence of different workflows.

We’ll see which of these have flipped or changed at year 10.

Small tail

Before also translated a more classic foreign language article, interested friends can look back at the previous article:

Easy-to-understand Web application architecture in production environment

reference

Chriskiehl.com/article/tho…

Pay attention to my

I am an Internet backend development engineer struggling in the front line.

Focus on back-end development, data security, edge computing and other directions, welcome to exchange.

I can be found on every platform

  • Wechat official account: A ramble on back-end technology
  • Making:@qqxx6661
  • CSDN: @Pretty three knives
  • Zhihu: @ Ramble on back-end technology
  • Nuggets: @ pretty three knife knife
  • Tencent Cloud + community: @ Back-end technology ramble
  • Blog Garden: @ Back-end Technology Ramblings
  • BiliBili: @Pretty three knives

Original article main content

  • Back-end development practices
  • Back-end technical interviews
  • Algorithm problem solving/data structure/design pattern
  • Life is interesting

Personal public account: Back-end technology ramble

If the article is helpful to you, please give me a thumbs-up and support. Your thumbs-up and reading is my motivation to update