
Practicing Programming (2005) - luu
https://sites.google.com/site/steveyegge2/practicing-programming
======
ntoshev
I think practicing programming should be about:

1\. trying many new things

2\. in a very tight feedback loop

So, code little ideas, but make sure you start from the essence of the problem
- not the registration/login process, not the new API - start directly from
the part that's new and challenging and risky. In this way, when the idea
fails, you wouldn't have wasted time building support infrastructure for it.

Also, pick light and flexible tools for exploratory programming - dynamic
languages, REPL, etc.

------
vega
So, fair point. Keep up to date with technology, don’t become obsolete. Sure.

But I don't know about the metaphor. I mean, programmers do practice daily. If
you’re coding at work you’re practicing.

More to the point: if the author played in the NFL he’d want the cornerback to
do exceptionally well at game time, to practice daily, of course, AND to go
home at night and keep practicing to become a quarterback AND a coach because,
you know, got to keep up. My guess is that’s not what happens in the NFL.

~~~
cicatriz
Coding at work is certainly not optimized for practice.

NFL players do an exceptional amount of highly optimized training in addition
to their "work" of playing the game: [http://www.si.com/nfl/2014/12/10/tom-
brady-new-england-patri...](http://www.si.com/nfl/2014/12/10/tom-brady-new-
england-patriots-age-fitness)

No, you shouldn't _have_ to work a 40+ hour week and then go home and practice
to make a living as a software engineer. But if we want highly performant
programmers, we should figure out the best ways to practice (and probably
spend less--but more effective--time on production code to balance it all
out).

~~~
JeremyMorgan
>No, you shouldn't have to work a 40+ hour week and then go home and practice
to make a living as a software engineer. But if we want highly performant
programmers, we should figure out the best ways to practice (and probably
spend less--but more effective--time on production code to balance it all
out).

You're coming very close to identifying a major problem with our industry that
isn't likely to go away. Yes you absolutely do have to "go home and study" to
keep up as a software engineer/programmer. This is due to two reasons:

1\. Advancements in technology outpace us

2\. We're generally overloaded by management that doesn't understand what we
do.

As for #1 there isn't much we can do to change that, and who would want to?

But for #2 it's a major problem. In many cases our 40+ hours have to be filled
with coding because of the unrealistic deadlines that are posed on us from
managers who don't understand the work.

Most of us are managed by people who have no idea what we do. They want "more
more more" in terms of features and gizmos but haven't the slightest
understanding of what goes into it. Add in scope creep and wasted time with
meetings (that make them look busy) and that adds up to a long work week for a
developer. And when you ask for time to study or learn something new, the
response is "sure, when things aren't so busy".

This just reinforces my belief that you need passion to do this. You have to
love development so much you're willing to put up this stuff, work your ass
off and still want to go home and learn more.

~~~
kyllo
Yes and it's also because the projects you'll typically work on in a corporate
environment are like maintaining and adding features to boring CRUD apps and
your skills will atrophy if you don't actively seek interesting, challenging
work on your own time.

~~~
JeremyMorgan
I agree 100%.

------
nkangoh
I would be interested to hear the opinions (or more accurately, experiences)
of developers regarding "practice." I'm beginning my career as a software
engineer this summer and I would like to become an "excellent" engineer.
Employable, of course, but also the go-to for knowledge in a subset of
computer science (let's say natural language processing, for example).

Given I have a very long life (hopefully) ahead of me, what would you say is
the best way to do this? Yes, coding is good, but is it the best way? I spend
a large amount of time doing side projects, but eventually I'll have a family
and other obligations, so I would need higher impact, less time consuming
practicing options.

An example of this I guess is how many expert violinists actually "practice"
for a surprisingly small amount of time because the practice is so deliberate.
What's the equivalent for us?

~~~
joe_the_user
I do martial arts and I program.

Nearly everything I do in martial arts is practice for the relatively few
times I might spar with someone.

I don't do any skills practice for programming. I've never met anyone who did
something equivalent to honing basic movement, practicing balance and similar
things.

Reading about the latest programming methods is a good thing and can increase
your repertoire but I don't think it's comparable to skills-practice in
martial arts or music or something similar. In practices like this, there are
fundamental skills that need to be in good shape to allow a person to anything
creative in the discipline (I have no idea why expert violinists wouldn't
spend significant periods practicing but I know little about that. I know that
most music requires significant practice of basic skills to achieve mastery).

My suspicious is that programming is an activity that is strongly connected to
the brain's language centers and so mastery of it on the skills-level is
simple and the problems with it appear on the judgment and understanding level
- which doesn't make it easy, rather gives it that extraordinarily hard
quality that we programmers are familiar with.

Also, most skills-practice disciplines are performance arts rather than
production processes. Machinist and auto-mechanics also have high skill levels
but like programmers they are obligated to show some significant
accomplishment for their entire time at work. We can contrast this with a
musician or other artist, who if they give an amazingly beautiful performance
once a month and have it recorded is considered remarkably successful. In
contrast, a programmer gets few accolades if she can just "be a great
programmer" for an hour a month - what is instead considered with programmers
is their entire output, which puts an entirely different series of pressures
and constraints on the programmer.

~~~
kyllo
Cool, what martial arts do you do?

Brown belt in Brazilian Jiu-Jitsu here. I love coding for some of the same
reasons I love training and sparring. It's endlessly complex, so you never run
out of new challenges.

------
throwaway1890
This is good advice, but it's a bit hard to act on. How does one know when to
leverage their existing skills to build something vs spending time learning
something new and using it to build something (which might not pan out due to
lack of experience with that technology, and which will certainly take longer
than using what is familiar)? For me, the biggest investment is that of
time... and while he provides ideas for small things to do, in the end one
really needs to use a technology to grasp it (which he does say).

I'm a beginning programmer working on a small team. We won't be hiring anytime
soon so many of the things he suggests aren't options. I'm lucky in that I've
been able to learn a lot of things across the stack. However, our main
language is Perl, which isn't the most marketable language anymore.

I have an idea for a useful little site -- something that will look good on a
resume, but not something that I can imagine becoming a big money maker of any
sort. Do I use my main strengths, my familiar technologies (such as Perl and
SQL), to write the site? Or do I choose something that might be an up-and-
coming technology (like Node.js or Clojure) even if I can't really find any
jobs in my area for them?

I do love learning. I spend downtime at work learning new things, but my time
outside of work to actually build stuff is limited. I'm getting a bit burnt
out on learning new languages and frameworks... I've wandered between Perl,
Elixir, Haskell, Clojure, Racket, Javascript/Node, and any number of
frameworks for them. I just want to make something solid, but I'm worried that
using my Perl skillset will be more of a short term than a long term gain.

I know there's probably no easy answer to this question. But it seems to me
that it's better to have made something and launched it (even if it doesn't
use the sexiest tech) than to have something half-finished stagnate because I
don't have the time to learn the ins and outs of the quirks behind some new
tech. Does anyone have any insight into handling this? Thanks.

~~~
sleazebreeze
I've had the same quandary as you. Mainly work with Java and Javascript at
work, so I wanted to add a purely functional language. I flirted with Haskell,
Scala, Node, Scheme and Clojure and eventually settled on focusing on gaining
a better understanding of functional programming with Clojure because it has a
familiar platform (JVM), syntax I can understand (sorry Haskell and Scala) and
it seems like it's going places.

Last year, I maintained a focus on Java and JS because I'm still intermediate
level with those and didn't want to distract myself with other languages and
paradigms. That was a good choice.

For this year, I've made a commitment that any side projects I do, I do in
Clojure. I cheated and started in 2014, but I am liking this way of focusing
on a language for a year and doing everything in that.

Maybe once I have more familiarity with more languages, I will feel more
comfortable using the appropriate language to solve a particular problem.
However, isn't that part of learning? Using a hammer on nails, screws and
bolts and figuring out what the hammer is good at and what it isn't?

------
JeremyMorgan
Great article. This is something I've said pertaining to interviews for years.
There has to be advancement in the skills. Doing something every day is not an
indicator of improvement.

In fact, sometimes it can be worse. When someone says "Call this person now!
he/she has been writing C# for 10 years!". That's great and all but have they
been improving their craft over that 10 years, or getting enough work to not
get fired? There's an enormous difference. And many times I would run into
folks who sunk into a rut and did the same thing for 10 years basically
"coasting". They make small incremental changes in what they do every day, but
weren't out seeking ways to drastically improve.

Programming is different than many other fields simply because it requires
passion to survive. If you look at learning new things like "Ugh, I have to
learn ___", eventually you'll start slipping and end up hacking PHP Wordpress
installs somewhere for subpar wages if you're employed at all. If you seek out
new things to push yourself because it's enjoyable keeping up is intuitive and
easy. Even stuff you may never use for your job can teach you new ways of
thinking.

Now if you'll excuse me I need to go back to playing with RUST.

~~~
guelo
With the speed of technology changes I think it's pretty hard for programmers
to get stuck in the exact same rut for 10 years.

Using your example of C#, there has been huge changes in the last 10 years to
the point that it's barely the same language.

Even if you imagine the most staid company that refuses to upgrade their tech
stack, the last 10 years has seen so many changes in the web and mobile that
it's hard to imagine that there hasn't been some pressure on even the most
unmotivated programmer to learn new skills.

~~~
JeremyMorgan
That's why I mentioned iterative changes, such as the changes to C# over the
last 10 years. Just because they started using generics at some point doesn't
mean they've been learning anything to drastically improve their code.

It's very easy to sit at a company building calendar apps for ten years and
fall behind the rest of the world. I see it every day.

------
peterwwillis
This is a _very_ long way of saying: you should learn new skills, and practice
the skills that you think will be valuable by the time you need to get a new
job.

Practice isn't rocket science... heck, just practice different kinds of
programming. You'll naturally improve at everything because it all relates to
each other. To borrow from his football and music examples, even practicing
dance will make you a better football player, and so will playing the drums
for a cellist.

------
yellowapple
Yet another reminder about how remarkably similar programming and musicianship
are in mentality and artistry. It's no wonder that I enjoy both :)

------
antichaos
(2005)

~~~
sctb
Updated, thanks.

