Programming Things I Wish I Knew Earlier

theodp writes "Raw intellect ain't always all it's cracked up to be, advises Ted Dziuba in his introduction to Programming Things I Wish I Knew Earlier, so don't be too stubborn to learn the things that can save you from the headaches of over-engineering. Here's some sample how-to-avoid-over-complicating-things advice: 'If Linux can do it, you shouldn't. Don't use Hadoop MapReduce until you have a solid reason why xargs won't solve your problem. Don't implement your own lockservice when Linux's advisory file locking works just fine. Don't do image processing work with PIL unless you have proven that command-line ImageMagick won't do the job. Modern Linux distributions are capable of a lot, and most hard problems are already solved for you. You just need to know where to look.' Any cautionary tips you'd like to share from your own experience?"

Comments

Comment your code

[Nkwe]

Put enough comments in your code so that five years from now you (and others) can remember what you indented the code to do. Remember that comments are not for describing what the code technically does (that is what the code is for), comments are for what the code is intended to do. Try and comment the decisions you made when developing the code, specifically why you took the approach you did and why you didn't use other options.

Re:Comment your code

[Anonymous Coward]

Put enough comments in your code so that five years from now you (and others) can remember what you indented the code to do

I indented the code to make it readable. That's so obvious I don't need a comment to remind me.

Re:Comment your code

[Anonymous Coward]

"indented the code to do"

So the real question is tabs or spaces?

Re:Comment your code

[Anonymous Coward]

> Remember that comments are not for describing what the code technically does (that is what the code is for), comments are for what the code is intended to do.

Corollary: Never debug comments, only code.

Re:Comment your code

[kantos]

Commenting is not enough... you need to make sure you clean up the comments in a file before resubmitting it... dead comments can be more dangerous than dead code... as dead code at least doesn't run... dead comments mislead the person following later into believing a lie a lie that could potentially have major impacts on the software. Lastly... write meaningful test cases... if your tests only prove the happy path, that's OK... but if they prove that the happy path is the only path.. that is better.

Re:Comment your code

[Anonymous Coward]

Commenting code isn't enough, it's just a small part of the design and documentation process. Comments are there to tie the code to the relevant part in your design document, which really is a part of programming people should put more effort into.

Re:Comment your code

[Xtifr]

Put enough comments in your code so that five years from now you (and others) can remember what you indented [sic] the code to do.

But not so many that you (or others) will find it more work than it's worth to change the comments when the code changes.

I prefer code with no comments to code with actively misleading comments, and I hate code with no comments! :)

Re:Comment your code

[negativewashout]

This is the best, IMHO. I, too, have looked code and gone, "WTF was this idiot thinking???? ...Oh wait... that's my code."

And agreed - dead comments have to be updated. I didn't always do it perfectly, but I pretty much got in the habit a few years ago of commenting as I go, right by the code in question. One of those times when it's good to be a bit verbose.

Re:Comment your code

[Manip]

I could never find the correct degree of commenting. Didn't help that in school they made us comment in an idiotically verbose way to the point of "this is a for loop to find needle in haystack" and we lost marks if we failed to. My reaction to that level of stupidity was to lose interest in comments entirely which obviously later bit me in the butt.

I really need to find some kind of "idiots guide to when to comment and when NOT to comment."

Re:Comment your code

[TheLink]

> As for the indents that people are talking about, tabs are more reasonable now than they used to be, but you're giving up screen space for them

Why would you be giving up screen space with tabs? On most text editors for programming people can adjust the tabs to display as whatever indentation they want. So if someone wants to view tabs as 2 spaces and another prefers 4 and another prefers 8, they don't have to change anything in the code if their editors are already set up for that.

The disadvantage of tabs is where you have some stuff that requires you to use spaces in (text string etc) and for some reason you want certain parts of it to align with your indents. Or you are mixing your indentation - spaces and tabs (try not to do that OK? ).

Re:Comment your code

[DMiax]

Put enough comments in your code so that five years from now you (and others) can remember what you indented the code to do.

I know, Python right?

Re:Comment your code

[russotto]

Commenting code isn't enough, it's just a small part of the design and documentation process. Comments are there to tie the code to the relevant part in your design document, which really is a part of programming people should put more effort into.

It's been said for years, but it is almost never done. When it is done, it's most often (IME) done _after the fact_ because of some requirement to produce the paperwork. Perhaps it's time to give up on it. Is there a real reason for insisting on a design document, or is it just some sort of self-flagellation on the part of programmers?

Re:Comment your code

[sourcerror]

Think of comments as an API documentation*. If something complicated is going on, I usually include several usage example as well. Just look at the documantation 3rd party libraries, and try to follow that granularity and style.

Re:Comment your code

[Richard Steiner]

Sure, assuming that everyone who ever uses that code is using the same code repository.

I've had to modify code professionally that was written over 30 years before I encountered it (older Fortran 66 stuff), and the comments in the code were invaluable to me. The folks who wrote it had no idea that their code would be running at another company when it was written.

Re:Comment your code

[Korin43]

I don't know. I prefer to comment, just in case:

while 1:
        # Indentation
        dosomething()

Re:Comment your code

[aLEczapKA]

If you need to comment your code you did something wrong and you should refactor it.

Inventor of C++ when asked 'How do you debug your code?', said: 'I don't, if I have to debug the code to understand it, it means the code is wrong and I rewrite it'.

Great book on the subject Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin.

Re:Comment your code

[TeknoHog]

Put enough comments in your code so that five years from now you (and others) can remember what you indented the code to do

I indented the code to make it readable. That's so obvious I don't need a comment to remind me.

(pun indented)

Re:Comment your code

[nacturation]

dead comments mislead the person following later into believing a lie a lie that could potentially have major impacts on the software.

// the following code delivers cake to the subject

Re:Comment your code

[ZorroXXX]

If the comments are out of date, then the code has been modified by someone who was too lazy to update the comments.

When code and comments disagree, both are probably wrong. -- Norm Schryer

Re:Comment your code

[SL Baur]

Put enough comments in your code so that five years from now you (and others) can remember what you indented the code to do.

/* This is hairy. We need to compute where the XEmacs binary was invoked
          from because temacs initialization requires it to find the lisp
          directories. The code that recomputes the path is guarded by the
          restarted flag. There are three possible paths I've found so far
          through this:

          temacs -- When running temacs for basic build stuff, the first main_1
            will be the only one invoked. It must compute the path else there
            will be a very ugly bomb in startup.el (can't find obvious location
            for doc-directory data-directory, etc.).

          temacs w/ run-temacs on the command line -- This is run to bytecompile
            all the out of date dumped lisp. It will execute both of the main_1
            calls and the second one must not touch the first computation because
            argc/argv are hosed the second time through.

          xemacs -- Only the second main_1 is executed. The invocation path must
            computed but this only matters when running in place or when running
            as a login shell.

          As a bonus for straightening this out, XEmacs can now be run in place
          as a login shell. This never used to work.

          As another bonus, we can now guarantee that
          (concat invocation-directory invocation-name) contains the filename
          of the XEmacs binary we are running. This can now be used in a
          definite test for out of date dumped files. -slb */

OK. So now everyone knows how Lisp programs written with a core in C initialize themselves, right?

And as much as people may joke about it, XEmacs was tested to ensure that it worked as a login shell prior to release.

Re:Comment your code

[Anonymous Coward]

// the following code delivers cake to the subject

// the preceding comment is a lie!

// the above comment explains the joke

Re:Comment your code

[gringer]

// the following code delivers cake to the subject

// the above comment explains the joke

== changelog ==
* removed redundant comments

Re:Comment your code

[Thangodin]

If you are new to coding, don't be a bedroom programmer. You are no longer writing a 10,000 line app alone in your bedroom. You may be working on a million line app with a team. Change your habits accordingly. Learn to work with other people.

Programming is one of those things that humans are not quite smart enough to do. This means you. Check your ego at the door. In the early 90's, IBM estimated that 80% of large projects in the industry (one million lines or more) were "abandoned in disgust". This should give you some idea of what you are up against.

Come to work knowing what you are doing. This may mean cramming in your off hours. Don't say that you don't know how to do something. Say that you do and then learn it!

Put in comments where they are needed, and maintain them. You will forget what you were doing within three months. The harder it was to code, the more you need the comments.

Use descriptive variable names. Try to organize your data into conceptually simple variables where possible.

If you have to complicate a mathematical formula by breaking it into sections appropriate for inner and outer loops, put the formula in the comments. It may even be worth putting in an ASCII diagram if you are working with geometry.

If you can't see the bug, it's because you have become blind to the code. Get someone else to take a look. The mistake may be embarrassingly obvious to a new set of eyes.

If speed is a factor, preprocess the data. Offload runtime cycles to preprocessing.

Maintain an up to date user manual for all tools and apps. Add to it as you add features, update it as you update the features.

Avoid magic numbers where possible, and put any magic numbers you do use into defines, again with descriptive names.

If you can, avoid virtual methods and pointers in streamed objects. This way you can bulk load them and bulk write them. Indices often fast enough, or can be converted to pointers if need be after loading.

If you have lots of booleans, consider a bit array.

Try to write reusable code. Code for the general case when possible, but...

Normalize your data and objects. Don't waste memory and time maintaining variables you don't need. Don't repeat yourself.

Your key indexes should be integers, never strings. Yes, I have seen databases keyed on memo fields--they were tragically slow.

If updating an existing project, get the client to sign off on what is not to be changed or fixed, and make certain that the QA department gets this list. Otherwise bugs will creep onto the list that you are not actually required to fix, expanding the scope of the project.

Build test harnesses whenever you can which can be turned on with a simple switch. This will make regression testing a lot easier.

Re:Comment your code

[rhyder128k]

The road to hell is paved with good indentions.

Re:Comment your code

[gringer]

My current annoyance with python:

1. Copy code from one section
2. Paste code to another section
3. Different indentation changes code function
4. ...
5. Bash head on keyboard

Re:Comment your code

[Just Some Guy]

In other words you document the intent of every paragraph of code, and a high level explanation of how it does it.

No offense, but I despise that style of commenting. I can tell what your code is doing by reading the code. What I don't know is why you're doing it that way. Why are you looking for needles? Have you proven needles are the only thing in your haystack made out of iron so that the code won't detect nails, screws, and hatchets six months from now? Is there a reason your haystack is a list and not a binary tree? These are the things I need to know to maintain your code. I don't need to be told how a loop works.

Re:Comment your code

[Greyfox]

/* Don't touch this function unless you REALLY know what you're doing */ Funnily enough the only guy who ever touched it didn't know what he was doing. In the short time he worked there, he did enough damage to the code base that it took 6 months to fix it. Too bad the version control system we were using at the time didn't allow you to simply mass-revert a user. That would have actually saved us a lot of time.

Re:Comment your code

[Coryoth]

But not so many that you (or others) will find it more work than it's worth to change the comments when the code changes.

I prefer code with no comments to code with actively misleading comments, and I hate code with no comments! :)

The trick is that if you are writing comments describing what the code is intended to do, you can write those comments in something like JML or Frama-C's ACSL. That was you can use ESC/Java2 and Junit, or Frama-C, to do your checking that the code does what you intended. You get two benefits: more rigorous checks on your code (including use of theorem provers from ESC/Java and Frama-C); if your documentation ever falls out of date with the code, you'll immediately get errors flagged.

Re:Comment your code

[AuMatar]

Yes, because what's clear to you is going to be clear to everyone else who ever reads it. And it'll be perfectly clear to you in 6 months or 6 years when you try to alter it. Yup.

There is no such thing as self documenting code. If you ignore comments and/or documentation, you're a shit poor programmer and a blight on the profession.

Re:Comment your code

[Hooya]

I have tried implementing a 'design document' process for the better part of 10 years that I've been with this group. It's never gotten done. We came close about a year ago. Here's why it's I still try (while knowing that it'll never get done):

There's a reason architects use blueprints.

Re:Comment your code

[russotto]

There's a reason architects use blueprints.

Which is? If it's along the lines of "It's easier and cheaper to fix a blueprint than a building", then it does not apply to software.

Re:Comment your code

[WolfWithoutAClause]

No, the comments above would explain that we're trying to do, e.g. find a needle to sew with, and the comments around the data structure definition would explain that we use a hashtable to speed up searching for ... The point *isn't* simply to do

// add 4 to y
x = y + 4;

it's more like

// we need to calculate the x coordinate, it's equal to y to be on diagonal, but add 4 due to border width
x = y+4;

So you explain *what* you're doing in HIGH LEVEL terms, and set CONTEXT. And you don't comment each line, you comment each group of lines that do one thing.

And I also disagree with your 'despise' thing. It's very, very rare that code is over commented, and in most cases failing to correct comments helps create bugs, because it shows you weren't able to understand the code well enough to explain it to others, chances are there's a bug there goes way up. I also find that after I've written code, then's a good time to read it over and comment it. I find lots of bugs that way, and the code ends up much better. Not doing that wastes time in the long run because you'll find the bugs the hard way.

Re:Comment your code

[Lotana]

Solution: Stop mindlessly copying and pasting.

I lost track of the amount of code I've seen that is a straight duplicate from some area that does vaguely the same thing. Then all the variable names don't match the new context, comments are not applicable and assumptions are not necessarily correct. Doesn't matter what language it is written in.

Of course the person that does it never bothered to look through it and only relied on compiler error messages to detect the obvious "not declared" errors. What ends up is a mess that is nearly guaranteed to have bugs.

If tabbing the new pasted code into place forces you to actually read it and think about what you just did: then it is well worth it!

Re:Comment your code

[DavidTC]

That's what the GP meant. Comment why, not how.

You only need how when you do something that people might miss, such as a switch fall-through, or not understand, like some tricky Boolean operation.

Everything else should be about what the code is attempting to do, and why it's trying to do it that way. When that's obvious, you don't need any comments at all. (Although function headings are still a good idea.)

Re:Comment your code

[IICV]

Is there a reason your haystack is a list and not a binary tree?

Clearly, this is why you need comments! Haystacks aren't lists - they're heaps.

Re:Comment your code

[MadKeithV]

There's a reason architects use blueprints.

Which is? If it's along the lines of "It's easier and cheaper to fix a blueprint than a building", then it does not apply to software.

Yes it does.
Consider all the useless implementation work you've done while your design was wrong (before you reworked it). It's just as important in software as in building.
Also, having blueprints / a design allows you to separate the work between many different teams with clear, agreed-on-beforehand interfaces between the sections that each team is working on. This is something that a lot of developers seem to miss (I know I did for the longest time) - perhaps because a lot of us tend to prefer working and thinking alone?

By the way, working out a design is not a solo 1-hour effort. It's just as much "development" as actually writing the code. Often you may actually want to write code while doing it just to make sure that what you are thinking of does work. But that's not the final software, it's still just the design. Don't give in to the temptation to "improve" that design prototype until it ships as finished software though...

Re:Comment your code

[erixm]

Come to work knowing what you are doing. This may mean cramming in your off hours. Don't say that you don't know how to do something. Say that you do and then learn it!

Please ignore that. Honesty is always better - and if your team doesn't welcome honesty, try to change the team's attitude. If you trust each other your results will be better. If you don't know how to do something, say you don't and THEN learn it.

Re:Comment your code

[EsbenMoseHansen]

Actually, what will have happened in 5 years is that the code will have changed, but the original comment remains, so that the code now does something slightly different. And it will be hours of debugging fun to find out which is right, if any.

Re:Comment your code

[BrokenHalo]

Took me a bit of headscratching before I realised what was going on. Ouch.

That's one reason why I have a tendency to be suspicious of editors that offer a WYSIWYG interface. I much prefer YAFIYGI (You Asked For It, You Got it) editors like (of course) TECO or more recently, EMACS or (if you insist) VI.

Re:Comment your code

[kbielefe]

That's because people who don't know what they are doing don't know that they don't know what they're doing. Those types of comments should be accompanied by a clear competence or acceptance test. For example, the last such comment I wrote went something like: /* This might look like an unnecessary delay, but the timing has been carefully calibrated against a wide range of marginal real world conditions. If you touch this function, you must ensure it does not time out under these configurations... */

In other words, "knowing what you're doing" must be definable and transferable knowledge.

Re:Comment your code

[Greyfox]

That's true. The function in question was actually quite well commented, and that last one was really more of a warning that all the comments should be read before messing with it. A set of unit tests would actually have been pretty nice and would have saved us a lot of trouble over the 5 years we worked on it, but it would have been a tough sell to management.

Re:Comment your code

[jgrahn]

Commenting code isn't enough, it's just a small part of the design and documentation process. Comments are there to tie the code to the relevant part in your design document, which really is a part of programming people should put more effort into.

It's been said for years, but it is almost never done. When it is done, it's most often (IME) done _after the fact_ because of some requirement to produce the paperwork. Perhaps it's time to give up on it. Is there a real reason for insisting on a design document, or is it just some sort of self-flagellation on the part of programmers?

It might be flagellation, but not self-flagellation. Programmers hate writing useless documents. Management wants those documents *before* the code is written, but the programmer knows he'll rework the design because of stuff he learns while doing the coding. Management also wants the documents in some word processor format not compatible with the version control software, so it cannot be updated along with the code either.

If I could have it my way, I'd have these things:

• User reference documentation, like man pages. File and protocol format specifications. Standards. Those can be very helpful for the programmer too. They cover the requirements aspect of things.
• Good checkin comments from the version control system, i.e. "I did this because of that".
• A *brief* text about the general design and architectural decisions, glossary etc. Things like "this program revolves around a single select() loop" or "we try to make this part bloody fast because ..." or "we use this trick throughout the code to avoid table lookups". Maybe a not-too-detailed class diagram, with a note that it might be obsolete and if you want a recent one you're free to draw one.
• A clear design with clear naming and strong typing, and/or readable unit tests.
• Comments on the class or module level: "class Foo represents this thing, with these limitations". On the function level too, but only if it's needed.

Re:Comment your code

[Coryoth]

I really think that means that you need to become better acquainted with those tools. specifying what you intend to happen is a lot easier than specifying how to do it. The first is a specification, the second is an implementation. Consider, I can specify a sqrt function by simply saying the result squared should be within some error tolerance of the input; that is a long way from writing an implementation of a square root function. Likewise, I can specify a sort function (the output list should contain exactly the same elements as the input list, and they should now be in order with respect to a comparison operator) without ever doing anything as complicated as actually implementing quicksort, or mergesort, or heapsort or ... Try looking at the tools and what they can do and you'll satrt to get the idea.

The hard way is more fun

[msobkow]

The truth is that the "hard" way of doing things is often more fun, because you have the challenge of learning a new tool or API. Plus sometimes it's actually easier in the long run because you've engineered a solution for the outer bounds conditions of scalability, so if your application takes off, it can handle the load.

I guess the real issue is that you have to engineer a "good enough" solution rather than a "worst case" solution.

Re:The hard way is more fun

[hedwards]

Eh, isn't that the basic difference between a programmer and an engineer? When I took my programming courses, there was a distinct focus on writing code with the smallest amount of new code possible, using preexisting libraries whenever possible and if there was any suspicion that the code might be useful later to split it off into a subroutine or method of some sort as done in the particular language. Sure it's a good idea to be able to write your own libraries and solutions, but it's a waste of time once you get to the point where you know how to do it. And generally using a library that's shared by other projects is much less likely that you're going to stumble on an undiscovered bugs with your program.

Re:The hard way is more fun

[jellomizer]

Well if you are coding professionally. You are wasting time going the hard route unless there is a real good reason to do such. Newbees want to show off that they can do all these things. Mature programmers know they can but if there is an easier way then go for it as it gets your project done faster and you look better to your boss who can give a rats ass on how you did it. Just as long as there isn't any consequences in the future.

Re:The hard way is more fun

[msobkow]

Actually I volunteer for the projects that are going to expose me to something new, rather than only taking on projects where I already know how the solution will work. The latter are bread-n-butter to the company, the former are the future of the company.

For example, I've spent the past year on a Freeswitch project rather than on the older Asterisk based code. Freeswitch scales better, is better architected, and is more flexible. The downside was spending 3-6 months working with the Freeswitch team to resolve issues with the code.

In the end, Freeswitch is where we are going; Asterisk is where we were. At the time that the Asterisk code was started, Freeswitch hadn't even reached it's first release, so Freeswitch wasn't an option back then.

Next up is a rework of the database IO codebase so that it becomes feasible to plug-n-play different databases. We could do it with the existing code base, but it would be very painful, kludgy, and difficult to maintain. Instead we're going to make a clean break on our next release to a new architecture for the database code. Sure it'll take longer at first -- but by the time we're on to our third database we should be well ahead of the curve and saving time.

Re:The hard way is more fun

[Firehed]

Hardware can certainly be the correct answer to the problem. Are you disk-bound? Then you need faster disks. Can't fix that in software. Saturating your pipe? You need more bandwidth.

Yes, you can do things to try and cut back on your use of those resources, but that's ultimately going to produce much less effective results unless you're at massive scale (read: you have your own datacenter) where a 1% performance gain frees up the equivalent of several hundred servers.

Hardware is also a good way to buy yourself a bit more time while you're working on fixing the real bottleneck, such as reworking an expensive database query. Sometimes you just need a couple extra weeks.

Don't read this post as advice to write bad software and only focus on vertical scaling, as that's not what I'm saying at all. But solutions that take you from 1-10k users are very different than going from 10k-1m users, and different still from 1m-10m. Trying to code for 10m when you don't have any users a) is a waste of time, b) is expensive (they rely on the assumption that you have lots of hardware anyways), c) won't work at all, and d) won't help you get users. Don't do dumb things, but users don't give a damn how well your software can scale if it sucks, and if they think it sucks you'll never find out how well it scales.

Re:The hard way is more fun

[danieltdp]

One build bridges and the other one codes. Oh, wait!

Re:The hard way is more fun

[Joe Tie.]

At some point at least, centos didn't. Or possibly it shipped with it, but in a useless state. I remember we used to get calls about it fairly frequently. That was a hell of a long time ago though.

Lesson #8

[pedantic bore]

Don't ask for advice about programming on slashdot unless you have a pile of salt grains ready.

Re:Lesson #8

[thoughtsatthemoment]

That applies to other sites as well. So many people are trying to preach than genuinely teach. The internet is great for seeking specifics, but for insight on programming, it has to come from within yourself.

Re:Lesson #8

[danieltdp]

The reason are two fold:

1) The amount of morons *always* exceeds the amount of experienced and reasonable people

2) Usually, morons don't have a clue that they... well... are morons!

I for one can assure you that I'm NOT a moron :-)

Re:Lesson #8

[SL Baur]

There's no substitute for a few solid courses in theory and design.

You must be new here. When I started programming, there were only a handful of colleges that had computer programming departments.

You came along late enough that you might have had decent instructors.

And I walked to and from college both ways, uphill, in the snow, barefooted, my first programming class used paper tape, my second programming class used punch cards, yadda yadda yadda.

Now, get off my lawn!

3 things I've learned.

[Anonymous Coward]

Sometimes it's easier and faster to code from scratch than it is to use off-the shelf software - especially in the age of "frameworks".

In that train of thought, its often better to toss and rewrite (or write new programs) than it is to extend existing programs.

It's easier to implement a whole new framework than it is to convince your boss that writing anew is actually faster.

Re:3 things I've learned.

[Trepidity]

Sometimes it's easier and faster to code from scratch than it is to use off-the shelf software - especially in the age of "frameworks".

I like this take on it: redundancy is bad, but the primary way of avoiding redundancy, factoring things out into libraries or frameworks, introduces dependencies, which are also bad. Which is worse? Depends, but I think dependencies are worse in more cases than people believe. I personally like to depend on something only when it's a big enough chunk of code to be worth adding a dependency for, has a clean API, and has an active and interested maintainer.

Making use of a database

[sphealey]

A database is not a bitbucket. Re-building basic database functionality in an external app is not a good idea. Applications, frameworks, languages come and go; data remains forever [1]. Business logic is part of the database. If you find yourself adding more and more "application servers" to get performance than you have a fundamental problem with your architecture (and probably a fundamental misunderstanding of how databases work). While it is not impossible to learn and implement good data management/database development practices using Microsoft tools, such a result is seldom seen in the wild.

sPh

[1] Per Tom Kyte of Oracle, whose first database job at the Department of Agriculture involved working with datasets stretching back to 1790.

Re:Making use of a database

[WarwickRyan]

> Business logic is part of the database.

I used to think the same thing, but that was before I ever had to solve a no-trivial problem.

What do I think now? Basically that business logic belongs in a domain layer, but that shouldn't mean that the database is treated like a black box. You should make use of constraints within the database server to ensure a base level of data consistancy. Default values (especially on auditing columns), correct datatypes, relationships, versioning and not-null constraints all belong within the database. Basically anything which can be supported without resorting to triggers or stored procedures.

Databases are excellent at sorting and filtering data. A massive amount of engineering talent has been invested in shaving miliseconds off of their algorithms. So let your database handle that. Don't filter in the application layer and then start complaining about performance. Need more capacity? Cluster. Throw more databases at the problem. Not more application servers. Make sure they're running on properly specified physical hardware, built to best match the actual usage pattern of the database.

Re:Making use of a database

[WarwickRyan]

Main reason is that you're hiding logic in the data layer. You don't want to do that. You should encapsulate all business logic in one place. Which, for systems of a certain complexity, is a domain model / layer.

Stored procedures are generally hard to test, and, unless you're using something like SQL Server's CLR integration the available functionality is limited. Not being object oriented, it's harder to manage complexity.

I've built some pretty complex logic in the past with SPs, and they're extremely useful when you need to do some data-only task with maximum performance. In my experience you'll usually get the task done better and faster (in coding time) with your programming language (assuming that you're working with a domain model etc etc).

Triggers are a similar thing, though it's good to treat them as a case of "I'll only use them if forced to" or if the alternative involves a massive amount of work (and if it does, then the triggers are the least of your problems) OR big risks to data integrity (think database which doesn't support cascade deletes).

2-port programs, Linux, PIL, expensive hardware

[tepples]

If you are writing a program that touches more than two persistent data stores, it is too complicated.

I disagree. Is a program too complicated if it has 1. input, 2. output, and 3. logging? Is a program to prepare images for an online store too complicated if it reads 1. raw source images and 2. an overlay image and writes 3. finished images?

If Linux can do it, you shouldn't.

That'd be fine if we all ran Linux. But in an organization that already has to run Microsoft Access for other reasons, we have to take Windows into consideration. And I don't think Ted Dziuba was talking about just using Windows as a shell to run Linux in VirtualBox OSE either.

Don't do image processing work with PIL unless you have proven that command-line ImageMagick won't do the job.

Our programmer is far more experienced in Python than in bash, and if I felt like it, I could benchmark PIL against subprocess.Popen(['convert', ...]).

if the physical machine is not the bottleneck, do not split the work to multiple physical machines.

Yet PC game developers split a 4-player game across four PCs when one could do, and increasingly, PS3 and Xbox 360 game developers are following the same path.

It is far more efficient to buy your way out of a performance problem than it is to rewrite software. When running your app on commodity hardware, don't expect anything better than commodity performance.

If you are writing software to be used internally, sometimes springing for better hardware is worth it. But if you are writing software to distribute to the public, you can generally assume your customer has commodity hardware unless your software costs at least 1000 USD a seat.

I RTFA

[Jorl17]

I just RTFA. It isn't that good. These aren't many tips and they also don't seem to be too specialized. Most of them are already known or predictable. I can say that I didn't learn anything from TFA.

I think that anything that reads "___ things to know about ____" or similar gets instant hits on /.

-1, Boring from me; hope it helps others.

I wish I'd known that CMS's are really hard

[petes_PoV]

Sure, you can do all the superficial stuff with simple point and shoot. But I wish I'd known (before I started?) that to do anything beyond that meant diving deep and dirty into PHP, Javascript, CSS, DOM, and a whole lot more alphabetti spaghetti.

And that's before you get into the really difficult stuff (that very few have managed to master) of getting a website that is easy to navigate and intuitive to use

until you find out why Python doesn't do the job

[tepples]

Don't program in C if Python will do the job.

But in a lot of cases, Python does not do the job. It doesn't do the job on iOS because Apple has explicitly banned everything but Objective-C++. It doesn't do the job on Xbox 360 or Windows Phone 7 because IronPython uses Reflection.Emit, and the version of .NET used by XNA doesn't support Reflection.Emit. And it doesn't do the job on Nintendo DS because the runtime uses up a lot of the available 4 MB of RAM.

What I want people to remember

[93 Escort Wagon]

Don't assume that, even six months from now, you're going to remember why you did things a certain way.

And the corollary: Don't assume you're going to be the one modifying the code a year or two from now.

Either way: Add comments liberally. Even if you're a conservative.

Re:xargs mapreduce?

[tepples]

I guess I'm an idiot, but.. err... did someone REALLY use mapreduce to solve an argument passing problem (the domain of xargs), or is the writing just shit?

xargs and its successor GNU parallel implement the "map" part of MapReduce.

Thing I wish _others_ would know

[melted]

Do not make things super-modular and generic unless they 100% have to be. In 99.9% of the projects no one, including yourself, will use your stupid dependency injection, and logging / access control can be done just fine without AOP. Don't layer patterns where there's no need. Aim for the simplest possible design that will work. Don't overemphasize extensibility and flexibility, unless you KNOW you will need it, follow the YAGNI principle (you ain't gonna need it).

Re:Thing I wish _others_ would know

[Anonymous Coward]

(too lazy to log in)

hear hear.

i'm working in an over-architected codebase now and all the Design Patterns thrown in haven't done squat for making it flexible or modular,
they've just made it obtuse.

This is te problem with Linux

[bogaboga]

"Modern Linux distributions are capable of a lot, and most hard problems are already solved for you. You just need to know where to look."

First off, I must say this piece says a lot about the Linux ecosystem. Specifically that this system's documentation is anemic at best. Why won't we have something like:

"What do you want to do?...with an associated answer...this kind of arrangement surely cannot hurt the Linux ecosystem.
 

Re:This is te problem with Linux

[jpate]

apropos

Re:This is te problem with Linux

[costing]

whatis apropos

Overengineering can be a good thing

[caywen]

You know, I find that as I get older, I am able to avoid overengineering things a lot better than when I was twenty something. There's nasty effect, though. I'm learning a lot less in depth about systems than I normally would.

Overengineering is terrible for a project, but it often is highly educational.

One more tip

[Posting=!Working]

Visual Basic - Don't. Just don't.

It's always great to learn a language then have the company change it so drastically in the next version that all your knowledge of the language is useless. I don't believe it'll be the last time that happens either. I do know I will never bother to learn another MS programming language again.

Good luck to all you C# programmers when they switch to C#.NET, or whatever they call the next one. Hope you like reading!

Re:One more tip

[radish]

Right - but a real programmer realizes that languages always come and go, that the real skill is PROGRAMMING not C# or Java or C++ or Python or whatever. If you have a real understanding of the fundamentals then learning a new language is usually easy (and often kinda fun).

Re:One more tip

[bertok]

Visual Basic - Don't. Just don't.

It's always great to learn a language then have the company change it so drastically in the next version that all your knowledge of the language is useless. I don't believe it'll be the last time that happens either. I do know I will never bother to learn another MS programming language again.

Good luck to all you C# programmers when they switch to C#.NET, or whatever they call the next one. Hope you like reading!

C# is already .NET, there has never been any other version.

And what about C++, hmm? That's a language that went from "C with classes" to a multi-paradigm language with a sprinkling of template mate-programming programming thrown in! The shift was so huge, in most compilers, the standard libraries have two versions, a legacy and a modern template version.

I had to re-learn C++ several times. Some of the new features are so advanced, that not even all compilers support it. Things like "partial template function specialization" are only turning up now, 10 years after standardization. It's a language where I was shocked to learn that there were entire language features I wasn't even aware of after having used the language in production code for 20 years! That kind of thing has never happened to me before or since with any other language.

Re:One more tip

[dbIII]

C# is already .NET, there has never been any other version.

Java :)

Yes, and no

[drwho]

Some oversimplified philosphy, some good hints. Programmers and SysAdmins who do a lot of resource management eventually become managers. This isn't neccessarily a bad thing, as the world needs more managers with extensive experience with that which they are managing, and the respect of those people they are managing. It's true that it's silly to adopt some software, technology or process just because it's new. But Ted seems to be resistant to any change, which is not good either. The problem with "don't fix it if it ain't broke" reasoning is..what do you do when it eventually breaks? This is a mistake made by many in process control / automation eniveronments: failure of a part which is so obsolete that it has become difficult and expensive to obtain a replacement. Just try to find a new motherboard with an ISA bus these days. Or a composite monitor. The same thing can happen with software and the OS..where are you going to find a guy who knows enough about that old Kaypro which was running some COBOL software on CP/M, which controlled the electroplating machinery? This is why companies have lifecycle management, so that the pain of switching to newer software / hardware comes with predictable cost and timetables instead of sudden, possibly prolonged unavailability and expensive, awkward, band-aid fixes.

This flows into the idea of organizational amnesia, where important processes become lost. This is perhaps best illustrated by the US DoE forgetting how to make this secret substance called FOGBANK, which is a critical component of H-bombs. Upper management felt as though, because there was no need for additional H-bombs, the process was unimportant, and didn't take into account that H-bombs become (more) dangerous with advancing age, and eventually these needed to be replaced. It took considerable time and money to re-engineer FOGBANK.

These are both examples of failure to consider that all equipment wears out, and failure to plan for long-term needs.

Some tips from a C guy.

[Murdoch5]

Hey

I know these might sound odd but hear me out. Start by trying to rewrite the basic library's. make your own printf, strcpy. strlen etc..... Write copies of your own link list and tree storage methods and above all really really start to understand how memory works.

Another really really important thing that I have learned is stay FAR FAR away from OO programming until your really really comfortable in lower level languages. The reason is that to many students and beginners sit there trying to figure out why there variable started with value X and ended up with value Y only to find out that there object bashed some memory earlier on.

Basically just grab a good C compiler, I mean C COMPILER, not C++, not C#, not F# and start to learn how all the functions you use on a dailiy basis work, it will give you new insight into why and how you can quickly avoid and fix problems when and before they happen. It's also important to get a really really good handle on using a CLI over a GUI, Stay away from Visual Studio and other simular compilers. Use GCC and CC and make sure you look at how LD is working and understand how compilers do optimizations and improvements to your own code. This post is taking about grabbing tool to do Image processing and preform functions that have working solutions. However taking the time to see how the solutions work and why they work will give you good insight into not only great code design but great programming methods. It might seem odd for me to suggest to a beginner to try and rewrite strcpy or strcmp, but once you see how they really work you'll be far less likely to make the simple mistakes that can ground your program / project from working. It's the same say with with a beginner figuring out how malloc works and where memory gets taken from and put to, all of these suggestions are coming from the way I learned to program in C and other languages.

Feel free to throw any of these away or take any of them into your own programming adventure, but one thing is for sure. When you can figure out how the basic functions you use every day work it will save you hours and days of trouble shooting and leave you with a greater pallet of tools to use in the class room and on the job. I welcome and one who wants to add ideas to this post and attack it with there own view points.

Re:Some tips from a C guy.

[spiffmastercow]

That's essentially what the K&R C book steps you through, and I'd say it's the best programming book ever written (or at least the best I've read). I don't get to do much in C these days, but the stuff I learned 10-15 years ago in C has made me a much better programmer. It's sad how programmers these days give you a blank stare when you ask if you passed something by value or reference.

Re:Don't code in C

[topham]

No. Sorry, I strongly disagree.

C is like a swiss army knife that can be used to assemble a chainsaw, a sword a lightsaber, etc. You'll have to carve out all the pieces, file them down and put them together yourself, but the swiss army knife will help you a long the way.

But don't forget the bandaids.

Re:until you find out why Python doesn't do the jo

[daveime]

Look, the PHB usually wants the code to run on HIS server for HIS use only. That's what he pays you for. Not to code it in the most cross-platform friendly language-du-jour and take 2 years to iron out all the bugs.

He doesn't give a shit if it'll run on the Xbox 360 or a Linux-ready Dead Badger.

And neither should you, unless you are some kind of anal retentive who spends all day arguing the merits of absolute versus relative positioning, fixed vs percentage tables, and worrying whether your code will run on every machine conceived in the next 50 years.

I have news for you, it won't.

Hell, I got an N900 6 months ago, and it's already EOL'd as far as updates to the OS are concerned.

I suppose I could wait till there's a port of Android or something, because the three coders on the project are doing a fine job, in less than a year I'll have the same functionality as a 3210.

Comment your data too!

[LihTox]

I'm in a different boat from most commenters here, I think, because I am a scientist writing simulations; some simluations run a long time and create a lot of data which would be costly to reproduce, and what I wish someone had told me early on was that I should comment my *data files*, not just my code. Each file should include the exact parameters used to create it, an explanation of what each column represents, and preferably there should be a way of knowing what version of your simulation code was used to create it. A couple of times in grad school I had toss out months of data after I discovered a bug in my code, and didn't know when the bug showed up and which data was affected by it.

(I'd welcome other advice from simulationists too; I've never had an advisor who was particularly programming-savvy, even though programming was always a large part of my research, and so I always had to make it up as I went along.)

Re:Comment your data too!

[dch24]

I had the same experience. As the data collection evolved, I used the revision number (from the source tree) compiled into the code and embedded in each data file.

The boss wanted everything in XML, since that was extensible, but then went halfway because raw images don't encode well in XML. So we maintained the dataset in XML and binary.

But as a result, I was able to keep around all versions of the binary-to-xml converter in the current code base. With some unit tests, and some comments, it really helped explain ancient data.

I enjoyed reading your comment. Thanks.

Re:Comment your data too!

[SplashMyBandit]

Yep. I learnt that lesson too when recording astronomical observations for research. You must design your software to *automatically* put in *all* the relevant information - just in case you need it. Rely on a human to put it in and you get mistakes that take a huge amount of time to untangle (if at all possible, sometimes you just don't have enough information to deconflict bad human-recorded values). My general rule is, "Never lose information". Once information has been thrown away it becomes a huge effort to try reconstruct it. Better to always keep as much as you can around to begin with. This is where using database to record 'state' stuff makes sense, and then have that point to the data files that are too big to go in the database. Then you can slice-and-dice the database tables as you need to. As a researcher I avoided writing software to existing databases (I now love Postgresql) but I wished I'd used Postgresql a lot earlier.

Re:Comment your data too!

[owlstead]

Yes, and if you use units (and generally you do) then make it clear what units each parameter expects. I am in crypto and I am always guessing if things are in bits or bytes. In physics it is even more important - fortunately students of physics will probably be more inclined to describe the units they expect. Also, the names of the parameters are even more important than those in the source files. Basically, if you have e.g. a configuration file, it should be thought of as part of the user interface.

Re:Comment your data too!

[B1ackDragon]

Very much agreed, though I'm not a simulationist per se anymore (these days I just do all kinds of crazy things to large data sets, and need to remember what crazy things I did, and when, and as you said, what the output means!)

Here's another tip, which I also thought about last time someone asked slashdot about scientific data organization: keep a wiki, and write down all the things you do (at least everything that isn't trivial to reproduce) there. Commands, paramaters used, input and output files created, etc. I organize chronologically. Having a digital "lab notebook" can be invaluable, and it makes the problem of organizing things much easier, since everything important is indexed in the wiki and can be looked up based on the timeframe of the project.

Emotional Things I Wish I Knew Earlier

[daseinw]

we could not figure out whether the author was an incredibly elaborate troll or just a run-of-the-mill idiot.

Reading this comment of his reminds me of something I read recently:
Physicists stand on each other's shoulders. Engineers dig each other's graves.

I've never understood why so many software developers feel the need to disparage one another in an attempt to prove their intelligence/superiority. There are plenty of tough problems out there and we all can learn something from one another, no? I've definitely been guilty of this in my tech career but lately I'm wondering more and more, why does the person who has a different solution always have to be an "idiot?" Why isn't he/she just someone who has a different take on solving this particular problem?

Now, I'm not saying that engineers do this more than any other group but out of all of my friends (some of whom are doctors, lawyers, teachers, etc.) it certainly seems like a more common event among software developers.

Re:Emotional Things I Wish I Knew Earlier

[azmodean 1]

I think there are several factors that contribute to this:
1. Programming is a very popular and easy to enter field.
2. It's actually pretty easy to get by as a programmer without really understanding what you are doing.
3. Regardless of how much you hear about it, modularity, reusability, and highly structured programming do not have good penetration in Software Engineering.
4. Because of #3, it is all to easy for otherwise competent programmers to paint themselves into a corner and generate software with really messy architecture and/or implementation.
5. Programmers OFTEN have to clean up after other programmers.

So, due to #1 and #2, there actually are quite a number of really bad programmers running around.
Due to #3 and #4, there are quite a number of otherwise decent programmers who produce working but unmaintainable code.
Due to #5, most programmers have ample opportunity to experience a great deal of pain from other programmer's incompetence.
Due to human nature, programmers tend to assume that all that bad code comes from #1 and #2 rather than #3 and #4.

And more speculatively and unrelated to the above:
6. Lots of programmers tend to hang out on Usenet, internet fora, mailing lists, and IRC, where harsh criticism is de rigeur, and internalize the habit of harsh criticism in their professional lives.

Re:Emotional Things I Wish I Knew Earlier

[laura42]

I agree with all of this, but also... Doctors, lawyers, and most (non-software) engineers have reasons not to present their work as being radically different from others in the same profession. Doctors who are sued for malpractice generally want to argue that what they did is the same as what any other doctor would do, lawyers want to argue that their positions are based on precedent, and civil engineers want to convince people that their suspension bridge designs are based on the same principles that make other suspension bridges safe.

Re:Oh if you find yourself repeating some code

[Haeleth]

Sadly, if you're working in Java then you will frequently be forced to write the same 8 damn lines over 70 times, and there will be literally no way to avoid it unless you resort to automatic code generation, which is a fancy name for using a separate program to do the copying-and-pasting for you.

Version Control

[BluePeppers]

Put everything in version control. Everything. EVERYTHING!

Well. You could skip /home, but I know a roll back of /etc has saved me a couple of times on config upgrades.

Remember that once code is deleted, you can't get it back. However, version control changes that. Version control is one of the most vital tools for anyone developing/working with a computer.

Oh and git rocks and stuff :)

LISP/Scheme

[turgid]

I wish I'd know about LISP 25 years ago. Stupid people told me it was "for processing lists." If only I'd known better. Functional programming gives you wings and a jet engine.

I wish I hadn't paid too much attention to people with limited imaginations. Just because they're older, have more money and shout louder doesn't mean they are clever or wise.

C++ is way over-rated but it's worth knowing because it's so widely used. Don't let it detract you from mastering C and learning scripting languages. Understanding object-oriented design is more important than knowing the latest trendy language.

Objective-C.

Just because software is Free/Open doesn't mean it's "cheap" and poor quality. I could have saved myself 2-3 years there.

Ignore Windows and it will ignore you.

Meaningfull messages.

[fahrbot-bot]

I don't know if this is still around, but a long, long time ago, I got this, and nothing else, from the shell when it died:

Assertion botch: This can't happen!

Nice.

The Truth

[TheCount22]

A few rules of thumb for a startup environment:

1. Don't overengineer! Overengineering wastes time on things that may never be used. Features should be customer driven.

2. Functions and methods should be as small as possible. You should make it an obsession to split methods and functions into the smallest possible components. Only then can you have good code reuse. Don't start thinking I will split it when I need it, you never will!

3. Never ever reinvent the wheel. Reinventing things that exist is overengineering.

4. Don't optimize ahead of time. When I say that I don't mean don't use a hash table instead of an array where it makes sense. I mean don't try to avoid exception handling or function calls or other minor optimizations. If it has an impact on readability don't do it. Optimization always comes last. Often you'll find there are only 1 or 2 "hotspots" in your code. If you spend time optimizing these "hotspots" after your application is built thats when you'll get the best return on your investment. Another gotcha with optimization is using technologies that can't deliver the level of performance you expect. You should test to make sure the underlying components you plan to use will perform as expected before you start coding.

5. Don't cram as much code in a single statement as possible. Every compiler I know about today will produce identical code whether it's one statement or 5 statements. It makes it hard to read so don't do it!

6. Allocate time for testing. No one writes perfect code.You want to give a good impression to your customer so don't skip this step.

7. Make unit testing an obsession. Always add unit tests for new code, it reveals errors in your code. When you find a bug in your code add a unit test to test for it. If in the future someone decides to rewrite some function or method you wrote because it's not elegant enough they will not reintroduce old bugs.

8. Don't rewrite code if possible. Refectoring is almost always easier and less error prone.

I disagree with nearly every point...

[SanityInAnarchy]

If you are writing a program that touches more than two persistent data stores, it is too complicated.

Others have already mentioned cases where multiple datastores make sense. A trivial example: One database to handle user data, another to handle blobs (image conversions, etc) -- bonus if the second store can do its own conversions; a third to handle logging -- that's already three, and that's before we start considering things like RESTful services, which can function as intelligent datastores of their own...

If Linux can do it, you shouldn't.

Unless you're not on Linux. And, specifically:

Don't do image processing work with PIL unless you have proven that command-line ImageMagick won't do the job.

If you're doing something that truly works as a shell script, and isn't part of a larger app, I agree. However, PIL likely performs better, and it removes the shell as an issue -- if you thought SQL injection was bad, wait till you have people exploiting your shell commands. You can do it safely, but why would you bother, when you've got libraries that accept Python (or Perl, or Ruby) native arguments, rather than forcing you to deal with commandline arguments? Why do you want to check return values, when you can have these native libraries throw exceptions?

Parallelize When You Have To, Not When You Want To

If you don't at least think about parallelization in the planning stage, it's going to be painful later on. It's easy to build a shared-nothing, stateless architecture and run it in a single-threaded way. It's hard to build a stateful web service with huge, heavyweight sessions, and then make it run on even two application servers in the future. Possible, but awkward, to say the least.

For example, if you are doing web crawling, and you have not saturated the pipe to the internet, then it is not worth your time to use more servers.

...unless, maybe, it's CPU-bound? And this is odd to mention in a section about parallelization -- wouldn't slow servers be a prime candidate for some sort of parallelization, even on a single machine, even if it's evented?

If you have a process running and you want it to be restarted automatically if it crashes, use Upstart.

Cool, but it looks like Upstart is becoming a Maslow's Hammer for this guy. Tools like Nagios, Monit, and God exist for a reason -- one such reason is knowing when and why your processes are dying even if they're spread across a cluster.

NoSQL is NotWorthIt

People who have read my other posts likely know where I stand on this, but...

Redis, even though it's an in-memory database, has a virtual memory feature, where you can cap the amount of RAM it uses and have it spill the data over to disk. So, I threw 75GB of data at it, giving it a healthy amount of physical memory to keep hot keys in...

So you found out an in-memory database wasn't suitable when you have far more data than physical memory? Great test, there.

Redis was an unknown quantity...

Maybe so, but that wasn't terribly hard to guess.

Yes, maybe things could have been different if I used Cassandra or MongoDB...

So maybe you should've benchmarked a NoSQL database which is actually designed to solve the problem you're trying to solve? Just a thought.

especially if something like PostgreSQL can do the same job.

If PostgreSQL could do the same job, the current generation of NoSQL databases wouldn't have been invented. Unless something's changed, PostgreSQL can't scale beyond a single machine for writes, unless you deliberately shard at the application layer, which would violate his rule about multiple datastores, wouldn't it?

It seems like the attitude is to no

Has ImageMagick improved?

[SL Baur]

Don't do image processing work with PIL unless you have proven that command-line ImageMagick won't do the job.

I think the worst mistake I made as Mr. XEmacs was attempting to unify our graphics support to call ImageMagick libraries instead of the custom stuff we were using (and later restored when ImageMagick was backed out).

Does it work any better now? The last time I looked at display(1) a couple of years ago, it still wasn't close to long lost and patent challenged xv(1) that got shut down by the GIF patent war.

Re:until you find out why Python doesn't do the jo

[dbIII]

Hell, I got an N900 6 months ago, and it's already EOL'd as far as updates to the OS are concerned.

So, where exactly did you get that information from and why do you think it is real?

Re:social advice, especially applicable to geeks

[russotto]

There is no silver bullet. You are no Superman. You're not going to change the world.

I'm not, no. But some people have, and they may be reading this right now. How do you know you're not addressing the next Bill Gates?

Anyway, your advice is way off. The people with the most _social_ success are raging egotists and shameless self-promoters. There's right ways and wrong ways to do it, and the wrong ways lead to you being written off as a pompous ass -- but not being such will never lead to social success.

Re:until you find out why Python doesn't do the jo

[Kludge]

Hell, I got an N900 6 months ago, and it's already EOL'd as far as updates to the OS are concerned.

I suppose I could wait till there's a port of Android or something, because the three coders on the project are doing a fine job, in less than a year I'll have the same functionality as a 3210.

Or you can read a little farther and see that upgrades are already available: http://en.wikipedia.org/wiki/MeeGo

Re:Oh if you find yourself repeating some code

[selven]

The code in question (9 lines actually) is:

private int variable;
public void setVariable (int val)
{
  variable = val;
}
public int getVariable()
{
  return variable;
}

Ironically, making your code less object oriented (ie. screw encapsulation) fixes this problem.