Citizen developers are rapidly becoming the vanguard of corporate digitisation(economist.com)
economist.com
Citizen developers are rapidly becoming the vanguard of corporate digitisation
https://www.economist.com/business/2022/01/29/what-if-all-workers-wrote-software-not-just-the-geek-elite
202 comments
https://archive.md/FtdBG
Business/career implications aside, normalizing people thinking about computers as tools that execute arbitrary instructions is an almost purely good thing.
I can't think of many other social trends that would be more beneficial for increasing general support for user agency, data interoperability, sideloading/modding, etc... we should applaud every single attempt to democratize coding and lower barriers of entry.
It's not about whether or not someone can replace your job or whether or not they take something that's a hobby project or an occasional side-task at their job and turn it into a professional career. It's not about whether or not the things they make are any good. It's about giving them a little bit more agency in how they interact with devices/software, and about reinforcing to them that as a user they should have agency over their devices/software.
We don't need everyone in the world to be an engineer, and we don't need everyone to write good code. The goal is not to make everyone into a programmer, or to elevate engineering as some kind of universal subject that everyone has to embrace. But it is good for average people who aren't engineers to be embracing a philosophy about computers that says, "I should be able to arbitrarily describe to this thing what to do, even if its designers didn't think about my use case, and it should do the thing I tell it to".
I can't think of many other social trends that would be more beneficial for increasing general support for user agency, data interoperability, sideloading/modding, etc... we should applaud every single attempt to democratize coding and lower barriers of entry.
It's not about whether or not someone can replace your job or whether or not they take something that's a hobby project or an occasional side-task at their job and turn it into a professional career. It's not about whether or not the things they make are any good. It's about giving them a little bit more agency in how they interact with devices/software, and about reinforcing to them that as a user they should have agency over their devices/software.
We don't need everyone in the world to be an engineer, and we don't need everyone to write good code. The goal is not to make everyone into a programmer, or to elevate engineering as some kind of universal subject that everyone has to embrace. But it is good for average people who aren't engineers to be embracing a philosophy about computers that says, "I should be able to arbitrarily describe to this thing what to do, even if its designers didn't think about my use case, and it should do the thing I tell it to".
It almost seemed like that global working knowledge of computers as tools would be the new norm, up until the early 2000s. In my own practice I saw more and more snall business owners writing their own websites and simple systems before coming to me to improve or polish up what they had. I always applauded that and I always try to make sure my clients have a full mental picture of what's really happening inside apps they commission from me now. Even if that means boring them with lots of details... they are savvier because they understand what can be done, and how. Sadly there's been a concerted effort by the FAANGs, mainly, to turn everything into an appliance and take that power away from users. You're absolutely right that anything that puts more power within the average user's reach is good for free computing and for free software development as a whole.
> Sadly there's been a concerted effort by the FAANGs, mainly, to turn everything into an appliance and take that power away from users.
That's because user education doesn't scale or pay well.
Scale, because some users are certainly intractable idiots who can't do basic addition. But even if you solve that hard problem, what have you accomplished? You've taught users how to control their own computers.
Which ultimately compresses the margin you're able to extract by artificially limiting features in your ecosystem.
If a user can glue together a storage backend themselves, fewer of them will use your cloud storage offering.
It's far easier, simpler, and more consistent and profitable to infantilize users, carve up your feature tiers with a simple pricing strategy, and maintain high margins.
That's because user education doesn't scale or pay well.
Scale, because some users are certainly intractable idiots who can't do basic addition. But even if you solve that hard problem, what have you accomplished? You've taught users how to control their own computers.
Which ultimately compresses the margin you're able to extract by artificially limiting features in your ecosystem.
If a user can glue together a storage backend themselves, fewer of them will use your cloud storage offering.
It's far easier, simpler, and more consistent and profitable to infantilize users, carve up your feature tiers with a simple pricing strategy, and maintain high margins.
I’m not sure the argument works that more empowered users equals less opportunity for big tech to make money.
Apple is certainly pushing Shortcuts. On the whole I think that citizen programmers would still need resources and services like cloud storage, access to media, or APIs for voice recognition.
Apple is certainly pushing Shortcuts. On the whole I think that citizen programmers would still need resources and services like cloud storage, access to media, or APIs for voice recognition.
The result of user empowerment is customization. The foundation of modern big tech is standardization. Facebook, Gmail, etc.
Scaling at low headcount-per-user doesn't work if your users have diverged too far from baseline, because that exponentially increases support cases and requires features for smaller sections of your population.
So maybe they'd be able to pivot, but it'd certainly be a sea change to start supporting full B2C APIs vs the existing more B2B2C APIs they target (when offered at all).
Scaling at low headcount-per-user doesn't work if your users have diverged too far from baseline, because that exponentially increases support cases and requires features for smaller sections of your population.
So maybe they'd be able to pivot, but it'd certainly be a sea change to start supporting full B2C APIs vs the existing more B2B2C APIs they target (when offered at all).
It’s true that people want to do their own thing, but at what level? People don’t want to write their own HTML, or run their own server. They want to solve problems that matter to them. Give them the right tools and you’ll grow your platform. Think how Windows benefitted from Excel.
People want to solve problems that matter to them, and most will not want to write their own HTML or run their own server. But some will.
Windows benefited from Excel because Excel was (and is!) the most widely available IDE in most companies, and provided a ridiculous amount of functionality (too much!) via VB*.
And it's a huge, fundamental, business-defining leap to say "We're going to let developers (and now users) capture more value out of our platform than we get, because we'll win in the end via growth."
I honestly don't think Google is there. And Facebook and Apple sure as shit aren't.
Windows benefited from Excel because Excel was (and is!) the most widely available IDE in most companies, and provided a ridiculous amount of functionality (too much!) via VB*.
And it's a huge, fundamental, business-defining leap to say "We're going to let developers (and now users) capture more value out of our platform than we get, because we'll win in the end via growth."
I honestly don't think Google is there. And Facebook and Apple sure as shit aren't.
> Business/career implications aside, normalizing people thinking about computers as tools that execute arbitrary instructions is an almost purely good thing. [...]
> We don't need everyone in the world to be an engineer, and we don't need everyone to write good code.
I agree. In sum this means app-ification of the - from the business people - boring matter of REST APIs. In the end, you build or use a product that abstracts many things away. (There is an old joke, that Excel sheets simply become apps now)
In my experience in Financial Industry, this leads to second level problems: What and how to build a new product? So there is an important intersection between the new users, Citizen Developers, and Product Managers.
I agree. In sum this means app-ification of the - from the business people - boring matter of REST APIs. In the end, you build or use a product that abstracts many things away. (There is an old joke, that Excel sheets simply become apps now)
In my experience in Financial Industry, this leads to second level problems: What and how to build a new product? So there is an important intersection between the new users, Citizen Developers, and Product Managers.
> to democratize coding
Does that mean we collectively vote as to whether the next addition is a for loop?
While a company may mean to make more widely accessible but used charged language, I think we should fight the urge to parrot.
Does that mean we collectively vote as to whether the next addition is a for loop?
While a company may mean to make more widely accessible but used charged language, I think we should fight the urge to parrot.
One alternative definition of "democratic" is "relating to, appealing to, or available to the broad masses of the people." [0] Regardless of whether this is considered charged language or not, it is a valid alternate usage of the term. I never read the comment you're referring to as anything political.
[0] https://www.merriam-webster.com/dictionary/democratic
[0] https://www.merriam-webster.com/dictionary/democratic
Democracy is a broad term. It can be used politically, but it can also refer to:
A) a leveling of access (ie, that ordinary people are able to participate in the process).
B) a rejection of "snobbish"-ness about a field or its participants.
A light, non-political definition of democracy is just taking something that is restricted and making it broadly available and accessible, or changing perspectives on that thing such that normal participation in or usage of that thing isn't looked down on.
----
From a "political" perspective (although probably not political in the way people think when they hear the word), democratizing code can also be thought of as an assertion that ordinary people should have agency over what their computers do. By building no-code solutions or accessible coding environments that allow ordinary people to create and share solutions to their problems, we give them the ability to compete with us about what those solutions should be.
In other words, it's not that a group of professional programmers decide what your computer can do, you can decide what your computer can do, and you can share your solutions and creations with other people on equal footing with the professionals.
There is a kind of "power to the people" mentality bundled up in concepts like Open Source and Open access to code. On one hand, these concepts don't require you to share anything, concepts like Open Source and Open access in computing allow for people to create fully private software that is entirely individual. But these concepts also allow groups of people to promote ideas about computing and about engineering in the form of working software or scripts that other people can use, and that gives those people more of a voice in conversations about what computers should and shouldn't do -- conversations that in a more locked down world would only be happening inside of companies or inside professional circles.
----
I'm certainly not trying to create charged language, and I get that people might read democracy as an explicitly political Right vs Left thing. That was not my intention at all. But my feeling is that "democratizing code" is a fairly common term that I've heard a lot over the years, even leading back to my childhood -- so it didn't really occur to me that people would read it any other way.
Always happy to clarify stuff like that though; and maybe you're right. I might be out of touch with the current climate and maybe the common usage of the term has changed.
A) a leveling of access (ie, that ordinary people are able to participate in the process).
B) a rejection of "snobbish"-ness about a field or its participants.
A light, non-political definition of democracy is just taking something that is restricted and making it broadly available and accessible, or changing perspectives on that thing such that normal participation in or usage of that thing isn't looked down on.
----
From a "political" perspective (although probably not political in the way people think when they hear the word), democratizing code can also be thought of as an assertion that ordinary people should have agency over what their computers do. By building no-code solutions or accessible coding environments that allow ordinary people to create and share solutions to their problems, we give them the ability to compete with us about what those solutions should be.
In other words, it's not that a group of professional programmers decide what your computer can do, you can decide what your computer can do, and you can share your solutions and creations with other people on equal footing with the professionals.
There is a kind of "power to the people" mentality bundled up in concepts like Open Source and Open access to code. On one hand, these concepts don't require you to share anything, concepts like Open Source and Open access in computing allow for people to create fully private software that is entirely individual. But these concepts also allow groups of people to promote ideas about computing and about engineering in the form of working software or scripts that other people can use, and that gives those people more of a voice in conversations about what computers should and shouldn't do -- conversations that in a more locked down world would only be happening inside of companies or inside professional circles.
----
I'm certainly not trying to create charged language, and I get that people might read democracy as an explicitly political Right vs Left thing. That was not my intention at all. But my feeling is that "democratizing code" is a fairly common term that I've heard a lot over the years, even leading back to my childhood -- so it didn't really occur to me that people would read it any other way.
Always happy to clarify stuff like that though; and maybe you're right. I might be out of touch with the current climate and maybe the common usage of the term has changed.
"Computer Science was always supposed to be taught to everyone, and it wasn’t about getting a job: A historical perspective"
https://computinged.wordpress.com/2021/11/26/computer-scienc...
https://computinged.wordpress.com/2021/11/26/computer-scienc...
ok only the rudiments of any sufficiently complicated field - politics, law, literature, math, physics, chemistry, biology, art etc. etc. including computer science, can be widely taught, furthermore given that time is limited and there is some showing that putting more hours of learning in actually decreases efficiency of education, it follows that the more complicated subjects we try to teach the more rudimentary our teachings in those subjects must be.
Given any sufficiently complicated enough civilization there will be enough complicated fields to maintain, and thus specialization will have to occur and some people will have to be specialized in some particular field.
Given any sufficiently complicated enough civilization there will be enough complicated fields to maintain, and thus specialization will have to occur and some people will have to be specialized in some particular field.
It's not saying there shouldn't be specialization.
In the UK they already teach CS to every student in primary school, just like math.
In the UK they already teach CS to every student in primary school, just like math.
I think that’s probably the opinion of many academic focused people about their profession.
My kid had a "computer science" class in 9th grade. They covered bits and bytes, discussed what files are, and then talked in the abstract about data compression so they know at a basic level why a wave file is so much bigger than mp3. They did get to some coding, but they covered a lot of basics that form the trunk of the tree. Most adults don't understand things in that way.
It's like teaching biology so people have a rudimentary idea of viruses and don't think vaccines have 5g tracking. Or so teenagers understand reproduction and don't think ridiculous things about how one gets pregnant.
Or how about chemistry, so people understand why con-trails form.
Basic understanding of things - particularly the ones everyone uses daily - is a good thing.
It's like teaching biology so people have a rudimentary idea of viruses and don't think vaccines have 5g tracking. Or so teenagers understand reproduction and don't think ridiculous things about how one gets pregnant.
Or how about chemistry, so people understand why con-trails form.
Basic understanding of things - particularly the ones everyone uses daily - is a good thing.
Yeah I’m the type that needs to make things. Theory makes no sense to me if i don’t see it in action. I struggled in a traditional theory / coding educational environment and dropped out of college.
Decades later I learned coding in a more hands on / make things way and I’m having fun working my way “backwards” into theory.
Decades later I learned coding in a more hands on / make things way and I’m having fun working my way “backwards” into theory.
You learn theory 10x more easily when it’s actually working for you. I think there’s a case for needing explicit instruction in mathematics and algorithms, but it only becomes intuitive when you’re solving your own problem with it.
Remember that Gauss didn’t just sit around inventing theories, he was trying to explain the world around him and his theories were the product of that.
Remember that Gauss didn’t just sit around inventing theories, he was trying to explain the world around him and his theories were the product of that.
Computer science is different, since it's the foundation of math and logic.
I think of this as using the computer vs using software on the computer.
One of the main differences I see on the road to learning to code has nothing to do with the tools; it’s the thought process.
A major hurdle is trying to get the business people to coherently express what they want. They seem to have a general sense of how something should go, but can’t actually put it down on paper. Or when they do, it looks different than what they imagined (simply because the required logic doesn’t match the cloudy vision they have in their mind), and then scrap it because it doesn’t “feel” right. They fail to think about the corner cases because “that doesn’t happen very often”, ignoring the fact that a program needs to work in all cases, no matter how often they happen. Or they don’t get the concept that processing 10 or 10,000 records makes no difference (i.e. it’s not “more work”) because they don’t really follow the idea that they’re setting the rules for the computer to do the work, not doing it themselves.
Understanding math is so important because it’s often the first formal step in learning how to think this way. I think it’s a pretty good bet that business people who do well in math would probably do well in some level of programming, but everyone else probably just can’t, or at least are unwilling to go through the mental training required to think this way.
A major hurdle is trying to get the business people to coherently express what they want. They seem to have a general sense of how something should go, but can’t actually put it down on paper. Or when they do, it looks different than what they imagined (simply because the required logic doesn’t match the cloudy vision they have in their mind), and then scrap it because it doesn’t “feel” right. They fail to think about the corner cases because “that doesn’t happen very often”, ignoring the fact that a program needs to work in all cases, no matter how often they happen. Or they don’t get the concept that processing 10 or 10,000 records makes no difference (i.e. it’s not “more work”) because they don’t really follow the idea that they’re setting the rules for the computer to do the work, not doing it themselves.
Understanding math is so important because it’s often the first formal step in learning how to think this way. I think it’s a pretty good bet that business people who do well in math would probably do well in some level of programming, but everyone else probably just can’t, or at least are unwilling to go through the mental training required to think this way.
I don’t think that having a knack for math necessarily matters for making a good programmer. I’ve known many good engineers who were drawn to programming because math was hard for them and they wanted to learn how to get the computer to do it for them. Ironically, coming to understand programming can be a way to understand math better.
One of the best programmers I know is a philosophy major, who thinks of code like poetry, with consistent readable concision as the goal.
There are many paths.
What programming does require is a vivid imagination, to form a mental picture of the machine you are building and what is happening as information flows through it and is transformed.
Even more than that, it helps to be a systems-thinker, and to be able to zoom out and ask “what are we really trying to accomplish here.” Most of the time the elegant software solutions come not from writing brilliant code, but from reframing the problem so that simple code can solve it.
One of the best programmers I know is a philosophy major, who thinks of code like poetry, with consistent readable concision as the goal.
There are many paths.
What programming does require is a vivid imagination, to form a mental picture of the machine you are building and what is happening as information flows through it and is transformed.
Even more than that, it helps to be a systems-thinker, and to be able to zoom out and ask “what are we really trying to accomplish here.” Most of the time the elegant software solutions come not from writing brilliant code, but from reframing the problem so that simple code can solve it.
> it helps to be a systems-thinker, and to be able to zoom out and ask “what are we really trying to accomplish here.” Most of the time the elegant software solutions come not from writing brilliant code, but from reframing the problem so that simple code can solve it.
This is exactly what math as a subject in school teaches you. Other subjects can too, but math seems to uniquely challenge people to really bend their mind around concepts, as opposed to many other subjects which often turn into memorization tasks.
I’m talking about stuff like algebra, statistics, etc., not basic adding and multiplication. What is reducing a fraction or using the commutative property to break a problem into smaller chunks, if not “reframing the problem”?
This is exactly what math as a subject in school teaches you. Other subjects can too, but math seems to uniquely challenge people to really bend their mind around concepts, as opposed to many other subjects which often turn into memorization tasks.
I’m talking about stuff like algebra, statistics, etc., not basic adding and multiplication. What is reducing a fraction or using the commutative property to break a problem into smaller chunks, if not “reframing the problem”?
>This is exactly what math... teaches you.
This is more or less agreeable.
>...as a subject in school...
Maybe for a lucky few. My entire math career in school, from middle school through university, grades were based on homework completion. I even had one sadistic teacher who would grade a semester's homework twice. Imagine getting Bs on tests with no curve, but getting a D in the class. I remember in highschool and uni, that there were often one or two kids who would do the homework and then it would get passed around and copied by half the class.
I would go so far as to say math-in-school was about successfully processing complex tasks without needing to understand them, as well as the value of teamwork & organization.
This is more or less agreeable.
>...as a subject in school...
Maybe for a lucky few. My entire math career in school, from middle school through university, grades were based on homework completion. I even had one sadistic teacher who would grade a semester's homework twice. Imagine getting Bs on tests with no curve, but getting a D in the class. I remember in highschool and uni, that there were often one or two kids who would do the homework and then it would get passed around and copied by half the class.
I would go so far as to say math-in-school was about successfully processing complex tasks without needing to understand them, as well as the value of teamwork & organization.
Both are exact disciplines that rely on making tools and abstractions as a away to solve problems, knowing how to combine your skills to form new skills, because you are often in a novel situation that doesn't match experience.
> This is exactly what math as a subject in school teaches you
Does it? My encounters with it at any place of formal education have all been about memorizing and practicing arbitrary operations. No intuition required.
Does it? My encounters with it at any place of formal education have all been about memorizing and practicing arbitrary operations. No intuition required.
Yes, every math curriculum teaches you to find the real problem instead of getting distracted by details. For example, you learn that adding together 5 apples with 7 apples is actually the same problem as adding together 5 cows with 7 cows. Math education was always about finding the core most pure representation of problems and learning how to solve those. That kind of thinking is what you need to understand to get good at programming.
Math has two things that are part of it that are a key part of software development.
There is the "this doesn't change." In many other jobs you can bend the thing you are working with to your will. Bend that pipe or apply just a bit more force here. Having plumbing being off by a little is often good enough for the tolerances.
Math, you can't do that. There is no way to push a bit harder and make one value a different value. Yes, there are ways to manipulate systems of equations - but at the heart of it, you have to submit and match the mental model of math rather than being able to impose your will on the material.
Carpentry? The wood doesn't bend the way you want it to? You can blame the wood, throw it out and start the process again. It may be costly over time, but doing the same thing may have different results the next time.
Software development and math - if you do the same thing again, it doesn't change.
The second part of this is the how you approach a very large problem and apply an algorithmic approach to breaking it down into smaller and smaller problems until they are solvable.
That isn't a "you can't use that approach on carpentry or plumbing" (and it is often that you do), but rather that it is necessary to do this in math and software development.
The knack for math is more about the acceptance of the inflexibility of numbers and computers along with the nature of the tools used to solve those problems. That said, some of the tooling for one or the other may be difficult to get your mind around. Calculus and derivatives and matrices... they are things that the tools to solve them and I go blank with them. I also know a sysadmin who was a math major who is proficient in PowerShell, but the parts of strongly typed larger codebase and he appears to have similar distain for it that I do for matrices and calculus.
> Most of the time the elegant software solutions come not from writing brilliant code, but from reframing the problem so that simple code can solve it.
This is also at the core of solving the harder math problems.
There is the "this doesn't change." In many other jobs you can bend the thing you are working with to your will. Bend that pipe or apply just a bit more force here. Having plumbing being off by a little is often good enough for the tolerances.
Math, you can't do that. There is no way to push a bit harder and make one value a different value. Yes, there are ways to manipulate systems of equations - but at the heart of it, you have to submit and match the mental model of math rather than being able to impose your will on the material.
Carpentry? The wood doesn't bend the way you want it to? You can blame the wood, throw it out and start the process again. It may be costly over time, but doing the same thing may have different results the next time.
Software development and math - if you do the same thing again, it doesn't change.
The second part of this is the how you approach a very large problem and apply an algorithmic approach to breaking it down into smaller and smaller problems until they are solvable.
That isn't a "you can't use that approach on carpentry or plumbing" (and it is often that you do), but rather that it is necessary to do this in math and software development.
The knack for math is more about the acceptance of the inflexibility of numbers and computers along with the nature of the tools used to solve those problems. That said, some of the tooling for one or the other may be difficult to get your mind around. Calculus and derivatives and matrices... they are things that the tools to solve them and I go blank with them. I also know a sysadmin who was a math major who is proficient in PowerShell, but the parts of strongly typed larger codebase and he appears to have similar distain for it that I do for matrices and calculus.
> Most of the time the elegant software solutions come not from writing brilliant code, but from reframing the problem so that simple code can solve it.
This is also at the core of solving the harder math problems.
math is not just about calculations and numbers that most people interact with during their education and seems to dislike or find hard.
the part that would be useful in programming is a little bit of logical reasoning, the symbolic reasoning and modeling of problems through abstraction.
coincidentally these are also the part of math that get thought and used in philosophy so I'm guessing that your colleague is somewhat familiar with them since their most probably are required core courses in getting a philosophy degree.
the part that would be useful in programming is a little bit of logical reasoning, the symbolic reasoning and modeling of problems through abstraction.
coincidentally these are also the part of math that get thought and used in philosophy so I'm guessing that your colleague is somewhat familiar with them since their most probably are required core courses in getting a philosophy degree.
I was exposed to this aspect of math through proofs, which are sadly given short shrift in K-12 math today. The schools in my hometown used a math curriculum that actually introduced basic set theory in first grade, and eased us into proofs. High school geometry was all about proofs. First of all, it was a good education. Second, proofs were what made math come alive for me.
I have a lot of opinions about K-12 math education. ;-)
I have a lot of opinions about K-12 math education. ;-)
I think there's a difference between being good at math itself and having a mathematical mindset. You can be unfamiliar with the (largely arbitrary seeming) rules and operations of maths while still being able to appreciate and reason about other types of algorithms/relationships.
My mom taught programming in the 80s, and the first thing she told students was: "Computers are stupid. They only do exactly what you tell them to do." People have to get over the misconception that computers can think.
Maybe it was easier in the days of DOS, because merely using a computer required the same precision.
Maybe it was easier in the days of DOS, because merely using a computer required the same precision.
So much of the ML hype is business people wanting something that everyone can operate equally poorly.
The fact that so much of ML is inscrutable alchemy and a guessing game is a feature not bug.
The fact that so much of ML is inscrutable alchemy and a guessing game is a feature not bug.
But ML (from a pure programming perspective) is just a lot of mathematical functions being strung together, usually as part of high level libraries.
If you truly have good data, approximating a signal from noise is trivial.
It's way less complicated code than, say, your bank's web app and payments system.
If you truly have good data, approximating a signal from noise is trivial.
It's way less complicated code than, say, your bank's web app and payments system.
So is everything else in software. Literally everything a computer can do is a form of math; it only seems like you're ever doing something not-math because we've made some very good abstractions over the math.
Computers do appear to think more and more these days, what with the tracking and targeted ads and so forth. To which your mom might say: Computers still aren't thinking; someone else -- someone at Google or Apple or Microsoft -- told them to do that.
Maybe that would help bring the privacy implications into clearer focus.
Maybe that would help bring the privacy implications into clearer focus.
I occasionally teach programming love this line.
It's doing exactly what you're telling it to do.
It's doing exactly what you're telling it to do.
[deleted]
That's just it; the article focuses exclusively on low code/no-code solutions. The author cites examples describing business people putting together functional systems without writing a lick of code (let alone understanding the math underlying such systems.) The whole point of the article is /not/ having to learn to code.
The idea is that these people are in the thick of a business problem, and given the right tools, they're likely to come up with a helpful solution. They don't need to express or communicate anything to anyone. They're able to provide a solution on their own.
I agree with this somewhat, having built and maintained more than a handful of the kind of apps that these low / no-code solutions target, i.e., line-of-business apps. These tools have a place. I've worked with trainers and consultants that, I firmly believe, would have thrived with these kinds of tools had they been available at the time.
Incidentally, I can't entirely agree that math is important because it encourages the appropriate thought process for constructing these systems. I've worked with more than enough technically inclined (if not remotely mathematically inclined) people who have managed to put together solid systems for themselves or their teams. I'm convinced that curious people excel in these cases, the ones that find a shortcut or an interesting path and just follow it.
The idea is that these people are in the thick of a business problem, and given the right tools, they're likely to come up with a helpful solution. They don't need to express or communicate anything to anyone. They're able to provide a solution on their own.
I agree with this somewhat, having built and maintained more than a handful of the kind of apps that these low / no-code solutions target, i.e., line-of-business apps. These tools have a place. I've worked with trainers and consultants that, I firmly believe, would have thrived with these kinds of tools had they been available at the time.
Incidentally, I can't entirely agree that math is important because it encourages the appropriate thought process for constructing these systems. I've worked with more than enough technically inclined (if not remotely mathematically inclined) people who have managed to put together solid systems for themselves or their teams. I'm convinced that curious people excel in these cases, the ones that find a shortcut or an interesting path and just follow it.
We already have this distinction: engineers vs bricklayers and plumbers. And it also works that way in software. Plenty of CRUD programmers would not be able to implement quicksort. But they sure are able to use it.
> They don't need to express or communicate anything to anyone.
My point about communication is not so much the need to actually tell something to someone, but that in order to be able to communicate something, they need to know how to break down a problem into all the various components. That’s what’s missing for many business people, so whether they are communicating the problem to a developer, or to a no-code platform, it won’t work.
There will always be business people who can do this just fine, but there are far more who see themselves as the people who give commands that others just follow and have no interest in actually doing that type of thinking.
My point about communication is not so much the need to actually tell something to someone, but that in order to be able to communicate something, they need to know how to break down a problem into all the various components. That’s what’s missing for many business people, so whether they are communicating the problem to a developer, or to a no-code platform, it won’t work.
There will always be business people who can do this just fine, but there are far more who see themselves as the people who give commands that others just follow and have no interest in actually doing that type of thinking.
How often have you found the metaphor that a computer is an extremely stupid employee with no common sense to be a useful prompt at getting business people to think of corner cases?
You make some very good points. I think that one thing that is not at all obvious to most non-technical people is just how FAST computers can compute, even the most basic and low spec ones.
I agree with all what you said, except the part about 10 records vs 10 000, that I think need better clarification.
depending on the amount of computation needed/task executed the number of record to update can make things very different. updating 1 million or 10 000 records that need very heavy computation and communication to other systems under some duration or latency constraints is very different from updating 10 of them.
you may need to optimize and/or rewrite your whole systems to handle such things.
depending on the amount of computation needed/task executed the number of record to update can make things very different. updating 1 million or 10 000 records that need very heavy computation and communication to other systems under some duration or latency constraints is very different from updating 10 of them.
you may need to optimize and/or rewrite your whole systems to handle such things.
I was hesitant to include that example because I was concerned it would be nitpicked in this way.
The vast majority of business records are not being sent through machine learning algorithms or being used to factor prime numbers, they’re simply lists of basic things like names, addresses, phone numbers, etc. In all of those cases, the difference between 10s or 1000s is trivial. These are the types of things people use Excel for daily.
In cases where the data processing is actually significant, then sure, bring in your data scientist.
The vast majority of business records are not being sent through machine learning algorithms or being used to factor prime numbers, they’re simply lists of basic things like names, addresses, phone numbers, etc. In all of those cases, the difference between 10s or 1000s is trivial. These are the types of things people use Excel for daily.
In cases where the data processing is actually significant, then sure, bring in your data scientist.
yes I'm aware it's nitpicking, which is why I said I agree and that it just need more clarification.
but you don't need machine learning to hit these cases just a mismatch between what want to do and how/where it's stored.
examples:
- a noSQL db that cant directly do what you want and now you need to download lots of document to string them together before updating that field.
- a SQL data schema not matching your tasks where need lots and lots of joins and aggregations.
- data scattered across multiple web APIs that may have rate limits, now you may have to use a batch API if it exists and find a new route.
- data scraped from multiple places, going from 10 to 10 000s now will get you banned from most website, now you need to rewrite your code to circumvent that.
none of these examples involve data science, heavy processing algorithms, just moving data and selecting from it. and they seems like the kind of things business/people with no coding experience might want to do. (I want to keep track of prices from competitor, department X,Y, and Z have these info in their databases and gave us read-only access since they don't have time to do things for us, etc ...)
but you don't need machine learning to hit these cases just a mismatch between what want to do and how/where it's stored.
examples:
- a noSQL db that cant directly do what you want and now you need to download lots of document to string them together before updating that field.
- a SQL data schema not matching your tasks where need lots and lots of joins and aggregations.
- data scattered across multiple web APIs that may have rate limits, now you may have to use a batch API if it exists and find a new route.
- data scraped from multiple places, going from 10 to 10 000s now will get you banned from most website, now you need to rewrite your code to circumvent that.
none of these examples involve data science, heavy processing algorithms, just moving data and selecting from it. and they seems like the kind of things business/people with no coding experience might want to do. (I want to keep track of prices from competitor, department X,Y, and Z have these info in their databases and gave us read-only access since they don't have time to do things for us, etc ...)
A lot of non-programmer office workers I've met aren't capable of writing software. Full stop. They're simply too incompetent. It's an uncomfortable truth.
I'm talking about scrum masters who have trouble navigating Jira, business analysts who aren't able to have a written conversation, product owners who struggle to create Outlook calendar invites.
Imagine asking these same people to write software rather than just use it. It isn't just a matter of training, it's a matter of disposition, and the gap is wider than we as a society care to admit.
I'm talking about scrum masters who have trouble navigating Jira, business analysts who aren't able to have a written conversation, product owners who struggle to create Outlook calendar invites.
Imagine asking these same people to write software rather than just use it. It isn't just a matter of training, it's a matter of disposition, and the gap is wider than we as a society care to admit.
> I'm talking about scrum masters who have trouble navigating Jira
I've been programming for 20 years and I still can't navigate Jira. The interface makes vim feel like a marvel of intuitive interface design.
I've been programming for 20 years and I still can't navigate Jira. The interface makes vim feel like a marvel of intuitive interface design.
8-year programmer here and I completely agree. JIRA is a perfect example of a tool that has grown so big and feature-flexible that very little is intuitive anymore.
> I'm talking about scrum masters who have trouble navigating Jira, business analysts who aren't able to have a written conversation, product owners who struggle to create Outlook calendar invites.
None of those have anything to do with writing software. You are mentioning two commercial packages with shitty user interfaces and you're talking about the skill of writing, which is hard for most people who need to write out a logical argument instead of winging it.
Apropos...
None of those have anything to do with writing software. You are mentioning two commercial packages with shitty user interfaces and you're talking about the skill of writing, which is hard for most people who need to write out a logical argument instead of winging it.
Apropos...
It has to do with people not willing to put even faintest effort in learning how to use or operate stuff that they use on a daily basis. You don't have to know JIRA "in and out" to open a board and move tickets around. If you put in 30 mins one day to set up your workflow you are done for the rest of your life. Unless other people come by and mess with the workflow, which also is not problem of JIRA but of people.
So it is not that people are stupid - it is more that people don't want to learn things. Learning things is hard.
Which goes back to why normal people run in terror when they see command line or some code.
Problem is with low code or no code platforms people still have to put in conscious effort to learn those tools and put the same effort understanding what they are doing.
I think that is the point that *booleandilemma* is making.
In the end from my POV biggest lie of "low code" is that it makes stuff simpler, but in reality it does not, you still have conditions and loops and all state to keep in mind while "low coding".
So it is not that people are stupid - it is more that people don't want to learn things. Learning things is hard.
Which goes back to why normal people run in terror when they see command line or some code.
Problem is with low code or no code platforms people still have to put in conscious effort to learn those tools and put the same effort understanding what they are doing.
I think that is the point that *booleandilemma* is making.
In the end from my POV biggest lie of "low code" is that it makes stuff simpler, but in reality it does not, you still have conditions and loops and all state to keep in mind while "low coding".
Does anyone not have trouble navigating Jira? I play Europa Universalis 4[0], and I feel like Jira is more complicated.
0: https://external-preview.redd.it/at0EwQpHU6A3xyU0KW80bc3aVMZ...
0: https://external-preview.redd.it/at0EwQpHU6A3xyU0KW80bc3aVMZ...
Jira isn’t nearly as bad as it’s made out to be, and I struggle to suggest any real alternative. The problem is that Jira do a lot of different things, and mixing those those things results in people having a bad time.
An example: don’t try to use Kanban board unless you’re planning on doing so in all project. Jira will happily show “kanban” tickets in the same overview as an ITIL incident, resulting in teams having to mentally switch between different workflows.
An example: don’t try to use Kanban board unless you’re planning on doing so in all project. Jira will happily show “kanban” tickets in the same overview as an ITIL incident, resulting in teams having to mentally switch between different workflows.
Jira isn't nearly as bad as it's made out to be, only because it's so, so, so much worse. It makes simple things obtuse and absurdly difficult, all in the name of flexibility that is more liability than feature. I hate Jira with the burning passion of a thousand fiery suns.
I've used a bespoke ticketing system. I've used Trello. I've used stickies on a whiteboard. They each had their pros and cons, but every single one of them was infinitely better than the shithole that is Jira.
I've used a bespoke ticketing system. I've used Trello. I've used stickies on a whiteboard. They each had their pros and cons, but every single one of them was infinitely better than the shithole that is Jira.
Jira is overloaded, a bit slow and a bit glitchy. But lots of software is. I tend to think that people mostly hate Jira because it reminds them of their dysfunctional processes and work in general.
Personally, from my work experience, I despise Visual Studio and Outlook a lot more (Jira is clearly trying to be usable compared to these).
Personally, from my work experience, I despise Visual Studio and Outlook a lot more (Jira is clearly trying to be usable compared to these).
I despise Jira because it is a bloated sluggish mess, and clearly the execs at Atlassian don’t give a crap about improving its performance or fixing the rough edges of its interface. Never have I loved Devtrack more than when I had to use Jira.
I agree, but the need to know special rules like this is exactly why JIRA's UX is so awful. I want my project management tools to guide us into a pit of success, not a dark rabbit hole full of sharp object.
The interfaces of Paradox games only get better with each release in my opinion.
Crusader Kings 3 looks polished and is easy to use. Leagues above CK2. I love the stackable tooltips that let you define terms in tooltips defining terms in menus.
Crusader Kings 3 looks polished and is easy to use. Leagues above CK2. I love the stackable tooltips that let you define terms in tooltips defining terms in menus.
A lot of programmers aren't capable of writing software. This is a nothing argument. Lots of office workers are very intelligent people.
I don't think you are necessarily wrong, but I'm not sure what this adds to the discussion.
There are plenty of competent people in non-programming domains. If "no-code" solutions can help these people build tools useful to them, that seems like a great thing to me.
There are plenty of competent people in non-programming domains. If "no-code" solutions can help these people build tools useful to them, that seems like a great thing to me.
I have trouble seeing your argument. People are stupid?
You may be surprised to see how good people are in their respective domains.
You may be surprised to see how good people are in their respective domains.
I've worked with several of these tools: Power Platform, Mendix, and Outsystems.
I despise the terms no code-and low-code. A better term is "visual programming" (as an alternative to text based programming). You should still follow some basic software development principles - Outsystems training in particular is excellent in this regard.
There definitely is an appetite for these tools. There is a class of business/operations people who know how to manipulate flowcharts, Excel macros and some MS Access but struggle with source code. I have worked with several team that successfully automated some processes using these tools, and were often able to create a pretty good user experience as well.
There is also no risk of this displacing developers - in my experience these tools open the imagination of what is possible and even more backend support is needed over time. Developers work on core capabilities and systems (which change slowly) and users work on creating the custom business process (which change often). With the right management it works quite nicely.
I despise the terms no code-and low-code. A better term is "visual programming" (as an alternative to text based programming). You should still follow some basic software development principles - Outsystems training in particular is excellent in this regard.
There definitely is an appetite for these tools. There is a class of business/operations people who know how to manipulate flowcharts, Excel macros and some MS Access but struggle with source code. I have worked with several team that successfully automated some processes using these tools, and were often able to create a pretty good user experience as well.
There is also no risk of this displacing developers - in my experience these tools open the imagination of what is possible and even more backend support is needed over time. Developers work on core capabilities and systems (which change slowly) and users work on creating the custom business process (which change often). With the right management it works quite nicely.
> in my experience these tools open the imagination of what is possible and even more backend support is needed over time.
I just don't buy the argument that visual programming tools are inherently more creative or imaginative than text-based programming tools because at some point, you are going to be constrained to the UI, which always comes with tradeoffs.
I recently used a visual programming environment for a work project, and I went into it thinking that it would be a fun and interesting way to program and very quickly turned to hating it. The visual aspect of the tool constantly got in my way and I quickly found myself wishing I could accomplish what I was trying to do in my text editor instead of this godforsaken web UI.
The error messaging in the tool was so bad that I wound up just intercepting the necessary HTTP calls and debugging those instead because it was so much simpler and informative than trying to navigate this "Disney World" UI that looked great with a trash UX.
I'd be OK with a visual programming tool that gives users the option to go straight to the code layer if they choose, but I've worked for so many software companies in my career that I'm just not confident that most companies would be able to ship anything with a dev UX that comes close to working with code directly. You can't get away with "happy path"-ing a visual coding tool, which is how so many companies build software these days.
I just don't buy the argument that visual programming tools are inherently more creative or imaginative than text-based programming tools because at some point, you are going to be constrained to the UI, which always comes with tradeoffs.
I recently used a visual programming environment for a work project, and I went into it thinking that it would be a fun and interesting way to program and very quickly turned to hating it. The visual aspect of the tool constantly got in my way and I quickly found myself wishing I could accomplish what I was trying to do in my text editor instead of this godforsaken web UI.
The error messaging in the tool was so bad that I wound up just intercepting the necessary HTTP calls and debugging those instead because it was so much simpler and informative than trying to navigate this "Disney World" UI that looked great with a trash UX.
I'd be OK with a visual programming tool that gives users the option to go straight to the code layer if they choose, but I've worked for so many software companies in my career that I'm just not confident that most companies would be able to ship anything with a dev UX that comes close to working with code directly. You can't get away with "happy path"-ing a visual coding tool, which is how so many companies build software these days.
> I just don't buy the argument that visual programming tools are inherently more creative or imaginative than text-based programming tools because at some point, you are going to be constrained to the UI, which always comes with tradeoffs.
They aren't inherently more creative for all people. For example there is a group of people that prefers LaTeX to MS Word - but it's undoubtable that Word is more accessible to more users. The creativity comes from letting business users directly iterate on the UI mockups and underlying process, which is possible in these tools. Instead of waiting a few months for an IT project to start, the users can create a mockup in a few days and iterate a few times before connecting to a real backend. I would have thought this was improbable 3 years ago, but personal experience has taught me that there are many business users capable of doing this.
Most of the tools created with these platforms never "ship"; the primary users are often internal. At large companies, an internal app may have 10k users. Also, YMMV depending on the tool - some are much better than others at debugging complex flows.
They aren't inherently more creative for all people. For example there is a group of people that prefers LaTeX to MS Word - but it's undoubtable that Word is more accessible to more users. The creativity comes from letting business users directly iterate on the UI mockups and underlying process, which is possible in these tools. Instead of waiting a few months for an IT project to start, the users can create a mockup in a few days and iterate a few times before connecting to a real backend. I would have thought this was improbable 3 years ago, but personal experience has taught me that there are many business users capable of doing this.
Most of the tools created with these platforms never "ship"; the primary users are often internal. At large companies, an internal app may have 10k users. Also, YMMV depending on the tool - some are much better than others at debugging complex flows.
Visual programming is an idea that keeps coming up because there are no examples of it, therefore it would seem like a great innovation.
Because there are no examples of it is precisely why it’s hard to do. Those who try either end up with something too application specific to be extended, or something too abstract to be used.
Take UML, it took the abstract route. It has many diagrams, it even has flow charts. It was big in the ‘90s and never amounted to much. Turns out that to implement something in UML is harder than just writing the code it maps to in the first place.
Because there are no examples of it is precisely why it’s hard to do. Those who try either end up with something too application specific to be extended, or something too abstract to be used.
Take UML, it took the abstract route. It has many diagrams, it even has flow charts. It was big in the ‘90s and never amounted to much. Turns out that to implement something in UML is harder than just writing the code it maps to in the first place.
UML did fail as a modeling tool - it was just too complex. However, flowcharts have succeeded on many platforms in many domains. (Gaming engines like Godot Visual Script and Unreal Engine Blueprints, BPM tools, Enterprise Integration tools, many hardware design tools)
The best environments combine visual and code based elements so you don't get "stuck" when something is missing in the low code areas.
The best environments combine visual and code based elements so you don't get "stuck" when something is missing in the low code areas.
That's a weird thing to despise. You know it's not necessary to try and put everything on a level playing field. I don't think your argument is valid on that front because when you code, you're inputting code. Nobody says "I'm going to do some text based programming" unless there's a need for that distinction in that situation. I think low code and no code are perfectly valid because you're inputting no or close to no code to achieve the task.
The main reason I despise it is that the term is often used to imply that there is "no technical debt" or "no maintenance costs" or that this is "not real programming". In reality, users are still creating software, so technical debt and other maintenance costs will still build over time. Project management, feature prioritization, data/schema design, system design, module decomposition, testing, etc are all still important tasks and don't go away just because the tools are visual.
A lot of it is due to perceptions - in my experience senior non-tech managers misunderstand the term, whereas "visual programming" still emphasizes that this is a software project with all that entails, just constructed in a more accessible way.
A lot of it is due to perceptions - in my experience senior non-tech managers misunderstand the term, whereas "visual programming" still emphasizes that this is a software project with all that entails, just constructed in a more accessible way.
+1 on these tools opening up people's imagination of what's possible. They're the experts in their domain, and having these tools allow them to project what they know onto a system that makes them more productive and efficient.
If you don't mind answering, what were the kinds of apps or processes that business/ops folks you worked with made?
If you don't mind answering, what were the kinds of apps or processes that business/ops folks you worked with made?
I work at a large healthcare equipment manufacturer - the group I worked with automated many business processes relating to equipment field sales, service, and maintenance. The end users were generally internal sales or field techs. Most of the apps are basic CRUD and maybe some video links. We're a typical large enterprise, so it takes a very long time to execute new software projects and often by the time they are done the business needs have shifted.
The users started out by using MS Power Platform and SharePoint to create simple apps and forms and get some feedback from the users. After a couple of iterations they would finalize the desired flow and my team would give them an enterprise integration point (sometimes Boomi, sometimes custom code) to read/update the real data. We are currently evaluating Mendix and Outsystems to see if that will further streamline the process.
The users started out by using MS Power Platform and SharePoint to create simple apps and forms and get some feedback from the users. After a couple of iterations they would finalize the desired flow and my team would give them an enterprise integration point (sometimes Boomi, sometimes custom code) to read/update the real data. We are currently evaluating Mendix and Outsystems to see if that will further streamline the process.
> A better term is "visual programming"
I tend to agree. "No code" seems to imply "no programming", but that's exactly what you do with these tools, just in a simplified way.
I tend to agree. "No code" seems to imply "no programming", but that's exactly what you do with these tools, just in a simplified way.
It also isn't always simpler. Once you're visually flowcharting minor text transforms "low code" is a misnomer
Yeah, text transforms are a bit of a nightmare in almost every platform. Most low code platforms have an expression or macro/function editor that would be used to deal with those - it's also ugly there. For my team, we usually cleaned them up in the back end services since citizen developers are not too familiar with these kinds of issues.
They'd all start trying to find their way into project management or design or something.
Being able to code is an important part of being a software developer but being able to code makes you no more of a software developer than learning newton's laws of motions makes you a mechanical engineer.
There are edge cases, debugging, scalability, one off errors integration, backups, etc. We tried this with VB and Acces and thedailywtf.com is rife with stories of trying to undo that mess decades later, we are going to run into the same problem with the new iteration of no code the difference this time is that we are paying per month to use it rather than just having an unsecured server in the basement running all the business critical functions.
Being able to code is an important part of being a software developer but being able to code makes you no more of a software developer than learning newton's laws of motions makes you a mechanical engineer.
There are edge cases, debugging, scalability, one off errors integration, backups, etc. We tried this with VB and Acces and thedailywtf.com is rife with stories of trying to undo that mess decades later, we are going to run into the same problem with the new iteration of no code the difference this time is that we are paying per month to use it rather than just having an unsecured server in the basement running all the business critical functions.
> being able to code makes you no more of a software developer than learning newton's laws of motions makes you a mechanical engineer.
Yes! I wish this point got more attention. So many articles - there was one on here from a16z today - pretend there is this magical thing called learning to code that takes a couple months and suddenly puts you on par with every software developer. The analogy I like to use is claiming that by taking an introduction to statics course you are somehow on par with an architect or engineer that is designing bridges and skyscrapers.
Software development needs wide acknowledgement as an actual trade that takes a broad base of theoretical and practical learning, including time spent writing code, to be proficient, and not seen through the lens of this learn to code nonsense. I've talked to so many business people who see "coding" as a skill they could pick up if they had a couple months, that would then let them be on par with career developers - if only they weren't busy with higher value work. This is one of the big reasons why many companies are so dysfunctional
Yes! I wish this point got more attention. So many articles - there was one on here from a16z today - pretend there is this magical thing called learning to code that takes a couple months and suddenly puts you on par with every software developer. The analogy I like to use is claiming that by taking an introduction to statics course you are somehow on par with an architect or engineer that is designing bridges and skyscrapers.
Software development needs wide acknowledgement as an actual trade that takes a broad base of theoretical and practical learning, including time spent writing code, to be proficient, and not seen through the lens of this learn to code nonsense. I've talked to so many business people who see "coding" as a skill they could pick up if they had a couple months, that would then let them be on par with career developers - if only they weren't busy with higher value work. This is one of the big reasons why many companies are so dysfunctional
This reminded me of "Teach Yourself Programming in Ten Years" - http://www.norvig.com/21-days.html
To the casual observer, the stereotypical age of computer programmers contradicts your claim. ;-)
While I can certainly appreciate that it takes time to mature as a developer, the job market at least reinforces the idea that you can get hired at the entry level after maybe a couple years of study. My mom's programming students got hired that quickly in the 1980s. What I do think is that the small part of software development called coding is something you can learn in a couple years. At that point you may be able to perform a useful role in a larger team of developers, e.g., under the wing of a senior, giving you time to further mature as a full blown developer.
While I can certainly appreciate that it takes time to mature as a developer, the job market at least reinforces the idea that you can get hired at the entry level after maybe a couple years of study. My mom's programming students got hired that quickly in the 1980s. What I do think is that the small part of software development called coding is something you can learn in a couple years. At that point you may be able to perform a useful role in a larger team of developers, e.g., under the wing of a senior, giving you time to further mature as a full blown developer.
Well ya, “entry level”, you said it yourself.
Yes, but it's going to be wonderful as prototyping.
Then we go back and make the GUI accessible, the backend scalable, etc.
People think we'll have no work - I am sure there will be even more work!
Yeah it turns out to be a mess, but it sometimes gets businesses off the ground. It’s crazy to think how much of the world’s software really consists of spreadsheets and macros.
Would you rather have a lot of businesses operating successfully with “poor” software or much fewer businesses operating with “good” software?
Would you rather have a lot of businesses operating successfully with “poor” software or much fewer businesses operating with “good” software?
I'm way too young to have experienced this myself and maybe this is something that has over-all been forgotten, but going back a few decades and looking at computer content from the 70s/80s it's amazing how crazy people got about spreadsheets. And that's for a good reason: It was a massive productivity boost.
These things have been driving our economy for a few decades at insane levels of productivity.
These things have been driving our economy for a few decades at insane levels of productivity.
> trying to undo that mess decades later
This implies that it has been used (successfully) for decades. That's a phenomenal success. Most software gets replaced after a few decades because the requirements change.
This implies that it has been used (successfully) for decades. That's a phenomenal success. Most software gets replaced after a few decades because the requirements change.
Honestly we’re already working towards that. Between excel and no-code tools a lot of the grunt work can now be handled by the people who need it.
The majority of stuff out there will be commodity software implementing some simple business logic and software engineers don't want to do that stuff anyway which is why we’ve been writing ourselves out of those jobs for decades.
I have a very nontechinal marketing friend who routinely dives into WP sites to diagnose dependency issues after upgrades because her work no longer thinks she _needs_ programmer support. Or connect a up web/email forms to CRM in going or outgoing and needs no assistance to create complex conditional filled marketing campaigns.
And mostly they're right. She's bad at it. It takes at least 10x as long to fixes these issues, but they occur quarterly or less. And if she can not fix it then they hire a consultant/contractor to fix it.
The majority of stuff out there will be commodity software implementing some simple business logic and software engineers don't want to do that stuff anyway which is why we’ve been writing ourselves out of those jobs for decades.
I have a very nontechinal marketing friend who routinely dives into WP sites to diagnose dependency issues after upgrades because her work no longer thinks she _needs_ programmer support. Or connect a up web/email forms to CRM in going or outgoing and needs no assistance to create complex conditional filled marketing campaigns.
And mostly they're right. She's bad at it. It takes at least 10x as long to fixes these issues, but they occur quarterly or less. And if she can not fix it then they hire a consultant/contractor to fix it.
Excel is a disaster. It will randomly corrupt input that happens to fit certain patterns by parsing it into "dates" or "numbers", unless you go to the trouble of explicitly setting the right "cell properties" via the incredibly clunky UI. It hides the code that's input in cells, lets it randomly mix with input data and does not support any kind of source control for it. It's not even fit for purpose as a prototyping tool, you're literally better off writing some code in FORTRAN IV and key-punching it into a fresh deck of punched cards. At least you're going to have proper code/data separation.
Yup, but you can make it do the job and that's enough for the majority.
It's only "enough" to them because they don't grok the failure modes. Which is basically the story of almost all "no-code" or "low-code" tools.
You can do "low-code" and even "no-code" right, but it basically has to be a DSL that's cleanly defined in terms of some other programming language with sensible semantics. That way when the DSL fails to do what you expect it to (as it invariably will at some point), you at least get to pick up the pieces and carry on. But that's not how Excel is built, or most similar tools.
You can do "low-code" and even "no-code" right, but it basically has to be a DSL that's cleanly defined in terms of some other programming language with sensible semantics. That way when the DSL fails to do what you expect it to (as it invariably will at some point), you at least get to pick up the pieces and carry on. But that's not how Excel is built, or most similar tools.
Preaching to the choir, but mostly they don't care about any of that.
It's not just that it can do the job, but that the majority has access to Excel. There may be better tools/platforms to solve a given problem, but in most cases the rank and file don't have access to them or permissions to do what they want.
"If the only tool you have is a hammer, you tend to see every problem as a nail."
"If the only tool you have is a hammer, you tend to see every problem as a nail."
I mean, we're renaming genes because of how much excel has been corrupting data.
https://www.theverge.com/2020/8/6/21355674/human-genes-renam...
I agree that there's tons of value in the paradigm (more than a lot of people on hn would admit), but excel particularly has way more sharp edges than people know.
https://www.theverge.com/2020/8/6/21355674/human-genes-renam...
I agree that there's tons of value in the paradigm (more than a lot of people on hn would admit), but excel particularly has way more sharp edges than people know.
Empowering smart people to succeed is easy, even if they dont understand your source code rune magic.
You jusy have to shift to a perspective of being an enabler/tech delegate for others. Most of that requires listening and willingness to be wrong, not individual contribution.
We have spent the last 2 years building tools and models that allow for our non-developer domain experts to handle 90%+ of software implementation concerns.
The biggest techinical key in my view is taking a data-oriented stance. This allows for you to talk about most problems in terms of excel spreadsheets, and any business logic can be developed in terms of SQL queries over those tables.
Having a rockstar developer contribute on an individual basis is amazing. Having that developer empower 1000 other employees to operate at even 1% their capacity is beyond amazing. It's also a lot more sustainable.
The elite developers who are capable of building these ecosystems don't grow on trees. If you find yourself with one, maybe have them build the fishing boat factory for you instead of forcing them to fish for every goddamn meal.
You jusy have to shift to a perspective of being an enabler/tech delegate for others. Most of that requires listening and willingness to be wrong, not individual contribution.
We have spent the last 2 years building tools and models that allow for our non-developer domain experts to handle 90%+ of software implementation concerns.
The biggest techinical key in my view is taking a data-oriented stance. This allows for you to talk about most problems in terms of excel spreadsheets, and any business logic can be developed in terms of SQL queries over those tables.
Having a rockstar developer contribute on an individual basis is amazing. Having that developer empower 1000 other employees to operate at even 1% their capacity is beyond amazing. It's also a lot more sustainable.
The elite developers who are capable of building these ecosystems don't grow on trees. If you find yourself with one, maybe have them build the fishing boat factory for you instead of forcing them to fish for every goddamn meal.
"If a programming language doesn't change how you think, it's not worth learning." ~I forget who
I always find it funny when people say things like this for our trade. I'd never imagine the likes would be said for Copy Writing or Sales, or Plumbing. Like James from the bookkeeping team decided to start rewiring the light fixtures last week. Spacing out the lights a few feet further apart, and using higher watt LED's saved the company X.
I never hear Elite Plumber or Elite Dentist. (Though I'm sure they exist)
We are no more Elite than any other profession. But we are professionals, and we do train.
I always find it funny when people say things like this for our trade. I'd never imagine the likes would be said for Copy Writing or Sales, or Plumbing. Like James from the bookkeeping team decided to start rewiring the light fixtures last week. Spacing out the lights a few feet further apart, and using higher watt LED's saved the company X.
I never hear Elite Plumber or Elite Dentist. (Though I'm sure they exist)
We are no more Elite than any other profession. But we are professionals, and we do train.
Quoth http://www.cs.yale.edu/homes/perlis-alan/quotes.html - no. 19
Well, this makes me feel old. It's no revolution, but a reversion. It was the norm, not that long ago, that anyone could do minor programming. The era of Lotus Notes and the like.
You would still hire a programmer for the big stuff, but office workers would build little scripts, or look under the covers when something goes wrong.
You would still hire a programmer for the big stuff, but office workers would build little scripts, or look under the covers when something goes wrong.
Programming is too important to be left to programmers. -- apologies to Clemenceau
I think it's possible to make productive use of programming without claiming to be developing software by which I mean, programs that are expected to be placed into long term or widespread use. That's what we did with programming in BASIC, 40 years ago.
As a scientist, I use programming for things like modeling, data analysis, lab automation, algorithm prototyping, and so forth. You folks all know why. I'm not going to sacrifice that power just because I don't develop full blown software. Scientists programmed before there was a software industry.
If something that I create threatens to end up in a product, it gets handed to the software department. We can hire an army of programmers.
Granted, there is a widely known problem with this approach. A program can evolve to the point where it's really "too big" for a non-developer to manage, but "too small" to justify the cost of spinning up a software development project in a typical organization. I don't have a good solution for that problem.
I think it's possible to make productive use of programming without claiming to be developing software by which I mean, programs that are expected to be placed into long term or widespread use. That's what we did with programming in BASIC, 40 years ago.
As a scientist, I use programming for things like modeling, data analysis, lab automation, algorithm prototyping, and so forth. You folks all know why. I'm not going to sacrifice that power just because I don't develop full blown software. Scientists programmed before there was a software industry.
If something that I create threatens to end up in a product, it gets handed to the software department. We can hire an army of programmers.
Granted, there is a widely known problem with this approach. A program can evolve to the point where it's really "too big" for a non-developer to manage, but "too small" to justify the cost of spinning up a software development project in a typical organization. I don't have a good solution for that problem.
There was plenty of actual, production software written in some variety of BASIC. The language(s) definitely had its weakness, but it was not uniformly terrible. Especially once the "structured" varieties were introduced.
For many BASIC was the gateway drug to programming in the same way that JavaScript is today, it was included with almost every system.
And Hypercard / Filemaker. The things I've seen non IT people build with those still blow me away.
A lot of us office workers still do. I prefer to keep scripts little and just use OTT software as much as possible. Often, scripting is not possible to avoid.
The author miss the point that coding complexity is exponential, not linear.
I.e. a lot of people can understand 10-20 lines of code, less can 100 LOC, less can 1000 LOC, maybe top 10% can understand 10K, 1% - 100K.
So no code can work, just that the size limit of the program will be low (10-100 LOC) .
However, most program start at low LOC, but ends up with high LOC, where the low code tools breaks.
Hence, the low code tools basically guarantee the future of the elite geeks.
I.e. a lot of people can understand 10-20 lines of code, less can 100 LOC, less can 1000 LOC, maybe top 10% can understand 10K, 1% - 100K.
So no code can work, just that the size limit of the program will be low (10-100 LOC) .
However, most program start at low LOC, but ends up with high LOC, where the low code tools breaks.
Hence, the low code tools basically guarantee the future of the elite geeks.
There is a difference between understanding 10, 100, and maybe 1000+ but beyond that I'm not so sure. Who really understands a 100k code base they didn't write themselves except at a high level anyway? I think once a developer accrues an understanding of certain key abstractions, it's just a matter of exposure and practice working within code bases.
No-code is a separate issue. Visually organized programs become very hard to understand very quickly.
No-code is a separate issue. Visually organized programs become very hard to understand very quickly.
Right, a professional programmer uses advanced tools and design pattern such that 100K can look like 1001K or 1000 100 LOC.
The complexity of a software system is due to interaction between its components. A professional developer know how to make it N instead of N2.
Note that most of the big software system that you know, were written by a single/two developers - C++/ Java / Unix / Linux / Riser FS / Kubernetes.
This can be evident by the power law distribution of github commits for every popular github project.
The complexity of a software system is due to interaction between its components. A professional developer know how to make it N instead of N2.
Note that most of the big software system that you know, were written by a single/two developers - C++/ Java / Unix / Linux / Riser FS / Kubernetes.
This can be evident by the power law distribution of github commits for every popular github project.
The trick to solving this is called scope. Because even that 1% won't be able to understand 100K lines all at once. They can also only understand the 20 lines in front of them (hopefully!). But they know how to use abstraction, and once that tool is in your box divide and conquer will get you to 100K LOC without losing your way.
So no code can work, just that the size limit of the program will be low (10-100 LOC)
This ignores the fact that each "line of code" in a "no code" app does significantly more than 1 line of code. The benefit of no code tools is that they solve the very problem you're claiming stops them being useful.
This ignores the fact that each "line of code" in a "no code" app does significantly more than 1 line of code. The benefit of no code tools is that they solve the very problem you're claiming stops them being useful.
Ok replace LOC with ‘Steps’. Its domain complexity, data types, relations, state, and the network that makes all of this hard. No-code doesn’t solve for big problems, but it sure does work for integration and the next million CRUD apps that fit highly specific niches.
Somebody who can write clever excel formulas can pick up a no code tool and be productive on day 1. That doesn’t mean they can go from there to writing an operating system - there is higher and lower abstractions that need to be considered, which comes from both experiences and the concepts they mature coding languages expose you to.
Somebody who can write clever excel formulas can pick up a no code tool and be productive on day 1. That doesn’t mean they can go from there to writing an operating system - there is higher and lower abstractions that need to be considered, which comes from both experiences and the concepts they mature coding languages expose you to.
I don't think anyone is suggesting people will make operating systems in a no code app. They're designed to make building CRUD apps easy. The thing is though ... CRUD apps are 90% of the dev industry (by dev headcount, not revenue).
For those who are skeptical of no-code/low-code, I am too, but here's perhaps a useful intuition pump / prompt for thought.
Excel is a low-code tool backed by a scripting language for customization (VBA). There's no argument that this tool has enormous business value and is basically never, ever going away. So, what can't Excel do, and does it make sense for there to be another low-code tool that fills those niches? What's in the space between "can be done in Excel" and "must be done by professional software engineers"?
Here are some tools I think fit the bill: Airtable, Alteryx, Looker...
(I kind of hate Alteryx at my company but it's not the software's fault, it's the company being stingy with licenses which makes people's workflows harder to learn about)
Excel is a low-code tool backed by a scripting language for customization (VBA). There's no argument that this tool has enormous business value and is basically never, ever going away. So, what can't Excel do, and does it make sense for there to be another low-code tool that fills those niches? What's in the space between "can be done in Excel" and "must be done by professional software engineers"?
Here are some tools I think fit the bill: Airtable, Alteryx, Looker...
(I kind of hate Alteryx at my company but it's not the software's fault, it's the company being stingy with licenses which makes people's workflows harder to learn about)
> (I kind of hate Alteryx at my company but it's not the software's fault, it's the company being stingy with licenses which makes people's workflows harder to learn about)
This brings up a great counter-argument to visual programming tools, which is vendor lock-in. We talk about this a lot on the cloud architecture side, but surely this also becomes a concern if a commercial visual programming tool becomes an integral part of one's core business domain. And if the solution to this problem is some sort exportable code, then what's the point?
This brings up a great counter-argument to visual programming tools, which is vendor lock-in. We talk about this a lot on the cloud architecture side, but surely this also becomes a concern if a commercial visual programming tool becomes an integral part of one's core business domain. And if the solution to this problem is some sort exportable code, then what's the point?
I could be OK with it if it exported some crappy machine-generated SQL, which lots of other tools can do. But yes, when you use these tools you're at the mercy of the vendor and their willingness to play well with others.
From a purely selfish perspective Alteryx is a disaster for me because I often need to see inside business process and Alteryx obstructs this more than other tools. But users swear by it so I have to grudgingly admit it's a "good" tool.
From a purely selfish perspective Alteryx is a disaster for me because I often need to see inside business process and Alteryx obstructs this more than other tools. But users swear by it so I have to grudgingly admit it's a "good" tool.
In my experience, whenever user-developed software grows to achieve some kind of critical mass in a large company, it is nearly always discovered that the rapid development and agility was achieved by a complete disregard for the kind of table-stakes engineering practices most take for granted.
Like: "Oh, you control changes to your massive Excel macro that Does The Thing by renaming the sheet and putting it on a shared drive, and it's never tested, and you have no idea who is using which versions of it, and hardcoded credentials for the database backend which running on your desktop which has no defined backup policy, and by the way also contains PII?"
Like: "Oh, you control changes to your massive Excel macro that Does The Thing by renaming the sheet and putting it on a shared drive, and it's never tested, and you have no idea who is using which versions of it, and hardcoded credentials for the database backend which running on your desktop which has no defined backup policy, and by the way also contains PII?"
Though I have seen user-developed software used the right way, I've also seen what you've described.
Aside from the concerns you raise, there also a tendency for information to get siloed. Different areas of the business start hoarding data. And people start using the same term to describe different things, etc. The incentive to share and use common definitions is often lost.
Aside from the concerns you raise, there also a tendency for information to get siloed. Different areas of the business start hoarding data. And people start using the same term to describe different things, etc. The incentive to share and use common definitions is often lost.
As someone who hasn't seen user-developed software built the right way, I'm very curious to know what enabled such an outcome. What processes or infrastructure helped prevent the situation described in the parent comment?
I imagine there's other ways to do it, but the biggest difference was a sort of centralized visibility and watching the user-developed stuff as it evolved. Then interceding politely to get anything off fixed. Linking like tables, identifying who the authoritative source is, changing field names, providing some sort of discovery of what exists, pointing out data privacy issues, etc.
Basically making sure there's a caretaker, and that they try to help and guide versus lock down and dictate, where practical.
Basically making sure there's a caretaker, and that they try to help and guide versus lock down and dictate, where practical.
Is that "a" caretaker, or a team? From your first paragraph it sounds like an awful lot of oversight, to where this sort of "user developed software" is rather different in spirit from what we're generally describing with that term.
Excel would lead to far fewer problems if you had a centralized "spreadsheet unification and QA" team overseeing all the spreadsheets...but then you'd see people opting out of that in order to move quickly, and the problem repeats itself.
Excel would lead to far fewer problems if you had a centralized "spreadsheet unification and QA" team overseeing all the spreadsheets...but then you'd see people opting out of that in order to move quickly, and the problem repeats itself.
>Is that "a" caretaker, or a team?
Like anything else, the team size would vary, based on workload.
As for Excel, it doesn't lend itself well to centralization. Lots of spreadsheets would float around on local drives, email, wouldn't have any simple inbuilt way to determine who is using them, how often, if they even exist, if they were ever going to be shared with more than one person, and so on.
Like anything else, the team size would vary, based on workload.
As for Excel, it doesn't lend itself well to centralization. Lots of spreadsheets would float around on local drives, email, wouldn't have any simple inbuilt way to determine who is using them, how often, if they even exist, if they were ever going to be shared with more than one person, and so on.
I expect that this is largely down to a fundamental UX mismatch of what's easy and what's not. You could probably "force" (encourage) some good practices rather easily by just making it easier to use them than to not use them. Backups would be a good example. This doesn't necessarily work for more complex things, but it seems to me (I am not very experienced with them) that a large part of these low code tools is exactly about making easy solutions like a hacked-up Excel sheet production-grade by doing the complex plumbing (like backups) for you.
The number of people conflating the high degree of skills and traits required to be a successful professional software engineer with the basic computer literacy and "hold my beer" ingenuity of day to day "citizen development" of Excel macros, RAD tools, and browser boommarklets is infuriating.
If you are one of those people: stop right now and go watch someone build something PowerApp or Appian.
Here's a good representative videos, feel free to watch at 2x speed, the details are unimportant.
https://youtu.be/s6-C2xismq4
And then read the comments on that video.
THAT is who this article is talking about; THOSE are citizen developers.
They are not learning Python or Go or recursion or symbolic logic. They are not on StackOverflow or Dev.To, they're not contributing on GitHub, they're not applying for Staff Engineer or even entry level web dev positions.
And they’re self-servicing precisely because anyone who knows how to code like a professional is working on way harder technical problems.
A Michelin chef makes thousands of meals a week, but they can't feed the world.
So we have cookbooks and air fryers and microwaves and ready to eat meals and yes they’re unhealthy or taste like cardboard or whatever but they fill the need.
Nobody is insisting everyone's food be made by Beard winners; but somehow they can't make the same leap that people can develop computer-aided solutions to their business problems without being Alan Turing.
And the "revolution" is just that automation of the middleware required to support these kind of folks - APIs, IaC, data catalogs - is reaching critical mass.
The available ingredients for the "cookbook" are better, and so the possible recipes are better.
Sprinkle in a little AI (think Clippy on steroids) and the home "cook" can make a satisfying enough meal.
Will they work at FAANG or build the next one? No? Who cares...?
If you are one of those people: stop right now and go watch someone build something PowerApp or Appian.
Here's a good representative videos, feel free to watch at 2x speed, the details are unimportant.
https://youtu.be/s6-C2xismq4
And then read the comments on that video.
THAT is who this article is talking about; THOSE are citizen developers.
They are not learning Python or Go or recursion or symbolic logic. They are not on StackOverflow or Dev.To, they're not contributing on GitHub, they're not applying for Staff Engineer or even entry level web dev positions.
And they’re self-servicing precisely because anyone who knows how to code like a professional is working on way harder technical problems.
A Michelin chef makes thousands of meals a week, but they can't feed the world.
So we have cookbooks and air fryers and microwaves and ready to eat meals and yes they’re unhealthy or taste like cardboard or whatever but they fill the need.
Nobody is insisting everyone's food be made by Beard winners; but somehow they can't make the same leap that people can develop computer-aided solutions to their business problems without being Alan Turing.
And the "revolution" is just that automation of the middleware required to support these kind of folks - APIs, IaC, data catalogs - is reaching critical mass.
The available ingredients for the "cookbook" are better, and so the possible recipes are better.
Sprinkle in a little AI (think Clippy on steroids) and the home "cook" can make a satisfying enough meal.
Will they work at FAANG or build the next one? No? Who cares...?
Programmers are essential to the modern business, and management absolutely hates that. It is very easy to extract money from the market, by promising management that they’ll no longer be dependent on programmers.
Code free, no code, visual development tool, rapid application development etc. has been a promised since the sixties or so.
Ever since the first programmer said “Hey this skill is pretty rare, I should get a nice raise”, have the bosses been saying “Free us from needing programmers, and we’ll pay whatever you want”
Code free, no code, visual development tool, rapid application development etc. has been a promised since the sixties or so.
Ever since the first programmer said “Hey this skill is pretty rare, I should get a nice raise”, have the bosses been saying “Free us from needing programmers, and we’ll pay whatever you want”
Coding may become ubiquitous, but visual coding isn't always easier than textual programming languages.
Back around 2001 we created no-code visual scripting logic bricks for the Blender Game Engine: sensors (keyboard, collision, raycast) controllers (and, or, etc) and actuators (move, play sound, animation etc).
Some games became very complex, with hundreds of linked blocks. We introduced a Python controller, that could do everything with or without using logic bricks and text scripting was much more concise.
Back around 2001 we created no-code visual scripting logic bricks for the Blender Game Engine: sensors (keyboard, collision, raycast) controllers (and, or, etc) and actuators (move, play sound, animation etc).
Some games became very complex, with hundreds of linked blocks. We introduced a Python controller, that could do everything with or without using logic bricks and text scripting was much more concise.
Having worked quite a bit with no/low-code abstractions and “workflow automations” I’ve seen a few problems arising over and over:
- ownership and its boundaries becomes blurred
- maintainability over time
- lack of systems thinking and architecture
These are things we struggle with in organizations with dedicated development teams!
When parts of critical apps or workflows become like “xls in sharepoint” - PoC’ing is dreamy, anything beyond that potentially very painful.
Just my 2c, although I’m keeping a watchful eye on this segment.
- ownership and its boundaries becomes blurred
- maintainability over time
- lack of systems thinking and architecture
These are things we struggle with in organizations with dedicated development teams!
When parts of critical apps or workflows become like “xls in sharepoint” - PoC’ing is dreamy, anything beyond that potentially very painful.
Just my 2c, although I’m keeping a watchful eye on this segment.
I'm a full-time developer, but I had a recent need for some quick internal tooling coincide with a HN posting about Budibase, and it sent me down a low code/no code rabbit hole. I evaluated a bunch of tools in that segment briefly, and spent a nontrivial amount of time on Budibase and Appsmith. And while I admire what they're trying to do, it was a disappointing journey. I made no serious progress, then threw together what I had in mind in React in half the time. Having spent some of this time researching that field, there sure seems to be a renaissance of what we'd call RAD (rapid application development) when I came of age. But it's astonishing how little progress was made since then. A younger me built some "applications" in Microsoft Access, which was not at all more frustrating than using these current day tools. So, Citizen Developers... good luck!
I am old enough to recall RAD, and young enough to have seen a few of these low/no code solutions come and go.
Don't get me wrong. I love them as a coder. Once I get the hang of them, I can bang out powerful stuff in a few minutes.
The problem is (IMO) to get to that level, you have to already be a coder to some extent. I strongly suspect this stated success story had a ton of upskilling help from MSFT, if not hand-holding.
I would not bet on a non-coder coming fresh to these platforms and building something useful with no other context. In their current state they are likely to be (very powerful) lazy programmer tools.
Until there is some paradigm shift I do not see the "Citizen Developer" becoming a practical reality. A field tech who crimps ethernet all day is going to have to learn some programmer skills to make a power app that pulls data from an API, parses the JSON and then does something useful with it.
Don't get me wrong. I love them as a coder. Once I get the hang of them, I can bang out powerful stuff in a few minutes.
The problem is (IMO) to get to that level, you have to already be a coder to some extent. I strongly suspect this stated success story had a ton of upskilling help from MSFT, if not hand-holding.
I would not bet on a non-coder coming fresh to these platforms and building something useful with no other context. In their current state they are likely to be (very powerful) lazy programmer tools.
Until there is some paradigm shift I do not see the "Citizen Developer" becoming a practical reality. A field tech who crimps ethernet all day is going to have to learn some programmer skills to make a power app that pulls data from an API, parses the JSON and then does something useful with it.
Why not? The problem is people can’t. I’m all for people learning how to code but majority of people can’t. That’s the reality.
I taught coding in college and bootcamps.
I taught coding in college and bootcamps.
IMO it depends on how long your willing to spend teaching people. Most young students can eventually get basic programs working in logo style systems given enough time. Make coding a core part of public education and I think we could see 80+% of people get reasonable competency by high school graduation.
Collages and especially boot camps on the other hand expect people to pick things up much more quickly, and I think that works because students often have most of the skills they need rather than it being enough time to actually teach people the relevant skills. It’s almost more a filtering process than education.
Collages and especially boot camps on the other hand expect people to pick things up much more quickly, and I think that works because students often have most of the skills they need rather than it being enough time to actually teach people the relevant skills. It’s almost more a filtering process than education.
You only need to spend time teaching a few semesters to have this belief completely turned upside down.
I know, because it happened to me.
I know, because it happened to me.
That wasn’t just a guess, the logo thing was from actual experience.
I have also known people that learned to code over a decade that needed to copy peoples homework to get through collage. One spent a long time setting up and troubleshooting network routers before things clicked. Another learned via increasingly complex sysadmin scripts, until he fell in a pure programming job.
Meanwhile a coworker of mine had a philosophy degree but two programming courses where more than enough to get him productive.
I have also known people that learned to code over a decade that needed to copy peoples homework to get through collage. One spent a long time setting up and troubleshooting network routers before things clicked. Another learned via increasingly complex sysadmin scripts, until he fell in a pure programming job.
Meanwhile a coworker of mine had a philosophy degree but two programming courses where more than enough to get him productive.
Seems you were having some good students. Try to teach in some community college or low income area.
People cannot code if you ask them to do something they don't understand.
I have seen people who have none of step, if and loop basics nailed down sitting in C++ class and be very frustrated why nothing they do is "correct". They hope get lucky and get their program right by throwing some things at the wall. That is because they have never experienced successfully putting multiple simple steps together in a list to achieve something meaningful.
Play some kid games where you need to put in steps, if statements and loops to move some character around obstacles. Need to give time to intuitively understand and develop curiosity about what is possible next. Then learn what is an API and what can be done when interacting with those. Then go to overview of a code file, variables and Hello world.
When people are clueless and you say it is "simple" - It is over. Few minutes later their brain starts blocking everything that looks like code to preserve their ego and they lose all interest.
That is result of skipping basics not giving a week to feel good about successfully playing some game with steps, ifs and loops. Going forward while still clueless and before interest for next step is in place.
I have seen people who have none of step, if and loop basics nailed down sitting in C++ class and be very frustrated why nothing they do is "correct". They hope get lucky and get their program right by throwing some things at the wall. That is because they have never experienced successfully putting multiple simple steps together in a list to achieve something meaningful.
Play some kid games where you need to put in steps, if statements and loops to move some character around obstacles. Need to give time to intuitively understand and develop curiosity about what is possible next. Then learn what is an API and what can be done when interacting with those. Then go to overview of a code file, variables and Hello world.
When people are clueless and you say it is "simple" - It is over. Few minutes later their brain starts blocking everything that looks like code to preserve their ego and they lose all interest.
That is result of skipping basics not giving a week to feel good about successfully playing some game with steps, ifs and loops. Going forward while still clueless and before interest for next step is in place.
It’s not even that binary. I can code about anything I’d want to, but I’m also aware of lower level code that I just simply will never have the desire to learn. It really is over my head and probably always will be.
I've heard it said that Excel is the world's most popular IDE.
Given what I have seen of some spreadsheets, I am quite glad we don't push those people into programming who aren't interested in doing so.
Given what I have seen of some spreadsheets, I am quite glad we don't push those people into programming who aren't interested in doing so.
Traditional programming? I would agree. But no code tooling? I think you'd be surprised.
As someone with experience supporting these types of people utilizing a no code platform, most of them actually thrive when given a toolset that is appropriate for the problem they are trying to solve.
The vast majority of the Excel/Access mess stems from the fact that those are the only tools people have access to use. Solutions get wedged in and people get into the weeds because if they can't make it work somehow they don't get a solution.
They build way more functional/sane things when given the right toolset to solve the problem.
As someone with experience supporting these types of people utilizing a no code platform, most of them actually thrive when given a toolset that is appropriate for the problem they are trying to solve.
The vast majority of the Excel/Access mess stems from the fact that those are the only tools people have access to use. Solutions get wedged in and people get into the weeds because if they can't make it work somehow they don't get a solution.
They build way more functional/sane things when given the right toolset to solve the problem.
It's kind of amazing if you think about it that most people are able to learn to read. Spoken language I can understand since it can evolve. Then one day people started writing things down and it turns out somehow we are pretty good at reading things back almost as well as talking to one another. Programming doesn't seem to be like that at all.
Two big differences I see:
1. Most people who learn to read start from a young age. It's rare to teach programming at 6 or incedently practice it everyday.
2. Reading is almost the same as listening, like a 1:1 mapping. So it's evolved with spoken language.
1. Most people who learn to read start from a young age. It's rare to teach programming at 6 or incedently practice it everyday.
2. Reading is almost the same as listening, like a 1:1 mapping. So it's evolved with spoken language.
Word meaning tangent: I have never heard the expression "line-of-business employee" before and I'm not quite sure what it means. Is it trying to differentiate from the "IT department" which is a cost centre?
Or are they just trying to say "ordinary employees" as in non-technical? Why don't they just use a generic term like "office workers" or something?
Or are they just trying to say "ordinary employees" as in non-technical? Why don't they just use a generic term like "office workers" or something?
Yes, LOB is consultant speak for "non-IT employee" (after reading your comment, I can't tell if it's a badge of pride or shame that this jargon is second nature to me)
It's because (rightly so) IT gets mad when you insinuate they are not part of "the business"
So "line of business" is the compromise to mean "any business unit but IT"
It's because (rightly so) IT gets mad when you insinuate they are not part of "the business"
So "line of business" is the compromise to mean "any business unit but IT"
Thx for the explanation.
> [...] I can't tell if it's a badge of pride or shame [...]
Lol... shame, definitely shame ;)
> [...] I can't tell if it's a badge of pride or shame [...]
Lol... shame, definitely shame ;)
I think the big issues present in many large companies isn’t democratic coding but interdependent technology architectures and business processes that must rely on centralized planning. In this case speed to market is a challenge due to the overall coordination burden and a hodgepodge of specialized technology and business domain logic. Coding and lack of coders generally aren’t the issue at big corps, it’s getting them meaningful instruction on what the business needs that is coordinated with all the other aspects of the business to yield productive outcomes. It’s why project costs are usually 30% developers and 70% overhead. There’s typically nothing democratic about this type of environment and low code / no code platforms can’t solve this type of issue.
I don't want to make fun of the idea, because more people thinking about software as a tool they can influence is good, however the initial paragraph which says, paraphrased:
Giant corporation had $12 million software problem they had no process for flagging up and fixing properly, until an untrained employeed took it upon themselves to personally sort, seems like the bigger issue.
If that kind of thing can happen, the the user created app can be mismanaged into catastrophe as well from similar root causes.
And wouldn't we all be better off if having decent software tools to complete your tasks was just table stakes in modern corporate life, rather than something to write excitable stories about?
Giant corporation had $12 million software problem they had no process for flagging up and fixing properly, until an untrained employeed took it upon themselves to personally sort, seems like the bigger issue.
If that kind of thing can happen, the the user created app can be mismanaged into catastrophe as well from similar root causes.
And wouldn't we all be better off if having decent software tools to complete your tasks was just table stakes in modern corporate life, rather than something to write excitable stories about?
Ah yes, the no-code dream of shareholders.
”Why pay those pesky developers if you can just click it together, how hard can it really be, I became CEO/sales/random-other-thing because I'm really smart, so this will be easy too.”
Every year I see this post rear its head, can we agree we only post it again when it's actually possible and not some CEO 'has a great idea that nobody thought about'?
Every year I see this post rear its head, can we agree we only post it again when it's actually possible and not some CEO 'has a great idea that nobody thought about'?
I think it low code/no code only gets you so far. I've worked in many places that were driven by an excel spreadsheet.
Hacked together solutions work fine, to a point, that's where us "geek elite" take over, and that's fine in my opinion.
Hacked together solutions work fine, to a point, that's where us "geek elite" take over, and that's fine in my opinion.
[deleted]
I don't think that "no-code" is the solution but I do think that we can treat some methods of creating software more like a trade skill.
There are ways to code web apps that can lower the bar of entry by quite a bit. That's not to say one wouldn't have to learn a lot to do it well, but that is true with any trade skill.
If we had classes in schools that focused on making apps using available tools like jQuery, PouchDB.js, Bootstrap, that's pretty easy to learn.
From there businesses could hire skilled workers to install and modify software they get free or purchase and tailor it to their needs.
I think it's fair to say that not everyone has what it takes to learn those skills. I took trombone lessons for a semester in 6th grade and never did hit a single note right. Not even close. Still can't.
There are ways to code web apps that can lower the bar of entry by quite a bit. That's not to say one wouldn't have to learn a lot to do it well, but that is true with any trade skill.
If we had classes in schools that focused on making apps using available tools like jQuery, PouchDB.js, Bootstrap, that's pretty easy to learn.
From there businesses could hire skilled workers to install and modify software they get free or purchase and tailor it to their needs.
I think it's fair to say that not everyone has what it takes to learn those skills. I took trombone lessons for a semester in 6th grade and never did hit a single note right. Not even close. Still can't.
I really wish we put guard rails in the form of fines and damages to prevent people from exposing private or sensitive data. Handing people who have no idea about security or sensitivity of data the keys to the kingdom is like handing a toddler a loaded gun. Or a JavaScript, front-end UX developer the AWS root keys.
Oh wait, we've already done that - and we regularly see them blow their parent company's heads off.
Oh wait, we've already done that - and we regularly see them blow their parent company's heads off.
The bulk of the main dataleaks are from internet connected services which usually are built by programmers rather than end users.
[deleted]
I was well paid in the 90's to program a desktop application that saved some Telefonica contractors from using its web application. I guess it's what they call "scrapper" now.
The web was incredibly slow and unreliable. Money aside, I still feel a steady incoming karma flow :)
The web was incredibly slow and unreliable. Money aside, I still feel a steady incoming karma flow :)
Not everyone can play in the NBA. Not everyone can safely drive a car. Not everyone can architect and write good code.
Yes, you can spend a LOT of time and get kinda good-ish at basketball, but you'll never make it to the NBA. You lack the biological talent (height, speed). Sure, you can work very hard and take serious driving classes, but you'll never win an F1 race even if given a chance. You lack the biological talent (reaction speed, ears able to better hear details in the engine noise, higher visual acuity). And sure, you can work very hard and learn how to write code, but that will not magically make you good at architecting solutions properly and producing code worth paying for. You lack the talent (ability to think abstractly)
Please do not try to counter any of these examples. They are clearly just that. I am sure sometime someone was short in the NBA and maybe your aunt once took a defensive driving class and it saved her life, but the point is clear.
Yes, you can spend a LOT of time and get kinda good-ish at basketball, but you'll never make it to the NBA. You lack the biological talent (height, speed). Sure, you can work very hard and take serious driving classes, but you'll never win an F1 race even if given a chance. You lack the biological talent (reaction speed, ears able to better hear details in the engine noise, higher visual acuity). And sure, you can work very hard and learn how to write code, but that will not magically make you good at architecting solutions properly and producing code worth paying for. You lack the talent (ability to think abstractly)
Please do not try to counter any of these examples. They are clearly just that. I am sure sometime someone was short in the NBA and maybe your aunt once took a defensive driving class and it saved her life, but the point is clear.
Not everyone can be a successful novelist, but we all can read and write.
It is OK to have basic literacy, and the educational system is quickly adopting coding as part of basic literacy. That, in turn is making more and more people good enough to do basic coding, even if they will never do it as a professional career.
Just like people play basketball in their drive. Just like they drive their cars around town.
It is OK to have basic literacy, and the educational system is quickly adopting coding as part of basic literacy. That, in turn is making more and more people good enough to do basic coding, even if they will never do it as a professional career.
Just like people play basketball in their drive. Just like they drive their cars around town.
I absolutely support everyone learning it. But for most it will be as annoying and ungratifying as calculus is to them in school. Tedious, and they'll never get good enough to get a job where they use it.
I'd bring it closer to shop class.
They might make a decent birdhouse/python app, but after that most will just put the knowledge on the shelf.
They might make a decent birdhouse/python app, but after that most will just put the knowledge on the shelf.
> and the educational system is quickly adopting coding as part of basic literacy
If only. They're mostly fooling around with random low-code or no-code tools that get misrepresented as "learning to code", when literally just teaching BASIC, LOGO or PASCAL in K-12 the way they used to do it back in the 1980s would bring us all a lot closer to that worthwhile goal.
If only. They're mostly fooling around with random low-code or no-code tools that get misrepresented as "learning to code", when literally just teaching BASIC, LOGO or PASCAL in K-12 the way they used to do it back in the 1980s would bring us all a lot closer to that worthwhile goal.
It’s not that much about playing NBA.
More being able to play a game of basketball. Or watch one and understand the rules.
Or knowing when you need to call a plumber vs running to Lowe’s and fix it yourself.
I don’t thing we should expect anybody beside software engineers to be software engineers.
But a greater code literacy would go a long way.
Imagine scenarios where you hand over your code delivery to a client that can actually run and manage it.
I don’t know what NBA level would mean for software.
You need a uncanny, almost innate ability to perform in a extremely competitive field, where a ton of other really good agents are operating at the same time.
I can’t think of anything like that in software really. E-sport would apply but it’s not really the subject. Maybe some demo-scenes? Or raw effective genius ala John carmak.
Or knowing when you need to call a plumber vs running to Lowe’s and fix it yourself.
I don’t thing we should expect anybody beside software engineers to be software engineers.
But a greater code literacy would go a long way.
Imagine scenarios where you hand over your code delivery to a client that can actually run and manage it.
I don’t know what NBA level would mean for software.
You need a uncanny, almost innate ability to perform in a extremely competitive field, where a ton of other really good agents are operating at the same time.
I can’t think of anything like that in software really. E-sport would apply but it’s not really the subject. Maybe some demo-scenes? Or raw effective genius ala John carmak.
> Not everyone can play in the NBA.
Writing code as part of a job isn't being in the NBA, it's just like writing as part of a job.
> Not everyone can safely drive a car.
A better analogy for code, but only a very small share of those who are employable at all are not employable in a job where driving a vehicle is a part (though not necessarily a central part) of the job.
There's no reason coding can't be like that.
> Not everyone can architect and write good code.
Not everyone can organize and write quality prose, either, but most people who can't can still get jobs where writing text is a required part of the job.
Writing code as part of a job isn't being in the NBA, it's just like writing as part of a job.
> Not everyone can safely drive a car.
A better analogy for code, but only a very small share of those who are employable at all are not employable in a job where driving a vehicle is a part (though not necessarily a central part) of the job.
There's no reason coding can't be like that.
> Not everyone can architect and write good code.
Not everyone can organize and write quality prose, either, but most people who can't can still get jobs where writing text is a required part of the job.
Aren’t they bad examples? There’s a distinction between an extremely rare occurrence of biological factors like being 7 feet tall in order to succeed, and that of needing a decent education in order to think critically.
Some people just cannot wrap their head around pointers. Some just do not get recursion no matter what. I used to teach CS, and tutor in CS. It is as rare as being 7 feet tall, sadly. And without understanding indirection and recursion, the most you'll ever do is ...well..not much...
Sit in a room and point at a spot on the floor.
You are a pointer, pointing at nothing.
Attempt to put shit where you're pointing and you have shite all over the floor.
Malloc creates a bucket. Now when you put shit where you're pointing it lands in a bucket.
When you're done with the bucket you clean it up.
If you try to put too much in the bucket, you end up with shite all over the floor.
If you forget to clean up the bucket, the place will start to stink.
If you change the pointer so nothing is pointing at the bucket of shit, then it will just sit there, forgotten. But the shit is still there.
No one ever forgets this way of teaching it.
You are a pointer, pointing at nothing.
Attempt to put shit where you're pointing and you have shite all over the floor.
Malloc creates a bucket. Now when you put shit where you're pointing it lands in a bucket.
When you're done with the bucket you clean it up.
If you try to put too much in the bucket, you end up with shite all over the floor.
If you forget to clean up the bucket, the place will start to stink.
If you change the pointer so nothing is pointing at the bucket of shit, then it will just sit there, forgotten. But the shit is still there.
No one ever forgets this way of teaching it.
> It is as rare as being 7 feet tall, sadly.
Objectively not true? Not even close to true.
I guarantee you there are many orders of magnitude more people in the world who understand recursion and that understand pointers than there are people who are 7 feet tall. Being 7 feet tall is extremely rare, and building a functioning C app is not.
The average height of an NBA player at the highest level of the sport is under 7 feet.
----
I don't understand why we're all commenting under this thread accepting the premise that good programmers are rare. They're not, look at the size of the industry and the output. The only way this argument makes sense is if you redefine "good" to mean something incredibly exclusionary, and even if you do it's impossible to argue that none of the software coming out of the industry is producing any value for users or solving any problems that they have.
> And without understanding indirection and recursion, the most you'll ever do is ...well..not much...
How do you think we have a software industry at all if you're claiming that both:
A) only an extreme minority of the population (<1 in a million) is capable of understanding very basic concepts like pointers, and also
B) it's impossible to build useful tools without them.
One of those two things has to be false, or you have to explain to me why the entire software industry hasn't collapsed by now from lack of talent and lack of output.
Objectively not true? Not even close to true.
I guarantee you there are many orders of magnitude more people in the world who understand recursion and that understand pointers than there are people who are 7 feet tall. Being 7 feet tall is extremely rare, and building a functioning C app is not.
The average height of an NBA player at the highest level of the sport is under 7 feet.
----
I don't understand why we're all commenting under this thread accepting the premise that good programmers are rare. They're not, look at the size of the industry and the output. The only way this argument makes sense is if you redefine "good" to mean something incredibly exclusionary, and even if you do it's impossible to argue that none of the software coming out of the industry is producing any value for users or solving any problems that they have.
> And without understanding indirection and recursion, the most you'll ever do is ...well..not much...
How do you think we have a software industry at all if you're claiming that both:
A) only an extreme minority of the population (<1 in a million) is capable of understanding very basic concepts like pointers, and also
B) it's impossible to build useful tools without them.
One of those two things has to be false, or you have to explain to me why the entire software industry hasn't collapsed by now from lack of talent and lack of output.
This kind of gatekeeping is ... beyond parody.
Have you ever used a no code application?
They never - not even close - mention pointers.
You can create great business apps without ever understanding a pointer.
What's so hard about understanding this?
Not every piece of software is Linux, or an NSA-worthy encryption algorithm, or a bespoke Silcon Valley web forum for that matter.
I don't know how a carburetor works but I can pump my own gas.
I don't have a medical degree but I am still allowed to self-medicate a cold.
I tune out when math PhDs start geeking out, but I can do my taxes.
I am aware of what a pointer is, but my old ship captain-turned-trading desk boss most certainly is not and he wrote several nifty SharePoint workflows to automate invoice approvals and legal reviews.
Have you ever used a no code application?
They never - not even close - mention pointers.
You can create great business apps without ever understanding a pointer.
What's so hard about understanding this?
Not every piece of software is Linux, or an NSA-worthy encryption algorithm, or a bespoke Silcon Valley web forum for that matter.
I don't know how a carburetor works but I can pump my own gas.
I don't have a medical degree but I am still allowed to self-medicate a cold.
I tune out when math PhDs start geeking out, but I can do my taxes.
I am aware of what a pointer is, but my old ship captain-turned-trading desk boss most certainly is not and he wrote several nifty SharePoint workflows to automate invoice approvals and legal reviews.
In their defence.. Most modern languages don't really make use of these.
I mean recursion is almost never better than a while loop (stacks don't love it), and pointers... Yeah everything in JS and Python, Elixir and Ruby is really a pointer (most everything) but the average day to day it's not something devs care all that much about.
As an ex c and c++ dev, and CS grad, I know about them. I think if I pushed myself, I could find perhaps 5 times in the last 10 years where knowing that things are pass by references in ruby was expressed as such.
I mean recursion is almost never better than a while loop (stacks don't love it), and pointers... Yeah everything in JS and Python, Elixir and Ruby is really a pointer (most everything) but the average day to day it's not something devs care all that much about.
As an ex c and c++ dev, and CS grad, I know about them. I think if I pushed myself, I could find perhaps 5 times in the last 10 years where knowing that things are pass by references in ruby was expressed as such.
i've been homeschooling my daughter through middle school. she's very smart, she's been in the highly capable program since maybe 2nd grade. she honestly surprises me with her ability to reason, but i've yet to hit on a way to get her to understand loops. i've been considering learning an array language with her in the hopes that it would allow her the chance to get interested in programming and excited about its potential without facing loops.
Definitely recommend MIT's Scratch, it's the closest thing (in terms of "they don't even know they're coding!") to Hypercard out there, tons of games and community examples, my kids make animated movies with it.
There's a board game Robot Turtles based on the Logo version where you provide instructions via a stack of cards to navigate your turtle through a maze.
The game is scored like golf, fewer cards are better, and it includes looping cards.
Definitely designed more for elementary students but it's visual, intuitive, and you (as parent) can "design" the maze.
There are several similar video games (they are simple and cute enough to paper their very dry subject matter, and they are level/puzzle based so easy to dole out in manageable amounts of enthusiasm )
Lightbot
Human Resource Machine
7 Billion Humans
Also my kids and I whiteboarded out and then coded a few of the games from
https://github.com/coding-horror/basic-computer-games
It was fun acting as the game designer who wanted this feature or that!
There's a board game Robot Turtles based on the Logo version where you provide instructions via a stack of cards to navigate your turtle through a maze.
The game is scored like golf, fewer cards are better, and it includes looping cards.
Definitely designed more for elementary students but it's visual, intuitive, and you (as parent) can "design" the maze.
There are several similar video games (they are simple and cute enough to paper their very dry subject matter, and they are level/puzzle based so easy to dole out in manageable amounts of enthusiasm )
Lightbot
Human Resource Machine
7 Billion Humans
Also my kids and I whiteboarded out and then coded a few of the games from
https://github.com/coding-horror/basic-computer-games
It was fun acting as the game designer who wanted this feature or that!
Maybe program her?
Maybe something like, place three eggs on the counter in a row. Tell her "Pick up the first egg. Crack it into the frying pan. Put the shell back where the egg was. Pick up the second egg..."
Then, next time, tell her "For each of the three eggs, pick up the egg, crack it into the frying pan, and put the shell back where the egg was."
Would she get something like that?
Maybe something like, place three eggs on the counter in a row. Tell her "Pick up the first egg. Crack it into the frying pan. Put the shell back where the egg was. Pick up the second egg..."
Then, next time, tell her "For each of the three eggs, pick up the egg, crack it into the frying pan, and put the shell back where the egg was."
Would she get something like that?
Loops are easy..
You have 3 chocolates, and for each one you take a bite. If it's spicy filled, you stop eating them.
While there are still crayons in your bowl, the colors in the rainbow grows.
"what time is it mr wolf?" When you reach daddy/mommy you stop.
While there are still crayons in your bowl, the colors in the rainbow grows.
"what time is it mr wolf?" When you reach daddy/mommy you stop.
What languages has she been learning and do they have list comprehensions?
I can count on one hand the number of people I've known in my lifetime who are over 7', but met hundreds of students over four years in college who understood recursion.
And programming is not the NBA, and people who write code are not all-stars. We're plumbers, and the idea that programming is some genius's endeavor that only the smartest people can understand is laughable.
And programming is not the NBA, and people who write code are not all-stars. We're plumbers, and the idea that programming is some genius's endeavor that only the smartest people can understand is laughable.
I've done embedded systems for 35 years. I've done quite a bit. Never needed recursion. (Not much use for it in the embedded world...)
Now pointers... yeah. I use those a fair amount.
Now pointers... yeah. I use those a fair amount.
:-) If you've written a while loop you've used recursion. Not saying you need to understand the inner beauty of a fixed point combinator . . . it's just there, to be noticed, if you choose. You might (meaning if it caught your eye) study some recursion and notice some properties that give you some insight into how your algorithm performs or how induction over your datatypes works. Often when writing some Scheme or Julia, I'll carry a mental model in C at the same time.
What I enjoy about code is that I can understand it on a number of levels.
What I enjoy about code is that I can understand it on a number of levels.
A while loop is only "recursion with tail-call optimization". It's not equivalent to "recursion without TCO".
But "while (true)" is also equivalent to a goto :-)
While both of those are true, I'm not sure that understanding either of them is relevant to dmitrigr's claim that you have to understand both recursion and pointers in order to amount to anything as a programmer.
But "while (true)" is also equivalent to a goto :-)
While both of those are true, I'm not sure that understanding either of them is relevant to dmitrigr's claim that you have to understand both recursion and pointers in order to amount to anything as a programmer.
You are of course correct and with respect to the claim "you can't be a good programmer without understanding indirection and recursion" I don't believe that holds water. I think different techniques allow for a deeper understanding; whether or not that deeper understanding translates to a "better programmer" is fairly subjective. For me, a good programmer is one who writes readable/understandable code and that's a different category all together.
well, you made me (try) to read the article to confirm you didn't get it, but i can only see two paragraphs. still, it seems that was enough to see it isn't about making software that others will pay for, but about avoiding paying a pro to make software when a novice can sling something good enough together.
someone with another job doesn't need to make software someone will pay money for. their real job is how they make a living. but they can write software to do their job better or easier.
code isn't basketball, it's duck tape. people other than duck tape specialists can make use of it.
someone with another job doesn't need to make software someone will pay money for. their real job is how they make a living. but they can write software to do their job better or easier.
code isn't basketball, it's duck tape. people other than duck tape specialists can make use of it.
> code isn't basketball, it's duck tape.
And this viewpoint is why the slack app uses 6GB of ram, and we consider 8GB a minimum amount to browse the web...
And this viewpoint is why the slack app uses 6GB of ram, and we consider 8GB a minimum amount to browse the web...
"Our stuff made by professionals is also terrible" is maybe not the slam-dunk argument against democratizing code that people think it is.
I don't think many people are looking at the software industry as it exists today and saying, "this is a group with standards." :) So why get upset over whether some minor automation project or side project that an office user writes is of engineering quality when it's being written to get around some half-thought, bad UX we professionals foisted on them in the first place? We build restrictive apps and bad workflows that make it harder for them to do their jobs, and then we have the gall to say that they're not professional enough or predisposed enough to a certain kind of thinking to write their own code?
Give those non-programmers some degree of access to a world where computers are creative tools that can be commanded, not just single-purpose devices that do pre-specified things. Because that world is great, and they should have access to it regardless of whether or not they're good at programming. And it's not like the modern software industry is so wildly quality-controlled right now that we're in any position to tell anyone that they're not good enough or thoughtful enough to deserve having more agency over the tools they use.
I don't think many people are looking at the software industry as it exists today and saying, "this is a group with standards." :) So why get upset over whether some minor automation project or side project that an office user writes is of engineering quality when it's being written to get around some half-thought, bad UX we professionals foisted on them in the first place? We build restrictive apps and bad workflows that make it harder for them to do their jobs, and then we have the gall to say that they're not professional enough or predisposed enough to a certain kind of thinking to write their own code?
Give those non-programmers some degree of access to a world where computers are creative tools that can be commanded, not just single-purpose devices that do pre-specified things. Because that world is great, and they should have access to it regardless of whether or not they're good at programming. And it's not like the modern software industry is so wildly quality-controlled right now that we're in any position to tell anyone that they're not good enough or thoughtful enough to deserve having more agency over the tools they use.
Also consider that the vast majority of the problems these non-programmers are trying to solve are not things "IT" is interested in solving.
Many of the no-code apps I see getting built by non-programmers at my place of employment are things that IT has outright rejected because developers are a limited resource and there are bigger fish to fry.
But that doesn't mean these problems aren't impacting teams in real ways. Some horrible workflow for a small department that functions by manually juggling 3 spreadsheets may not rise to the level of an IT provided solution being created, but with the proper tooling the non-programmers can create a better solution than what currently exists.
Many of the no-code apps I see getting built by non-programmers at my place of employment are things that IT has outright rejected because developers are a limited resource and there are bigger fish to fry.
But that doesn't mean these problems aren't impacting teams in real ways. Some horrible workflow for a small department that functions by manually juggling 3 spreadsheets may not rise to the level of an IT provided solution being created, but with the proper tooling the non-programmers can create a better solution than what currently exists.
Exactly. And in a lot ways this is something of an Open Source/hacker mantra: that people shouldn't have to ask permission from a bunch of gatekeepers to solve their own software problems, particularly when no one else is interested in solving them. Part of the narrative of hacker culture is a bunch of hobbyists looking at established businesses or processes that aren't addressing their needs and saying, "well heck you, I don't need your validation, I'm going to build software that accomplishes my goals and I don't care if you think it looks professional or not and I don't care if it scales to whatever tech stack or business that you think it needs to."
There's nothing more "hacker" than a non-engineer sitting down with a no-code app and cobbling together an actually working, tangible solution to their problems that lets them calculate payroll, or coordinate schedules, or automate some data import task or whatever, all while a bunch of people on a web forum mock them for using Excel instead of a database language or argue that their solution is bad because it's not backed up by Git or doesn't use pointers correctly. That's the most hacker crud ever, and it says something about us if we push those people down instead of encouraging them.
There's nothing more "hacker" than a non-engineer sitting down with a no-code app and cobbling together an actually working, tangible solution to their problems that lets them calculate payroll, or coordinate schedules, or automate some data import task or whatever, all while a bunch of people on a web forum mock them for using Excel instead of a database language or argue that their solution is bad because it's not backed up by Git or doesn't use pointers correctly. That's the most hacker crud ever, and it says something about us if we push those people down instead of encouraging them.
hate to break it to you, that mess was made by the duck tape specialists.
fnqpt(1)
What an ego shattering revelation it would be if it turned out just about everyone can be good at coding. Being able to code is what qualifies us to know everything about everything!
There's nothing special about software engineering beyond:
- meticulous attention to detail,
- explicit deductive reasoning,
- an ability to understand and build abstractions,
- a high tolerance for frustration,
- and a love of instant gratification when things work.
None of these are rare traits. But the cluster of traits isn't widespread. Which is to say it's not common among people in general, but also not unusual.
- meticulous attention to detail,
- explicit deductive reasoning,
- an ability to understand and build abstractions,
- a high tolerance for frustration,
- and a love of instant gratification when things work.
None of these are rare traits. But the cluster of traits isn't widespread. Which is to say it's not common among people in general, but also not unusual.
And, as captured in many of those points, a relatively high IQ. Almost certainly at least 1 SD above the mean, and in many cases (complex software), closer to 2 SD.
"Explicit deductive reasoning" is pretty darn rare.
(and "meticulous attention to detail" is not strictly necessary, as my own career attests.)
(and "meticulous attention to detail" is not strictly necessary, as my own career attests.)
It is, but we have a repeatable process for teaching it. And it CAN be learned by anyone with a patient teacher and several years.
I'd disagree. Debugging IS meticulous attention to detail. A single misspelling is often fatal. And if you've figured out how to program without debugging I'd love to know your secret.
I'd guess your baseline for that metric is enormously skewed by the people you spend time around. Even completing Algebra 2 requires meticulous attention to detail.
I'd disagree. Debugging IS meticulous attention to detail. A single misspelling is often fatal. And if you've figured out how to program without debugging I'd love to know your secret.
I'd guess your baseline for that metric is enormously skewed by the people you spend time around. Even completing Algebra 2 requires meticulous attention to detail.
See it's not really ego. I'd say most people could be good at coding. But most people could be good electricians, and plumbers and mechanics, and carpenters, and ... well and heaps of other things.
It's that it all takes training, and time in. It all takes reading and learning new things.
It's not a question of could they be good. It's a question of, do they want to. I don't think most people want to be good at it.
It's that it all takes training, and time in. It all takes reading and learning new things.
It's not a question of could they be good. It's a question of, do they want to. I don't think most people want to be good at it.
Technically accurate, but not practically true.
If you've ever needed to teach someone patience, you'd see the futility of trying to teach a random person programming.
Nowadays, I will tell people straight out I can't see them dealing with the frustrations long enough to develop the patience needed to learn the basics.
If you've ever needed to teach someone patience, you'd see the futility of trying to teach a random person programming.
Nowadays, I will tell people straight out I can't see them dealing with the frustrations long enough to develop the patience needed to learn the basics.
I never teach people to code. I ask them what they want to build, and then we work to building that.
People don't need to be patient. Beyond assignment, if, for and while, just make sure they use good variable names and function names.
Code reviews take care of the rest.
If learning your first programming language doesn't require patience, I don't know what the word means.
I've never met anyone who wasn't frustrated for at least the first few months trying to get even basic programs working. The syntax is orders of magnitude less tolerance of mistakes than any other subject.
I've never met anyone who wasn't frustrated for at least the first few months trying to get even basic programs working. The syntax is orders of magnitude less tolerance of mistakes than any other subject.
Not sure a doctor would agree with that last sentence.
Or even a carpenter really.
Cut that bit off at the wrong angle and it's not something you're coming back from.
Cut a line of code wrong and the test fails, and you try again, and again and again.
I’m not talking about the importance of mistakes or likelihood of making them. I’m talking about the literal binary nature of the (syntax) mistakes. From day 1 to day infinity a single misplaced character is more likely than not completely unacceptable.
But for any physical skill you have some notion of tolerance. Whether that’s millimeter or micrograms things aren’t absolute in the way they are with programming.
But for any physical skill you have some notion of tolerance. Whether that’s millimeter or micrograms things aren’t absolute in the way they are with programming.
I should say.. they don't need to be more patient than most other trades. To get good they need to practice and learn.
What I do think coders need to know is that they are building on quick sand. That bit is the only thing I think we do that other trades don't. We can never rest, because as soon as we stop for a breath we start to sink and fall behind.
What I do think coders need to know is that they are building on quick sand. That bit is the only thing I think we do that other trades don't. We can never rest, because as soon as we stop for a breath we start to sink and fall behind.
Spot on.
I think a piano is the best example. No one sits down at the piano and can just rip the first time.
Almost anyone though can learn to play piano if they practice enough. You don't have to be the best in the world either to make good music.
Then there is a huge difference between being a great piano player and being a great composer of music in a creative sense.
Culturally though, I would think we are going backwards. I feel like I would know so much less in this area if I was 25 years younger and grew up with a phone instead of a PC.
Almost anyone though can learn to play piano if they practice enough. You don't have to be the best in the world either to make good music.
Then there is a huge difference between being a great piano player and being a great composer of music in a creative sense.
Culturally though, I would think we are going backwards. I feel like I would know so much less in this area if I was 25 years younger and grew up with a phone instead of a PC.
My impression is that most people can't be good at it because they have no interest in it, and no willingness to spend time on it, learning and practising.
Too true.. But is there a trade you can't say that about. I suck at guitar and skateboarding. I suck at car repair and carpentry.
Seems like Microsoft have infiltrated Hacker News with the recent number of submissions trending on here.
Is this the Economists way of stealth advertising Github's CoPilot?
Is this the Economists way of stealth advertising Github's CoPilot?