[HN Gopher] Practising Programming (2022)
___________________________________________________________________
Practising Programming (2022)
Author : luu
Score : 100 points
Date : 2024-01-09 10:07 UTC (12 hours ago)
(HTM) web link (tratt.net)
(TXT) w3m dump (tratt.net)
| 082349872349872 wrote:
| A stolen aphorism: "programming is not a spectator sport"
| maipen wrote:
| I will steal this too. Short, simple and effective.
| geff82 wrote:
| The problem with programming nowadays is not so much the
| programming language or the algorithm. The problem is the
| ecosystem. "In the old world" (as an example) you bought Turbo
| Pascal, installed it on your MS-DOS and practiced and explored
| the system, one step at a time. Nowadays, aside the OS, the IDE
| and the language, you have to deep-dive into different
| frameworks, different tools that all do the same thing in the end
| and understand how the pipeline works that, in the end and due to
| some magic produces something.
| chii wrote:
| > you have to deep-dive into different frameworks, different
| tools that all do the same thing in the end
|
| you aren't forced to use these frameworks and tools. You can
| chuck a NIH syndrome, and just write everything from scratch.
|
| The only reason you wouldn't is because you aren't interested
| in programming as a craft in itself, but is only interested in
| the output and productivity.
| karmakaze wrote:
| It also depends on the language and ecosystem. I've found
| that with Go or F#, they typically use smaller task oriented
| libraries, the largest of which might be an http router,
| client, config reader, and db driver. There may also be
| larger more framework style libraries but tend to be less
| often used.
| klabb3 wrote:
| Yes. When people ask why I prefer Go over Rust (as a solo
| dev in web-adjacent space) it's mainly two things:
|
| - std lib that does some really heavy lifting. (Dep tree is
| maybe 10 libs total, 2-3 layers deep for mid-sized
| projects).
|
| - concurrency is simpler and less boilerplate. Data races
| is a non-issue with good hygiene + race detector
|
| I would normally throw in the Go toolchain as a plus but I
| think Rusts tooling is very good as well, in some cases
| maybe even better. It's much more of a problem with other
| languages.
| kragen wrote:
| maybe what you need to practice is figuring out how to
| locate, evaluate, and use new libraries and tools?
|
| if not, then that means those libraries and tools save you
| less time than it would appear, and you might as well write
| your own code
| jodrellblank wrote:
| > " _The only reason you wouldn 't is because you aren't
| interested in programming_"
|
| Niklaus Wirth said writing an RDBMS was too hard for him.[1]
| Where does that fit into your "only" reason?
|
| [1] in the Questions/Answers section at the end of this
| presentation https://www.youtube.com/watch?v=EXY78gPMvl0
| adamddev1 wrote:
| > you have to deep-dive into different frameworks, different
| tools that all do the same thing
|
| You can also just choose one language/tool/framework and do
| _everything_ in it. I know this might get snubbed, but you can
| do almost anything these days with TypeScript. It can be as
| typed or dynamic as you want it (well sort of), plays well with
| UI/web/react, server with node, has pretty good performance
| these days, and you can even easily run CLI scripts with tsx.
| `#!/usr/bin/env tsx` (https://github.com/privatenumber/tsx)
| alkonaut wrote:
| This is why I like doing desktop dev (I imagine gamedev is
| simimlar). I grew up with turbopascal and similar. Doing
| desktop dev today is very similar. You have ONE repo. It has
| ONE tree of code, producing ONE project in ONE compilation.
| Your IDE has a _play button_ which launches 100% of the
| product, on your local machine, in ONE process, exactly as it
| would work and look at the end user. Being able to break the
| entire process of the product and step, knowing that there isn
| 't some other process somewhere else (a db, a web server) that
| keeps its own state is bliss. Highly recommended. Sure it's
| still lots of abstraction and you'll use a couple of
| frameworks. But a 10-20 year old framework in the desktop
| business is still a young one so there isn't that element of
| framework fatigue that you have in the web ecosystem.
| lolinder wrote:
| To make an analogy here--all programming used to be at most as
| complex as making a shed in your backyard. Now a lot of
| programmers are designing and implementing the equivalent of
| high-rise buildings. The existence of the large-scale
| programming tools creates the sense that you have to use them
| for your backyard shed projects.
|
| The thing is, you don't! Nowadays you don't even have to go out
| and buy Turbo Pascal in order to practice, you can just create
| an HTML file on your desktop and open it in your favorite web
| browser! Heck, if creating a file is too complicated you can
| press F12 and start scripting right away. Most operating
| systems come with Python preinstalled, so you can just drop
| into a REPL at any time, or write a script and run it.
|
| Programming hasn't become more complicated to get into, it's
| just that software engineering is growing up and people are
| given the false impression that they need to start with the
| professional tooling. We in the industry should be reminding
| people how truly simple it is to get started with something
| small, not bemoaning the existence of the large, complex and
| nearly interchangeable tools that we have to choose between to
| work at scale.
| danielvaughn wrote:
| I really want to create a series of tutorials on getting
| started with programming, but with this kind of focus. The
| biggest risk as a beginner is getting (a) distracted and (b)
| overwhelmed.
|
| By filtering out the noise and starting out small and simple,
| we'll make it much easier for newcomers to grasp the basics
| before learning about modern toolchains.
| colonelpopcorn wrote:
| At the same time, it used to be expected you would learn to
| program a computer you bought. So much so, that operating
| systems shipped with BASIC and a language manual. That is not
| the case today, but I guess software doesn't ship in the same
| ways it used to either.
| bluetomcat wrote:
| If you don't start with the professional tooling, you may
| have good fun, but nobody will hire you. When I entered the
| industry 20 years ago, "software development" generally meant
| desktop application development (Visual C++, Delphi) and
| "server-side web development" (PHP talking to MySQL, spitting
| out HTML). By just knowing how to upload files to an FTP
| server, you could do your own address book application or CD
| catalogue, and get hired.
|
| Now you need to fool non-technical people into demonstrating
| "industry" knowledge of a specific combination of Tool A/B/C.
| mbork_pl wrote:
| > If you don't start with the professional tooling, you may
| have good fun, but nobody will hire you.
|
| You're right, though some people want to learn to program
| to either have fun, or to make simple tools for themselves
| (see e.g. the discussion here:
| https://news.ycombinator.com/item?id=38877423; disclaimer:
| I only read a small fragment, but it seemed very
| interesting)
| sim7c00 wrote:
| too right. i am too bored with modern tools and
| frameworks hence i do not work as a programmer. i wish i
| could, but i cant get interested in it. not knowing
| modern tools and frameworks directly makes me unhireable.
| i always ask people who want to learn. do you want to
| learn programming, or want to be a programmer? (the later
| implying hirablility)
| geff82 wrote:
| You are right - Frameworks make building Skyscrapers easier.
| But it also means that you somehow first have to understand
| how to build them and THEN you have to understand what you
| don't need. Sure, starting out with some Python or Javascript
| interpreter is incredibly cheap and easy. But actually
| getting into serious programming is.... complicated. It feels
| like every shed now requires the foundation of the
| skyscraper.
| js8 wrote:
| > Now a lot of programmers are designing and implementing the
| equivalent of high-rise buildings.
|
| I get your point, but I think it's a bit of a myth. I work on
| mainframe applications and when you look at the actual
| business logic, there is a comparable amount of it in the
| apps that are 20, 30, 40 years old. I would even say that the
| modern methods of building software are to the detriment
| because there is a lot of incidental complexity coming from
| the tooling.
|
| It seems that creation and maintenance of business logic for
| a given domain isn't really much helped with modern tooling,
| so it takes about the same time to develop. On the other
| hand, businesses today are demanding things to be done
| cheaper with more UX polish. This means that actual software
| capabilities (which require domain knowledge) are made less
| general and take more time to develop. I would say today,
| many applications are simpler in terms of features than 20
| years ago.
| lolinder wrote:
| If by "features" you mean "business logic", you might be
| right. But UX polish that makes the application accessible
| to ordinary people who are going to give the app 2-3
| minutes to prove itself is a feature, and one that can take
| an _overwhelming_ amount of engineering to get right.
|
| Dismissing that engineering because your mainframe
| applications do more "work" with less code is shortsighted,
| a continuation of the "frontend developers aren't real
| engineers" meme that has _finally_ started to die.
| sim7c00 wrote:
| it took me like 5-7 years to find my way back to the old ways
| from within the muck of frameworks and high level maze/jungle
| that is there now. just to explore and learn my system... but i
| do recognize, programming itself has changed. less people are
| programming computers or devices, more are hooking in to
| frameworks, both are programming and creating cool stuff. i
| hate the jungle though, its a hot mess with lots of mosquitos
| and other bugs that constantly bite u!
|
| i am rather in the desert, where there is nothing and the few
| bugs you encounter are avoidable, but super fatal at the same
| time when not avoides or handled with care :')
| dakiol wrote:
| Oh boy. I would love to dedicate my entire working hours to the
| pure joy of programming (talking with customers and
| understanding their requirements, included). Instead I have to
| deal with tons of BS and accidental complexity in the form of:
|
| - k8s
|
| - ci/cd
|
| - containers
|
| - gradle/npm/poetry/composer/etc
|
| - ORMs
|
| - aws/gcp
|
| - jira/scrum
|
| - swagger/grpc
|
| - kafka/sns/rabbitmq
|
| and tons of yaml.
| rauljara wrote:
| A huge +1 for automating all the things as a form of practice! I
| don't even think that you have to (strictly speaking) end up
| saving time on a particular task for a lot of automation to be
| worth it. The act of practicing automation makes you more
| efficient at future automation. Even a failed attempt at
| automating something can teach you stuff about why certain things
| are hard to automate that can make you a better engineer.
|
| Getting in the habit of automating stuff in your editor and
| environment can also have a real snowballing effect. Yes, you end
| up "wasting" some time with yak shaves that don't work out. But
| it doesn't take long before the scope of what you can tackle in a
| day grows. It's really profound how much friction you can remove,
| and how much friction there is in fresh environments.
|
| Also, and ymmv, but a lot of repetitive tasks can be pretty soul
| crushing. Too much toil and you can come to dread your job.
| Automating something away almost always feels rewarding to me.
| Keeping yourself happy and motivated in your work should also
| count for something.
| swsieber wrote:
| Here here! And not just automation, but glue! At my last job I
| was a big advocate for automate all the things. "Manual Jenkins
| lookup task? I bet I could write a plugin for that.", etc. I
| got lots of practice jumping into new systems, tracing what the
| minimum essentials for what I needed to do were, and then
| making something useful.
|
| At my current job we have some code that generates typescript
| RPC bindings from our java code. It's quite slick but the
| backend definitions and the frontend definitions aren't linked,
| and navigation between them is a pain. So I decided to write an
| IntelliJ plugin that allows for navigation and find usages
| across our two languages. Took 2 days-ish, but totally worth
| it.
| pksebben wrote:
| I feel like my ADD makes the soul-crushing busywork thing _way_
| more of a motivator. Half of what I do at work is just an
| upgraded version of the things I do to go really far out of my
| way not to do a thing twice.
|
| There's another benefit, too. By "living in the system" and
| treating every part of the computer as something to manipulate,
| automate, and control, you get a more organic sense of the
| shape of the thing. It's a fairly common occurrence that I'll
| have a feeling that something ought to be different without
| really knowing why, and then later that feeling is proven out
| (this typically has to do with stuff like the shape of
| dependencies or the usage of tools in contexts that are a
| misfit, which then turns into ever-expanding kluges that should
| have been better design from the outset).
|
| That said, try explaining to someone else on the team that "I
| dunno, just doesn't feel, like, _nice_ ".
| revskill wrote:
| One thing that i self-regconized is, the more lazy you are, the
| better tool you'll implement ! Only lazy people can know what to
| automate to keep being lazy at work.
|
| The "busy" developers never or hardly see that problem, because
| they're happy with their business already !
| olzhas wrote:
| a very weird definition of being lazy.
| barrkel wrote:
| It's an old trope from Perl. The virtues of the programmer:
| laziness, impatience and hubris.
|
| https://wiki.c2.com/?LazinessImpatienceHubris
| 082349872349872 wrote:
| I was surprised to read an 18th or 19th century army manual
| that suggested, whenever one has the choice, that the ideal
| subordinate officers are either smart and lazy or dumb and
| active. Dumb and lazy has the obvious problems, but smart
| and active comes with the risk that they'll annoy their men
| coming up with all sorts of novel things to do that don't
| really need to be done. For people who had never heard of
| software, let alone software development, the authors
| seemed to know a lot about project management.
| lcnPylGDnU4H9OF wrote:
| I remember this as a quote from a general where each
| combination of traits had its place except "dumb and
| active". Smart and lazy become generals, smart and active
| are field officers, dumb and lazy are grunts, dumb and
| active are shot.
| somewhereoutth wrote:
| The lazy person invented the wheelbarrow! Everyone else was too
| busy lugging rocks around by hand.
| yard2010 wrote:
| For me, automating things was the karate kid thing only with
| programming. Automating is just like cleaning an old person's
| house just to realize you know Karate
| ChrisMarshallNY wrote:
| I just write Swift, every day (like, seven days a week, 52.4
| weeks per year)[0].
|
| It certainly seems to help me to be very productive. I am not as
| advanced as Swift scientists and academicians, but I speak it
| without an accent.
|
| As far as automating everything; I automate some stuff, but not
| that much. If the act of doing the automation teaches me
| something, I guess that's good.
|
| However, automation often encourages a "Greatest Common
| Denominator" approach to things that may be best served as hand-
| crafted, artisanal work. An example is what I'm working on, right
| now. I'm preparing an app for App Store release, so I have to do
| a whole bunch of screengrabs and videos. It's a big fat pain.
| Many shops automate this.
|
| But I am also carefully choreographing the process, and ensuring
| the best Quality for everything. The App Store page is incredibly
| important to branding (something many techs don't take as
| seriously as they should, IMNSHO). It's worth it to spend as much
| time as possible, working on it. I only do this, every now and
| then, so it's not really a big deal.
|
| [0] https://github.com/ChrisMarshallNY#github-stuff
| swsieber wrote:
| What this actually sounds like is building up a base of tricks
| and tools. Like a senior dev who has utility code they bring with
| them from job to job. The same applies to paradigms and code
| patterns.
|
| The fun thing about programming tasks and tools in particular
| though is that you crystalize your mental models into tools
| because of the natural of computers.
| swayvil wrote:
| Do you "practice programming" or you you "make something cool"?
|
| Both lead to learning to program I suppose. But the former is an
| alien concept to me. The latter is the more natural.
| jwindle wrote:
| I do practice programming, but I feel like the practice is not
| deliberate. Most of the time I find myself lost in whatever side
| project I have going on rather than being mindful about the
| improvement of my craft. As stated in the article, it is tough to
| keep up with practice due to life changing. I now have to take
| much better care of myself than I used to to be present with my
| family. This takes time away that I used to spend learning.
|
| Something I've found tough at this point in my career 10 years in
| is trying to practice skills that I don't care as much about but
| can be necessary at times. I have many friends in my area that
| are very skilled at frontend development. I am not. I will reach
| for the first template library I can find to get a frontend
| built. I wish that I could take the time to properly sit down and
| learn HTML/CSS/JS but every time I do I get some weird focus
| block. It's almost as if my brain shuts down and refuses to take
| that information in. Maybe because I know that my time is
| limited?
|
| I have to set really strict schedules with myself to get any kind
| of practice in. Sometimes this works and sometimes it doesn't. Oh
| well.
|
| I'd love to start automating more common tasks for myself.
| agentultra wrote:
| I do practice and depending on my goals I take different
| approaches.
|
| The two main ones are: _data structures and algorithms_ and
| _rapid prototyping_.
|
| The former is basically leetcode stuff and straight forward. I
| want to be able to implement bread-first search without having to
| look it up. And I want to be able to do it without it occupying
| too much space in my mind. Repeated practice helps me retain this
| kind of stuff so that it becomes reflexive and almost like muscle
| memory.
|
| The other kind of practice takes a bit more work. I did this for
| a period where I produced a body of small prototype games. The
| idea was to write them in the fastest way I could. I forgot all
| about coding practices that you would use in production code and
| went all in on, "how fast can I get from typing the first byte of
| source code to user interaction?"
|
| For these projects I used a timer. Everything was permissible. It
| was code I wouldn't use again so I didn't care about it being
| reusable or readable or anything like that. I kept light notes on
| my experiences with each of them.
|
| Prototyping is an oft-overlooked skill that can some times be
| useful. The idea is to write some code to hash out the idea;
| experiment with it in the fastest way possible with the goal of
| finding out whether the idea itself is viable. For a mountain of
| a task like developing a game, and in boring stuff like
| enterprise software, it's useful to save yourself a bit of work
| from going down a dead end if you can scout ahead a little bit.
| clbrmbr wrote:
| Only intentional practice I've been doing has been learning Rust.
| Everything else is just solving classic compsci problems over and
| over again, in C, on little embedded systems, which I guess is
| practice too but it just doesn't have a steep leaning curve.
| gabrieledarrigo wrote:
| In your opinion peeps, is this still relevant with the advent of
| LLM?
___________________________________________________________________
(page generated 2024-01-09 23:01 UTC)