I know you have the best of intentions. We all do. We’re software developers; we love writing code. It’s what we do. We never met a problem we couldn’t solve with some duct tape, a jury-rigged coat hanger, and a pinch of code. But Wil Shipley argues that we should rein in our natural tendencies to write lots of code:
The fundamental nature of coding is that our task, as programmers, is to recognize that every decision we make is a trade-off. To be a master programmer is to understand the nature of these trade-offs, and be conscious of them in everything we write.
In coding, you have many dimensions in which you can rate code:
• Brevity of code
• Speed of execution
• Time spent coding
Now, remember, these dimensions are all in opposition to one another. You can spend three days writing a routine which is really beautiful and fast, so you’ve gotten two of your dimensions up, but you’ve spent three days, so the “time spent coding” dimension is way down.
So, when is this worth it? How do we make these decisions? The answer turns out to be very sane, very simple, and also the one nobody, ever, listens to: Start with brevity. Increase the other dimensions as required by testing.
I couldn’t agree more.
I’ve given similar advice when I exhorted developers to Code Smaller. And I’m not talking about a reductio ad absurdum contest where we use up all the clever tricks in our books to make the code fit into less physical space. I’m talking about practical, sensible strategies to reduce the volume of code an individual programmer has to read to understand how a program works. Here’s a trivial little example of what I’m talking about:
if (s == String.Empty)
if (s == “”)
It seems obvious to me that the latter case is better because it’s just plain smaller. And yet I’m virtually guaranteed to encounter developers who will fight me, almost literally to the death, because they’re absolutely convinced that the verbosity of String.Empty is somehow friendlier to the compiler. As if I care about that. As if anyone cared about that!
It’s painful for most software developers to acknowledge this, because they love code so much, but the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it. If you can’t get away with no code, the next best thing is to start with brevity.
If you love writing code– really, truly love to write code– you’ll love it enough to write as little of it as possible.
Posted by Jeff Atwood
The “everyone should learn to code” movement isn’t just wrong because it falsely equates coding with essential life skills like reading, writing, and math. I wish. It is wrong in so many other ways.
• It assumes that more code in the world is an inherently desirable thing. In my thirty year career as a programmer, I have found this … not to be the case. Should you learn to write code? No, I can’t get behind that. You should be learning to write as little code as possible. Ideally none.
• It assumes that coding is the goal. Software developers tend to be software addicts who think their job is to write code. But it’s not. Their job is to solve problems. Don’t celebrate the creation of code, celebrate the creation of solutions. We have way too many coders addicted to doing just one more line of code already.
• It puts the method before the problem. Before you go rushing out to learn to code, figure out what your problem actually is. Do you even have a problem? Can you explain it to others in a way they can understand? Have you researched the problem, and its possible solutions, deeply? Does coding solve that problem? Are you sure?
• It assumes that adding naive, novice, not-even-sure-they-like-this-whole-programming-thing coders to the workforce is a net positive for the world. I guess that’s true if you consider that one bad programmer can easily create two new jobs a year. And for that matter, most people who already call themselves programmers can’t even code, so please pardon my skepticism of the sentiment that “everyone can learn to code”.
• It implies that there’s a thin, easily permeable membrane between learning to program and getting paid to program professionally. Just look at these new programmers who got offered jobs at an average salary of $79k/year after attending a mere two and a half month bootcamp! Maybe you too can teach yourself Perl in 24 hours! While I love that programming is an egalitarian field where degrees and certifications are irrelevant in the face of experience, you still gotta put in your ten thousand hours like the rest of us.
I suppose I can support learning a tiny bit about programming just so you can recognize what code is, and when code might be an appropriate way to approach a problem you have. But I can also recognize plumbing problems when I see them without any particular training in the area. The general populace (and its political leadership) could probably benefit most of all from a basic understanding of how computers, and the Internet, work. Being able to get around on the Internet is becoming a basic life skill, and we should be worried about fixing that first and most of all, before we start jumping all the way into code.
Please don’t advocate learning to code just for the sake of learning how to code. Or worse, because of the fat paychecks. Instead, I humbly suggest that we spend our time learning how to …
• Research voraciously, and understand how the things around us work at a basic level.
• Communicate effectively with other human beings.
These are skills that extend far beyond mere coding and will help you in every aspect of your life.
Posted by Jeff Atwood
• Coding For Violent Psychopaths
• Pseudocode or Code?
• The Best Code is No Code At All
• When Understanding means Rewriting
HERE ARE 10 REASONS WHY YOU SHOULD CONSIDER LEARNING RAILS.
1: The Ruby language itself
The Ruby language is pretty impressive. It combines some of the best features of dynamic languages, while taking some of the best ideas from strongly typed, static languages and blending them with an object-oriented paradigm that is focused on “getting things done” and not “writing lots of code.” The Ruby language is an excellent language, and you may very well find it makes you quite productive.
2: Code-based data model
In Ruby on Rails, you define your data model with code. In fact, once the initial data model is made, any changes to it are made through scripts that manipulate the model. While this may feel a little unusual, it means that it is trivial to replicate a Rails project on another server or even target it against another database.
3: Open source
Rails (and Ruby) are not just “open source,” they have a thriving, helpful community around them. Although the magic of open source is often overstated, the reality of Ruby and Rails is close to the ideal, which is great for new developers.
4: Well documented
You may not see a row of Ruby or Rails books at your local bookstore, but Ruby and Rails are both well documented. I’ve been very impressed by the amount of video tutorials available on the Web, both for free and for pay. Not only are there lots of these tutorials, but they are often of high quality, fun to follow, and much more effective than most books.
5: Good jobs
Rails may not have a pile of open positions, but the Rails jobs I have seen advertised all look attractive. I’ve talked to a number of recruiters and people running Rails shops, and the general attitude is that the superior efficiency allows them to pay a bit more and still save money. Also, the lack of experts means that they often employ people who work from home or otherwise get benefits that a .NET or Java developer would be hard pressed to get.
6: Rapid development model
The Rails development model depends upon convention, not configuration. This means that if you learn to do things the way Rails expects you to do them, it will do a lot of the heavy lifting for you. This applies to a wide variety of development tasks, and as long as you keep yourself from trying to micromanage Rails, you can work very quickly in it.
Rails makes no presumptions about how to turn your logic into output. Instead, you get 100% control over the presentation layer of your code. This makes tying your application’s logic to AJAX’ed front ends mighty easy. It also allows you to work closely with design experts, to produce nice looking sites that are difficult to do in less-flexible systems.
8: Vendor support
Is Rails available on every host out there? Not at all. But most hosts do offer it now. Even better, a number of them now specialize in Rails hosting and can provide a high level of service and support. In fact, Engine Yard employs a significant number of developers who are core members of the Rails and Ruby teams, giving them a massive amount of in-house knowledge of the product. As a result of specialization, you can get great help from these vendors, in stark contrast to the experience that most vendors typically provide.
9: Tool options
The relative simplicity of the Rails system means that there are already a number of good IDEs for Rails development. In addition to IDEs, the Rails ecosystem is filled with excellent tools that fill just about any need you may have, and most of them are free and/or open source. If you want to work in an ecosystem with topflight tools support, Rails is a good place to be.
10: Better fit
There is something distinct about the Rails philosophy (and toolset) in comparison to the Java or .NET environments. If you are the type of person who “thinks in code” and likes to work with scripts to get things done, Rails may be a great fit for you. While the focus on command-line tools may feel like a quaint anachronism, this mode of working simply suits some people better. There is a good possibility that you will find yourself very comfortable working in the Rails style, and it is worth your time to check it out.
Compared to C/C++/Java – Python/Ruby allow you to write the same program with much, much fewer lines of code. It is estimated that a typical Python or Ruby program will require 5 times fewer lines of code than a corresponding Java code. Why spend that much more time on writing programs unless it is absolutely necessary? Also, someone said that a good programmer can reasonably maintain 20000 lines of code. It does not matter whether those are in assembly, C, or Python/Ruby/PHP/Lisp. So, if you write in Python/Ruby, whatever you do alone would probably need a 5-person team in Java/C/C++.
Compared to VB/PHP – Python/Ruby are much, much better designed languages than PHP/VB. PHP and VB are very popular for writing websites, and desktop applications respectively. The reason they’re popular is that they are very easy to learn and even non-programmers can pick them up quickly. But write any large program in these languages and you’ll start seeing the huge problems with these languages because they’re so badly designed. Friends don’t let friends program in PHP/VB.
Compared to Lisp/Scala/Haskell/Closure/Erlang – Python/Ruby are still quite “mainstream”. Sure these languages have some really cool features, and for advanced programmers, exposure to these languages can really improve the way they think about programming. But there will be time later in your career to decide whether you want to pick up one or more of these. But for now, Python/Ruby do a much better job of balancing the power of the language against commercial applicability.
Compared to Perl1 – Both Python & Ruby owe a lot to Perl, and Perl was the biggest and best dynamic language before they started gaining prominence. But now, Perl’s popularity is reducing and more and more people are adopting Ruby/Python. I find Perl’s object-orientedness a bit contrived and ugly. In general, I think Perl is a harder language to learn since it has so many different ways of doing things, and the syntax tends to be cryptic and non-intuitive until you get the hang of it. Overall, I feel that Perl is not the best language for a student to pick up, unless there is a very good reason to do so (i.e. if you have lots of regular expression processing, then Perl shines)
Which Programming Language To Focus On?
***You MUST learn basic HTML & CSS: It’s foundational!***
Don’t choose Java, C, C++, C#, or PHP: Too much time and knowledge required to accomplish seemingly small things.
Don’t choose Scheme, Logo, LISP, Ada: Their applications are too special-purpose for you to show your results to your girlfriend and have her be impressed.
Don’t choose VB.NET: Your hosting costs will be silly for toy projects. (plus I’m a language snob).
BEST – Learn Python with Django and Heroku: The combination of extremely well documented online tutorials, sensible language design, simple/free hosting is a slam-dunk. If you get serious, there’s lots of Python work out there (3,946 hits on a Dice.com job search for “Python”)
Runner up – Ruby with Sinatra and Heroku: There were only 2,238 hits on a Dice job search for “Ruby”, so maybe there’s less work out there if you decided to get serious. Otherwise, I kind of like this one myself.
Learn at least a half dozen programming languages. Include one language that supports class abstractions (like Java or C++), one that supports functional abstraction (like Lisp or ML), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), one that supports coroutines (like Icon or Scheme), and one that supports parallelism (like Sisal)