This is a very hot take and also not a new one but here we go: the goal of a properly functioning software engineer is to obviate themselves, not by solving the customer's specific problems but by blurring the line between using a computer and programming one to the point where users can solve their own problems.
It really worries me that so many programmers sneer at Excel and Access. Those tools exist because they allow users to do programming; yet somehow this is not cheered, but seen as an enemy of 'proper' programming.
(of course then systems programmers sneer at 'mere web developers', etc)
I don't understand the division and I never have. It doesn't seem to be about wanting to make the tools better - more a resentment that user-accessible programming tools exist AT ALL.
At the last place I worked, users were often using excel sheets and access databases, created by other users a decade ago, and modified bit by bit over time. They'd been used so long no one remembered how they worked, and their creators were long gone, but the staff relied on them so much that they didn't know how else to do their jobs. We'd learn these existed at 3am if it 'broke'.
@natecull @deejoe @enkiv2 So us IT people would get calls at 3am complaining that the 'program' wasn't working anymore. When we asked which program, it would turn out to be some excel document that had been copied and re-copied over the years; and a few copies back, someone had probably typed over a formula field and broken something.
@natecull @deejoe @enkiv2 And it was our fault it wasn't working, because of course it was. This spreadsheet we didn't make and didn't know about and would probably take weeks to untangle and figure out (not just from a technical point of view, but because we didn't know their jobs well enough to guess why any of it did anything).
So these things were the bane of our existence, basically.
@Lexi Spreadsheets definitely have a debugability problem. :/
If you're getting paid for it or someone gets hurt when it breaks, it's big computing and should be bulletproof. (Throw TDD and formal methods and everything else at it.)
For everything else, it's small computing, which should be as fast and loose (and flexible and expressive) as possible.
Big computing is ADA and small computing is LISP.
@Lexi @natecull @deejoe
Nobody uses a vice grip to do important mechanical repairs the way people use PHP (the developer's equivalent of the excel spreadsheet) to build important software -- almost entirely because people consider programming language preference a part of their identity while they don't think of physical tools the same way.
@enkiv2 @natecull @deejoe Makes sense! Our problem was historic, really--left over stuff from old ways of doing things. We spent years creating more robust replacements for crucial stuff like this and encouraging users to keep us in the loop. It was just scary whenever we found that the only way new employees at some remote branch had been taught to do their job was dependent on a flimsy excel 2000 document...!
This violates your notion of how things are supposed to be done, but we all probably have stories like this. Peripherally, mine are about mainframe programs that are *still* running after, what? 30 years? Spreadsheet formulae, ha! How about no source & no toolchain?
This *is* how the world works. Messy reality mated to universal machines under deadlines and other constraints by messy, imperfect monkeys.
@enkiv2 @Lexi @natecull @deejoe One thing that I'd argue is that there needs to be a good way to move from small to big computing, before the small computing gets contorted into things that are too hard to understand.
I think a lot of this requires responsive development organizations in companies, though, and that's one of the first things to get cut.
I suspect that the constraints are so different that it's better off if a total rewrite and change of tools between prototype and release is done. Otherwise you get hacky stuff left over. (Not even hacky code -- just concepts and structures that have no place in serious code that needs to be maintained by angry strangers.)
Spreadsheets and Excel have some /good things going for them!/ specifically the same thing that Shell has going for it: programming is not a separate domain from the rest of your activities but something integrated into it.
Like Shell, the language integrated by Excel is...not very good.
BUT, I would /looove/ to see something like Access made /better/. Someone could probably do pretty well taking a language like Smalltalk and building an Access-like application in terms of that, where you not only get the drag 'n drop interface construction and a 'table' as a basic primitive you can play with and get use out of, BUT a general purpose language on top of it.
I use Excel for data analysis sometimes and almost always regret it. But there's often not much else that quite does what it can: just splat up some tabular data on a screen so you can view it, sort it, make some tweaks, transform it in some ways.
One thing that amazes me about both Excel and Access is how terrible both of their support for CSV is. I mean, CSV! How can you get that wrong? Yet they do. And it's never been fixed.
@Azure @natecull @deejoe @enkiv2
Yes, this! There are people who can program in office jobs but aren't "developers" and so the only tools available to them are the ones in Excel.
There's no ladder between what you get in Excel to Visual Studio. The editor is painful, you can't do version control, _that's_ what leads to convoluted, brittle VBA hell.
The "developers" are keeping the good tools to themselves and then complaining when they find their colleagues are spiralising vegetables with a hand drill.
@natecull @deejoe @enkiv2 I used to sneer at Excel and Access. It didn't bother me that they were programmable by non-programmers. It bothered me that when the time came to migrate to a "proper solution", meaning one where the data was kept inside a RDBMS instead of Excel or Access, actually getting the data out of Excel/Access and presenting it to users in a way that wouldn't confuse them was like pulling teeth. Users never wanted to migrate anyway, but management always insisted...
I know, but instead of directing their concerns and fears and frustrations at the managers who mandate these changes without considering the needs and desires of the people who will be expected to use the new system, they dump it on developers like me and expect me to act like I give a shit.
That kind of emotional labor isn't in my job description.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!