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.
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.
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.
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.
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.
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.
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.
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...
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.
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."
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
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.
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.
:-) 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.
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.
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.
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.
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.
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.
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.
> 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.
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.
"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.
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.
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.
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.
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.
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!
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
I see it even more simply. Most people can't handle something being so stupid and frustrating. And the bigger their delusions on how smart computers are the less possible it is.
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.
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.
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.
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.
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."
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.
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.
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.
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.
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 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
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.
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?
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.
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.
"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.
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.
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.
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.
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).
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.
Please don't post supercilious putdowns of other people. It's reliably the marker of a bad comment (by which I mean one that leads to worse HN threads).
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.
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.
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.
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.
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.
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.
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).
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.
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.
> 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.
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".
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.
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?
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"
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.
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.
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.
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. ;-)
> 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”?
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.
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 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.
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.
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.
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.
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.
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.
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 ...)
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.
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.
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.
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.
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.
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?
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 :)
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".
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.
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.
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).
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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”
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?
202 comments
[ 5.1 ms ] story [ 245 ms ] threadI taught coding in college and bootcamps.
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.
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.
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.
I know, because it happened to me.
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 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.
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.
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.
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.
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?
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!
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 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.
Now pointers... yeah. I use those a fair amount.
What I enjoy about code is that I can understand it on a number of levels.
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 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.
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.
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.
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.
They might make a decent birdhouse/python app, but after that most will just put the knowledge on the shelf.
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.
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.
And this viewpoint is why the slack app uses 6GB of ram, and we consider 8GB a minimum amount to browse the web...
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.
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.
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.
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.
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.
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.
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'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.
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.
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.
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.
- 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 "meticulous attention to detail" is not strictly necessary, as my own career attests.)
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.
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.
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.
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.
"If the only tool you have is a hammer, you tend to see every problem as a nail."
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.
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.
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.
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
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.
Would you rather have a lot of businesses operating successfully with “poor” software or much fewer businesses operating with “good” software?
These things have been driving our economy for a few decades at insane levels of productivity.
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.
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.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.
No-code is a separate issue. Visually organized programs become very hard to understand very quickly.
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.
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.
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.
https://www.teamten.com/lawrence/writings/norris-numbers.htm...
https://news.ycombinator.com/newsguidelines.html
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.
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.
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.
0: https://external-preview.redd.it/at0EwQpHU6A3xyU0KW80bc3aVMZ...
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.
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.
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.
Personally, from my work experience, I despise Visual Studio and Outlook a lot more (Jira is clearly trying to be usable compared to these).
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.
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...
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".
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.
You may be surprised to see how good people are in their respective domains.
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?
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"
> [...] I can't tell if it's a badge of pride or shame [...]
Lol... shame, definitely shame ;)
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.
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.
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 have a lot of opinions about K-12 math education. ;-)
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 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.
Does it? My encounters with it at any place of formal education have all been about memorizing and practicing arbitrary operations. No intuition required.
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.
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.
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.
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 ...)
Maybe it was easier in the days of DOS, because merely using a computer required the same precision.
The fact that so much of ML is inscrutable alchemy and a guessing game is a feature not bug.
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.
Maybe that would help bring the privacy implications into clearer focus.
It's doing exactly what you're telling it to do.
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.
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.
Is this the Economists way of stealth advertising Github's CoPilot?
The web was incredibly slow and unreliable. Money aside, I still feel a steady incoming karma flow :)
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".
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.
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.
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).
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.
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.
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.
[0] https://www.merriam-webster.com/dictionary/democratic
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.
https://computinged.wordpress.com/2021/11/26/computer-scienc...
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.
Decades later I learned coding in a more hands on / make things way and I’m having fun working my way “backwards” into theory.
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.
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.
In the UK they already teach CS to every student in primary school, just like math.
Oh wait, we've already done that - and we regularly see them blow their parent company's heads off.
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.
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”
Hacked together solutions work fine, to a point, that's where us "geek elite" take over, and that's fine in my opinion.
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?