Comment by dmitrygr | Hacker News Reader

Comment by dmitrygr | Hacker News Reader

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.

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.

I'd bring it closer to shop class.

They might make a decent birdhouse/python app, but after that most will just put the knowledge on the shelf.

> 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.

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.

> Not everyone can play in the NBA.

Writing code as part of a job isn't being in the NBA, it's just like writing as part of a job.

> Not everyone can safely drive a car.

A better analogy for code, but only a very small share of those who are employable at all are not employable in a job where driving a vehicle is a part (though not necessarily a central part) of the job.

There's no reason coding can't be like that.

> Not everyone can architect and write good code.

Not everyone can organize and write quality prose, either, but most people who can't can still get jobs where writing text is a required part of the job.

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.

Loops are easy.. You have 3 chocolates, and for each one you take a bite. If it's spicy filled, you stop eating them.

While there are still crayons in your bowl, the colors in the rainbow grows.

"what time is it mr wolf?" When you reach daddy/mommy you stop.

Maybe program her?

Maybe something like, place three eggs on the counter in a row. Tell her "Pick up the first egg. Crack it into the frying pan. Put the shell back where the egg was. Pick up the second egg..."

Then, next time, tell her "For each of the three eggs, pick up the egg, crack it into the frying pan, and put the shell back where the egg was."

Would she get something like that?

Definitely recommend MIT's Scratch, it's the closest thing (in terms of "they don't even know they're coding!") to Hypercard out there, tons of games and community examples, my kids make animated movies with it.

There's a board game Robot Turtles based on the Logo version where you provide instructions via a stack of cards to navigate your turtle through a maze.

The game is scored like golf, fewer cards are better, and it includes looping cards.

Definitely designed more for elementary students but it's visual, intuitive, and you (as parent) can "design" the maze.

There are several similar video games (they are simple and cute enough to paper their very dry subject matter, and they are level/puzzle based so easy to dole out in manageable amounts of enthusiasm )

Lightbot

Human Resource Machine

7 Billion Humans

Also my kids and I whiteboarded out and then coded a few of the games from

https://github.com/coding-horror/basic-computer-games

It was fun acting as the game designer who wanted this feature or that!

What languages has she been learning and do they have list comprehensions?

I can count on one hand the number of people I've known in my lifetime who are over 7', but met hundreds of students over four years in college who understood recursion.

And programming is not the NBA, and people who write code are not all-stars. We're plumbers, and the idea that programming is some genius's endeavor that only the smartest people can understand is laughable.

In their defence.. Most modern languages don't really make use of these.

I mean recursion is almost never better than a while loop (stacks don't love it), and pointers... Yeah everything in JS and Python, Elixir and Ruby is really a pointer (most everything) but the average day to day it's not something devs care all that much about.

As an ex c and c++ dev, and CS grad, I know about them. I think if I pushed myself, I could find perhaps 5 times in the last 10 years where knowing that things are pass by references in ruby was expressed as such.

I've done embedded systems for 35 years. I've done quite a bit. Never needed recursion. (Not much use for it in the embedded world...)

Now pointers... yeah. I use those a fair amount.

:-) 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.

Sit in a room and point at a spot on the floor.

You are a pointer, pointing at nothing.

Attempt to put shit where you're pointing and you have shite all over the floor.

Malloc creates a bucket. Now when you put shit where you're pointing it lands in a bucket.

When you're done with the bucket you clean it up.

If you try to put too much in the bucket, you end up with shite all over the floor.

If you forget to clean up the bucket, the place will start to stink.

If you change the pointer so nothing is pointing at the bucket of shit, then it will just sit there, forgotten. But the shit is still there.

No one ever forgets this way of teaching it.

> It is as rare as being 7 feet tall, sadly.

Objectively not true? Not even close to true.

I guarantee you there are many orders of magnitude more people in the world who understand recursion and that understand pointers than there are people who are 7 feet tall. Being 7 feet tall is extremely rare, and building a functioning C app is not.

The average height of an NBA player at the highest level of the sport is under 7 feet.

----

I don't understand why we're all commenting under this thread accepting the premise that good programmers are rare. They're not, look at the size of the industry and the output. The only way this argument makes sense is if you redefine "good" to mean something incredibly exclusionary, and even if you do it's impossible to argue that none of the software coming out of the industry is producing any value for users or solving any problems that they have.

> And without understanding indirection and recursion, the most you'll ever do is ...well..not much...

How do you think we have a software industry at all if you're claiming that both:

A) only an extreme minority of the population (<1 in a million) is capable of understanding very basic concepts like pointers, and also

B) it's impossible to build useful tools without them.

One of those two things has to be false, or you have to explain to me why the entire software industry hasn't collapsed by now from lack of talent and lack of output.

This kind of gatekeeping is ... beyond parody.

Have you ever used a no code application?

They never - not even close - mention pointers.

You can create great business apps without ever understanding a pointer.

What's so hard about understanding this?

Not every piece of software is Linux, or an NSA-worthy encryption algorithm, or a bespoke Silcon Valley web forum for that matter.

I don't know how a carburetor works but I can pump my own gas.

I don't have a medical degree but I am still allowed to self-medicate a cold.

I tune out when math PhDs start geeking out, but I can do my taxes.

I am aware of what a pointer is, but my old ship captain-turned-trading desk boss most certainly is not and he wrote several nifty SharePoint workflows to automate invoice approvals and legal reviews.

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.

> code isn't basketball, it's duck tape.

And this viewpoint is why the slack app uses 6GB of ram, and we consider 8GB a minimum amount to browse the web...

hate to break it to you, that mess was made by the duck tape specialists.

"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.

Reply on news.ycombinator.com