Practising Programming

I don't believe programming is anything like other skills(That's why I love tech jobs!). There's no muscle memory strictly needed. No precise memorization.

There's none of what I call "atomic time regions" where once you start, everything has to be right or the whole thing is considered a failure(Think of calligraphy and how one bad move can ruin a piece).

Instead there's just a small amount of base knowledge every coder needs, plus vague familiarity with frameworks, and a general sense of what will possibly screw you over later(Anyone can write most programs that don't involve novel math or algorithms, the challenge is in making them not screw you over somehow).

If a world champion level programmer makes a basic app in Vue, it will maybe be 20% better than mine, because... modern programming is all about providing obviously ways to do common things. There's not much variation possibly in something so completely technical.

If we both design 100kloc apps, his(hers?) will be a lot better. There design choices in that kind of thing that don't come up at all in a 1 day project.

Sports people say you play how you practice, right? So there's only one kind of technical practice I care about. The kind that is similar to production code. Either in scope and scale, or depth of crazy algorithmic math, or any other way, but if it doesn't replicate production... is it really practice?

Guitar plays have a concept called "Noodling", defined as playing guitar... but not really playing something. It might sound OK, but you can kind of feel that it's not really helping you towards being able to play that song you want to play, the way you actually want to play it.

It's widely considered not really practice. Almost like scrolling Facebook compared to reading a book, like I should be doing instead of scrolling Hacker News....

I don't make any effort to practice programming unless I want to learn a specific new technology.

I just do projects that I think are worth doing, and resemble the stuff I want to do in the future, and I try to do them well without hackery.

Yeah, when i practice programming its normally a toy version of something thats been bouncing around my head for an actual project. And normally something that i would like to learn for myself or a curiosity about how something works.

Generally outside of work hours I'll throw together a vague example and validate that the idea is something that works and get vaguely familiar with the libraries involved. That way when I go to build it at work I don't start from zero. If its for a personal project i just noodle in a repl or ide on a branch

> When we see a world-class musician flawlessly play challenging music, it can be tempting to imagine that they were always able to do so. A moment's thought makes it obvious that they must have had to spend huge amounts of time practising basic techniques in order to reach that level. What's less obvious is that they have to continue spending considerable amounts of time simply to maintain that technique, let alone expand it.

The average SaaS engineering job is akin to recording a different concert for several hours every day, with no time to tune your instruments and little investment to fix or replace them.

Even if the orchestra is out of tune, the conductor won't necessarily notice or care because his job is not to actually conduct the orchestra. In fact, he doesn't understand music, he just knows how to request and deliver recordings. At times he pretends to understand music, which mostly involves flailing his arms spastically while musicians do their best at not minding him.

After 8 hours where only a couple were actually spent playing and the rest were spent arguing and debating how to play music with the conductor and the audience, musicians are left exhausted, with no energy to improve their skills.

I think it's a good point that there are many more domains within large organizations than one might expect from the outside.

However, people are undoubtedly in more specialized roles and teams on the whole.

I'm merely trying to explore the differences in growth as a developer between the two extremes.

While I don't think as many people who build React interfaces at Facebook are also spending days creating Postgres schema diagrams and responding to mission criticial DevOps failures, I certainly grant that the small team varied project approach might be more similar than I realize.

In that case or either way, the most impactful difference in how personal growth is impacted may be the surrounding ecosystem and knowledge base.

In one scenario you are flush with existing infrastructure and the thoughtful people who designed or maintain it. This can focus your work as you mentioned and is also a great learning environment.

While on the other side you are working without a safety net slogging your way through creating everything* from scratch. This forces you to learn new skills in unfamiliar areas and managing all sorts of tradeoffs autonomously (there could be literally no one else to motivate you or to ask a question aside from your search bar).

* Infrastructure, tools, processes, etc. I'm not talking about reinventing the wheel though you are free to do so for your own pleasure or peril.

You may want to watch a number of Benjamin Zander's YouTube videos and revise your statement.

I share your frustration on feature pressure with no official room for practice and refactoring however the metaphor about the role of a conductor is completely off. A conductor knows and understands music, deeply, a d they connect the dots and coordinate the orchestra and zoom into lots of little details while improving the big picture.