Ask HN: What can you practice every day to improve at programming?

there's no baseline skill aside from syntax drills. those are of limited help longterm.

if you really want to improve, try learning more advanced math concepts and using them in code to solve a problem. a good example would be learning linear algebra to implement the low level primitives and operations for a ray-tracer.

Programming over a long term is less about syntax and nore about te meta skill of building something. ANYTHING. just have a goal and work with that goal in mind. you'll get better as you go.

Check out Coding Math’s YouTube channel. It has a bunch of simple utilities, and the projects are fun.

While actually using your tool of choice is important to mastery, my instincts say that if you're working in a technical field, you probably don't need extra practice just for the sake of it. Designing and reading programs are skills which seem to be improved with repetition and persistence more than study. It's also often said that learning many languages of different paradigms makes better programmers.

Typing.

If you aren't touch-typing and are looking down at the keyboard, or even just having to spend mental cycles thinking about typing, it's taking away from your capacity to think about the problem you're solving.

Can you write programs without being able to type? Sure, of course. But, you asked for basic skills that will improve your programming, so I say: typing.

60 WPM is a minimum. 80-90 WPM is a reasonable low goal. 100-120 WPM is probably an upper bound limit on QWERTY; if you're very serious, you may want to consider learning Dvorak or Colemak layouts, where you might be able to hit top speeds of 150-200 WPM.

1. Touch typing. You must be able to type as fast as you think. So that there are no barriers between your brain and the code. [0][1]

2. Alan Kay says: "if you want to be a better programmer, play more violin." The idea being that playing an instrument improves our brain

3. Write tests for ever open source project you encounter: unit tests, property tests.

4. Write specs using TLA+

[O] some people say that typing speed doesn't matter, because the slow part is thinking about the code. Those people are wrong.

[1] see the essay: "We are typists first, programmers second" https://blog.codinghorror.com/we-are-typists-first-programme...

build stuff. and I don't mean go write code, I mean literally run make/yarn build/compile whatever is interesting to you. this way you run into all the internals, different setups and modules and glues and bugs and errors and fixing and sometimes even finding workarounds by hacking stuff. I've done security research and reverse engineering and got to experience such wide variety of systems. many times I get asked if I "learned by myself", so I answer I've self-taught but had great teachers.

Figure out something you are interested in, and start your own project in a language you like or would like to learn. 13 years ago, HashBackup was my first Python project and I still enjoy working on it nearly every day.

As a piano player too, you'll get a lot more out of practice time if your brain is fully engaged on every note rather than practicing mindlessly. :-)

I'm going to use Math problems as scales. Maybe proofs from Elementary Number Theory or from Analysis.

Math. I majored in psychology (very little math relative to STEM) and got into programming after graduating. After 5 years of working as an ML engineer (basically a lot of calculus and linear algebra) I decided to study more abstract math starting with proofs and discrete math. So many things started making sense at a deeper level and became easier. I think discrete math in particular since it’s very important in CS but just like playing an instrument, it just improves your thinking.

Pick a tool in your regular workflow and spend some time learning it better. What are the new ways you can use `git log`?

Whatever thing you're working on, after you've come to understand how it all works, try to think about how to make it do the same things with a more compact representation, number of processes, or interface area.

Typically features have been incrementally added, most naturally by adding to the pre-existing design. It's rare that things get factored as thoroughly as possible. Doing so at every step is also inadvisable. The purpose of this exercise isn't to make the current system x% better, but rather to know what's being 'left on the table' that could be tidied-up in the future when a refactoring is due. With practice, you get good at noticing and revising designs in this manner while adding new capabilities paying refactoring costs incrementally.

What's even better is that the new smaller/simpler design is easier to explain, understand, document, and further adapt.

Another kind of exercise I do is think of all the steps/operations for the happy-path of an existing or new capability/feature in the context of where it fits in the most common use-case. List out the key operations/steps. See if there are any ways to reduce the number of steps or conditionals. This can often be achieved by making non-uniform things into uniform things. E.g. 'shapes' that can return their own bounding box, treating single or multiple things all as potentially multiple, etc--kind-of like programming with monads in a normal procedural language.

Simple doesn't come easy. Easy is doing the most obvious adjacent thing--usually the first thing that comes to mind. Simple is the last thing you can come up with because it's what's you get when there's nothing left to remove. i.e. "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." ― Antoine de Saint-Exupéry

You could try programming katas or very simple leet code problems. After completing 10 or 15 of them in your favorite language, try again. It should go faster and the quality of your code should improve a bit (unless you are already at a fairly high level). You can then move to a language you know less well or to one you would like to learn.

Sadly, at least for me, even relatively routine programming tasks take more time than drills like shadowboxing or speed bag work, so finding a close equivalent is hard.

In my opinion, the goal of programming is to solve problems, so to become better at solving problems one needs to be aware of the many different (programming/systems) solutions implemented by other people out there. Just a simple example, in http://aosabook.org/en/index.html one can see how a template engine can be programmed. You read it, understand it, and keep the solution in your bag of "solutions to be used later on". Maybe in the future you may need to implement a tiny engine template, so would know where to start.

Another example https://www.martinfowler.com/eaaCatalog/

I don't think programming as in: typing, writing better "for" loops, etc., has anything to do with "getting better at programming".

There is no one answer to this question as it depends on the individual and what they need to improve on. However, some things that could be practiced every day to improve programming skills include:

-Working on coding projects -Practicing writing code -Studying different programming languages - Doing online coding challenges

Others have said touch typing. That is a given, but I don't think the speed matters once you get over a baseline (and yes, I say that as a relatively slow touch typist).

I would extend it to be able to touch type your IDE of choice (which should be a Jetbrains product, if possible), by which I mean be able to use the shortcuts without having to think about what they are. If you think something should be refactored, you should already be selecting which methods to move to a superclass. If you need to rename a function, you should spent 100% of your effort on coming up with the name and 0% on navigating your IDE.

Work through reading the manual. Of your programming language of choice, of your IDE, of your packages, etc...

Programming is like creating music, not playing it.

There are no primitive building blocks to this complex skill. Each “building block” like math, abstract thinking, reasoning etc - is a complex thing in itself.

So if you want to get better at writing music, you have to write more music. There’re no short cuts or cheat codes to mastery, sorry.

When you're coding you can look up most stuff on stackoverflow etc in not that much time.

Another approach, is to daily spend time studying the stack you currently work with including the source code and books about the theory of architecture for those sets of tools.

Over time you can expand into other areas too that seem interesting.

Having a really deep and comfortable knowledge of your underlying language and tooling goes a long way toward being able to work quickly and make choices that are a natural fit for the stack rather than shoe horned in.