Submitted by Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It’s a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world.
StillDrinking writes on the torment of being a programmer.
Or go to IOCCC at http://www.ioccc.org/
Or http://thedailywtf.com/default.aspx
Kochise
This is one of the best rants I’ve read in a long time. I laughed, I cried. Now back to work making more shit code.
Here’s some more:
http://research.microsoft.com/en-us/people/mickens/thenightwatch.pd…
https://www.usenix.org/system/files/1403_02-08_mickens.pdf
Or any of James Mickens USENIX stuff, they’re all good.
http://research.microsoft.com/en-us/people/mickens/
Look under “Miscellaneous Excellence”, “I have written several humor columns for USENIX’s online magazine!” for links.
The problems start the moment another programmer steps in. Another programmer that is not you!
Absolutely hilarious article! I have to go through it again to save the best lines…
Edited 2014-05-07 19:46 UTC
I agree. Good read.
I dont even try anymore…i write 12 dozen functions that do the same thing….dont even need a team for that.
just chuck it out.
Reminds me of this:
https://www.youtube.com/watch?v=BKorP55Aqvg
I recall running into http://www.99-bottles-of-beer.net/ at some point, and while browsing it learning about the existence and “beauty” of brainf–k.
http://www.99-bottles-of-beer.net/language-brainf–k-2542.html
Edited 2014-05-05 22:59 UTC
The author forgot the bit about every programmer being on the edge of alcoholism, a nervous wreak and a chain smoker, but other than that it’s spot on!
Not all professional programmers are driven by sales teams, While the article is probably true for many programmers, my experience hasn’t been quite so grim.
Though I like the points about bad code, without some vigilance its easy for things to become a total mess.
Edited 2014-05-06 00:04 UTC
Yeah. I love coding, love design, love it all. I’ve been doing it for about 13 years now. I’ve had bad jobs and good ones. I’ve had to maintain 100k+ lines of 20 year old c++ code…. but i still love coding!
I’ve decided recently to move out of coding for work (into release management / devops) because I’ve done more coding in open source projects, etc and I realize that I do need to transition before i start (possibly) hating code lol
Some people forget that “professional” actually only means that you get payed for your work in contrast to an “amateur” that does what he/she/it does out of love. In the strictest sense of the words ofcourse.
In my experience when building or doing anything in life there’s a tendency to wanting get it done in a perfect way. So you’ll spend endless time thinking about details, thinking about the beauty of code, thinking about how to make something for the ages, writing and rewriting, changing your mind again or even scraping a project because you don’t feel you have what it takes to meet your own standards. I guess this perfectionist tendency is fairly common.
Because of this I always remind myself of the “perfect is the enemy of good” mantra that I read somewhere. It’s the perfect thing to remind yourself about again and again. This will allow you to release work that’s not up to your standard, because you keep reminding yourself what’s good about it, you can appreciate what’s good and forget about perfection. When I write a script I don’t give a flying fuck about the best possible variable names or the very best coding techniques anymore, the first goal is always to get the basics working, because life is short. Once I’ve some basics working I might restructure and improve code, but I do it only as far as necessary to add new features and to make it easier to read code that I can’t read anymore. Remembering that perfect is the enemy of good, helps me to get going and to mess with ideas, to be creative and not worry about criticism from others as much. I realise that I might need to start perfecting details later on, so that people can better read code and so that the code base can expand without becoming a cluttered mess. I wouldn’t even have started to write this comment, had I first thought about whether or not I’ll get the perfect response from it. I started this comment while I wasn’t exactly sure that my message would resonate with anyone. But it feels good to me that I got something out there, instead of writing and contributing no thoughts at all.
Good enough is not good enough.
“Good enough is good enough” isn’t supposed to be my message. Trying to get it just perfect can make you obsessive(which is a kind of insanity) or prevent you from getting anything done at all. I’d rather know that there’s a cure for AIDS with side effects that’s very expensive and only working 50% of the time and have it NOW, than having no cure at all available because a government agency won’t approve it because of the negative side effects. You always have to begin somewhere, and that’s usually anything but perfect. (Think about the first car, or the first plane, or the first anything) Will you never workout, just because you’ll probably never get to an olympic level? Does your girl friend have to look like a top model, or can you be glad that you have a girlfriend in the first place?
Yeah, i figured that’s not what you meant. I just wanted to put it out there
Physical engineering disciplines have a very formal education and licensing process to ensure that all practitioners are competent to perform high quality work. They don’t let self taught high school graduates design bridges or cars.
Software designers tend to take a far more ad hoc approach than other engineers. IT projects often have massive cost blowouts, huge delays and are sometimes simply scrapped because they lack adequate planning, poor documentation and low quality implementation.
Although it must be said, in physical engineering projects where the requirements are changed often, you see the same kind of blowout, if they’re lucky. Especially in the modern age where things are no longer really built to last, but to hug the cost graphs as close to possible. They even call it over-engineering now.
This is similar to what my Software Engineering instructor use to say…
Programmers get the code to work by any means, otherwise known as hacking!…
Software Engineers design the system to work from the outset, before the first line of code is written…
Most coders are and want to be the former. It takes an Engineer to be the latter.
***Good enough is not good enough.***
Yet it keeps the world turning 90% of the time.
edit: added quote.
Edited 2014-05-06 11:26 UTC
Maybe that’s why the world isn’t doing so great.
There’s perfect, there’s good, and then there’s crap. Sorry, but being blase about things like picking the right names for things – that’s crap coding.
You shouldn’t aim for perfection if that’s going to cause design paralysis. However, you need to get coding at the micro level right. Programming is hard enough. Don’t make it harder by taking shortcuts. You’ll simply end up wasting more time and effort later on.
The only way to keep your sanity as a programmer is to be eternally vigilant about managing complexity. Sure, don’t over-design. But by God, please get the coding part right.
The problem is what constitutes a shortcut depends on the language, the libraries, the project, the skill level of the programmer, coding standards decided on a whim (and possibly many more factors).
I think the uglier truth is that programmers just have to suck it up and learn to read code of many different styles, and learn the advanced features of the language so they can read it if not write it.
The other problem is that what is a shortcut in one language is the canonical solution in another and the least ugly way to bodge it into working in a third.
I’ve been coding for about 15 years, and I’m starting to hate it, the new generation of hipster is contributing badly to it.
I know that, but I refuse to make the youngsters responsible for that situation.
I am now a grey haired. I was given time to learn back when I was green. Furthermore, I have been allowed to make my very own mistakes, to learn to be responsible for my own mistakes. I had the chance to learn.
Today’s younsters are mostly doomed to deliver from hour 1.
Greetings,
pica
If you think that’s bad, imagine being an engineer at Sony! You design and slave away for years coming up with amazing products, technological miracles, only to have the jerks you work for cripple your great, amazing product with utter garbage software.
THAT has to be frustrating. To this day I won’t buy anything from Sony that uses software for that reason. I love their stereos, (the older ones,) and headphones, but that’s IT. They let their burning desire to make as much profit as physically possible inform the decisions they make when designing their products.
To break it down simply, imagine if someone built you a flying car that ran on nothing but rainbows and sunshine, didn’t pollute, was almost silent, was super-smooth and so quiet inside you have to use the radio because otherwise it would be like being inside a sound-booth, and oh, it tops out at 10,000 miles per hour, and it can fly itself!
However, no matter where you tell it to take you, the car always flies to, lands, and parks itself in Camden, New Jersey.
You hack the thing, and upload FlyBox, an Open Source replacement ROM for the onboard computer, and everything goes swimmingly for 6 or 8 flights, until you try to recline your seat, which was not an option FlyBox was built to handle, so the car lands right in the middle of Lake Erie going upwards of 600 miles per hour.
That’s pretty much my experience with Sony software, like SonicStage, for one example. It makes what should be a joy into a nightmare. Then if you replace it with something else, it’s suddenly very easy until it fails catastrophically, bricking the device.
Sony Vegas Pro…
Kochise
So tell me what Sony physical product doesn’t use software these days ?
http://www.sony.co.in/section/product
Hmmm, let me guess, Sony’s storage media ?
Kochise
Seems that site isn’t loading for me.
But do you mean flash-based storage ?
There is a lot of firmware in flash-based storage:
http://www.youtube.com/watch?v=CPEzLNh5YIo
Hell, harddisks even have firmware.
Or did you mean CD/DVD ?
That medium seems pretty much dead these days, who still buys that ?
I’d guess plenty of people buy that, otherwise shelf space wouldn’t be dedicated to it…
Sony Vegas is a very decent piece of software. Overall, it depends on which Sony division we’re talking about.
I have serious problems sometimes with getting a product out the door because I fret over all sorts of issues, usually design patterns.
I always seek a unifying pattern for a piece of software or problem I solve in writing Java/C code.
Sometimes I spend too much time doing so, and it gets me into trouble more often than not.
I am also obsessed with building a library of these patterns for reuse. I am building right now a private lexicon similar in scope to the Mark Williams C Lexicon, I knew when I was a teenager on my ATARI 1040ST.
I have a love hate relationship with writing software because the people I write the software for and pay me want stuff too fast for my taste.
I want code to be perfect, and that isn’t inline with delivery schedules unfortunately.
… and when you do manage get it just right, the next guy that comes along to maintain or extend your code will claim it’s crap. By then its “other people’s code” and legacy afterall. Other people’s code is always crap.
Even if you do manage to produce something genuinely, objectively beautifull, it will have a fatal flaw. it will be wrong. All our code is doing is modelling some little piece of reality, and reality is never pretty or elegant. This is nowhere more true than in the world of business driven software requirements.
In my view the article is about coding not programming. In my opinion programming starts with the platform specific modeling and coding is the art to transform that platform specific model into code.
What is your opinion on that matter?
pica
What I think about it is harsh : there are common practices out there for the past 50 years, 1000s of books written on the subject, professionnal courses provided, forum, feedback, yet the average level of software coded is pretty low.
Why ? Because coders are asked to work against a deadline set arbitrarily my marketing people, thus have to rush out their coding, tweak things that accumulate, and are requested to reuse the old bad code previously produced when refactoring from previous experience, if not restarting from scratch, would produce better future proof coding.
Please be kind, review your own code in an iterative fashion, clean the mess, ensure the indent is good, improve yourself.
Start here : http://en.wikipedia.org/wiki/V-Model
Specification, Conception, TEST (before actual coding), coding (against the unit/regression TESTs), functional validation, release…
Simple as pie !
Kochise
V-Model, quite interesting. I did many projects with V-Modell 92 and 97. Furhermore I have been solution and application architect in the first pilot using V-Model XT. That very project also has been choosen by the German government as 1 of the 3 WEB 2.0 reference projects out of more than 700 projects.
Well, I know V-Model. I like the 92 and 97 releases very much. Just because these are like a hand rail. These are really simple to use and very comprehensive guides.
The V-Model XT is completely different in this aspect. I consider and very much appreciate it as a process meta model to model process models, but not as a ready to use process model. As a meta model for process models V-Model XT covers all the range from strict waterfall to extreme agile.
But the critics remains: V-Model XT for most people is much too complicated to use. That is why V-Model 97 is still commonly used. BTW, V-Model 97 is a process model covered by V-Model XT. As such I quite often sell V-Model 97 as V-Model XT. If it fits better I sell SCRUM or even XP as V-Model XT.
Yes, V-Model is worth to study. Beside the process model itself, V-Model provides you with a tailoring process. That is the preferred way V-Model to adjust V-Model to your current project size and criticality. Furthermore you get the style sheets for all documents defined within the V-Model.
Greetings,
pica
EDIT typos
Edited 2014-05-07 07:44 UTC
I want to explain, why I consider V-Model XT as too complex for joe average project manager to use.
V-Model XT defines products and modules.
A product is a delivery. That might be a document like a project plan or a concept. But a product also could be a statistics or even source code.
A module defines a task to be performed. A module requires products as input and produces products as output.
Provide that in raw form to your project manager and in almost all cases you will have a Dilbert like situation afterwards
Yeah, V-Model XT is pretty handy for process designers, but does not fit project manager’s needs and requirements.
Greetings,
pica
please feel free to take a look at https://sourceforge.net/p/processmodel
Greetings,
pica