hyperbolic exaggeration or plain ignorance
What popular tech advice you wish you didn't follow?
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.
The display could be more like a smart word processor, where you can format code however you want. (A feature that the Xerox Alto provided.) You should be able to stick images in your code to describe things, rather than creating ASCII graphics. Tabs vs spaces shouldn't even exist.
And now we're created libraries and packages.
Not to mention that sometimes a database gets too big and performance goes down, so maybe we want to split it up or shard it or something. And I haven't even mentioned all the database types out there, relational, document, graph, time-series...
page 4 https://www.google.com/books/edition/Mastering_ENVY_Develope...
Programs written using the Win32 GUI and forms still work decades later. Its a shame there isn't an equivalent in the Linux world.
---
We should have rich source text by now. You should be able to freely time comments, include notes, links, images, etc. in the source code of a program, and still have it compile correctly.
---
We should be able to directly modify the Abstract Syntax Tree of programs, renaming as it is stored in the tree would cause it to correctly change the name of every use with zero errors. Refactoring this way would be much faster and more reliable.
1: https://www.youtube.com/watch?v=8Ab3ArE8W3s&t=1012s (link jumps to 16:52)
Counterpoint: 80 chars is too short for writability. You need to make arbitrary splits and refactors all the time and it ends up hurting readability.
120 is a better sweet spot to strive for in my opinion.
- rise of autoformatters
- language servers decoupling editing from editors
- all in one build tools (cargo, go)
This might be case of happens slowly then all at once.
It's not an insane jump from LSPs to new editor UIs and since the code is formatted on save, people care less about the minutiae of 80 char lines.
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.
Some new dev with no understanding of how bare metal OS operates will be stuck within the limits of docker.
Like a goat who spent all it's life inside a fenced yard.
That's a good way to put it, I like it.
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.
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
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.
With this said, I know I just made a few extra enemies.
I will counter my own unpopular opinion in that many of the newer ways are better or easier to use (if I used postgres this looks interesting) but as an industry we certainly don't need the countless variations that are out there.
- 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.
In a more personal context, I do care about software quality… but this only applies to personal projects.
Can't risk working with old-timey tech. Gotta keep up with the fashion and the trends, because the industry encourages RDD
Resume Driven Development
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!
People adore constructing <inputs> and writing @get("/users") and users.objects.findById(req.params.id).
I'm tempted to say that many people out there are not programmers, but boilerplate code janitors.
* 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.
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.
Today the market moves too fast, priorities have changed, and there seems to less of a willingness to "do the right thing".
My assumption is that, nobody knew there would be that much cash involved in this industry.
It's about making the most money the fastest way possible.
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...
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.
This may work to keep your current job, but should you need to find another job for any reason, how will you sell yourself to the next company, other than trying to bullshit your way in?
“I worked on this project, I did the right things, wrote all the documentation, there were no bugs, etc” Everyone will say that, how is an interviewer going to tell who’s honest and who isn’t ?
The things that make the difference between an ok and great engineer are things that never get published along with the product.
They might filter out some exceptional candidate and let in some regurgitator.
But I agree of you can grasp those fundamental concepts you're a great programmer.
Some of these concept became clearer, years after college
I agree, but I think the widely accepted thought of "it's gatekeeping and shouldn't be interview-whiteboard trivia for most roles" sometimes gets extended to an attitude of "you'll never need this stuff"
>They might filter out some exceptional candidate and let in some regurgitator.
hah, we think alike, had the same scenario when I detailed this answer:
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.
Like no offense to other engineers but if people who call themselves engineers can’t understand new systems within a week of joining a team they should probably find other work.
I’ve worked on dozens of teams and projects and with the exception of a few where everyone was S tier (the best team experience let’s be real) the rest were mediocre people who somehow were able to spend more time coming up awful implementations (that waste everyone’s time) to get a promotion rather than actually doing their job. Over time nobody maintains these things or people naturally stop using these approaches because they suck, and the problem starts again because some new joker joins and shoots their shot.
It’s hard to describe unless you’ve been on the receiving end of it, but it’s pretty common at larger companies.