321–330 of 364 posts
I'm talking about things like sign-up workflows, password recovery, two-factor authentication, role-based access control, search, approvals by manager, integration with BI tools etc.
There are application development frameworks that solve some of these problems for you, but they tend to be so heavy-weight and/or impose so many restrictions on you that they hardly seem worth using.
I think making software human-understandable (and by extension modifiable) is one of the biggest problems for software engineering. As it stands, both beginners and experts have difficulties understanding exactly what their own programs are doing as well as what programs written by other people are doing. We encode complex algorithms in static, abstract text descriptions that are hard for humans to understand and rea…
What matters most is what you want to still be there when the power goes off: data. No amount of processing power matters if you don't have the data. Everyone in the industry focuses too much on the processing side: objects, functions, containers, VMs, k8s, etc. but nobody really gives proper attention to data, its provenance, where it stays and where it goes, etc. I'm not saying engineers don't think about these thi…
The problems around data are in general harder to address than the processing part. Most people dabbling in software engineering don't have the skills or attention span to work on those, and most of the issues are already solved by extremely complicated systems (e.g. DBs, Apache projects, ...). As for 12 factor principles, it was first touted by a PaaS provider. The whole idea is that they take care of the nitty grit…
However when I look at the accidental complexity we have created on the processing side, I wonder if it does not surpass the essential complexity of dealing with data.
In other words: maybe we have yet to create the proper concepts and tools to deal with data, all this time the industry created a tower of babel (and of overspent $$$) with our languages, frameworks, containers, etc.
Earlier quoted context omitted.
Learning new skills is easy enough, what kills me is the enormous manpower invested in churning working code. Easily 30% of my company's total engineering effort is just treading water, migrating from a deprecated platform to another one that will be deprecated by the time the migration is complete. Typically because the original team's standard 18-month tenure has elapsed and the new guy was under-leveled at hiring…
Backwards compatibility causes a lot of evil. I would prefer that breaking changes come with automated tools to migrate. Sometimes bad decisions get made, and we shouldn't have to carry the burden of that forever out of laziness/stubbornness. What ends up happening is the opposite of what you wanted, because after enough backwards compatibility debt adds up, someone starts a fresh competitor that takes over.
The hard part of the migration isn't that you can't automate it. The hard part is that you can't automate verifying that it didn't break anything. So you rather stick to what you have.
> Sometimes bad decisions get made, and we shouldn't have to carry the burden of that forever out of laziness/stubbornness.
Here's the deal, Mr. Developer who wants to change everything because the old stuff is somehow bad and the new stuff surely is better: I almost certainly have better use for the money than to spend it on migrating the code. The old code will keep working. That's not laziness, it's prudence.
Developers always exaggerate the benefit of rewriting stuff and changing things around. I understand why, you'd rather arrange the code you work with to your taste than whatever horrible stuff is there already. The problem is that every other developer feels the same way, but with a different taste.
For instance, some people hate object oriented programming, some people think procedural programming is somehow bad, some people believe functional programming is generally good. I believe the best programming is the one you can just stop arguing about and solve the damn problem with, sooner rather than later.
> What ends up happening is the opposite of what you wanted, because after enough backwards compatibility debt adds up, someone starts a fresh competitor that takes over.
That's not true at all in the vast majority of businesses cases. The benefit of the migration would have to be so spectacularly high, it would have to offset its cost. Again, this almost never happens.
Whenever you break compatibility, you burn good will. Whenever you break compatibility, you give me an opportunity to switch to your competitor. If I have to migrate, I might as well migrate to something else.
Rewrite the Internet stack - it's a bunch of layers on top of workarounds on top of layers of workarounds.
Do you mean the internet or the web? Either way, how would you rewrite it?
As to how, just use what we didn't know the first time. The right question would be how to have everyone switch.
Emphasis on exchanging information between 2 unknown programs.
So much programming plumbing (parsing text etc.) to do just that.
So many hours wasted chasing API documentation to figure out how to call an incantation.
So many software features hidden away and inacessible unless used through a UI maze.
So much code sitting there unused and undiscoverable.
Earlier quoted context omitted.
How does it compare to Codesandbox?
Focused on simplicity, speed, and generality. They do really well on frontend and client-side execution. Our speciality, on the other hand, is language support and containers/general dev environments.
UI development is still very clunky on any desktop OS other than windows. (and I have not done UI on windows in a decade, it used to be pretty good back in the day). iOS is good, I mean like you want to create a utility to do a job for yourself, not a big project. And I know there are lots of html / web based things you can run on desktop but they are even more complex, for me at least.
Code reviews are bad, I want to be able to run the code and put breakpoints from GitHub. Having to check out the branch, install dependencies, build the code and run it only to then go back to the UI to see the changes and comments is very time consuming and being able to test suggested changes instantly would save me a ton of time. I would gladly pay for this.
Excellent point. The code review tool in GitHub is a much worse than I was using in 2009, ten years ago! ( https://smartbear.com/product/collaborator/overview/ ) I haven't used Collaborator in a while, but I wonder how much it has improved in ten years. It sounds like you're thinking of a code review tool + CI/CD pipeline, right, @inglor? e.g., 1. suggest a change in the UI or backend in the code review tool 2. run C…
Earlier quoted context omitted.
I was talking about this with a friend the other day. I don't know about the technical feasibility (RE sybil attack[0]), but if it were possible, it would have a massive impact on the web. The current state of the art (in terms of new user signup) is using phone numbers as representing unique "trustable" people, which is kind of absurd. This reminds me of how social security numbers weren't originally intended to be…
Hot take, but the only real way to solve this identity problem is to take people's DNA. The only attack on that is to literally synthesize fake DNA/fake hair/fake saliva. Even then you can prompt randomly for DNA the way Twitter randomly prompts for phone number verification. Or ask the user for a selfie and spot inconsistencies in the mapping from DNA to face. It's scary to let internet companies have your actual DN…