> a book I would write about software engineering:

You should probably go do that, rather than using the comment section of HN as a scratch pad of your stream of consciousness. That's not useful to anyone other than yourself.

Is this a copypasta you just have laying around?

▲

MisterMower 6 days ago | parent [-]

On the flip side, his commment actually contributes to the conversation, unlike yours. Poorly written? Sure. You can keep scrolling though.

▲

ghurtado 6 days ago | parent | next [-]

> unlike yours

If irony was a ton of bricks, you'd be dead

▲

motorest 6 days ago | parent | prev [-]

> On the flip side, his commment actually contributes to the conversation (...)

Not really. It goes off on a tangent, and frankly I stopped reading the wall of text because it adds nothing of value.

▲

EGreg 6 days ago | parent [-]

How would you know if it adds nothing of value if you stopped reading it? :)

▲

actionfromafar 6 days ago | parent | next [-]

Here let me attach a copy of Wikipedia. Don’t stop reading! :-)

▲

motorest 6 days ago | parent | prev [-]

> How would you know if it adds nothing of value if you stopped reading it? :)

If you write a wall of text where the first pages are inane drivel, what do you think are the odds that the rest of that wall of text suddenly adds readable gems?

Sometimes a turd is just a turd, and you don't need to analyze all of it to know the best thing to do is to flush it.

▲

EGreg 6 days ago | parent [-]

Every sentence there is meaningful. You can go 1 by 1. But yea the formatting should be better!

▲

motorest 6 days ago | parent [-]

> Every sentence there is meaningful.

It really isn't. There is no point to pretend it is, and even less of a point to expect anyone should waste their time with an unreadable and incoherent wall of text.

You decide how you waste your time, and so does everyone else.

	▲	EGreg 6 days ago \| parent [-]
		For a developers to know 1. Set up a local IDE with a full clone of the app (frontend, backend, DB). Thus the app must be fully able to run on a small, local environment, which is true of open source apps but not always for for-profit companies 2. Use .env or similar to manage config/secrets; never commit them. A lot of people don’t properly exclude secrets from version control, leading to catastrophic secret leaks. Also when everyone has their own copy, the developer secrets and credentials aren’t that important. 3. Debuggers and breakpoints are more scalable than console.log. Prefer conditional or version-controlled breakpoints in feature branches. A lot of people don’t use debuggers and breakpoints, instead doing logging. Also they have no idea how to maintain DIFFERENT sets of breakpoints, which you can do by checking the project files into version control, and varying them by branches. 4. Test & Deployment Environments Maintain at least 3 environments: Local (dev), Staging (integration test), Live (production). This is fairly standard advice, but it is best practice, so people can test in local and staging. 5. Make state cloning easy (e.g., DB snapshots or test fixtures). This is not trivial. For example downloading a local copy of a test database, to test your local copy of Facebook with a production-style database. Make it fast, eg by rsync mysql innodb files.