“Set a duration of how long you think it should take to solve a problem”—
C’mon, admit it! I’m just as guilty as the next programmer. I’ve seen programmers sit in front of a monitor for eight hours at a time trying to solve a particular problem. Set a time table for yourself of 1 hour, 30 minutes, or even 15 minutes. If you can’t figure out a solution to your problem within your time frame, ask for help or research your problem on the Internet instead of trying to be super-coder.
“In computing, the second-system effect or sometimes the second-system syndrome refers to the tendency, when following on from a relatively small, elegant, and successful system, to design the successor as an elephantine, feature-laden monstrosity.”—Second-system effect - Wikipedia, the free encyclopedia
I’m a big proponent of programming being accessible to everybody. I’ve linked to this article in the past and quote Marc Prensky in my talks sometimes. To me this is obvious, but I don’t think it’s a view shared by too many.
As programming becomes more important, it will leave the back room and become a key skill and attribute of our top intellectual and social classes, just as reading and writing did in the past. Remember, only a few centuries ago, reading and writing were confined to a small specialist class whose members we called scribes.
“As programming becomes more important, it will leave the back room and become a key skill and attribute of our top intellectual and social classes, just as reading and writing did in the past.”—Marc Prensky
“Parsers are invoked upon an input stream. They will consume a certain number of tokens and then return a result along with the truncated stream. Alternatively, they will fail, producing an error message.”—
Conceptually, a Parser represents a very simple idea.
“Most programmers code up FETCH operations all over the place and do not ever realize they are denormalizing. I think this pattern is just so natural that most of us never think about it. If you examine your database applications you will likely see that you are doing this all over the place.”—The Database Programmer: Denormalization Patterns
There’s been lots of discussion recently about finding other HNers to talk to / bounce ideas off / work with, some Google spreadsheets were set up to share details but they were soon vandalised. I had a spare afternoon yesterday (which turned into a long day) and here’s the result:
“Among other functions, pivot-table tools can automatically sort, count, and total the data stored in one table or spreadsheet and create a second table (called a “pivot table”) displaying the summarized data.”—Pivot table - Wikipedia, the free encyclopedia
It is a programming style where the developer tries random shots at the code. “Well, this method call is failing…. I’ll try changing this parameter from false to true!” Then of course it doesn’t work and the developer goes: “Well, maybe I could just comment out the whole method call!” and so on. It can go on forever until it works by pure chance or the developer is rescued by a peer who points the correct solution.
A regular developer can go crazy in a few hours if he finds himself pairing with a shotgun programmer. It can drive you NUTS. Two shotgun programmers should never do pair programming together, because their destructive results are magnified when they work together.
Programming by accident
It is a mild form of Shotgun Programming, and it is surprising to see how common it is. I think this category encompasses the majority of developers worldwide by a wide margin. It happens when the developers doesn’t really understand what he is doing, but things work. The dev codes some more, and the program still works. Since this is happening by accident, at some point something will break and the dev will have no idea on how to fix it. At this point, he usually has 2 courses of action: stop and understand what he did, in order to find the cause of the error, or, most likely, engage into Shotgun Programming to try to fix the problem.
Test Driven Development came to the rescue of the millions of programmers by accident. Now, you have an excuse to be program by accident: as long as the tests pass, you are good. Don’t get me wrong, Test Driven Development is a Good Thing, and it limits the damage that can be caused by Programming by Accident.
The term comes from the Cargo Cults that appeared in many pacific islands during World War II. During the war, the US used the illands as bases and built airstrips for their cargo planes. The natives were amazed by the planes who brought all those goods and food. When the war was over, the planes disappeared, and the natives built their own air strips, with bamboo control towers, in the hope that if they did exactly like the white men did, the planes would return and bring back the beloved cargo.
Cargo cult programming is the practice of applying a popular solution just because everybody else is doing and it seems to work form them, but without understanding why it is being done that way. Lots of people engaged on it during the first years of J2EE by overusing EJBs and Entity Beans, for example.
Least effort programming
This style is very common specially among junior developers. One day you are assigned a task to fix a NullPointerException, so you just go to the line of code where the exception is generated and surrounds it with a if (reference != null).
It may very well work but you didn’t solve the cause of the bug, you just hid it until it comes back to haunt you again. What you should have done is to go back and fix the problem that caused the reference to be null in the first place.
Design pattern driven programming
As the name says, it is the programming style where you use design patterns for EVERYTHING. Your code is full of Facade this, Observer that, Strategy whatever, Adapter, blah blah blah. It reaches a point where you have to dig real deep to find the code that does the actual job in the middle of the Design Pattern Tangle.
When working on a bug, the Surgical Programmer investigates the cause. And then the cause’s cause. Then, he investigates the consequences of changing the code that is causing the other code to cause the other code to fail. Then he does a text search to find all usages of that class in the code, just in case. And for each match, he does another text search to find what uses the usage’s usage. Then he writes unit tests for 30 different possible scenarios, even those that don’t have anything to do with the bug he is fixing. In the end, full of confidence and with surgical precision, he fixes a typo.
In the meantime, the regular programmer fixed five other bugs.
It is the programmer that has an extreme itch to refactor everything he touches. It is the kind of programmer that, the night before shipping, when fixing a typo in an error message, changes 10 classes, refactors other 20, plus changes the build script and 5 deployment descriptors.
IZ __name__ KINDA LIKE “__main__”?
N CAN HAS 999
I CAN HAS CHEEZBURGER
ME CAN HAS 0
WHILE I CUTE?
IZ I ATE MORE CHEEZBURGER THAN N?
Q CAN HAS I SMASHES NICELY INTO 3
RTRI CAN HAS I TAKE AWAY Q OF THOSE 3
Q CAN HAS I SMASHES NICELY INTO 5
RFIV CAN HAS I TAKE AWAY Q OF THOSE 5
IZ RTRI KINDA LIKE 0?
ME GETZ ANOTHR I
OR IZ RFIV KINDA LIKE 0?
ME GETZ ANOTHR I
I GETZ ANOTHR ONE
In many OOP languages you have access modifiers such as private and public to set visibility of your class content. These modifiers help to hide information and create a clean interface. In Haskell, however, there are no equivalent reserved words. What you have instead is module declaration.
1801 - Joseph Marie Jacquard uses punch cards to instruct a loom to weave “hello, world” into a tapestry. Redditers of the time are not impressed due to the lack of tail call recursion, concurrency, or proper capitalization.
1842 - Ada Lovelace writes the first program. She is hampered…