…meie igapäevast IT’d anna meile igapäev…

2014-02-19

Bright sayings of bright people: programming quotes

Filed under: Programmeerimine — Sander @ 13:56:40
Tags: ,

While the last post had my own sayings, this one has some of my favorite programming quotes from others. Even the first part of the title is from the late Frederik Pohl.

  1. "Don’t just echo the code with comments – make every comment count."
  2. "Make sure comments and code agree."
  3. "Don’t comment bad code – rewrite it."
    "The Elements of Programming Style" by Kernighan and Plauger, 1974
  • "It’s important to communicate what the code should be doing.” – Joe Kunk
  • “It’s hard enough to find an error in your code when you’re looking for it; it’s even harder when you’ve assumed your code is error-free.” – Steve McConnell
  • “If debugging is the process of removing software bugs, then programming must be the process of putting them in. ” – Edsger Dijkstra
  • “Walking on water and developing software from a specification are easy if both are frozen.” – Edward V. Berard
  • “First, solve the problem. Then, write the code.” – John Johnson
  • “Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.” – Stan Kelly-Bootle
  • “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” – unknown (attributed to John F. Woods, Rick Osborne, Martin Golding)
  • “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler
  • “Programs must be written for people to read, and only incidentally for machines to execute.” – Abelson/Sussman
  • “Computers are good at following instructions, but not at reading your mind. ” – Donald Knuth
  • “Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” – Rick Cook, The Wizardry Compiled
  • „Do unto the next developer as you would have them do unto you“ – Joe Kunk

2014-02-14

Quotes on programming

Filed under: Isiklikud,Programmeerimine — Sander @ 14:47:21
Tags: ,
  • There is nothing worse than a programmer who compiles the spec into the code, without asking “could the workflow be better?”, “could this be a bug in spec?” or even “does this make any sense whatsoever?”

  • Bad programmers tend to gravitate towards management. Too often they will become mediocre project managers, then bad department managers and finally horrible CTOs.

  • (on Robert Martin’s “Clean Code”) “Clean Code” doesn’t tell you how to write good code, nor maintainable code. Instead, it teaches you to write consultant code, or “cuckoo code”: you drop a nice shiny egg into the nest and fly away, leaving others to maintain the ugly monster that hatches.

  • Every programmer writes bad code sometimes. But when you have to ask "doesn’t he know better or is he trying to sabotage the project?", you’ve found a truly horrible coder.

  • If you are looking at your own code from two years ago and it looks fine, it doesn’t mean you were a good programmer two years ago. Quite the opposite, it means you haven’t grown as a programmer within these two years. You haven’t learned anything.

  • Code review is like a pair of pants. If you work at home, pants are optional. But if you are in public, you’d better make sure you have pants on, even if no one looks at you.

  • Too often the only reason teams use agile programming is to be able to say that they are using agile programming.

  • But what is there to love about the code? It is the same excitement that a poet gets from writing a poem, or a painter from painting. It is the act of creation, the “develop” part of the word “developer”. We write some lines of text, which abides to the certain rules, and suddenly ex nihilo! we have a website, a video player, a database engine or something else.

  • The point where I’m getting to is that you can be eager and write more code. Or you can be lazy and figure out a way to write less code. Being lazy is a good thing in a programmer. It forces us to find patterns and promotes code reuse. It makes us more effective. It makes us better.

  • A programmer should be smarter than his tools. Don’t expect the compiler to fix your bad code.

  • If the comment does not match the code, it is the comment that is correct and code that is wrong.

***

I’ll post these mostly so I would remember them and re-use when appropriate.

I think these quotes are mine, from various blog posts, presentations and discussions. If I have inadvertently picked up or rephrased someone else’s text, please let me know in the comments.

2012-05-04

The three L’s of programming

Filed under: Programmeerimine,Rant — Sander @ 18:20:28
Tags:

Html-source-codeRecently I’ve done quite a lot of interviews with candidates for a position of junior programmer, reviewing their test assignments and so forth. This has led me to wonder – what exactly am I looking for? How can I tell the difference between someone who will be a good programmer, and someone to whom programming will be just a nine-to-five job. Or, more precisely, what makes someone a good programmer?

I’d like to think I am a good programmer myself – or at least strive to be one. Sure, I will never be a coding guru who has all of Knuth memorized and can solve the travelling salesman problem with 23 cities using seven different algorithms without a computer. But I’m good enough for my daily chores.

This post tries to formulate some of the ideas I’ve had. I won’t pretend this to be an absolute, universal and final truth, these are just my thoughts on the subject.

Love

You have to love the code.

There is no other way to put it. You have to be passionate about what you do. The happiness when you pull off something above and beyond what the framework authors intended. Or the deep satisfaction from just finishing a really good piece of code. Or even the frustration of hunting an ever-illusive bug – and the joy upon fixing it.

If you have that passion, then you’re half-way there already. Everything else will come – knowledge, experience, “code-sight” – but if you lack that love, then you’ll never be a good programmer in my book. There is simply no replacement for it.

Largely, this is the reason why the famed Indian programming sweatshops (which were such a rage four or five years ago) are now mostly out of the picture. You had a circle of twenty university graduates and a supervisor walking around behind them, making sure everybody are coding as fast as they can. No slacking!

But the result of such work was simply not worth the price of $500..1000 per developer/month. As far as I know, a lot of the major players have now stopped outsourcing the work to such places (which are not necessarily in India, you can find programming sweatshops in quite a few places around the world). It is just cheaper to pay local, higher-paid programmers to do the same work in half of the time and a tenth of the bugs.

If you lack that love of code, then you still may write a decent code. But it will never be a brilliant code, it will just be a code that sort of works. You’ll lack the spark, the similar spark that makes Shakespeare different from a copywriter.

But what is there to love about the code?

It is the same excitement that a poet gets from writing a poem, or a painter from painting. It is the act of creation, the “develop” part of the word “developer”. We write some lines of text, which abides to the certain rules, and suddenly ex nihilo! we have a website, a video player, a database engine or something else.

Learning

If you are looking at your own code from two years ago and it looks fine, it doesn’t mean you were a good programmer two years ago. Quite the opposite, it means you haven’t grown as a programmer within these two years. You haven’t learned anything.

Programming is all about learning. New languages, new frameworks, new ways to do things, new tricks. Like Lewis Carrol’s Red Queen put it, “It takes all the running you can do, to keep in the same place.”

If you want to become a programmer, you will not be able to stop learning the day you left the university. In fact, you’ll realize that a lot of what your Alma Mater taught you is, frankly put, useless.

My own way to become a programmer was… convoluted, to say the least. Some day I will write a post about it – but suffice it to say that I don’t have a formal education in programming. I am completely self-taught. And, in a way, that is a good thing. Constantly learning something new is normal for me, whereas people just out of university often go “but I was taught to do it this way?!”

And so far, every time I’ve looked back at myself from two years ago, I’ve been able to go “boy, was I stupid back then. I am glad I am so much better now.” I hope this never ends.

Lazy

A programmer I used to know needed to generate some HTML. Cleverly, he used helper methods to do that. He needed H1, so he created a method similar to:

  1. public static string GetH1(string content)
  2. {
  3.     return string.Format(“<h1>{0}</h1>”, content);
  4. }

He also needed a H2. So:

  1. public static string GetH2(string content)
  2. {
  3.     return string.Format(“<h2>{0}</h2>”, content);
  4. }

And then he needed H2 with an ID. Lo and behold:

  1. public static string GetH2(string content, string id)
  2. {
  3.     return string.Format(“<h2 id='{0}’>{1}</h2>”, id, content);
  4. }

And then he also needed H2 with a class. I’ll spare you from the code now, but you can guess what he did.

But this was just for H1 and H2 tags. He needed various other tags as well – img, div, p and so forth. And yes, you guessed right. He had overloaded methods for each and every one of them. The helper class ended up with about 30 methods in a several hundred lines of code.

Me, I’m a lazy bastard. I would have written:

  1. public static string RenderTag(string tag, object attributes = null, string content = null)
  2. {
  3.     tag = tag.ToLowerInvariant();
  4.     var html = new StringBuilder();
  5.     html.AppendFormat(“<{0}, tag);
  6.     if (attributes != null)
  7.         foreach (var prop in attributes.GetType().GetProperties(BindingFlags.Instance | BindingFlags.Public))
  8.             html.AppendFormat(” {0}=\”{1}\“”, prop.Name, prop.GetValue(attributes, null));
  9.     html.Append(content == null ? “/>” : string.Format(“>{0}</{1}>”, content, tag));
  10.     return html.ToString();
  11. }

Less than dozen of lines of code without empty lines and braces. And that’s it for every tag you can imagine. Call it any way you like – RenderTag(“br”); RenderTag(“h1”, null, “header”);, RenderTag(“h2”, new { id=”myId”, @class=”myClass” }, “subheader”); – it just works. You can even render tags inside tags with that method.

Sure, I wouldn’t use that method to render a full website, but for a few dozen lines of HTML that was needed, it would have been perfect. Far faster to write than hundreds of lines of repetitive code.

The point where I’m getting to is that you can be eager and write more code. Or you can be lazy and figure out a way to write less code. Being lazy is a good thing in a programmer. It forces us to find patterns and promotes code reuse. It makes us more effective. It makes us better.

Or, to use the words of Terry Pratchett, “Having to haul around extra poundage was far too much effort, so he saw to it that he never put it on and he kept himself in trim because doing things with decent muscles was far less effort than trying to achieve things with bags of flab.”

—-

tl;dr: just read the damn thing.

Create a free website or blog at WordPress.com.