What's your unpopular tech, programming opinion

My unpopular opinion is that computing is stuck in a local maximum based on technology from the 1970s.

In particular, typing into an 80x25 terminal window with unformatted fixed-width characters should be obsolete; we don't need compatibility with punch cards any more. There was a thread a week ago about displaying graphs in your terminal using ASCII graphics. This shouldn't be necessary!

Also, code shouldn't be a sequence of 80-character lines like a deck of punch cards. It makes no sense to carefully organize the order of code in a file for things that don't matter. Chunks should float around and be displayed as sensible, not tied to an arbitrary location in a file. Code should be more like a database than a flat file. (Yes, I know the arguments that flat files are better for tools like grep.) We should get out of the 1970s editor model; Emacs is from 1976 and vi from 1978.

The whole command-line operating system approach is like being stuck in the 1970s, even using the same commands. Yes, small tools composable with pipes are nice, but there must be a better approach. We have powerful graphics, but we're typing into terminal windows that simulate a Teletype.

To summarize my unpopular rant, hardware and I/O is exponentially better than the 1970s, but our programming environment is still stuck with the approaches of the 1970s. Computing needs to get out of this local maximum. For a supposedly fast-moving field, computing changes at a glacial pace.

Docker doesn't actually save time.

The thinking is that with docker you can manage your dependencies in one place, and so you don't need to spend time and headache dealing with issues like incompatible packages.

In reality, you trade that time and headache for the time and headache of dealing with docker: did you mount all the files you needed? Did you start the container with the proper command to enable debugging? How do I attach the debugger to my process inside the docker container? And personally I don't like the extra "state" I have to maintain in my head that I'm in a docker container.

My overall argument is that if the dependencies are so crazy that you're wasting time on conflicting packages, take a hard look at those dependencies and see if you really need all of them, or if you can simplify.

To be absolutely clear, docker is still great for certain use cases. For spinning up new CI machines it's fantastic and really simplifies that process in a meaningful way. But for local dev I think the advantages/disadvantages wash out and makes it either a net zero at best or negative at worst, since that "state" will always be there.

Minority Opinion: Computer security is a solved issue, and most people don't know about the solutions.

We need operating systems that enforce file selection, instead of deferring to the applications. This is known as capability based security, and most people think of "allow access to X" on their phone, which is NOT what I mean.

When you want to open a file, an application shows a system supplied dialog box, then goes ahead and opens whatever the heck it wants with the full trust of the OS, no matter how wrong that is.

All I'm asking for is the OS to handle the file dialog and pass a capability (like a file handle) to the app instead of trusting it blindly.

The downside is that unless there are clever shims, this requires rewriting everything.

---

The reason we have VMs then Docker then Containers is that our Operating Systems don't enforce capability based security, and we've been improvising a replacement for it in this manner.

Minority Opinion: Programming productivity peaked at VB6/Delphi/Microsoft Office 2000.

These tools allowed domain experts to get a GUI tool built in a matter of hours, and for the most part, those solutions just worked.

Microsoft Access 2000 managed tables and relationships automatically. You could have master/detail relationships multiple levels deep and it all just worked. It did queries well enough, hooked to SQL via ODBC, and did pretty good reports.

It was a pretty cool environment when you tied it all together.

- Then Microsoft got obsessed with .NET and Borland got greedy, and ruined it

On the Web side of things, there were WYSIWYG Web editors that worked in much the same fashion, with a whole stack to support it. You could lay out a Form, and have a CRUD app running on the web in short order.

- Then Ruby on Rails came along, and ruined it

The main thing we've gotten in the past decade is faster hardware, especially thanks to SSDs, and GIT. GIT is amazing, but don't be fooled into thinking it actually stores deltas, it just acts like it does. GIT is a snapshot tool, way better than stacks of floppy disks/USB sticks labeled Archive001 -- Date

Don’t rewrite it.

Every time I hear someone wanting to rewrite something without a VERY solid reason is a flag for me. It is hard improving a system that’s already there, but can be super rewarding if you change your mindset.

Everyone is eager to go with a blank canvas and greenfield a project but ultimately we’ll end up with the same shit situation in 5-6 years after the original authors have bounced and the newer devs are side-eyeing the code.

Unpopular opinion: there hasn't been advancements in web app development for the last ~15-20 years. People are creating new tools/frameworks because they can, not because there is an actual need for yet another new shiny thing to build HTML+JS+CSS pages that do CRUD on database rows via HTTP verbs. To put it another way, some people thrive on solving problems that already have solutions with nuanced solutions because its their solution.

- I like data structures and algorithms interviews.

- Writing Rust is generally unpleasant - trying to figure out how to do something that you don’t yet know how to do is much more painful than doing the same in another language.

- Unit tests are overrated.

Software design is subjective. After years of professional work, I cannot stand anymore getting entangled in architecture/design discussions. Any competent software engineer (most of us are) can come with a reasonable working solution to common problems 99% tech companies face. So, it doesn’t matter if you use Date or DateTime, REST or gRPC, Postgres or MySQL, Go or Rust… In a commercial context, good software is software that brings money. Period.

In a more personal context, I do care about software quality… but this only applies to personal projects.

Cloud IDEs are the future. Nobody will run code on their laptop/workstations in 10 years in a professional context.

There's no difference to a business between first-gen infra as code (terraform/cloudformation) and second-gen (CDK/pulumi/etc ...). They both should be replaced by a developer platform that runs in your own cloud

The best tool to build on is something that combines the two with one simple config, like what we're building at withcoherence.com!

My unpopular opinion, which is less unpopular than it used to be, is that object-oriented programming is a bad idea -- in particular, inheritance -- and the Go programming language demonstrates that you can write everything you need without object-oriented programming. I learned in school that a language is "object oriented" if it has inheritance, encapsulation, and polymorphism. Some years ago, I was feeling like giant class libraries were very complex and asked if that complexity is really necessary? And embarked on an experiment to see if I could stop using object-oriented programming and do everything with regular functions. I discovered in short order I needed polymorphism, and that objects were the easiest way to do that. Encapsulation is nice to have. But amazingly, I never came across a scenario where I needed inheritance. Shortly thereafter I discovered the Go programming language, which does not have inheritance at all, though it does have polymorphism (through the inheritance keyword) and encapsulation (via control of exports at package boundaries). It's not just me: powerful software like Kubernetes has been written in Go. The lack of inheritance doesn't get in your way and in fact enables polymorphism to work the way it would in an ideal world. The decision to leave out inheritance was really bold on the part of the Go language designers and it is my favorite "feature" of the language.

The fact that (evidently) you can't have some kind of seamless end-to-end connection between a relational database and "front-end user interface" data display/entry fields, with some kind of uniform/standardized DSL in-between to manipulate & validate, strikes me as totally FUBAR.

* It (usually) doesn't have to be perfect the first time. Programming is an interative process and your first attempt is going to have bugs, or make faulty assumptions about the problem.

* A design which can be generalised is inherently more complicated, and is often unnecessary (you probably won't make use of that generality, leaving you the burden of maintaining it), so you'll be glad you made a simpler first pass.

* I don't like working with docker/containers personally. It makes me feel so far removed from how services are deployed that it's basically magic.

I'm a professional Haskell programmer and have been writing in the language for almost 20 years. It's amazing and I love it.

Nix is the single worst thing that's happened to Haskell development tooling. The last 9 months at my current job have been Nix misery non-stop.

Nix in general is hot garbage.

We hit a local maximum in language design with Common Lisp in the 80's. I mean putting in the hard work to make a language be as powerful as you can imagine.

Today the market moves too fast, priorities have changed, and there seems to less of a willingness to "do the right thing".

Spicy take: Despite the amount of attention paid to code quality, it generally does not matter beyond some (extremely low) baseline. By contrast, data quality (consistency and sensibility of the data model, proper migration of old data to new schemas, alerting around anomalous data) is neglected but vitally important. Adding abstraction will usually improve your code quality metrics, but make it harder to tell where data is coming from, how it is being transformed, and where it is going. Copy/paste/modify will do terrible things to your code quality metrics, but frequently does not make your data flow harder to understand.

As such, abstraction for the purpose of avoiding copy/paste/modify is usually bad. You should just copy/paste/modify, and maybe extract out common functionality if the common functionality is obvious and well-contained.

Epistemic status: I don't fully endorse literally the above take, but it gestures in the direction of my actual opinions if you're starting from the viewpoint "Martin Fowler's Clean Code is approximately correct", which seems to be the majority viewpoint in my circles. As always, take into account the rule that you should probably reverse any advice you hear[1] -- if this take resonates with you, it is unusually likely to be bad advice for you in particular.

[1] https://slatestarcodex.com/2014/03/24/should-you-reverse-any...

Most DevOps technologies and teams are unnecessary. Things like app.logz.io, Prometheus, and Grafana provide no value. In fact I wish I could lay off the majority of our infra team @ every company i've worked, but I don't have that authority.

GitOps (as in ArgoCD style workflows) is not nice. Deploying from code, and storing all infra, etc as code is great, but this pull based approach creates IMHO a really decoupled and inconvenient deployment pipeline.

A lot of the complexity you see in code, tool or project are

Job-Security sub projects. At first you have a bright eyes junior dev who wants to do the right thing, change the world they said.

Little by little he realizes that documenting everything, writing easy to follow and bug free code is a great way to be out of a job.

Complex code is what gets you promoted because you have fire to put out, bugs to fix, getting pulled in meetings where you have to explain the intricate architecture.

While it's valid to say that for most software jobs you won't be having to write tree search algorithms 10 times a day, you'll still need to use the intuition and body of knowledge that solving such problems requires more often than you think, even if it doesn't present itself as a whiteboard trivia problem.

Nobody seems to know what a data diode is, or when one should be used. Quite a few places where you want to monitor a system without being able to control it would benefit from the use of a data diode.

ASICs are cheaper and better than most people believe. Companies are unnecessarily scared of them due to costs associated with the newest processes.

Embedded linux is more trouble than its worth 6.5/10 times

A lot of PCB developrs pretty much refuse to perform proper V&V on their designs because they're allowed to push it off on firmware engineers.

Tabs are not that bad

less "people engineering" and more "technical engineering"

The madness that is overlay networking and other brainfuck networking stacks that are normalized now due to Kubernetes and Docker are horrific. Moving to micro-VMs with each one having it's own unique IP and leveraging basic networking has paid us off in spades.