4 ms·

> Some requirements mean a lot of code to change. Some requirements require almost none. My point is ultimately marketing/finance/administration people do not

> Some requirements mean a lot of code to change. Some requirements require almost none. My point is ultimately marketing/finance/administration people do not know, fundamentally, what is a lot of code and what isn't. That's knowledge for programmers. https://xkcd.com/1425/ https://xkcd.com/1425/ > What will happen is the "mostly talking, with fairly obvious code changes" part of the job will get absorbed into other roles. There is no such thing as "obvious code changes". > Marketing, support, finance, they'll just do that coding themselves. Never happen. > Or do I want to drop the "programmer" title, still do some coding, and move to marketing/support/finance alongside other "non-progeammers" who are doing a decent amount of high level programming. My software team develops all the software for the marketing, finance, HR, and support departments. They are deeply involved in the design of their products (some departments more than others) but ultimately none of them can or want to program. Even basic SQL is beyond the skills of most them -- although we encourage anyone with interest to do their own queries. You massively under-estimate the skill and experience involved in even the most basic programming tasks. Programming, version control, deployment, database design, systems design, etc. These people have their own professions with their own issues to deal with.

erikpukinskis 10y ago
> There is no such thing as "obvious code changes". What about "there's a letter missing in this heading"? > Even basic SQL is beyond the skills of most them I would put SQL in the category of "advanced programming". It's declarative programming, which is not easy for beginners, and you can literally do any operation at all from any place in the code. There's zero separation of concerns. > You massively under-estimate the skill and experience involved in even the most basic programming tasks. What's so hard about changing a letter in a string on Github? Anyone who can send a text message could do that. To me, that's the "most basic programming task". What's impossible about: Hi Fred, Thanks for noticing that typo! You can fix it yourself... The code is here: https://gist.github.com/erikpukinskis/198a752e2fd286f2179b16335f9cf0b1 https://gist.github.com/erikpukinskis/198a752e2fd286f2179b16... Just click "Fork" and then "Edit" and make the change. The system will send me a notification and if nothing is broken I'll merge it, and it should be live within the hour! Best, Erik > ultimately none of them can or want to program. OK, so that's a cultural barrier. If you want to really lure people in, it will require a little more than an email like the one I suggested. I think to get people to bite, you need a few things: 1) Web-based editing, with instant preview (no downloading anything, no commands to type) 2) No repos, just editing single files 3) Very high ratio of domain-specific language to implementation language. Most programmers don't bother separating out their domain language (customer, sale, analysis, etc) from their implementation language (page, element, server, etc) You can't have a sidebar with node_modules, src, view, etc, it distracts people. All this really requires is writing an extra layer of domain code that wraps your implementation code. It's not necessary if your code is only ever read by professionals so most programmers don't bother doing it. It's extra work after all. 4) Use only functions, function calls, and literals. No loops, no classes, etc. That stuff can go in the implementation layer, but you can't expose it. This also means no SQL, no CSS, etc. One language, three language constructs. 5) Separation of shared code from sensitive code and data. If you can do something like: import "users" users.delete_all() ... you're screwed. People will never feel safe making changes in that environment. You need real separation of concerns where the code being edited is mechanically separated from everything but the few functions you want to expose to people. Think of each source file as a custom sandbox for just one non-programmer employee. Get all five of those, and you have yourself a changed game. Building all of those things is a bit of work, but there's nothing fundamentally mysterious about how to do it. It's just work that most companies don't do because you can just wall off your code within your professional programming team instead.

erikpukinskis 10y ago

> There is no such thing as "obvious code changes". What about "there's a letter missing in this heading"? > Even basic SQL is beyond the skills of most them I would put SQL in the category of "advanced programming". It's declarative programming, which is not easy for beginners, and you can literally do any operation at all from any place in the code. There's zero separation of concerns. > You massively under-estimate the skill and experience involved in even the most basic programming tasks. What's so hard about changing a letter in a string on Github? Anyone who can send a text message could do that. To me, that's the "most basic programming task". What's impossible about: Hi Fred, Thanks for noticing that typo! You can fix it yourself... The code is here: https://gist.github.com/erikpukinskis/198a752e2fd286f2179b16335f9cf0b1 https://gist.github.com/erikpukinskis/198a752e2fd286f2179b16... Just click "Fork" and then "Edit" and make the change. The system will send me a notification and if nothing is broken I'll merge it, and it should be live within the hour! Best, Erik > ultimately none of them can or want to program. OK, so that's a cultural barrier. If you want to really lure people in, it will require a little more than an email like the one I suggested. I think to get people to bite, you need a few things: 1) Web-based editing, with instant preview (no downloading anything, no commands to type) 2) No repos, just editing single files 3) Very high ratio of domain-specific language to implementation language. Most programmers don't bother separating out their domain language (customer, sale, analysis, etc) from their implementation language (page, element, server, etc) You can't have a sidebar with node_modules, src, view, etc, it distracts people. All this really requires is writing an extra layer of domain code that wraps your implementation code. It's not necessary if your code is only ever read by professionals so most programmers don't bother doing it. It's extra work after all. 4) Use only functions, function calls, and literals. No loops, no classes, etc. That stuff can go in the implementation layer, but you can't expose it. This also means no SQL, no CSS, etc. One language, three language constructs. 5) Separation of shared code from sensitive code and data. If you can do something like: import "users" users.delete_all() ... you're screwed. People will never feel safe making changes in that environment. You need real separation of concerns where the code being edited is mechanically separated from everything but the few functions you want to expose to people. Think of each source file as a custom sandbox for just one non-programmer employee. Get all five of those, and you have yourself a changed game. Building all of those things is a bit of work, but there's nothing fundamentally mysterious about how to do it. It's just work that most companies don't do because you can just wall off your code within your professional programming team instead.