This version of the site is now archived. See the next iteration at v4.chriskrycho.com.

Syntax is easy. Languages are a bit harder…

(A note to would-be designers and developers, and to myself.)

You don’t really know a language till you know the library and the tools. Syntax is easy.

Look: any trained C/C++/Java developer can pick up the syntax of Javascript or PHP in no time flat. They’re just not that different; the hardest adjustments are to using an interpreted language instead of a compiled language, and to dynamic typing instead of static typing. Even with a language a bit further out – Python or Ruby, for example – the syntax remains relatively straightforward to learn.

But here’s the trick: a language is more than syntax. Think about it: English is more than its grammar, and indeed more than merely its vocabulary. Learning English requires first learning its vocabulary and its grammatical rules. Mastering English, however, requires learning far more than simply words and the basics of how they fit together. It involves gaining a knowledge of connotation as well as denotation. It requires understanding of culture. It demands grasping the ways that different words and phrases and approaches are appropriate (or not) in various contexts.

The same is true for a programming language. It is one thing to know how to construct a foreach statement in PHP. It is another thing entirely to recognize that sometimes you’re better using a library function that does the same thing you want your loop to do, only faster and better. You have to learn the libraries, and in some cases you have to learn the standard tool sets.

Learning Ruby is one thing. Putting it in practice in the web development community means learning more than Ruby or even its standard library though; the vast majority of Ruby web development these days seems to be using the Rails framework. Similarly, you can have a good handle on PHP and even know its library well – but you’ll be much more employable if you also know the Zend framework, because while it’s not quite an industry standard, it’s close.

Even back in the world of static software, this is true. Good luck becoming a top-notch C++ programmer in a short time. Learning the way C++ approaches object-oriented development is simple. Learning the enormous library will take longer. Getting a good handle on templates? You’ll be at that for a while.

This is the thing so many people fail to understand: software engineering (and even programming, which is only a subset of engineering) is more than knowing some syntax or the basics of logic. Being a really good developer – being the kind of developer I hope to be someday – requires having a good handle on the language and its library, its strengths and its quirks, the primary tool kits and the corner cases. It is not enough to be able to regurgitate the syntactical rules for the language; best practices come to be over time as people discover both the benefits and the costs of various approaches. The most obvious solution may also end up being the wrong solution.

The only way to gain this knowledge is by immersing yourself in using it and by studying. You can either repeat the same mistakes everyone else has already made, or you can put forth the effort to educate yourself so you can avoid them. You can either content yourself with a superficial understanding of the language, or you can dive in and really get a handle on how it works and what really makes it tick.

Shockingly, these are the same realities that apply to learning any new subject. No one ever mastered the piano, or became a skillful tennis player, or really succeeded at gaining any skill without putting in significant time and effort. If one of the major benefits of the modern web design and development is that just anyone can jump in and start doing it, one of the problems is the same reality – because most of the people who jump in and start are not willing to do the hard work to actually become good at their field. They don’t want to study, they don’t want to dig in to the hows and whys as well as the whats of any given discipline. And accordingly, they just aren’t very good.

If you’re not prepared to work hard, be prepared to always be a third-rater. If you want to do well, be prepared to work hard. Stop thinking you know a language because you know the syntax. Stop thinking you know design principles because you’ve read a few articles. Stop thinking you don’t need to study any more. You always need to study more.

Discussion

  • Jerrad Genson thought to say:

    Like most skills worth knowing, software development takes time and dedication to master. Indeed, Peter Norvig wrote in Teach Yourself Programming in Ten Years, about the “How to Learn Language X in N Days” fad, that “There are no books on how to learn Beethoven, or Quantum Physics, or even Dog Grooming in a few days”, and “the book can only be talking about a superficial familiarity, not a deep understanding. As Alexander Pope said, a little learning is a dangerous thing.”

    And so it is. I know people in managerial positions at software companies who make key development decisions, without the experience of having ever written a program of any significance in their life (but they took a class over C in college! …or was it C++?). Need I even mention what usually becomes of the projects these people manage? As the software industry has taught us, time and time again, there are no shortcuts worth taking here.

    But there are a few points to which I digress.

    “You don’t really know a language till you know the library and the tools. Syntax is easy.”

    Certainly, vague familiarity of a language’s syntax does not constitute a genuine understanding of the language. But what does it mean to know the library and tools? Must one memorize every class in the standard library to know Java? Are Tkinter, wxPython, Django, etc. all required to know Python?

    Not really. In fact, Eric Raymond said that “web application frameworks like RubyOnRails, CakePHP, Django may make it too easy to reach a superficial sort of understanding that will leave you without resources when you have to tackle a hard problem, or even just debug the solution to an easy one” (How to Become a Hacker). Now, Ramond wasn’t advocating that software developers should forgo web application frameworks, or reinvent the wheel all the time; he was talking specifically about learning to program. “A hacker”, he wrote, “cannot approach problem-solving like a plumber in a hardware store; you have to know what the components actually do”.

    What separates excellent programmers from mediocre programmers is not the number of tools they know, or library functions they’ve memorized. Perhaps the most relevant quote from Raymond’s essay is this: “You need to learn how to think about programming problems in a general way, independent of any one language. To be a real hacker, you need to get to the point where you can learn a new language in days by relating what’s in the manual to what you already know.” This is an interesting assertion; maybe it’s languages that are easy, and programming that’s a bit harder. Mastering the core programming concepts – the language paradigms, idioms, algorithms, data structures, and design patterns – is much more important than mastering the languages themselves.

    The most recent language I learned was OCaml. When I developed my first non-trivial program in OCaml, I found myself reaching for the library quite often. I didn’t think anything of it at the time, but I hadn’t studied OCaml’s library enough to even become familiar with what was in it. I’ve learned enough languages that I know what functions and classes I can expect to find in a standard library. In other words, I know when it’s appropriate to reach for a language’s library, and when it isn’t. The hard part about learning OCaml wasn’t how to make good use of the library, it was the concepts the language employed that I wasn’t familiar with – pattern matching and the Hindley-Milner type system. The same thing applied when I was learning ANTLR; since I was already familiar with similar tools, and had written a top-down recursive descent parser by hand, learning another LL parser generator wasn’t too difficult.

    Don’t misunderstand me, language is important, and mastering every detail can be valuable. I program much faster in Python than I do in OCaml, largely because I rarely have to use the reference manual in Python. But programmer productivity is not nearly as important as knowing how to write reliable, maintainable code, and I learned neither skill from studying Python’s library.

    Regardless, your main point about studying the skills you use was spot on, and very well-stated. The software industry is massive. There are many ways to apply programming knowledge, and my digressions may partially be a result of that – the specific niche that I cater to may be very different from what you do (for instance, I have never done much web development), and I enjoyed reading about your perspective.

    Offer a rejoinder↓
    • Jerrad, thanks for the comment and the pushback. You’re a far more seasoned and experienced developer than me, and your comments here have me thinking, which is good. I think you’re absolutely right that the real skill is knowing when to pull out a library reference and when to just plain do it the hard way, because the hard way is sometimes the best (and sometimes the only) way to get it done.

      I’ll have to take a look at Raymond’s essay, as it seems helpful and on point, as well.

      I think you’re absolutely right: being a good programmer has very little to memorizing library functions; speed and efficiency are not everything, and in fact may be very secondary concerns when put up against doing something right. Productivity isn’t and shouldn’t be our only concern. My point was more that seeing yourself as (much less selling yourself as) a really solid PHP developer when you don’t know the library at all, but can turn out tons of toy scripts – this kind of knowing the syntax but not the language – is dishonest to yourself and to your customers. It’s something I’m particularly sensitive to because I’m picking up freelancing and I’m trying very hard to be very honest about my strengths and my weaknesses with potential customers along the way. Really top-notch PHP developers know the libraries, tools, and frameworks. But, and this is where your point is essential, they also know when those are appropriate parts of the solution to a given problem, and when they aren’t.

      In that sense, then, there’s a hierarchy at play here: syntax → language → programming. You really can’t program without knowing some language. (A clarification is in order even there: you can certainly practice the logical and problem-solving aspects. I’m a tolerably decent developer not because of the depth of my software background but because my degree in physics taught me how to think and how to solve problems I didn’t even understand when I first looked at them.) And to become skilled in a single language requires getting a handle on more than the syntax. But being a good programmer – being a good engineer – requires mastery of much more fundamental skills, skills that have far more to do with thinking about problems than about the knowledge set.

      Thanks for commenting. :)

      Offer a rejoinder↓
  • Jerrad Genson thought to say:

    Chris, I appreciate your response, and thank you for fixing my links. Eric Raymond and Paul Graham’s programming essays have strongly contributed towards my growth as a software developer. I highly recommend them.

    I can understand and sympathize with your frustration; as an honest person, competing with dishonest people for development contracts (or jobs) is a sobering experience. When I was a hiring manager for my company, I interviewed all kinds of experts who couldn’t pass a basic programming exam, in any language. More often than not, their code wouldn’t even compile. I imagine the problem is worse with contract jobs. Knowing the tools you work with is very important – I don’t mean to imply that it’s not. There is something to be said for the rare programmer who has truly mastered the language he’s coding in. Incidentally, I know the syntax of many languages, but I only list languages on my resume that I know really well. For example, I used PHP in a CS class when I was an undergrad, but I don’t feel that I’m proficient enough with PHP to say that I know it. For the languages I do list, I indicate my level of proficiency, and briefly describe the projects I’ve worked on with them.

    You summarized my point well with your hierarchy. That is the spirit of what I was getting at. I think programming is a lot like playing the piano; a lot of people can do it, but not many do it well. And on a final note: I’ve learned that there is very little correlation between skilled programmers and degreed programmers. One of the highest scores on my programming exam was achieved by someone who didn’t have a CS degree. So if that bothers you, it really shouldn’t.

    Offer a rejoinder↓
    • I read one while on a break (and a few other articles linked from it and related to it), and will read the other this afternoon. Very good stuff.

      Because of the enormous amount of work out there for web developers, there is an equally large number of people trying to get work in that area. Some of them are like me – hard working and dedicated to learning their craft well. Others are basically con artists, who know little more than the letters they put on their resumé. When you have lots of experience, that distinguishes you from the masses, but when you don’t, well… my standing assumption at this point is that my honesty about my comparative newness will pay off, especially when combined with the effort to actually keep getting better. The trick, though, is getting those jobs in the first place. I’ve done a fair bit of personal, free, and low-cost work over the last year to just be in a position where I honestly feel like I can put Javascript and PHP on my resumé… but then I immediately need to clarify my skill level. It’s a catch 22, unfortunately, although one that the next 6 months should help eliminate, as I now have contract work that is improving my skill and knowledge dramatically.

      It doesn’t bother me being an outsider. It does mean I have had to work harder to get up to speed since getting out of college, but I actually am very glad that I have a physics degree and not a CS/CE degree. The training in thinking I got there is invaluable, and I’m certainly not pigeonholed into any particular role. Costs and benefits. In my case, I wouldn’t trade that physics degree for anything. (But I do learn an awful lot from my degreed colleagues!)

      Offer a rejoinder↓
  • Jerrad Genson thought to say:

    I really meant something more along the lines of “don’t let it discourage you from pursuing a career in software”. Of course, there is no reason a physics degree should bother you. In fact, having knowledge of other industries may help you apply your software skills, and many techniques in computer science were inspired by solutions to problems in non-CS fields. My degree wasn’t solely in computer science, and I’m glad it wasn’t. Diversity is definitely a good thing here.

    If you enjoyed Raymond’s essays, you may want to take a look at these as well: http://www.paulgraham.com/articles.html

    Offer a rejoinder↓

Your rejoinder to Jerrad Genson

Opt for silence instead↑

Anonymity is most unhelpful. Please identify yourself!

You may use GitHub-flavored Markdown and/or these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>