[HN Gopher] Programming isn't coding (2020)
___________________________________________________________________
Programming isn't coding (2020)
Author : luu
Score : 108 points
Date : 2023-03-31 00:26 UTC (1 days ago)
(HTM) web link (occasionallycogent.com)
(TXT) w3m dump (occasionallycogent.com)
| dangus wrote:
| You could summarize this article by saying that students don't
| know a whole bunch of things yet, which is kind of the point
| right? They're students! Of course they don't know how to use all
| the tools in the toolbox.
|
| I would agree with the author in the sense that there should be a
| class or segment of the class that tackles how software engineers
| leverage their environment and use common tools. But, the way I
| understand it, that sort of thing is common in formal curriculum,
| it just doesn't cover _everything_.
|
| I wonder if this concern the author has brought up represents a
| perspective trap of having a significant level of lived
| experience. It's probably anxiety-inducing to think of someone
| leaving your class and not knowing 100% of the things a software
| engineer needs to succeed. But, really, if we think back to how
| we all were as students all those years ago, we were probably in
| the same boat.
|
| For example, personally, I didn't know how to use source control
| until I entered the industry. I learned git on the fly because an
| employer needed me to. Multiply that same story a few
| hundred/thousand times that you've got an experienced
| practitioner.
| eimrine wrote:
| > students need to know that Ctrl-C will interrupt most things,
| Ctrl-D will stop some other things
|
| This is so true.
| lisp-pornstar wrote:
| Commenting on: X is not Y (510 BC)
| mattigames wrote:
| Reminds me of my recent issue with parcel, one those tools that
| it's supposed to make frontend development less messy that lets
| you start with no configuration, I was in for a surprise, it does
| a lot of weird unexpected things with your code and files:
|
| - it changes the names of static files (e.g videos), if you put
| "type=module" on a script tag it deletes it (after investigating
| its due some incompatibility with how parcel works and top level
| awaits)
|
| - if you try to use any library that works on both the browser
| and node like fabricjs it fails at compile time (some parsing
| goes wrong), if you try to find some way to ignore such files you
| discover the only way is to host that script online because
| parcel doesn't touch these
|
| - if you use shadow Dom in your app it appends everything inside
| those twice when hot-reloading modules (tbf that has an easy
| solution that listens, to listen a parcel event to force a
| reload, about 3 lines of JS)
|
| And some other smaller issues, in conclusion it was a mistake, I
| converted it to webpack an it works all better now, I should have
| gone with webpack from the beginning and avoid things I haven't
| used before just from fake promises of simplicity.
| davidhbolton wrote:
| There are no hard and fast definitions of programming or coding.
| To me they are the same but coding is more like slang. The formal
| name for both is software development.
| slaymaker1907 wrote:
| I know there at least used to be implications for immigration
| depending on the terminology for the job description.
| rascul wrote:
| I've considered coding to be what some amateur hobbyist like me
| does. Programming is what people who get paid for it do. Both
| are software development. I'm not going to die on this hill,
| though.
| okareaman wrote:
| Learning to use your tools is part of any job. I don't understand
| the point of this article or why such a low quality entry is on
| the front page.
| kazinator wrote:
| > _Unfortunately, doing anything in the terminal is, if not a
| struggle, something very new to most beginning programmers._
|
| Ah, but the terminal is also the territory where the low-
| dependency, instant-gratification, just-get-coding tools live.
| ARandomerDude wrote:
| > When teaching "programming", a surprisingly small amount of
| time is spent actually helping students with logic - and a lot
| helping them learning & managing programming tools.
|
| This is true and fits my experience.
|
| > Programmers like to think that they spend all their time
| creating elaborate & complex abstractions but far more time is
| consumed dealing with the tools and idioms encrusted with
| historical baggage.
|
| I disagree. _Junior_ developers spend a disproportionate amount
| of time learning how to use the tools but after about 3 years all
| the terminal and editor idiosyncrasies should be second nature.
| If a person is still struggling with tooling for any significant
| part of most weeks either something is very wrong or you've
| recently changed jobs (and will be up to speed soon).
|
| It's clear that the author spends a huge amount of time with
| beginners, which probably colors his perception too much.
| textninja wrote:
| Programming isn't _just_ coding.
| EyeSayUntoThee wrote:
| Well, coding != complicated frontend development, which it
| appears you are teaching your students as an allegedly "easy"
| programming environment.
|
| You could perhaps consider starting them with Racket or some
| other "batteries included" programming environments specifically
| designed to avoid tooling bogs?
| mdaniel wrote:
| I would offer that writing CSS is for sure "coding" in my world
| because the computers they are so picky about all those goofy
| characters. Damn, they have to be in the right order and
| matched up and everything :-D
|
| But I would be on-board if someone said that CSS is not
| "programming" since (AFAIK) there are no iterations, very few
| conditional statements, no recursion, and "library" means
| something entirely different
| eyelidlessness wrote:
| CSS definitely has iterations. Animations are the most
| obvious, but you could definitely build a state machine which
| progressively passes through and even recurses on state with
| custom properties ("variables") and various conditional
| interactions from media/container queries.
|
| I'm not inclined to do this, because I have way too long a
| list of higher priorities, but I could possibly be nerd
| sniped into showing some proofs of concept if the idea sounds
| outlandish.
| ChrisMarshallNY wrote:
| This has always been an issue with me.
|
| I first learned coding/programming in the days of "big iron," and
| embedded (machine and ASM) coding.
|
| These require a "Measure Twice, Cut Once" approach. In fact, the
| "coding" part is really just data entry.
|
| These days, with integrated symbolic debuggers and IDEs, I can
| start coding right away, and writing a prototype is often MUCH
| faster than planning it out. I'll usually spend very little time,
| planning, and start coding, very quickly[0].
|
| In the "days of yore," this would have me excommunicated.
|
| But I have found that it results in extremely well-written, well-
| designed, and fast end results. I also tend to work very quickly.
|
| Being experienced helps. In fact, it may be a requirement, as I
| can map out a design in my head that follows the desire path to a
| good result. I have very manageable failures, and seldom need to
| throw everything out, and start from scratch.
|
| But even then, I'm not throwing out a whole boatload of invested
| time and effort. It's easy to toss a bad design, and that's
| critical, for me.
|
| [0] https://littlegreenviper.com/miscellany/thats-not-what-
| ships...
| micheles wrote:
| >In my experience teaching programming, we spend very little time
| helping students actually write code. >Instead, the mentors
| mainly deal with problems of tooling - "it says 'EADDRINUSE' and
| crashes"; "git is giving an error"; "npm just says segmentation
| fault".
|
| He is doing things wrong. If he wants the students to use modern
| tools he first need to give a course on the tools and later
| another one on programming.
|
| Otherwise he must not use modern tools (no git, no react) and use
| some simplified teaching environment (not ideal, but at least he
| will not be distracted by the tooling issues).
|
| In my experience (I have to work a lot with Ph.D. students in
| science with very little IT expertise) the tools are always the
| issue, while the algorithmic thinking is rarely a problem, so
| probably a course on the tools is more useful than one on
| programming.
|
| He must focus on tools that are not the fashion of the moment, so
| the terminal is okay, git is okay, React is not okay.
| lispisok wrote:
| If you arent teaching the modern tools then you arent teaching
| the "marketable skills to get a job" which is increasingly the
| focus of education. Nobody cares about underlying principals
| anymore.
| ojkelly wrote:
| This makes sense.
|
| You don't start woodworking by cutting a hardwood timber to
| length by eye with a circular saw.
|
| You get familiar with the basics like a hand saw, tape measure,
| and some soft wood like balsa.
|
| You're first vehicle was _probably_ a bicycle or go-kart, not a
| truck or race car.
| seanmcdirmid wrote:
| It depends where in the sciences they come from. Physicists
| don't have much problem with abstract thinking, but biologists,
| maybe not as good (I used to help my biologist PhD student
| roommate write some Perl to crunch numbers). It reminds me of
| that xkcd comic https://xkcd.com/435/.
| cratermoon wrote:
| How TF do you get a segfault from npm?
| eyelidlessness wrote:
| Well it's not uncommon to have Node segfault, especially when
| interfacing with native extensions of one kind or another.
| NPM is just a Node script. It runs a whole lot of other Node
| scripts as preconditions by default. Many of them, maybe even
| most, interface with native extensions of one kind or
| another.
| cratermoon wrote:
| OK, Node I can see. I suppose part of the point of the
| article is that a student doesn't know npm from node, nor
| how npm run works.
|
| On the flip side, a core tool like node segfault commonly
| seems like a problem. Or at least a problem with poorly-
| written native extensions.
| nuc1e0n wrote:
| This blog post is referring to the same accidental complexity
| that Fred Brooks did in his classic 'No Silver Bullet' essay.
| Overly complex tooling remains a problem today.
| Cyphase wrote:
| "Published 2020-08-02"
| cutler wrote:
| Gradle must die. If learning the build tool is more work than
| learning the language it supports something is wrong.
| efortis wrote:
| Related, Gerald Jay Sussman explains why they pulled the plug on
| MIT 6001 (SICP) here:
|
| https://www.youtube.com/watch?v=OgRFOjVzvm0
|
| In my words, he says: devs continuously change tech stacks
| without poking at the layers underneath. So only a few become
| proficient enough to focus on the abstractions.
|
| The same happens with designers, many become technicians of
| graphic design tools.
| 1bent wrote:
| I think this is more of a complaint that GUIs have prevented non-
| programmers from learning to do novel things with a computer;
| that's been the focus of GUIs since the Apple Lisa. I was working
| in a university comp center, and got to see a Lisa at an Apple
| event shortly after it was announced. Everyone who went with me
| agreed, it's better than an etch-a-sketch, you don't have to turn
| it upside down and shake to clear the screen.
|
| But at that moment computers bifurcated: real computers for
| programmers, and appliances for the rest of them.
| divan wrote:
| The best explanation I've seen is in the book "The Secret Life of
| Programs" by Jonathan E. Steinhart. I'll quote that paragraph
| verbatim:
|
| ---
|
| Computer programming is a two-step process:
|
| 1. Understand the universe.
|
| 2. Explain it to a three-year-old.
|
| What does this mean? Well, you can't write computer programs to
| do things that you yourself don't understand. For example, you
| can't write a spellchecker if you don't know the rules for
| spelling, and you can't write a good action video game if you
| don't know physics. So, the first step in becoming a good
| computer programmer is to learn as much as you can about
| everything else. Solutions to problems often come from unexpected
| places, so don't ignore something just because it doesn't seem
| immediately relevant.
|
| The second step of the process requires explaining what you know
| to a machine that has a very rigid view of the world, like young
| children do. This rigidity in children is really obvious when
| they're about three years old. Let's say you're trying to get out
| the door. You ask your child, "Where are your shoes?" The
| response: "There." She did answer your question. The problem is,
| she doesn't understand that you're really asking her to put her
| shoes on so that you both can go somewhere. Flexibility and the
| ability to make inferences are skills that children learn as they
| grow up. But computers are like Peter Pan: they never grow up.
| asadawadia wrote:
| what a great explanation
| scarface74 wrote:
| > For example, you can't write a spellchecker if you don't know
| the rules for spelling,
|
| me: write a spell checker using Python.
|
| ChatGPT: gives me a simple Python script that uses the Pychant
| library.
|
| But a more realistic example...
|
| These days, with my slight career pivot, I am working mostly
| with AWS APIs using various languages. Luckily, there are
| plenty of examples on the web and ChatGPT is well trained on
| them. I can often just tell it what I want on a very high level
| and I get very good results.
|
| Using ChatGPT is more like working with an intern than a three
| year old _if_ it is a domain it has been trained on.
| nextaccountic wrote:
| This is an amazing explanation, but I sense that it will become
| dated in some years, like, it will describe how computing
| worked in the old times, when people actually coded by hand.
|
| Because,
|
| > Flexibility and the ability to make inferences are skills
| that children learn as they grow up. But computers are like
| Peter Pan: they never grow up.
|
| LLMs will change all of this. Maybe in some decades we will see
| programming environments that don't require people to
| understand the solution in order to create a program. For
| example, it may be possible for people to create spellcheckers
| without understanding the rules of spelling.
|
| Unfortunately this will create a whole new class of bugs due to
| AIs hallucinating code, and I'm afraid that the average
| software quality will take a hit.
| bmitc wrote:
| I strongly suspect that the impact of LLMs is overblown.
| Unless they suddenly are able to synthesize complex and ill-
| defined requirements that change over time, I don't expect
| their impact will be beyond novelty.
| mistercow wrote:
| Their impact is already beyond novelty. I don't know when
| we'll get to the point of not needing to understand the
| underlying concepts, but that much isn't necessary for the
| models to be useful. Their use right now is just as time
| savers.
| bmitc wrote:
| > Their impact is already beyond novelty.
|
| Do you have some examples?
| mistercow wrote:
| Copilot. For that matter, TabNine several years earlier,
| even when using a low parameter local GPT-2.
| JoeyJoJoJr wrote:
| One anecdotal example: I gave ChatGPT 4 some prompts to
| write a shader to generate a signed distance field based
| on specific requirements. Within half an hour I had a
| working result. It solved a specific problem I was having
| that would have otherwise required in-depth research or
| finding an expert in two niche areas.
| timr wrote:
| See, this is the danger zone. How do you _know_ that the
| solution you were given is correct? Even if you 're an
| expert in the space, if you didn't know enough to solve
| the problem yourself, you're _by definition_ , incapable
| of evaluating the output of a mindless text-generator.
|
| Now, I grant you that a lot of people work this way
| today. They're in trouble. We're about to enter the
| golden age for competency, and the dark ages for
| incompetence.
| og_kalu wrote:
| This is overblown imo. of all of the areas/domains where
| this might be an issue, programming isn't it. Programs
| run. if they work as envisioned then you're good to go.
|
| and in numerous other professions, nobody is signing off
| work that hasn't been checked by multiple parties either
| way, LLMs will be a pipeline in this process.
| benj111 wrote:
| The programmer has to understand the problem. If the person
| behind the keyboard offloads that to AI, the AI is the
| programmer. The person behind the keyboard is basically just
| a manager.
| scarface74 wrote:
| The gap between "understanding the problem" and "coming up
| with a solution" has become a lot narrower over the years.
|
| 1. To do anything interesting and at any speed on my Apple
| //e I had to know assembly.
|
| 2. Then I got a Mac in 1992 and the original Mac Toolbox
| routines could do a lot from a higher level language.
|
| 3. Then Visual Basic made graphical programs easier and
| later WinForms, C# etc.
|
| 4. Then AWS made provisioning infrastructure a matter of
| just writing a bunch of yaml
|
| 5. Now that LLMs exist and ChatGPT is well trained on AWS
| APIs in various languages, I can use natural language and
| it spits out code that works 95% of the time with only
| slight tweaks if any.
| benj111 wrote:
| I'd state it more as, you don't have to reinvent to
| foundations to solve a new problem.
|
| If your problem is writing a link list, you still have to
| understand linked lists. If your problem just happens to
| be solved by linked lists, you can rely on a library.
|
| Re point 5. If debugging is twice as hard as writing
| code. How long before AI becomes half as intelligent as
| the average programmer making said programs undebuggable
| by the average programmer? Is it a good thing to have
| black boxes writing black boxes?
| owl57 wrote:
| > How long before AI becomes half as intelligent as the
| average programmer making said programs undebuggable by
| the average programmer?
|
| It doesn't work this way. A programmer with a bit of
| experience knows to curb the desire for cleverness and
| write code they -- and their teammates, probably having
| comparable intelligence and even less knowledge about
| specific code -- can debug.
|
| Unless they are on a coffee trip and hacking on a cool
| weekend project, of course. Now that's another question,
| what in the hell will AI's weekend projects be.
| benj111 wrote:
| >A programmer with a bit of experience knows to curb the
| desire for cleverness
|
| Are you suggesting AI will know to curb it's cleverness
| so that mere humans can understand it???
| owl57 wrote:
| Setting aside all that debate about future AI agency and
| focusing on currently known mode of operation, why not. I
| haven't tested, but GPT-4 may already know enough to act
| on "this part of my/your code is too clever, please
| rewrite it simpler" and "please add this feature to that
| program, and don't be too clever".
| scarface74 wrote:
| GPT3 could do that.
| marginalia_nu wrote:
| Aren't the two always the same thing? I'll even go so far
| as to say you don't understand a problem if its solution
| does not appear childishly trivial.
| scarface74 wrote:
| You don't see the gap between "I want a natural language
| chatbot" and being able to create ChatGPT?
| marginalia_nu wrote:
| Right, the gap is a whole lot deeper understanding of the
| problem than "1 chatgpt plx", probably starting with
| understanding just what chatgpt is.
| schwartzworld wrote:
| > don't require people to understand the solution in order to
| create a program. For example, it may be possible for people
| to create spellcheckers without understanding the rules of
| spelling
|
| Lol, no. How would you validate the output of that program if
| you didn't understand the rules?
| patrulek wrote:
| Programming is creating a program. Coding is writing a code.
|
| These two often overlaps but they doesnt have to.
| throwaway118899 wrote:
| [flagged]
| generalpf wrote:
| Clickbait if I've ever seen it.
| meling wrote:
| Reminds me of the MIT course the missing semester:
| https://missing.csail.mit.edu/
|
| Not sure they still run.
| galaxyLogic wrote:
| There's two challenges:
|
| 1. Coming up with an algorithm which really means expressing it
| in SOME language. That language can be pseudo-code or plain
| English.
|
| 2. Getting the computer to execute that algorithm. That requires
| that you get the computer to understand what you say is your
| algorithm.
|
| The latter can be called the "tooling" issue.
|
| The "tooling issue" is as important as algorithm development.
| Algorithm is great but you must be able to express it, in a way
| that somebody else besides you hopefully the computer understands
| it.
|
| It's like a composer would come up with a fantastic song in their
| head, but then for one reason or another were not able to play it
| to anybody.
|
| Tooling is about communicating with the computer, getting it to
| understand you, do what you want it to do.
| mdaniel wrote:
| No one asked me, but my taxonomy is
|
| * coding = typing or clicking to have computers do stuff
|
| * programming = knowing how to type or click to make computers do
| stuff given knowledge of the SDK, libraries, toolchain, and
| _ideally_ how to communicate effectively with the IDE
|
| * software engineering = knowing when _not_ to program, knowing
| about components and the implication of their boundaries and
| contracts with the things outside of that component's boundaries,
| which in my world includes but is no limited to other methods in
| that same module, other modules in the same deployment, internal
| consumers, and most importantly any promises the code (or
| management) have made to _external_ consumers
|
| ---
|
| * coding = able to use a hammer
|
| * programming = able to assemble an Ikea cabinet, sometimes
| without the correct tools or complete instructions available
|
| * software engineering = able to design an Ikea cabinet for
| others and striving for a very low RMA rate
| drewcoo wrote:
| I call that first one ("typing or clicking to have computers do
| stuff") "typing."
|
| The taxonomy is missing "designing," "architecting,"
| "crafting," and more things people like to say they do. To feel
| important. More important than someone(s) else.
|
| And I often call myself a "professional typist" because the
| whole taxonomy is pompous BS.
|
| I get paid to solve business problems.
| rfrey wrote:
| >I get paid to solve business problems
|
| That's far more pretentious than any of the things you
| listed.
| WinnieRallycar wrote:
| I wouldn't say so. In essence, every employee is paid to
| solve business problems.
| irrational wrote:
| How is it pretentious? I feel the same way. When people ask
| me what programming is like, I tell them it is 50%
| understanding the business problem, 49% problem solving,
| and 1% writing code.
| rfrey wrote:
| Because first, it's trite: literally every person in the
| organization is hired to "solve business problems".
| Second, I think it's pompous to elevate one's position to
| some sort of strategic "problem solver" role when, unless
| you are a consultant, you are hired to translate
| requirements into working software systems. Your boss
| would roll her eyes at the "I solve business problems"
| language. She would say, "Uh-huh. You do that - solve the
| business's problems. Just make sure you close your Jira
| tickets while you're doing it."
| d0mine wrote:
| "translate requirements into working software systems"
| demonstrates fundamental misunderstanding what
| programmers do. It is a decades old and rather common
| misconception. It is why there is "mythical" in the
| Mythical man-month book (1975).
|
| More https://news.ycombinator.com/item?id=35297082
| mechanical_bear wrote:
| That's literally what it is though.
| poidos wrote:
| I forgot the place I read this:
|
| Software development ("programming" in your taxonomy) is a
| solitary activity. Software engineering involves multiple
| people and the explosion of complexity involved.
|
| I do like your point about knowing when not to program. Will
| keep that in mind next time I think about this.
| mdaniel wrote:
| Ah, yes, I forgot about that axis. I'd have to think more
| carefully about the distinction between "programmers who just
| happen to be in a google of other programmers" versus
| "software engineers in a team"
|
| _A lot_ of my software engineering mantras are centered
| around empathy management, both of internal consumers (future
| you, your colleagues, etc) and 100% unquestionably for
| external consumers (heh, "future you in 6 months" and folks
| that are _forced_ to use your software, people who you want
| to _renew_ ). The world sucks bad enough already: don't
| swallow error messages and voluntarily tell your users the
| equivalent of "have you tried turning it off and on again?"
| bcrosby95 wrote:
| I use software development in place of software engineering.
| To me software engineering involves more measurement and pre-
| planning than most developers use, even if they're working in
| large teams.
| 6510 wrote:
| God that was so funny. I'm that hammer guy you talk of!
|
| I know you can assemble at least a thousand Ikea cabinets while
| I hammer away on my carefully designed cabinet made from trees
| I've chopped down myself and nails I've forged. It fits
| perfectly with the table made by my great grandfather.
|
| By the time you've assembled 5000 cabinets they collapse as
| fast as you assemble them but you need 50 000 so you have to
| hire 300 people mostly to talk about how it is going, document
| the process etc. Ikea switches to THEIR new cardboard line that
| is both cheaper, faster to assemble and last even shorter. You
| get an even larger building and hire 100 more people. Then you
| put stickers with advertisement on the cabinets because woah
| the operation is getting expensive!
|
| You put cameras on them cabinets to track the user. Everyone is
| doing IoT now, you cant fall behind. You launch an app to open,
| close, lock and unlock the cabinets again with in-app
| advertisements and purchases.
|
| Ikea goes out of business etc
|
| I look at you, and back at my cabinet, and at you again... I
| have no idea what it all means. I wish I was the one to think
| of cardboard cabinets... or do I? I'm not Ikea, no one would
| have cared for it? I try to convince myself that building my
| own cabinet was a poor choice only to end up rubbing it with
| oil and carving Suum Cuique into its ornament.
| perilunar wrote:
| > and nails I've forged
|
| What? a true carpenter joins wood without fasteners /s
| 000ooo000 wrote:
| I have never found much value in these distinctions or
| analogies, particularly because the top tier is usually
| 'software engineering' which I find to be largely self-
| congratulatory given there are basically no requirements around
| ethics or rigor to claim oneself as an 'engineer' (at least
| outside of Canada who ruled recently that software engineers
| aren't engineers, IIRC - read that article a while ago).
| bouchard wrote:
| Depending on the province, "Engineer" and/or "Professional
| Engineer" are legally restricted titles.
|
| You can't use the title (neither can your employer) unless
| you are licenced to do so.
| 908B64B197 wrote:
| What people from Canada told me, they just add "B" in front
| of "Eng" which is a valid claim for someone working in tech
| with an engineering degree even if they aren't licensed
| (and what would they even license them for?).
| [deleted]
| [deleted]
| keyle wrote:
| This is so dumb. I'm sorry but I've been doing this for over 24
| years now and this kind of over simplification resume-building
| keywordy teenage fuckery makes me sick to my gut.
|
| If you're a good programmer, you know how to find your way out
| of the forest without knocking all the trees. Call yourself
| coder, programmer or engineer I don't care your leetcode scores
| and your fizzbuzz one liners, and the amount of stickers on
| your overpowered laptop.
|
| You're there to make the computer do the damn thing you want it
| to do with the least amount of resources. And of course it has
| to be maintainable, this isn't your bedroom.
|
| So respectfully, sir, take your taxonomy and pipe it straight
| to where the light don't shine. /s
| yjftsjthsd-h wrote:
| > You're there to make the computer do the damn thing you
| want it to do with the least amount of resources. And of
| course it has to be maintainable, this isn't your bedroom.
|
| That's engineering. That you don't want to care about
| terminology doesn't change that.
| brigadier132 wrote:
| The point is that these labels don't matter. Your response
| that something "is engineering" misses the entire point.
| You have not shown why it matters that we call this
| "engineering".
| aheilbut wrote:
| you're all going to upset the actual professional
| engineers
| musicale wrote:
| It seems to me that a key requirement for engineering
| would be that there are formal design specifications for
| the system (such as a car or bridge) as well as its
| constituent components. There are also usually
| mathematical models of the system that can predict its
| behavior and performance as accurately as needed for the
| application.
|
| Many modern software systems seem to lack such
| specifications or models. In these cases software
| development seems more like tinkering than engineering.
| yjftsjthsd-h wrote:
| I'm happy to agree that the terms have some fuzziness and
| that they're frequently misused, but no, words do still
| mean things.
| Dudeman112 wrote:
| >words do still mean things.
|
| They don't if there's no consensus
|
| And I'm _sure_ you ain 't got the authority needed to
| affirm that those definitions are commonly used in those
| ways
| auxfil wrote:
| [flagged]
| yjftsjthsd-h wrote:
| There's no need to be rude.
| Scarblac wrote:
| It's also programming, and coding, and developing. They're
| all synonyms.
|
| Or rather, they're used by different companies for the same
| type of jobs, some people make distinctions that other
| people don't know about, terms go in and out of fashion.
| They're all essentially synonyms because if there are
| differences, nobody agrees on them and there is no context
| in which they matter.
|
| Same for junior, medior, senior, et cetera.
|
| Except for architects. They're _ex_ programmers.
| Izkata wrote:
| > It's also programming, and coding, and developing.
| They're all synonyms.
|
| The way I see it, these three all refer to the same
| things, but "coding" is hobbyist and "developing" is
| professional. "Programming" is somewhere in between / for
| both.
| dack wrote:
| curious why it bothers you so much that someone else has a
| taxonomy? they didn't say you have to adhere to it. your
| opinion to just call all of it programming is fine too! but
| it's just an opinion
| brigadier132 wrote:
| It reeks of tiktok popculture bs. It also doesn't matter.
| mongol wrote:
| I deleted tiktok some months ago so I missed this
| reference. Is there something going on now that defines a
| taxonomy of things?
| [deleted]
| auxfil wrote:
| To you. It doesn't matter, to you. And you're just a
| number. Go touch some grass.
| PheeThav1zae7fi wrote:
| [dead]
| auxfil wrote:
| "Sorry but"? "Respectfully"?
|
| Don't care how many years you've been "doing this" for, you
| clearly haven't spent enough time sorting your own shit out.
| keyle wrote:
| On the contrary I think I have my "shit" sorted out.
|
| The industry is sick. So much money has flown into it over
| the years without anyone battling eyelashes at the sheer
| waste of resources, and I mean this both from the body
| count as the cpu cycles.
|
| I look at most products built today that cost millions to
| get off the ground and you have buttons busting out of
| windows, incoherence everywhere, 5 seconds to start the
| said product, and 2 seconds between 'pages'. Every version
| increment is a slow decent to hell.
|
| It all starts with the industry self-reinforced pumped-up
| resume culture, with hell holes like linkedin."Engineers".
| Please, have you met a real engineer? One that can do the
| maths, the design and build of a product? You need to wake
| up, engineering isn't writing docker files, cobbling python
| scripts copy pastes together and claiming that yaml is
| clean code.
| dunno7456 wrote:
| Do they even know how to yaml without complaining?
| markeibes wrote:
| If you do, you should get some professional help
| johnfn wrote:
| Take a breath and maybe step away from the computer.
| You're not fighting the "industry" or "waste"; you're
| just getting into an argument with a guy on HN with a fun
| classification scheme.
| keyle wrote:
| Fair point, thanks.
| markeibes wrote:
| Thank you for this.
| Genbox wrote:
| I've gone by a similiar taxonomy:
|
| - Coder: Can change scripts, HTML/CSS, SQL queries etc.
|
| - Programmer: Can write scripts, small programs, declarative
| queries etc.
|
| - Developer: Can write one or more of [applications, games, web
| sites, services] etc.
|
| - Software engineer: Can create complex software with many
| moving parts.
| schwartzworld wrote:
| I go by the title I'm given. My job has been remarkably
| similar from company to company despite them all using
| different verbiage.
| argo_navis wrote:
| My own version of that goes like this: the difference between
| being able to code and being a programmer is like the
| difference between being able to write and being a writer. One
| is a fairly simple skill you can teach to a child, the other is
| an art and a craft that can take a lifetime to master. Just
| because you can write doesn't make you a writer, and just
| because you can code doesn't make you a programmer. Inspired by
| a certain team member who believed that writing some code, that
| sometimes even worked, makes him as much a programmer as anyone
| else in the company and used to bristle and get defensive
| whenever someone tried to discuss finer points with him. "It
| finishes executing eventually, doesn't it? Just wait and stop
| wasting my time", while ignoring the fact that our
| administrators wanted to lock our team out because his script
| was putting so much load on the database.
| marcus_holmes wrote:
| > Programmers like to think that they spend all their time
| creating elaborate & complex abstractions
|
| Nope. Totally not. I spend all my time creating super-simple code
| using as few abstractions as possible. If anyone thinks my code
| is "elaborate" then I done it wrong.
| zol wrote:
| Teaching programming via the technologies in fashion and
| practical for getting a job _today_ is flawed. Teach the
| fundamentals - math, logic, algorithms. But, most importantly,
| teach how to learn and problem solve. If your students can't
| figure out how to quit their editor they're doomed in this
| career. Forget about React and hooks, those will be out of date
| by the time they're entering the workforce.
| namaria wrote:
| I agree in essence but I disagree it's fundamentally flawed to
| teach current tooling first. A lot of (aspiring) programmers
| and companies don't really care about actual technical
| competence. They just need to do something gainful for the day
| and get paid. The fact that I go about it differently doesn't
| mean they are wrong of flawed.
| abeyer wrote:
| Wait, "react week"?
|
| In what way is trying to cram learning react into one week a good
| idea? Especially if someone is already unfamiliar or struggling
| with classes and functions and using the tools. I've seen
| experienced programmers not really grasp react in a week.
|
| This feels like a "if we skip all the fundamentals to train
| 'marketable' programmers as fast as possible then they struggle
| with fundamentals" problem.
| userbinator wrote:
| I also hate the "tool fetish" (and general advocacy of hidden but
| substantial complexity) that the software industry seems to have
| created...
|
| _Programmers like to think that they spend all their time
| creating elaborate & complex abstractions_
|
| ...and that's the essence of the problem. If you want to create
| needless complexity, you'll also suffer its consequences.
|
| _although there absolutely still is a pretty strong contingent
| of people that advocate for a reversion to a "simpler" way of
| doing things_
|
| I'm one of these, and I still avoid additional tools like the
| plague, unless they offer a _very_ clear cost-benefit tradeoff.
| The vast majority of what I do needs only a few windows of a
| plaintext editor and a terminal. In my experience, others I 've
| worked with who are also similarly minimalistic tend to be more
| competent too; at the other end of the scale, those who seem to
| love complex tooling are also the ones who need them as a crutch
| the most.
|
| That said, I have a different view of the "coding" vs
| "programming" distinction than some of the other comments here;
| to me, the latter implies more mindless work while the former
| (exemplified by terms like "sizecoding" or "democoding") refers
| to a more intimate and lower-level knowledge of what's going on,
| along with increased creativity and a problem-solving
| perspective.
| Lerc wrote:
| I'm with you on this. I'm ok with tools that tha I choose to
| make things easier. When a tool is a necessity it is a big red
| flag. Once you get to compulsory tool chains, you are working
| in a world of someone else's personal preferences.
|
| Android development is like this. Ironically the code I have
| developed for Android tries to hide all of that by providing
| another tool to the end of the chain that takes simple code and
| wraps it in a package of monstrosity for the designated
| 'correct path' tool chain to use.
| asdff wrote:
| People need to live by the quote of "learn the rules before you
| break them." Its fine to use abstractions to save you time
| perhaps, but if you use them without understanding how they
| work, the considerations or assumptions being made, or what
| these results mean compared to alternatives, you are trodding
| off into the dangerous unknown, maybe even moving backwards.
| Uncertainty should be minimized.
| emme wrote:
| This ITiCSE working group tried to clarify why we should be
| interested in programming (not coding) in education: What We Talk
| About When We Talk About Programs
| https://dl.acm.org/doi/10.1145/3571785.3574125 (open access)
| cjohnson318 wrote:
| > For most non-Windows developers, a giant amount of time is
| spent using the terminal.
|
| The terminal might seem arcane, but the fact that you can
| copy/paste commands in there is a huge win. I'd much rather
| copy/paste some terminal commands into a safe place than try to
| take notes on what to click on to see what in a Windows system.
| yCombLinks wrote:
| I mainly use windows, but always have multiple terminal windows
| open. Do people think that windows means I'm clicking around in
| folders and double clicking files all the time to do work?
| rootw0rm wrote:
| same. also a couple putty terminals connected to tmux
| sessions.
| mdaniel wrote:
| I mean this seriously: then what do you "use Windows" to
| do? Because it sounds like you have a dumb terminal
___________________________________________________________________
(page generated 2023-04-01 23:02 UTC)