I'm curious whether there's a similar primitive for programming. Whether there's a baseline skill you can practice daily and find yourself inevitably improving.
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...
Care to elaborate? There are people who cannot type (like physically) and yet they are programmers. Also, programming is all about mental gymnastics. Only accidentally (we are in the year 2022) we need to take our hands out of our pockets and type our solutions in an editor.
By Jeff Atwood, cofounder of stackoverflow.
When you are refactoring a codebase, when you need to rename things inside a block, when you need to match function signatures, when you need to change a bunch of statements or expressions inside a block ... that's where VIM and emacs shine.
Additionally I'd recommend to learn about fuzzing and the ideas behind it, because it teaches you to write more defensive code and will teach you to never use these "quick return" style branches ever again.
Care to elaborate? Im not sure if I understand but I thought quick return from function was quite goode strategy for defensive coding? Or many You are taking about something else (I do not know fuzzing - can You point to some link with good explaination that would sell this concept to me?)
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. :-)
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
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".
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.
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.
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.
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.
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.
-Working on coding projects -Practicing writing code -Studying different programming languages - Doing online coding challenges
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.