Hacker News Reader

Comment by skeeter2020 | Hacker News Reader

skeeter2020

This opinion piece paints a pretty limited perspective as the defacto state, which I don't think is really true. From my perspective programming (in the vast majority of situations) is neither engineering nor computer science. The creations are not particularly complex, at least not in their initial manifestations where something like formal verification would help. Even the assembly patterns are not unique; the differences can only be determined by actually some form of build-test cycle. There are a lot more non-traditional developers in the world, by which I mean not comp sci or engineering (or uni) grads, which is maybe what the author interprets as "YOLO". I think that on the whole this is a really good thing, and even as a formally trained student in the area don't agree we're in some sort engineering desert because of the academics that came before us.

View on HN

There's also this cycle of complexity most programmers go through.

For example, I remember when I was told patterns were important, the time I put in memorizing, implementing and reviewing all these patterns, reading GoF, etc... Now, I'd just like something that works. Patterns are great for recognizing how code is intended to function, but tests are still the only way to verify the implementation of nontrivial code. And the smaller each contained unit of logic is, the more testable. So modularity and sensible, predictable interfaces are all you need.

I used to overengineer a lot more in my younger days. Now I'm just smarter about writing extensible code up front and improving it as I go.

There’s a percentage of young developers who, right after learning to program, lean hard into patterns and GoF. You end up with architecture astronaut code pretty quickly. Some of these programmers are still unskilled and they are just adding a ton of complexity to a codebase that doesn’t even work yet.

That said, I think the GoF stuff is mostly “stuff that works”, but…

1. A lot of it is specific to the language, or certain languages, and

2. Most of the patterns are useful only rarely.

But there are exceptions. We’re just blind to them. We use the Command pattern for UI programs because it’s a sane way to implement undo/redo. We use the Factory pattern all over the place. YMMV.

The mistake these young developers make is that they use “does this use patterns?” as a proxy for “is this good code?”

I was tech lead on a team with a guy like this. We sat down and had a long discussion and whiteboard sesh about a piece of code that could/should have been about 500 lines of code in half a dozen files. Walked out of it thinking that he understood the assignment and I should just step back and let him code it up.

He came back a week later with something that was about 20k lines of Node.js, all just abstraction piled on abstraction piled on indirection, hundreds of files with like one line of code in each one plus a bunch of imports. "Separation of concerns" taken to the far extreme. 100% statement coverage by the horrible kinds of unit tests that you have to write to get 100% coverage.

TBH I feel lucky I came out of that episode with my job, and it wasn't even my code!

>but tests are still the only way to verify the implementation of nontrivial code

But who tests your tests?

Your actual test cases would be review for suitability and coverage of the change. ( that's how we worked in my company, If our software had failed , damage could be in the millions - a lot less than Crowdstrike )

the mutation tester

> The creations are not particularly complex, at least not in their initial manifestations where something like formal verification would help. Even the assembly patterns are not unique

Utility shafts and traffic lights are not particularly complex either, and are built using off the shelf parts. Nonetheless they make up the daily work of tens of thousands of civil engineers, and what they are doing is engineering.

It's engineering because at its core it is a practice of tradeoffs. Building the strongest possible bridge for the sake of it is research or maybe art, building a strong enough bridge within budget is engineering.

Applying known solutions to familiar problems is engineering, whether the project is a retention basin or a payment system.

To construct a building an engineer or architect may be involved but a carpenter is always required. Sometimes our software is a large public building and sometimes our software is a shed in the dooryard. It is important to know the difference.

Reply on news.ycombinator.com