7 ms·

Practising Programming (2022)

114 points by luu 3y ago

deleted 3y ago
[deleted]
082349872349872 3y ago
A stolen aphorism: "programming is not a spectator sport"
- maipen 3y ago
  I will steal this too. Short, simple and effective.
geff82 3y ago
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 3y ago
  > 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.
  - kragen 3y ago
    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
  - karmakaze 3y ago
    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 3y ago
      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.
  - jodrellblank 3y ago
    > "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 https://www.youtube.com/watch?v=EXY78gPMvl0
- adamddev1 3y ago
  > 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 https://github.com/privatenumber/tsx)
- alkonaut 3y ago
  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 3y ago
  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 3y ago
    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 3y ago
    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 3y ago
    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.
- sim7c00 3y ago
  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 3y ago
  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 3y ago
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 3y ago
  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 3y ago
  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 3y ago
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 3y ago
  a very weird definition of being lazy.
  - barrkel 3y ago
    It's an old trope from Perl. The virtues of the programmer: laziness, impatience and hubris. https://wiki.c2.com/?LazinessImpatienceHubris https://wiki.c2.com/?LazinessImpatienceHubris
    - 082349872349872 3y ago
      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 3y ago
        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 3y ago
  The lazy person invented the wheelbarrow! Everyone else was too busy lugging rocks around by hand.
yard2010 3y ago
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 3y ago
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 https://github.com/ChrisMarshallNY#github-stuff
swsieber 3y ago
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 3y ago
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 3y ago
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.
- diarrhea 3y ago
  I also have similar blockage going on when trying to learn front end technology. My theory is: I know beforehand how impossibly much it is. If you printed and stacked the CSS, JS and HTML specs (not sure they all have one), it’d reach into space. And that’s not even talking about the technology built on top of these (TypeScript, React, Tailwind, …). Simply insurmountable, and while quite interested, I am more interested in other topics. Such are the limitations of time I guess.
agentultra 3y ago
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 3y ago
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 3y ago
In your opinion peeps, is this still relevant with the advent of LLM?

114 points by luu 3y ago

deleted 3y ago

[deleted]

082349872349872 3y ago

A stolen aphorism: "programming is not a spectator sport"

maipen 3y ago
I will steal this too. Short, simple and effective.

geff82 3y ago

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 3y ago
> 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.
- kragen 3y ago
  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
- karmakaze 3y ago
  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 3y ago
    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.
- jodrellblank 3y ago
  > "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 https://www.youtube.com/watch?v=EXY78gPMvl0
adamddev1 3y ago
> 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 https://github.com/privatenumber/tsx)
alkonaut 3y ago
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 3y ago
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 3y ago
  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 3y ago
  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 3y ago
  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.
sim7c00 3y ago
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 3y ago
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 3y ago

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 3y ago
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 3y ago
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 3y ago

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 3y ago
a very weird definition of being lazy.
- barrkel 3y ago
  It's an old trope from Perl. The virtues of the programmer: laziness, impatience and hubris. https://wiki.c2.com/?LazinessImpatienceHubris https://wiki.c2.com/?LazinessImpatienceHubris
  - 082349872349872 3y ago
    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 3y ago
      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 3y ago
The lazy person invented the wheelbarrow! Everyone else was too busy lugging rocks around by hand.

yard2010 3y ago

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 3y ago

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 https://github.com/ChrisMarshallNY#github-stuff

swsieber 3y ago

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 3y ago

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 3y ago

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.

diarrhea 3y ago
I also have similar blockage going on when trying to learn front end technology. My theory is: I know beforehand how impossibly much it is. If you printed and stacked the CSS, JS and HTML specs (not sure they all have one), it’d reach into space. And that’s not even talking about the technology built on top of these (TypeScript, React, Tailwind, …). Simply insurmountable, and while quite interested, I am more interested in other topics. Such are the limitations of time I guess.

agentultra 3y ago

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 3y ago

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 3y ago

In your opinion peeps, is this still relevant with the advent of LLM?