Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Confessions of a crap programmer

By cezarg in Op-Ed
Tue Jan 16, 2001 at 07:15:50 AM EST
Tags: Software (all tags)
Software

I don't think I have to convince anyone here that a lot of software gets written these days. Also I probably don't have to defend the argument that the vast majority of software written is completely useless junk. A large proportion of software is a rewrite of existing tools that mainly aims at giving marketing departments more stuff to sell. However, not all software is crap. In this flood of mediocrity and sloppiness there shines a real gem of software design that leaves me stunned and jealous.


You saw that right: jealous. When I come across certain projects that I admire I get the feel of that great admiration for its authors. Perhaps this has something to do with the fact that after working for three years as a professional programmer I still haven't written anything that I consider worthwhile (at least in the long run). After eight hours of my dilbertisque existence I go home and download software such as Mozilla which leaves me very humble and serves to remind that certain people are still working on things that are nothing short of amazing.

It is for a reason that I picked Mozilla for my example. Not only did they receive a lot of negative attention from various opinionated online journalist wannabes but they also received a damning post mortem by Jamie Zawinski himself. Yet the Mozilla group released a browser that works. The browser that I can use on a daily basis without that depressing feel of using substandard stuff which I often get from using most other software (open source or not).

Well, the question I want to raise is about that incredible force that drives developers like those of the Mozilla team to create a working web browser (no mean feat by any stretch of imagination) in an often hostile environment. A project that receives every imaginable insult from the community that should be cheering it instead (check out the bottom 50% of slashdot comments every time a mozilla article gets posted there).

I am the first to admit that early on (before milestone 12) I ridiculed Mozilla like everyone else saying that it will not hold a candle to IE unless it gets scrapped and written from scratch over again. Luckily somebody out there more intelligent than myself thought otherwise. The result is that we have a cross platform working browser that is not called Internet Explorer.

If you ever participated in a software project that you are proud of (I never did - hence the title) I would like to know what makes people like you tick. How do you manage to stick with the code when bugs seem to multiply with every line of code added? How do you stick with it even when it seems that some "issues" just aren't resolvable? Do you work to a predefined schedule or is your work driven by bursts of inspiration? Share your tips for writing extraordinary software if you have any.

If on the other hand you're like me and do not feel that any of your software is something you really feel good about vent your frustration and tell me what went wrong. I hope I'm not alone with my frustrations about the lack of quality in software today (including software written by me).

I am not asking for another Java vs. C++ flamefest or a doze of software management speak. I'm interested in the signifance of software development sucess stories and development failures as seen by software developers themselves. Is the current high turnover rate in software jobs caused by developers trying to inflate their salaries or is it a result of the urge to "start from scratch" we all feel at one point or another? Is developers' apparent short attention span a symptom or a cause of the fact that most software is less than impressive? How long can you stick with a project before the lure of the fresh start takes over and makes you abandon months (and often years) of your blood sweat and tears? Did you ever call it quits before your project saw the light of day the way Jamie Zawinski did?

Half finished projects are plentiful in both opensource and traditional environments. Why are those "last two weeks" of development always so long and daunting that they almost never get completed?

Am I just being a grumpy bugger that always sees the glass as half empty?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
To improve software programmers should:
o Keep rewriting software as each iteration is inherently better 25%
o Quit pondering stupid questions and collect those fat cheques while they can 10%
o Leave it to the professionals from Redmond WA. 7%
o Seek a cure for attention span disorder 26%
o Something else 29%

Votes: 161
Results | Other Polls

Related Links
o Slashdot
o post mortem
o Also by cezarg


Display: Sort:
Confessions of a crap programmer | 83 comments (81 topical, 2 editorial, 0 hidden)
Software developers are an odd breed (4.28 / 25) (#2)
by wonko on Tue Jan 16, 2001 at 02:03:48 AM EST

The simple answer to your question probably has something to do with the fact that the very best software developers are driven by an insatiable need to solve problems, whether those problems are bugs, new features, or simply filling a void that no other software currently fills.

I'm a programmer myself, and I identify with you at least somewhat. I've never been a part of a very active open-source project for more than a short time. I find it too stressful -- too much like what I do every day at work. In my spare time, I'd much rather work on small projects by myself. But I think a lot of developers have a stronger drive than I do. Despite the fact that they may prefer working on smaller projects and may not like working with a large group, they still participate because they must solve just one more problem.

The very best programmers, I think, are the ones who hate to code. They're damn good at it, they just hate it. These are the programmers who will be presented with a problem and spend hours, days, maybe even weeks if it's particularly nasty, coming up with a solution before they'll ever write a line of code. Then, when they've got it all figured out in their head, they'll sit down and pound out the code, despite the fact that they view coding as mere busy-work.

At least, that's my excuse for why I hate coding but love developing software...

Hate to code again (4.85 / 7) (#23)
by ucblockhead on Tue Jan 16, 2001 at 11:08:52 AM EST

I don't hate to code. What I hate to do is code something I've already coded. It is amazing how often you get stuck doing that. Code this report that looks like that report. Code this module that replaces that module for another device. The first time's fun, the second time's boring.
<P>
I think that what the best coders do in that case is try to step back and abstract out the commonalities so that they never have to code it again. The first time, you code the specific version. The second time, you code the generic version. The third time, you spend ten minutes adding table entries or running code generation scripts or whatever so you don't have to do it at all.
<P>
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Yeah (2.72 / 11) (#3)
by regeya on Tue Jan 16, 2001 at 02:10:34 AM EST

I know what you mean about Mozilla. I've been cursing it for quite some time, until recently. :-) I haven't grabbed any code since M18 and that was pretty good. Maybe it's time to look again. :-)

[ yokelpunk | kuro5hin diary ]

You gotta track the nightly builds (3.20 / 5) (#6)
by pwhysall on Tue Jan 16, 2001 at 04:22:05 AM EST

Mozilla has improved vastly, even since the middle of December.

I'm running the nightly build from 9 January and it's sweet - fast, stable and all-round huggable.
--
Peter
K5 Editors
I'm going to wager that the story keeps getting dumped because it is a steaming pile of badly formatted fool-meme.
CheeseBurgerBrown
[ Parent ]

Which OS? (3.00 / 1) (#15)
by adlr on Tue Jan 16, 2001 at 09:16:28 AM EST

I got Mozilla 0.7 and it still crashes on my linux box. Which OS are you running it on?

-andrew

[ Parent ]
get the nighly builds (none / 0) (#22)
by cetan on Tue Jan 16, 2001 at 11:04:26 AM EST

the 0.7 fork was obsolete by the time it was released (imho). A lot of the bugs have been fixed. I stick with the nightly builds at work, and at home grab a nightly build at the beginning of the week (provided it's a solid release). Stick to the main trunk and it's hard to go wrong. As with any project, a nightly build can be broken, but soon fixed.

http://www.mozillazine.org/build_comments/ is the resource I use for build info.


===== cetan www.cetan.com =====
[ Parent ]

Linux (none / 0) (#27)
by pwhysall on Tue Jan 16, 2001 at 11:54:12 AM EST

I run the 20010109 build on Red Hat Linux 6.2 with kernel 2.2.18 and XFree86 4.0.2. It's just fine.
--
Peter
K5 Editors
I'm going to wager that the story keeps getting dumped because it is a steaming pile of badly formatted fool-meme.
CheeseBurgerBrown
[ Parent ]
Miscellaneous thoughts. (4.53 / 26) (#4)
by Christopher Thomas on Tue Jan 16, 2001 at 02:16:45 AM EST

I'll avoid the whole Mozilla thread, as I don't use it (I run an ancient but adequate version of Netscape under *nix, and IE under Windows).

As far as why developers continue to reinvent the wheel, I see a couple of reasons:
  • In commercial environments: Better control.

    Working with software vendors is a hassle. A big, big hassle. They do not share your priorities and generally have no great vested interest in making your life easier, so they don't bother. This causes problems. In a big way.

    Having solutions in-house when they're practical to develop gives you the control to make your own changes and on-site tech support at all times, if you do it right.

  • When programming for fun: For fun, flexibility, or control.

    I usually write libraries and applications when I consider it fun to do so. Sometimes they're toy projects, and sometimes they're actually useful. I don't care, as long as they're cool to write and play with.

    My coding is influenced by the fact that having one or two critical libraries in a form I can easily play with will allow me to play with many other fun project ideas. I'll usually write these libraries myself, for the toy value.

    Lastly, I'll on occasion rather have absolute control over a project than be at the mercy of an existing vendor/maintenance team. This doesn't come up often, but it's still there occasionally.

As for why development drags on and on and why projects are abandoned half-finished, I have a few observations as well:

  • Stopping in the Middle: Boredom, change in lifestyle, or diminishing returns.

    I'm making more of an effort to finish toy projects nowadays, but I'll still get bored with a project and shelve it for a year (or a decade) when it's half-finished. I'm usually coding for fun, and fun is a fleeting, whimsical thing.

    I'll generally have courses or a day job to deal with. When one of these demands too much time, toy projects will halt. They may or may not ever get started again, depending on my schedule and my interest.

  • Dragging on and on: Bad estimates, bad management, changing requirements, or all of the above.

    Over my years of coding, my ability to judge a project's length has improved from abominable to just abysmal. When I was working in the field, my managers were somewhat better at this, but still not amazingly good at it. Our customers, who often set our schedules, didn't have a clue about estimating development time. Schedule and reality failed to mesh on a number of occasions both at work and at home for all of these reasons, with overrun being the result.

    I've had the good fortune to work only for managers who are bright, clueful, and who genuinely want to help their teams accomplish goals. Not everyone is this lucky. If management produces an unreasonable schedule, fails to properly define the project, or fails to communicate specs or assignments to programmers, the project will run over schedule, bigtime.

    Lastly, project requirements will change. If you're lucky, they'll stay mostly the same for the duration of one major version, and only change in the interval. If you're not lucky, then either you'll make a bad decision planning a toy library and have to rewrite large chunks of it to make it useful, or else you'll be working for a development house that has an indecisive customer or indecisive management. Whenever requirements change, project time expands by leaps and bounds.

    In practice, you usually get all of these happening, unless you're working on your own personal project, in which case it's just the first and last.

I hope that this gives insight into the way that I, at least, think, and possibly a few of the reasons coders in general have for acting the way that they do.

The Wheel went around (4.00 / 5) (#45)
by Devil Ducky on Tue Jan 16, 2001 at 05:45:00 PM EST

I know I reinvented the wheel.

When I did my first release on freshmeat I didn't expect anybody to download it. I expected everybody to see the announcement and say "Oh no, not another MP3 encoder!" but many people didn't and they downloaded it.

OK, so they downloaded it, so what? They probably never even untarred it. Then I started getting complimentary e-mails (once I listed the correct email address, see version 0.2).

I know why I decided to reinvent the wheel, none of the existing programs would work for me. I wanted different stuff than any of the existing programs offered. I did recieve quite a few emails about the features already included in abcde and other products, thank you... I still am not sure why the users decided to use it.

That's how I started an almost succesful project. Maintaining it is a whole other story.

Devil Ducky

Immune to the Forces of Duct Tape
Day trading at it's Funnest
[ Parent ]
upgrade your Netscape (4.00 / 1) (#76)
by G Neric on Thu Jan 18, 2001 at 07:47:59 PM EST

I run an ancient but adequate version of Netscape under *nix

There are known, serious security holes in every version of Netscape up till the latest. Continuing to use code with security holes makes your machine vulnerable to compromise, where compromise includes your machine being subverted for use to attack other people's machines. Large numbers of compromised sites make distributed denial of service attacks possible, among other problems, and allows sites like Kuro5hin to be maliciously taken offline. Please don't use old Netscapes any more, it's anti-social.

and yes, there are large numbers of security holes in Windows too. Upgrading to the latest service patches is really important.

[ Parent ]

What keeps me going (3.38 / 13) (#5)
by goonie on Tue Jan 16, 2001 at 03:25:39 AM EST

  • I work for company doing an open-source project, so I personally feel good about the end result of my labours being available to the world forever (or at least while somebody continues to mirror it).
  • The guys I work with are intelligent, pleasant, and better coders than I am, and the code is also intelligent and pleasant to work with.
  • When I finally get something finished it's very rewarding to be able to point to and say "I did that".


What keeps me heading towards finishing (4.36 / 22) (#8)
by Inoshiro on Tue Jan 16, 2001 at 05:24:18 AM EST

Somedays (most days, in fact) I have no significant urge to program. I have needs which I think can be addressed, but I'm tired, or busy with other issues, etc. If I forced myself to program in these phases, the code is mediocre, dense, and usually impossible to work with maintenance wise.

But every few weeks or so, I get The Urge. I can see the code in my head -- it flows around, crying to be let out. I sit down, read over what I was doing last time (todo list, BUGS file, and code) and hop right back in. I see enchancements to the base code that I didn't see the last time I was there, subsystems started reveal their ending and are completed. Every time I go through one of these phases, I can see the ending that much closer. After a few days of programming -- nothing but, and a few intervals of those programming sessiosn, the ending becomes close enough to reach out and touch. That's when I frantically thump against the final problem until I can go "wow -- this is perfect for an N.0 release."

Then it goes into the maintenace phase, which can be interesting in its own ways (especially since, once you start wading in and fixing bugs, you start seeing other base code enchancements for N+1.0 releases ;)). To finish a project you need inspiration that comes from the inside. It doesn't matter how your muse shows itself, as long as it's there. The rest is a natural outgrowth of it.



--
[ イノシロ ]
Re: What keeps me heading towards finishing (4.50 / 2) (#31)
by mcelrath on Tue Jan 16, 2001 at 12:14:50 PM EST

But every few weeks or so, I get The Urge. I can see the code in my head -- it flows around, crying to be let out. I sit down, read over what I was doing last time (todo list, BUGS file, and code) and hop right back in. I see enchancements to the base code that I didn't see the last time I was there, subsystems started reveal their ending and are completed. Every time I go through one of these phases, I can see the ending that much closer. After a few days of programming -- nothing but, and a few intervals of those programming sessiosn, the ending becomes close enough to reach out and touch. That's when I frantically thump against the final problem until I can go "wow -- this is perfect for an N.0 release."

This is perhaps the best description I've ever see of the way I code. It's totally an urge. It's a hobby. I have long lists of software ideas that I'll never have time for, but every once in a while one will be overpowering and I'll have to write some code. Most of my projects never seem to finish though, I think because I have a short attention span, and a few days later have a new idea, totally unrelated to the last one, or I'll see a new direction to take with my current project. (I'd be a horrible manager) And not all of my urges revolve around software either.

In the real world, I do physics during the day. I have worked as a programmer though, and hated it. I was damn good at it. But when I got home at night I was totally drained. I couldn't think about much of anything. I couldn't stomach the thought of looking at a computer for another second. I had zero drive to work on my own projects. And that killed me, destroyed programming as a career for me. Many of the ideas I have are software, and not being able to work on my own ideas is, to say the least, disheartening.

In physics, I get to scratch the "problem solving" itch, and write some code too. But it's more self-directed than doing software for a company. And when I get home at night I don't have a problem sitting down and working on software, because I haven't necessarily been working on software all day long.

I can't help wondering about this idea of "scratching an itch" and working on open source software is fleeting. What will happen when the market for programmers sees a downturn? Will people hoarde their code, because it's their livelihood? Or will all these same drives we're discussing still allow so many people to work on open source?

--Bob
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 2=0; 1=0.
[ Parent ]

As others have pointed out ... (3.20 / 10) (#9)
by gregholmes on Tue Jan 16, 2001 at 05:59:12 AM EST

... you keep going because you are internally driven to.

OTOH, in a multi-person environment (i.e. work) you are allowed to keep going (if you are) because you have established a reputation for success. Thus you are believed when you look the manager in the eye and say "this will work".



in reply to the poll (2.50 / 12) (#10)
by squee on Tue Jan 16, 2001 at 07:27:32 AM EST

> Keep rewriting software as each iteration is inherently better

Can you say bloatware. Change is enevitable progress is not.

Rewriting does not mean bloatware. (4.33 / 3) (#13)
by Sax Maniac on Tue Jan 16, 2001 at 09:02:34 AM EST

Huh? Rewriting software should make it smaller and faster, because you know what needs to be done have more efficient algorithms in mind. Adding to existing software without rearchitecting is what causes bloat.
Stop screwing around with printf and gdb and get a debugger that doesn't suck.
[ Parent ]
A writer once said... (4.00 / 2) (#21)
by ucblockhead on Tue Jan 16, 2001 at 11:04:16 AM EST

A famous writer, whose name escapes me, once said at the end of a letter "I apologize for the length of this letter, but I had no time to make it shorter".

Programming is just like that.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
It was Pascal. (5.00 / 1) (#36)
by Minuit on Tue Jan 16, 2001 at 02:45:35 PM EST

"I have made this letter longer than usual, only because I have not had the time to make it shorter."
-- Blaise Pascal, Provincial Letters

If you were my .sig, you would be home by now.
[ Parent ]
See? (5.00 / 1) (#41)
by ucblockhead on Tue Jan 16, 2001 at 04:09:18 PM EST

See, it does apply to programmers!
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Got a better quote, booyea! (3.00 / 1) (#72)
by 0xdeadbeef on Thu Jan 18, 2001 at 09:21:51 AM EST

Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away. - Antoine de St. Exupery

Refactoring != creeping featurism

[ Parent ]

The 'Age-Old' Programming Dilema (4.41 / 17) (#11)
by laotzu on Tue Jan 16, 2001 at 08:29:00 AM EST

The biggest problem a programmer faces is deciding when to do things 'right' and when things just have to be done. Especially in a corporate environment.

When the QA team starts bashing down your office door and holding a pitch-fork to your head (or when they decide to create a Microsoft Access 'database' of their bugs just so you can deal with the piling up reports without wasting time talking to them....), you really gotta fix that damn bug. Often the bug is a glitch resulting from a fundamental problem in your software, and you can either re-write the software and get a stronger door, or just cover up the glitch until you have more time.

This is really why some people don't write software they're proud of. Good programming takes a lot of time, much more than working programming. When you have a deadline, you have to make sacrifices for your software. Some programmers, like myself, sacrifice time for correct software, even when that means working late or all weekend. Most don't believe their jobs are that important.

When it comes to open-source software, another factor comes into play. Some people just suck at programming. Oh, they can physically do it and churn out something that works, but how they did it is utterly stupid. Mozilla is a wonderful project because they don't (seem-to) have choke-hold deadlines. Netscape programmers may be given some deadlines to produce working products, or to fix bugs, but the majority of their time is spent in Mozilla code where there is no upper-management about to fire them. Yet they still get paid. At least, that's how it seems to myself, looking in at the Mozilla project from a distance.



database (2.66 / 3) (#12)
by fantastic-cat on Tue Jan 16, 2001 at 08:46:31 AM EST

how come you put 'database' in inverted commas?

[ Parent ]
Because.... (4.33 / 3) (#24)
by dave.oflynn on Tue Jan 16, 2001 at 11:11:33 AM EST

....he's talking about Access. If you've ever tried to do anything serious with it, you begin to realise just how crippled it is. Disclaimer: I've not worked with Access 2000. Access 2.0 however, defined pretty much everything that a database should not be.

[ Parent ]
Ugh, Flashback (none / 0) (#75)
by stewartj76 on Thu Jan 18, 2001 at 03:59:31 PM EST

If you think Access sucks as a database, try using it with JDBC. That really blows. Once you can actually find information on how to get at it, Microsoft recommends you use the default ODBC driver, sun.jdbc.odbc.JdbcOdbcDriver. And they give you basically the minimum compatability with ODBC 1.0, which is just enough to get data into and out of the database. Thank God I convinced my bosses to switch to mySQL. Some people are impressed by free beer software.

[ Parent ]
...and some people dont understand what it means.. (4.00 / 6) (#18)
by 42 on Tue Jan 16, 2001 at 10:16:02 AM EST

....to do a good job.

Help! I'm surrounded by such people. These are the kind of programmers who, if given task A, would (a) not understand the rationale for the change and do coding without any perspective - thus leading to work which meets the letter but not the spirit of the reqt. or (b) are not interested in making sure that their program is robust (the philosophy is : code it and let the user deal with it).

*Sigh*. To top it all of, management doesnt seem to have figured out that there is a difference between coding and programming. (According to Wirth : programming is finding a solution to a problem using computers, and coding is implementing that solution using a programming language). Most of the people I am grumbling about fall into the category of "coders" but are mistaken for (with dire consequences) as "programmers".

[ Parent ]

Interactions (3.77 / 9) (#14)
by slaytanic killer on Tue Jan 16, 2001 at 09:12:06 AM EST

Well, I will analyze myself, and see what makes me the best programmer I can be.

My great love is in seeing the world at its most complex, and each day is unpredictable. That means I can intelligently allocate things (eg. time, energy) according to the situation. Not only that, but it is also seeing things anew, like at some points in a chess game, where a quiet move changes everything. Everything must be seen from fresh eyes.

For any new long-term contracts/employments, I will demand a month (unpaid, I don't care) writing libraries and whatnot. I have to fit my nature with that of the corporate world, which necessarily operates differently. They need predictability, even at the cost of speed, because it is their job to allocate money and the like. And since they hold the pocketbooks, they generally (not always) hold their requirements at a higher priority than those of others. So the best case is where I compress everything near the end, where my actions can't help but be fairly predictable.

In the future, companies will pay for the amount people contribute to a project, at the end of every month. That way, people can be very flexible WRT their output and methodologies.

the amount people contribute ... (4.00 / 3) (#46)
by Speare on Tue Jan 16, 2001 at 06:09:49 PM EST

In the future, companies will pay for the amount people contribute to a project, at the end of every month. That way, people can be very flexible WRT their output and methodologies.

Nothing could be scarier than volume-based incentives. As one Dilbert strip considered it, Wally said something like, "I'm gonna go write me a new Ferrari." Even if you're not counting *lines* or *hours* or *keystrokes*, a simple metric cannot measure true quality.

The basic benchmark is "ten bug-free lines a day." Sure, you may write 500 lines in a day, then you may skip a day, then you may kill a day or two to testing or fixing, and so on. Rewarding pure volume leads to bloat and untested bug nests.


[ e d @ h a l l e y . c c ]
[ Parent ]
I never said volume... (4.00 / 1) (#50)
by slaytanic killer on Tue Jan 16, 2001 at 08:04:18 PM EST

When I wrote that, I got a sense of the dangers in store. For one thing, it will be mainly subjective and have an "average pay," if you contribute a normal amount. The person paying must have a good sense of design and what is completed. In a sense, I'm assuming programming has progressed to the point where it is as clear to see how much someone has done, as it is understandable how much a construction worker has built of a house. Milestones: a person is compensated X for building a certain module, with a bonus for especially clear or optimized work.

Perhaps at some point I can turn this into an article.

[ Parent ]
Bad analogy (3.00 / 1) (#56)
by Joeri Sebrechts on Wed Jan 17, 2001 at 07:17:19 AM EST

I'm assuming programming has progressed to the point where it is as clear to see how much someone has done, as it is understandable how much a construction worker has built of a house.

Often, it's not that easy to see how much a construction worker has built of a house. Substandard building doesn't point itself out, just like substandard coding doesn't. You need to know what to look for.
QA is like going shopping for a second-hand car. If you don't know cars better than the guy selling 'em, it's likely you're going to get ripped off.

Only if management are better programmers than the programmers themselves would payout by volume coded be fair. And if management really were better programmers they wouldn't need programmers in the first place.
Face it, programming is a medieval art, and it's going to stay that way until it's automatised.

[ Parent ]

Sigh... (4.00 / 1) (#57)
by slaytanic killer on Wed Jan 17, 2001 at 07:55:51 AM EST

This is certainly hot water; I haven't had the time to type everything I think about this. In fact, I've been doing this with my last 10 posts, and so I will remain silent until I can write with what I consider to be quality and thought. All I will add is:

. There are project sizes that lend themselves to distributing work, with the lead programmer doing the dseign and some of the interesting work.

. How does it become clear that substandard building was done? By audits; checking the quality of the code itself. Regression test, etc. If a payment dispute reaches a court of law, experts are called to testify the veracity of each side's claims. Same with programming at some point. The only reason this may be infeasible now is that very fact that programming is medieval.

[ Parent ]
Rule #1: Work where they value good code (4.58 / 17) (#16)
by Sax Maniac on Tue Jan 16, 2001 at 09:49:35 AM EST

You've seen good code, you know what it looks like. You have the interest to write good code, and that's 90% of what you need. Read the books. Look at good open source code. Figure out what makes it good. Then, get out of your job and go somewhere where it is appreciated! Now!! A true crap programmer writes crap but thinks it is great, because they never educated themselves on software engineering outside of their own little world.

IMHO, the key is to find a company that values good code and work there. I've found that, for a software guy like myself, the only option is a software company. Their primary products must be software. If you work for the software department of a widget company, and you don't make widgets: you're secondary, you're not important. You'll get the 5x5 cube shared with 3 other people, and be asked to work overtime to meet some deranged PHB's notion of a 4-year schedule compressed into 9 months.

How can you tell if they write good code? Ask them! If they say something buzzword-laden and non-specific like we're ISO9001 compliant because we use the DOD-2176A waterfall software process and require 900 pages of documented, signed, sealed unit testing per line of code then avoid, avoid, avoid. If they say something specific like we use Purify, run nightly builds on all platforms via a cron job, use aggressive assertion checking, compile with warnings cranked up, and have regression tests run automatically during a build, that's what you want. One of these is drowning in paperwork, the other has the computer do all the grunt work for you. Guess which? ;)

Why do I feel this way?

In the not so distant past, I worked in the software lab far a very large, nameless Dilbertesque company. Then, I felt as you do now, that most of the code that I wrote was worthless. What was worse, was that I knew I could write better code. I felt held back.

I've always had interest in writing good code. All during my first job, I enjoyed reading books on how to make your code better: Design Patterns, Effective C++, The C++ Programming Language, even AntiPatterns. All these books have section on how to properly design. Now, don't think the authors are 100% right all the time-- they're not-- but I like to try everything and make my own decision to see if what they're suggesting is appropriate to my situation.

The problem was that I couldn't use any of these techniques there. There was the usual litany of excuses: we don't have enough time, it works good enough now, we don't use that language, blah, blah blah. These excuses were repeated year after year, as we scurried from one late crisis to the next.

Eventually, I realized to write good code, I had to leave, and did just that.
Stop screwing around with printf and gdb and get a debugger that doesn't suck.

Oops, bad link. (2.66 / 3) (#17)
by Sax Maniac on Tue Jan 16, 2001 at 10:12:02 AM EST

D'oh! That first link was hosed. Sorry.
Stop screwing around with printf and gdb and get a debugger that doesn't suck.
[ Parent ]
Not sure if I love being a programmer (4.54 / 24) (#19)
by technik on Tue Jan 16, 2001 at 10:18:00 AM EST

I love to program and spend much of my spare time doing it, but I agree with cezarg about being a crap programmer. This isn't a mea culpa, I do turn out some good code for my employer and some useful stuff for myself, but I'll make an observation of the environment in which I work which is probably not unlike his:
  • Most of the existing code is crap
    I used to think that How to Write Unmaintainable Code was funny. Now I see the tragedy. I regularly run up against not just poor but blatantly stupid and crippling design decisions- ones obvious enough that I can see them and know to avoid them- in production code or used as an essential part of a framework. At least once or twice a week one of these beauties derails my train of thought. My grumbling is answered with,"then fix it!" but the fix is necessarily going to break something somewhere and no one is going to allocate developer and QA resources to my fix, which leads to the next issue.
  • If it works it is good enough
    This stuns me. Bad ideas that someone tweaked long enough to get working persist indefinitely. Okay, it passed QA. BFD, it still sucks and it slows everything down because maintaining it is monsterous.
  • Poorly defined problems, poorly designed solutions
    Need I say more?
  • Politics
    The little fiefdoms and power struggles make accomplishing anything as a programmer a challenge. Jumping the artificial hurdles imposed by squabbles between Security, Networking, Infrastructure, Business teams et. al. have nothing to do with the code but they end up defining it. Passed the Security review? Okay, but Infrastructure won't deploy it because they didn't attend the design meetings and didn't read the documentation and your boss called them on it so now it's a grudge. The system administration teams are fighting the NT/UNIX battle and will try to leverage you as the next tactical battle. Networking doesn't care one way or the other so long as no one asks them to do anything and wishes it was more like the good old days of TN3270s, leased-lines, and telephones. None of these people have a clue and it shows.
  • Stagnant technology
    This one is really the result of the above four. Everything has to be shoehorned into working with the least common denominator (in this case, Java 1.0/1.1). Got a great idea? Won't work with the existing stuff? Sorry, we're on a five year plan for upgrades but try to fit it in.
  • The problems are not interesting
    This is the fundamental problem, to which I have no comment or solution. Most of the work runs along these lines,"We have this (legacy|client-server|abortive attempt) product which needs a rewrite to fit our Web business model." Great stuff... not.

This has devolved into a rant and I apologize.

Alternate link (3.75 / 4) (#30)
by slakhead on Tue Jan 16, 2001 at 12:04:36 PM EST

For those of you who haven't read How To Write Unmaintainable Code here is the google cache version. The main site seems to have been slashdot'd rather heavily.

[ Parent ]
You read my mind here (3.60 / 5) (#35)
by cezarg on Tue Jan 16, 2001 at 02:41:15 PM EST

Well, your post is better than my article! I guess this is what K5 is all about... I've hit pretty much all the points you outline. Internal politics can be a severe impediment to adding features but the biggest danger of it lies in the low morale of the crew subjected to dirty tricks of management.

The title was a bit of a tongue in your cheek statement, I was paraphrasing Philip K Dick's book "Confessions of a crap artist" but I guess nobody spotted :-(

[ Parent ]

The fuse of interest (3.14 / 7) (#20)
by TigerBaer on Tue Jan 16, 2001 at 10:22:16 AM EST

I have similar problems. When i start to design a fun project, I get really excited. I see the interactions of the objects in my head (yes.. i am an OO nut), and imagince the modularity, adding addition upon addition to my design. Then i sit down to code......

Ugh! It is so hard to maintain momentum! Coding is a very laborious and nitpicky act. How do you do it for 8X5 hours a week???? I am a CS student right now (3rd year) and i have worked for the 8x5.. and i really get annoyed with it. The pace is so slow compared to what i imagine in my head when i design things.

Any ideas on how to make the designing to coding transition, and maintain the velocity of thought and excitement?

Find the high. (4.33 / 6) (#25)
by Sax Maniac on Tue Jan 16, 2001 at 11:15:26 AM EST

IRL, coding moves a bit faster because you'll probably work with others, and be calling out to libraries to handle large chunks of functionality.

What you're running into is this: during implementation, you've realized the flaws in your design that constrain your implementation. You have two choices: fix the design and re-code, or hack around the limitations and have your design be inconsistent. I don't think completely separating design from coding (meaning no feedback loops) produces good products. Sure, you could ascend to a designer who doesn't touch code; but if you get to that position without going through the coding trenches, the designs will be, um, crap.

I've worked for "designers" who do not code. (By "designer", I mean someone who produces models/diagrams of how the software internals should work; I don't mean "designer" like a game designer who operates at a much higher level, and really doesn't touch the software architecture.) They either do not, or have forgot, the difference between an implementable and unimplementable design. A good design will have a good implementation. A bad design will have a nasty-ass implementation that breaks the second you breathe on it.

What's my motivation? Aim for the Turning Point. Find the high. I don't know if there is an actual name for it, but it's always there for me:

You've designed. You're coding. It's all messed up; first it doesn't compile. You fix the compile-time errors. Then it compiles, but it crashes immediately. You fix those errors. Then it runs, but doesn't do what it's supposed to do. You fix those errors. You run the program to check again...

Then the magic happens: it runs, and the new feature works! That is the thrill of programming. It's the high I get every single time, when that new feature works for the first time.

But, your job isn't done yet, the feature is fragile. For one case where it works, there are ten when it doesn't. You go fix those. Repeat. Eventually, it becomes stable.

If you don't get this high, you don't enjoy programming. And if you don't enjoy programming, don't do it for a living. You'll be miserable. I'm not saying abandon CS-- you can be in CS and not program (research? math proofs? net admin?).


Stop screwing around with printf and gdb and get a debugger that doesn't suck.
[ Parent ]

High (4.00 / 1) (#47)
by TigerBaer on Tue Jan 16, 2001 at 07:27:49 PM EST

Luckily, I do feel the high when i start coding. I completely agree with what you are talking about. In fact i consider myself a good coder, I am quick, and my designs are usually fairly solid (minimal feedback loops from design to coding). On the whole I am a good programmer.

The frustration i am talking about is when I realize the time it takes to code something. Unfortunately designs take microseconds to start, and seconds to establish, and minutes-hours to refine. The coding on the other hand always takes a long period of time. Its fun when you blast through all the higher level algorithms that set your program apart, but when you hit (my personal dislike) parsing input and output to create your objects (or structs) that is tedious and often nitpicky work.

Anyway, I completely agree with your strategies, but i dont think i expressed my difficulties well. Thanks tho!

[ Parent ]
UI (4.50 / 2) (#58)
by Sax Maniac on Wed Jan 17, 2001 at 09:20:52 AM EST

Yeah, that IS a pain.

Things change in the the "real world" a bit. You probably won't have to worry too much about user I/O. Why? IRL, code usually to fall into one of two categories:

1) It gets input/output from the user.
2) It gets input/output from other code.

#1 is almost always going to be a GUI. In a properly written system, it will be the top-most layer and usually well separated from the rest of the logic. UIs need a lot of attention to handle the strange whims of the user- you want them to only input numbers, but they will want input letters, drop ice-cream on the keyboard, and generally make things difficult for the computer. UIs have to accomodate this un-computer-like behavior.

Most code, however, is #2- it gets input from other code and sends output to other code. Code-to-code interfaces are more formalized in parameter lists, binary interfaces, structs, etc. Dealing with them is much easier because you can say "my function takes an int and nothing else, dammit!"

Most university assignments, IMHO, focus too much on user interface- e.g., using cin and scanf or worse, GUI buttons, from the start. The best assignments I've had read formatted input from files or the command line, and allow you to focus on the course topic, not the vagaries of implementing a UI. UIs are whole courses unto themselves.

Good luck and hang in there!
Stop screwing around with printf and gdb and get a debugger that doesn't suck.
[ Parent ]

Some devices (3.60 / 5) (#32)
by slaytanic killer on Tue Jan 16, 2001 at 12:26:03 PM EST

Here are some devices that some people I know use, which may or may not be useful to you.

. Use templates. Like downloading code examples or using some older code from your current project. Many people with good ideas hate the sudden speedbump of programming cold.

. Think of your programs in terms of inputs and state. Often, this will let you think in such a minimal way that you don't hit so much upon the stranger regions of your programming language or API. When you must, then you can just calmly research it a bit.

. Use comments as pseudocode. Specify steps that occur to you in terse one- or two-line comments. That makes it easier at times to keep exceptional cases and alternatives in mind. Then you can insert the actual code.

These are not panaceas for everyone, but if any of these seems right to you, you might be well off using them. And most importantly, one measure of their use is when you stop using them.

[ Parent ]

Dealing with Coding (4.66 / 3) (#42)
by SlydeRule on Tue Jan 16, 2001 at 04:53:26 PM EST

If you've got the option... consider using Eiffel.

The Eiffel language is a programming language for OO designers. Coders hate it because it's "too simple". (See 42's comment on the distinction between programmers and coders). Designers love Eiffel because it's simple. The resulting code is clean and clear, and is structured exactly the same way as the OO design.

Eiffel code is quick to write because there is no need to choose how you'll write the code. There is only one way to do any particular thing, and that way is obvious.

You don't write Eiffel code with any consideration at all for making the compiler's job easier. There are no optimization hints to the compiler, no fussing over declaring forward references, no import or include statements. It's the compiler's job to figure this stuff out, not yours.

You'll also find no bookkeeping code in an Eiffel program. Again, the compiler and runtime handle that for you. You focus on your problem.

Perhaps the most startling point of code-reduction is that you don't write defensive-programming code in Eiffel. Instead, at design-time you devise contracts between your classes and methods. These contracts consist of preconditions, postconditions, and invariants, and are expressed declaratively, not as directly executable code. Of course, devising the contracts increases the workload at design-time, but for designers that's a lot more fun than coding is.

It's amazing how little code you have to write when all of that junk is taken away, and all you need to do is to write a straight-forward implementation of your solution. Takes all of that "laborious and nitpicky" right out of the picture.

[ Parent ]

Eiffel (3.50 / 2) (#44)
by curious on Tue Jan 16, 2001 at 05:07:31 PM EST

If you've got the option... consider using Eiffel.

Wise words.

I learnt Eiffel as the Department Approved Object Oriented Language in my first year of Computer Science. Everything mentioned above is quite correct, it is a very clean, precise, language. However, the point about coders hating it is also valid.

Coming to Eiffel from an ASM / Pascal background ( Strange bedfellows, I know ) made me feel as though I was trying to code with one hand behind my back.

Where was my graphics libraries?
Where was my non-line delimited inputs?
Where was my BIT SHIFTING!

It's a hard leap, particularly if you're used to feature rich, library rich languages.

After a while, sanity dawned, and I wrote some very functional Eiffel programs - but I have a caveat to this endorsement.

Eiffel is just not suited to a lot of things. I wouldn't want to write, for instance, CGI programs in it, and I certainly wouldn't try to write client / server or general networking applications under it's spreading boughs.

As this are pretty much all I do, at least in the office, Eiffel is of limited use to me. But looking over my shoulder at the 20,517 lines of increasingly obtuse Python in the terminal nextdoor... perhaps it might be time to investigate such methods again...

I apologise in advance for the slightly mangled signature.

--
"Got History?" -- The Prelinger Archive of Ephemeral Movies.
[ Parent ]

Thnks for the tip (3.50 / 2) (#48)
by TigerBaer on Tue Jan 16, 2001 at 07:29:41 PM EST

I have seen Eiffel, and yes, I think it is a fantastic language for learning. I am using Java right now, which is similar to Eiffel in its pure OO sense. Thnks for the tip tho. I refined my frustrations (see the reply to the other reply to my original comments (**!)heh..

ps.. if you like Eiffel and havent tried Java, you should.!

[ Parent ]
something to consider (4.00 / 2) (#71)
by luethke on Thu Jan 18, 2001 at 07:05:39 AM EST

even if you do not write code in eiffel I would consider designing with the design by contract in mind (read Object Oriented Software Construction 2'nd edition, It and Zen of Code Optimization have been the two books I have learned the most from). Using flat forms for design and many of the ideas from eiffel (design by contract, invariants, etc...) I have produced code that I think has gotten the highest compliment I could get (though it was meant as a criticizm at the time). After working on a particulary complicated problem for a while a teacher asked why I had taken so long to write the code, he said it looked simple. Of all the people in the class I was the only person to finish the code and when the code review took place every person in the class understood what I had done (he was the only teacher who ever complained my code looked to simple). While that teacher didn't like what I had done, every place I have worked since (including a national laboratory in high performance computing) and every other teacher has been very happy with what I do. The ideas work in oo, structural, and functonal languages, I can write eiffel-like code in almost any language. I didn't learn eiffel as a language I expected to use in the "real world" but it was invaluable as a learning tool.

[ Parent ]
Designers point of view. (4.80 / 20) (#26)
by driph on Tue Jan 16, 2001 at 11:29:03 AM EST

First off, let me get it right out in the open that I am not a programmer.. However, I've worked as a designer on several coding projects, one of which you all are familiar with. :]

Here are two examples.

I used to work for a dotcom. They were working on Yet Another Portal Application, and I was one of the interface designers for the app. No one was especially enthused about the idea, although occasionally we were actually listened to by management and that would cause a jump of enthusiasm. I was in the company of some of the best coders and graphic designers I've worked with, however, the project was shit. Why is that?

None of the people who really knew what they were doing actually had any control or desire to control the development of the software. The company had more managers than developers. We were trapped in an endless cycle of meetings. Something would be decided, we'd develop it, and a week later management would change their mind. It was frustrating, and eventually nobody cared. We didn't feel like we had any part in it.

Last time I spoke to one of my former coworkers, the company had laid off all but a skeleton crew of managers and a couple developers, and is tinkering on the brink of shutdown.

The second example is Scoop(including Kuro5hin). No one has really been paid to work on scoop, however, everyone involved has put in a great deal of their personal time into it's development. It's been progressing at a steady rate, constantly improving. Why is this?

Because there is a feeling of accomplishment. Albeit slowly at times, things are moving forward and progression can be seen. The end results are put to use. Rusty, Hurst, Ino, etc are personally involved. Everyone listens to each other. They are not answering to a higher level of management that they feel is clueless. They are not trapped in Scoop meetings all day, eating away time that could instead be used to get something done. When something is decided, they get to move forward at their own rate and incorporate that decision, as opposed to waiting for the bureaucracy to decide that yes indeed it IS okay to go ahead and start adding those features and can we have that done by Friday with documentation thank you very much. In spite of everything that could be hindering it, Scoop & Kuro5hin moves forward.

What have I learned?

    1) This is not an Open vs Closed course issue. The problems that cause a project to founder can be seen on both sides of the table.

    2) This is not a money issue. Big paychecks don't necessarily result in a quality project. Small paychecks(or none at all) don't have to result in a lousy project either.

    3) Management in itself isn't bad. Bad managers are bad. They can destroy an otherwise quality project. Managers, listen to your developers. Sometimes meeting are required. It's good to bring everyone in on the same level and inform the crew, brainstorm ideas, etc. Just don't overdo it. Let your developers develop.

    4) Finally, and by far the most important, if you want your project to succeed, place yourself in the company of others who also want your project to succeed. No matter how great the potential is, we all find ourselves burned out now and then. Your interest may drag, other things get in the way. However, with the right crew, someone is going to be there to bring you up, build morale and renew your vigor. That isn't going to happen if no one else cares.

    --
    Vegas isn't a liberal stronghold. It's the place where the rich and powerful gamble away their company's pension fund and strangle call girls in their hotel rooms. - Psycho Dave
My Confession. (4.57 / 26) (#28)
by broody on Tue Jan 16, 2001 at 11:54:56 AM EST

I have greatly enjoyed thinking about this article. I hope this doesn't sound cocky but here are some thoughts that I had after reflecting on the article. Wow, I seem to have written a book here. LOL.

If you ever participated in a software project that you are proud of (I never did - hence the title) I would like to know what makes people like you tick. How do you manage to stick with the code when bugs seem to multiply with every line of code added?

The application that I am most proud of retreived TIFF images from an Informix database & jukeboxes and queued them for printing at remote locations scattered accorss the country. Sadly, the client elected not to use it and returned to an akward client based solution. Penny wise, pound foolish; they went with PPP leased lines with an 8K circut coupled with a cludgy VB application on a timer. The irony is that the VB application was slower, it simply held the images client side and printed them all together every 10 minutes creating the illusion of speed.

My main motivations changed during this project. In the beginning, I wanted to solve the problem detailed by the customer. The second was pure competition as I focused on speed, increasing the number of supported printers, and portabillity. I wanted to make this application perfect, even when I knew it was never going to be used. Of course it never hurts that one of the developers I was working with loudly declared it could not be done in the timeframe.

At some point in my career, I am sure that I will decide to move to a tighter focus with a company like Vividata or Easy Software Products but for now I am enjoying the variety and flexibillity of producing the best applications I can on short time frames.

How do you stick with it even when it seems that some "issues" just aren't resolvable?

The only issues that I feel are not "resolvable" are unrealistic expectations about what computers can do. Changing these misconceptions and moving people to simple, cheap, long term solutions is my job. Simple as that...

I believe that I am responsible for providing solutions to my coworkers, managment, and customer with cost/benefit apprasals of the options and making them happen. I want my applications to be perfect and "just run" for years. For example, while the mainframers were doing Y2K they were talking about a COBOL guy whose programs had been untouched since the 1970s. I wish I could accomplish that kind of reliabillity and foresight!

It is much harder for me when something was considered an "acceptable bug" to move on and forget about it. For example, I was working on a scanning application that had a screen refresh bug that caused a very minor "lightning effect" on the initial loading of the control. To correct it the form needed to be redisgned but there was no business case for doing so based on a screen artifact that only I seemed to notice (others did after I showed them). To this day, I occasionaly encounter this form and I still have a strong urge to "fix" it.

Do you work to a predefined schedule or is your work driven by bursts of inspiration?

I produce the best results from "bursts of inspiration" but some issues can only be solved by pushing on and through. Some requested features I consider "wrong" from an asthetic, design, security, or functional perspective. If the decision is made to add them against my advice, I simply push through and remind myself where my repsonsibillity ends. The other thing that I learned was to step away from things from time to time; like this post.

Share your tips for writing extraordinary software if you have any.

I am hesitant to describe my applications as "extrodinary" but they have potential. With luck I can share some "tips" without coming across as cocky.
  • Strive for perfection in your software.
  • Attempt these wacky ideas that come to at odd times and never believe someone when they tell you something is "impossible".
  • Solve the problems your custumers tell you about but don't forget to solve the ones they do not know they have.
  • Compete with "rival" applications, products, and developers. At the same time remember you are really only competing with yourself.
  • Strive to be the person who "puts out fires" and being one of the poeple whom the maintence programmers cannot remember working on your code.
  • Don't hoard "knowledge" or hide ignorance.
  • Exceptional software comes from an internal standard of excellence rather then a "quality culture" or other training bullshit.
  • Realize & accept the limits of your responisbillity.
  • If some bugs don't have you rolling with laughter you are taking it too seriously.
  • Tools are simply tools. The guy who manages to build a sports car with a wood chisel has still acomplished something.



~~ Whatever it takes
My approach (4.00 / 6) (#34)
by 0xdeadbeef on Tue Jan 16, 2001 at 12:59:51 PM EST

Wow, that's a great list. I would like to add one thing:
  • Always. always, strive for self-improvement. Seek better ways to do things, and don't be afraid to experiment. Extend and refactor your skills like you would a piece of old code. Make it better, and better, and better...
I think of my approach to writing software like a giant Swiss-army design pattern. Every time I learn something new, from a better way to name things to a conceptual model for entire classes of problems, it fits into my mental schema called "Programming: a HOWTO".

Think of yourself as a machine for writing code, and the best thing you can do for that machine is enhance it, tweak it, hot-rod it, overclock it, extend it like you would any piece of cool hardware or software.

[ Parent ]

A doze of software management speak (4.00 / 10) (#29)
by leviathan on Tue Jan 16, 2001 at 11:59:33 AM EST

OK, once in a while, fabulous, amazing, magical software can just happen if you throw a bunch of extremely talented developers in a room with a project they want to do. No-one knows how this happens, and no-one's ever been able to do it with any regularity.

There are probably a few examples of this in the open-source world, but Mozilla certainly isn't one of them. Things that help are design methodologies (why do you think experienced software engineers like to talk patterns and XP) and support infrastructure (just like bugzilla for mozilla). These techniques are the industry's (for want of a better word; it's certainly not a science) best attempt at emulating the magic and when done right, it's fabulous stuff (pun intended).

--
I wish everyone was peaceful. Then I could take over the planet with a butter knife.
- Dogbert

The Best Book ever written (3.00 / 8) (#33)
by toddmilburn on Tue Jan 16, 2001 at 12:37:47 PM EST

best book ever written on how to spurn people to succeed in software development, is PeopleWare by Demarco and Lister... it deals more with management type things but it's a good read...

Another best book ever written (none / 0) (#79)
by simonb on Sat Jan 20, 2001 at 07:29:18 AM EST

A fantastic methodology book that i just got through reading
The Pragmatic Programmer by Andrew Hunt and David Thomas.
It has heaps of great ideas for managing your code,
and practical advice on how to deal with real world problems....
No matter if you are a good programmer or a bad one
CHECK IT OUT!



[ Parent ]
Programming as a student (3.50 / 6) (#37)
by NexusVoid on Tue Jan 16, 2001 at 03:06:40 PM EST

I too, have experienced almost every feeling expressed here. Throughout highschool, I took a series of Visual Basic and C++ courses meant to teach the basis of computers, how they work, and how to make them do what you want them to. The courses were mainly dedicated to programming projects, with a smidgeon of history and science lessons thrown in for spice.

While I have never programmed in a career setting, i do notice many similarities between being a student even in high school, and programming every day for your bread money. For one, both offer time restraints, albeit on a smaller scale. I can't count the number of times that I didn't get nearly enough done in school, and ended up emailing all of my code home, just to work on it again on my home PC. This went from an almost biweekly occurence, to a daily occurence. Why would I do this? Because I just wanted to keep up. I also tend to program in bursts of creativity, while doing the repetitive work and design on a set schedule. Unfortunately, the teacher didn't understand this. He expected everything to be done on a set schedule, in a set order. After about four months of this, I completely lost my love for programming.

Did I drop the class? No. Did I just sit there and play games or use the web while everyone else worked their asses off to hammer out a good project? No. I sat there every day, taking every study hall to go to the computer lab, and every night at home, and worked my ass off to program something *not* using the teachers programming philosophy. I even kept diaries included with the final build to show that I did just that. My reward for doing so? An A and a renewed fondness for programming, despite all of the crap I had to slog through to get it back.



OT: PKD (2.33 / 3) (#38)
by cameldrv on Tue Jan 16, 2001 at 03:17:05 PM EST

This reminded me of the Phillip K. Dick work "Confessions of a crap artist", and I was just curious if anyone on k5 is into PKD's later works like Valis.

It's not coincidence (5.00 / 1) (#39)
by cezarg on Tue Jan 16, 2001 at 03:30:21 PM EST

I am a big fan of pretty much all of PKD and the title was meant to remind you of the book although the content of my article is not at all related to the novel.

[ Parent ]
yes (5.00 / 1) (#52)
by byoon on Wed Jan 17, 2001 at 12:49:55 AM EST

VALIS and its follow-ups are among my favorite books. Have you ever read anything from Dick's journals that record his real life experiences and were the foundation for VALIS?
"I'm a going to break you down into the little cubes." -Picasso
[ Parent ]
Yes I have (3.00 / 1) (#54)
by cameldrv on Wed Jan 17, 2001 at 02:04:51 AM EST

I've read some portions of the exegesis on the web, but I have stopped for now because I was seriously concerned that it was driving me insane.

[ Parent ]
Exactly (none / 0) (#70)
by byoon on Thu Jan 18, 2001 at 01:36:15 AM EST

I went through a heavy PKD phase about five years ago after I read the VALIS trio and the parts of the exegesis that were published in softcover and it got to the point where that's all I would talk about to anyone. Then I discovered that Sonic Youth's Sister album, which I'd been listening to forever, had tons of PKD references on it. The first song, Schizophrenia, is about PKD's dead sister and I believe Stereo Sanctity was the song with Radio Free Albemuth references in it. So of course I had to go back to PKD for another flirt with madness.
"I'm a going to break you down into the little cubes." -Picasso
[ Parent ]
Another failure (4.22 / 9) (#40)
by kagaku_ninja on Tue Jan 16, 2001 at 03:41:40 PM EST

My career (now at 16 years professionally) has been one long series of compromises. The project I am most proud of (and I consider it to have had the best management) ironically was something I did in college.

From my experience, the big killer is that hasty (and/or incompetent) design decisions become set in stone. There is never time for rewrites of foundation code due to management priorities. Then a succession of barely competent programmers add more layers of crap over the years

My current job is at a startup. Even though the code was only six months old when I started, it is already too late. The system I work on is supposed to scale to 200,000 objects, and yet the foundation uses arrays and linked lists! (And people were suprised when I ran benchmarks demonstrating abysmal scaling...) I have added hash table lookups, but this is building on top of a shaky foundation.

The product at my previous job had at its core, an engine for aggregating data into a multi dimensional database style "cube". That core data structure was implemented using a tree, which (you guessed it) uses linked lists. The engine was hacked out in a few months by the original guru programmer. This was quite an accomplishment, and helped launch the company. The problem is: the engine is still in use 8 years later. Two rewrites have been attempted, but both got scuttled due to changing priorities.

fixing up krufty code is not that hard (3.00 / 2) (#49)
by G Neric on Tue Jan 16, 2001 at 07:32:34 PM EST

hasty (and/or incompetent) design decisions become set in stone. There is never time for rewrites of foundation code ... six months old when I started, it is already too late.

I understand the sentiment, but I don't buy the truth of the argument.

Do a good job of the source control and build system. Then, incrementally improve at your leisure. Want to change and interface? grep for every occurance of the old and change it. It's not that hard, but you have to know how to use command line tools, macro editors, stuff like that.

I'd like to see stuff like strcpy go away completely: it's a huge source of buffer overrun security problems. The way to do it is, #define strcpy as a compile error, and change every occurance on your project. It's totally doable, just requires some fortitude.

So, does every project I work on get cleaned up? Not on your life. I refuse on principle to be the guy on the project cleaning up other people's messes. I don't mind doing it at all so I take a lot of consulting projects that consist of mess cleanup, but that's when it's an operational mess and everybody thinks I'm a hero for fixing it. But clean up other people's stuff for aesthetic reasons? If they'd kiss my feet, I'd be happy to. In any case, my point is, it's not hard to fix up old code, you just have to be willing to read and understand what it does, and not fear making improvements where you encounter them.

[ Parent ]

Reality Gap (3.25 / 4) (#51)
by kagaku_ninja on Tue Jan 16, 2001 at 09:09:14 PM EST

Dude, we are not talking about something as simple as eliminating strcpy in an open source project, or whatever you are smoking.

Get some experience on real projects, with deadlines, unrealistic management expectations, and customers who will massively bitch if anything breaks. I am talking about projects developed by 10-20 full time developers over the span of 5 years (and that is considered "small" by industry standards).

[ Parent ]
don't make me laugh (2.33 / 3) (#53)
by G Neric on Wed Jan 17, 2001 at 01:38:50 AM EST

Dude, we are not talking about something as simple as eliminating strcpy in an open source project, or whatever you are smoking.

I used strcpy as an example of something that I think should be eliminated from the c library, from unix entirely, not from one project Of course, once it is gone from the library, you'd need to eliminate it one build at a time from every project you touched. I gave it as an example of something that all the pinheads think is hard to do because I don't see it happening. People fear deleting strcpy. strcpy should not be on your machine, or anyone else's, period. Delete it.

Get some experience on real projects, with deadlines, unrealistic management expectations, and customers who will massively bitch if anything breaks. I am talking about projects developed by 10-20 full time developers over the span of 5 years (and that is considered "small" by industry standards).

ha ha! listen, my child, it is you who needs to learn for I have far more experience than that which you detail, though I would slit my wrists before joining a project with 20 developers: industry standard? who do you work for, a bank? yippee! Sure, if you don't impress people on a project you are doomed to slog in other people's shit. But, if you are experienced and senior with a juicy resume, you code whatever you want however you want and if they don't like it, fuck'em, work is easy to find. They always cave.

My comments were addressed to those senior people who seem unwilling to fix broken APIs, I think because they fear code.

customers who will massively bitch if anything breaks

Duh! Then don't break things. Cleaning up APIs makes code more robust, not less. When you are cleaning up, resist the temptation to make any functionality changes, just clean, and if you have any clue you will not break things. Your attitude, by the way, is what I mean by "fearing".

This is exactly the kind of project I was referring to in my original post. I fix code running on webservers or in live databases essentially on the fly and I never break them and that's why people hire me. Why would I take that risk, editing live? because it's code that's already broken but customers bitch if you take it down. Most programmers have such shitty operational habits that they can't reproduce the same build of a complex project twice, that's why they get stuck bringing in an outsider to fix their crap. But, it is completely erroneous to believe as they always do and as was hinted in the story at the top that starting from scratch fixes the mess: it just generates a new mess. The skills that allow you to clean up a mess are the only skills that will stop you from creating one again.

[ Parent ]

krusty code? (2.50 / 2) (#55)
by www.sorehands.com on Wed Jan 17, 2001 at 04:00:26 AM EST

It's not hard to fix krusty code.

What is hard is when people throw code at a problem. But, it gets worse when it happens over time. I worked at a company on a 250,000 project. One of the original authors said it took minor miricles on a daily basis to keep it working.

It needed to be redesigned a rewritten from scratch. If proper design is not done early, you get burned later.



------------------------------------------------------------------------------
http://www.barbieslapp.com
Mattel, SLAPP terrorists intent on destroying free speech.
-----------------------------------------------------------
[ Parent ]

kruft (3.00 / 3) (#59)
by G Neric on Wed Jan 17, 2001 at 09:46:02 AM EST

krufty is a term of art, not a typo.

if software is requiring miracles to keep it going every day, then it is apparently being used every day. I fix code like that, really fix it at a very deep level, without rewriting it from a new design. The benefit is that it keeps working every day and the knowledge it encapsulates remains.

If you look at a call-tree of who calls who, many many subsystems are entered through only a few points. If there is a subsystem you want to rewrite, you can redesign the subsystem. Then create a new interface that has the same functionality as the old and is implemented on top of the old, but which can also support your new design. Visit every interface between the old and the old and uplift it to the new. You can often test one at a time because you are still using the old. Then, you can plug in the new when it is ready. If it doesn't work, rolling back to the old (with the new interface) is easy too.

Now, stuff like this you cannot do within Dev Studio or other crappy editors like that. It's much too much work. But in emacs... piece of cake. Just don't be scared.

[ Parent ]

You assume (3.00 / 1) (#65)
by www.sorehands.com on Wed Jan 17, 2001 at 03:18:52 PM EST

You assume that there are 'interfaces' and some modularities.

In this case, we are talking about C code that has 60k of global variables.

I was doing much of what you talk about. What you talk abotu can be accomplished if there is some modularity and encapisilation.



------------------------------------------------------------------------------
http://www.barbieslapp.com
Mattel, SLAPP terrorists intent on destroying free speech.
-----------------------------------------------------------
[ Parent ]

good, keep going (4.50 / 2) (#73)
by G Neric on Thu Jan 18, 2001 at 12:47:21 PM EST

You assume that there are 'interfaces' and some modularities.

Not at all. I assume there is functionality, some shred of a reason to preserve the code; that's all.

In this case, we are talking about C code that has 60k of global variables.

You need to think abstractly: passing parameters via global variables is the interface: the goal is to change it. And guess what? it's the easiest kind of code to clean up. How can that be? Because the variables are much more likely to have unique names. This makes grepping very accurate.

You clean code like this up by starting with the lowest level procedure that accesses some global, and change it to take a parameter. Now's a good time to introduce a variable naming convention. I highly recommend also changing the name of the procedure at this point, so nobody will call it with the wrong parameters. Fix all callers. Done, the code is now better. Do not attempt any functionality improvements. Don't even fix bugs (though, make a note of them). Make sure it compiles, and check your change into a source control branch. No need to test yet, you hardly changed anything (remember, you're on a branch). There are other good ideas. Follow very regular calling conventions. Keep the same parameters always in the same order. Why? Because you will want to encapsulate many of them into struct*s that you pass. If you are proficient with a macro text editor, you can fix vast amounts of code in a day. Write a quicky little perl script for concatenating your source files into one big file, and another script for breaking them back out again. Then, with one file to edit, you can even accomplish a lot of this with a crappy editor since a global replace will really replace everything.

I was doing much of what you talk about. What you talk abotu can be accomplished if there is some modularity and encapisilation.

Not to belabor the point, so I'll say it differently: adding modularity and encapsulation to working code (a) is a pleasure because you're doing a good thing and (b) is easier than actually adding functionality and debugging code in the problem domain. When you're done, you've really unleashed the value of what is in the code already. More changeable, less crash-prone, and all the bosses that kagaku was grousing about will now start to trust you more than your cohorts. Think about it from their point of view: you have a bunch of expensive programmers sitting around saying "can't do it" and that everything "they" wrote now needs rewriting. But you've got one guy saying, "I can fix that, and with little risk of breaking the existing system, blah blah..."

Don't fear code, it's fixable. And bosses with unrealistic expectations? Don't be a programmer with unrealistically low expectations and the bosses will be on your side.

[ Parent ]

Motivation along the long road (4.73 / 23) (#43)
by jonabbey on Tue Jan 16, 2001 at 05:05:08 PM EST

I've spent the last 5-6 years working on a large open source metadirectory system called Ganymede. It is something I'm very proud of, and it has taken me an enormous amount of time, energy, and continued dedication. I'm planning on putting out 1.0 prerelease 1 sometime this week, if all goes well. Just got to finish up the documentation..

Why did Ganymede make it to this point? Because I didn't let it not come to this point, pure and simple. I'm fortunate to work in a research laboratory where it is not considered insane to have the computer support division engage in development projects that wind up taking longer than the NCC-1701's original five year mission, but if I had let the project die at any point, it would have, instantly.

In the beginning, it helped a lot to have a lot of hubris. To make something great, you have to believe that you are making something great, and you have to always keep in your mind that you won't accept anything less than a great result.

Planning and vision is essential. I spent 6 months writing ideas down with pen and paper before writing any code for Ganymede. I benefited from a prototype system that my group had written beforehand that taught me about several design difficulties that Ganymede would have to smoothly handle. The worst things about Ganymede are those things that reflect flaws or shortcomings in my original design vision. The best things about Ganymede are those things that came out of good initial design work and a clear understanding of what I wanted to achieve.

On the other hand, ignorance is also essential. If I had really understood that it would take five years before I had something that I felt good enough about to call '1.0', I can't imagine I would have done it. I remember 3 years ago excitedly telling my boss, "It's done!!". Ha.

For something of this kind, patience and stubborness helps tons. At a number of points along the way I thought that my project was doomed, that someone else had done something that would make my work obsolete and irrelevant. But after a day or two of heavy depression, I just kept going. All those other products and projects that I was worried about have gone away. Either they never finished, or their product was closed and commercial and the company abandoned it. While I was working on Ganymede, a company named Ganymede (oh no! trademark conflict, I'll have to rename all those classes, and the documentation, and and) came and then it went.

During its development, I've had maybe one email for every one to two hundred downloads of Ganymede, maybe. That's never been much, but every email that I've received that was at all positive or appreciative of what I was doing was gold for me, and helped keep me going. It has helped that I have been a) so starved for approval that any positive mail energized me and that I have been b) so stubborn that I just consider a lack of email a natural consequence of the stage of development at, and that people *will* love it when they finally see it.

As for the "last two weeks" of development, I fully agree about how daunting that is. My "last two weeks" have gone on for at least the last year and a half. It is easy to make software that seems plausible, it is hard to make software that is truly robust, and that works in intuitive ways, and that can be extended and adapted for unforeseen uses. It is easy to make software complex, it is hard to make everything in a complex system perfect. Evolution and iteration is the only way to see complexity through, especially if your goals were overly ambitious or your design foresight overly simplistic.

And documentation is one of the hardest things to do, and the most essential. Writing documentation is like re-writing your software, except that you have to do it in much less precise language, in a loose and connotational way that feels utterly wrong after having hand-wired a piece of software line by line, bit by bit. And you can't run your documentation through a debugger.. even if you have users downloading and using your software, the odds that they will give you useful and meaningful critical commentary on your documentation is very low, in my experience.

So I'd say that vision, optimism, stubbornness, deliberate blindness to odds and obstacles, and a healthy capacity for masochism are all essential. Ganymede is about a quarter million lines of code as it exists today, and it has taken the majority of my energy for the last five years to achieve it. There have been moments of despair along the way, when it seemed impossible to move the design forward, or I just felt lost. There have been moments of joy, when I finally *knew* how to achieve the next goal in developing the system and I could finally code what I had been wrestling with in my head for weeks, and when users at my employer started taking what I had written for granted.

In then end, I can't tell you how happy I'll be to be done with it, nor how long it'll be afterwards before I'm able to judge whether it was all worthwhile. If anyone is willing to make that kind of sacrifice for the sake of a piece of software, I think that software will get done.


Ganymede, a GPL'ed metadirectory for UNIX and friends.
My list of tips (4.66 / 12) (#60)
by pmk on Wed Jan 17, 2001 at 12:05:15 PM EST

I'm a generalist systems programmer. While I've spent most of my career doing compiler work, I've also hacked kernels, binary translators, and pretty much everything else that snuggles up close to the hardware.

I've worked on a few projects that generated "extraordinary" software. My tips may not work for everybody, but they work for me.

  • Use scaffolding, get something working quickly
  • Time spent on infrastructure pays off
  • Monitor performance
  • Leave cheap assertion checks on
  • Manage expectations
  • Use your own code
  • Partition carefully
Scaffolding is what builders put up around new construction to hold things up until the building can support itself. In software, I use the term to refer to throwaway components that are placeholders for real production code, existing so that other code can be written and tested. Sometimes scaffolding will get thrown away to be replaced with new scaffolding before it's replaced with real code. Scaffolding lets you get something quickly into the hands of your users. It also permits development of interdependent components to proceed in parallel, solving "chicken and egg" situations that can otherwise gridlock a project.

For example: I wrote a simulator for our new hardware architecture so that our software groups could develop compilers, libraries, OS, and diagnostics long before real hardware was available. But you can't write a compiler unless you have a kernel that can run compiler tests, and you can't write a kernel until you have a compiler that can build it for a new architecture. So I also wrote a little throwaway kernel and a quick-and-dirty C compiler as placeholders for the real software. (And when the compiler group screwed the schedule pooch, the kernel group wasn't left dead in the water; we just beefed up the throwaway C compiler to production quality.)

Infrastructure refers to the code in the project that's there for the developer's benefit, not the users'. Put good internal tracing buffers into your kernels; put good internal representation dumping into your compilers. Debuggers provide a lowest-common-denominator view of your program's guts; your own formatted dump routines can be designed to show you what you need to know and can also detect inconsistencies. Your code has bugs; make it easy to pinpoint them from your own dumps and traces.

For example: The Cray-3's optimizing compiler could make a huge number of changes to programs as it ran. Most optimizations are of the form "test to see if we can make this change legally, test to see if it's a good idea, make the change." When a bad optimizing transformation is made to a program, it can be miserable to work backwards from the bad generated code to the point in the compiler where things went awry. So I added code to each transformation that would increment a global counter whenever the program changed, log the transformation to an optional trace file, and would prevent any optimizations after a cutoff limit was reached. This let me use a binary search to find the exact point of most problems automatically.

Monitor performance: Figure out reasonable metrics of performance, like source lines compiled per second for a compiler, or instructions simulated per second for a simulator. Measure these things and, unconditionally if you can get away with it, always emit messages at the end of the program reporting the performance. You'll soon know what your code's usual range of performance is, and you'll notice slowdowns as soon as they happen. So will your users.

Leave cheap assertion checks on so that bugs don't stay hidden until you run your debug code. A failed assertion is always easier to fix than a core dump. Expensive data structure integrity checks are better enabled from the command line or environment than from a separate debug build. If you can build and deliver just one version of your code, do so.

Manage expectations by never promising more than you can deliver. In fact, promise less and deliver more. When a feature is new and potentially unstable, make sure that your users know that. Get them on your side and life is happy.

Use your own code whenever possible. Be your most demanding user; you'll find problems and fix them before your other users are affected. Learn how your users use your code so that you can test it out before you deliver a revision. For example, before I install a new version of my simulator or compiler, I use the new software to build and boot an OS kernel from scratch. This takes time, but I don't have to deal with the embarrassment of having a kernel hacker show up at my door to tell me that the new compiler can't build the kernel.

Partitioning carefully is a design goal of complex systems. Keep components well-defined in intuitive ways; split features into multiple components with well-defined interfaces rather than writing feature-rich bloatware.

For example: our new machine's simulator simulates only the mainframe hardware. It doesn't have a user virtual simulation environment for user a.out's built into it; you always have to boot a kernel. It doesn't have disk or console device simulation; you have to run a separate device simulation program that connects to the mainframe over a socket. The flexibility of this approach has made some things possible that we never thought of at the beginning of the project, and has kept the simulator itself nicely self-contained and maintainable.



Wow... (3.00 / 1) (#61)
by DebtAngel on Wed Jan 17, 2001 at 12:37:40 PM EST

That covers (almost) everything. Kudos.

I particularly agree with your comment on scaffolding and partitioning. I have always been the type that needs something to build on - I have a horrible time starting from scratch. Having that scaffolding in place makes it easy to build a new routine to replace the old routine, which is how I like to work.

The one thing I would add is never leave your code alone. I'm a tweaker. Get a crappy (but well designed) version done - or scaffold up a shell - then start replacing the crappy bits with better bits. When you're done, do it again.

If I'm writing a new procedure, it takes about three tries to get it to the point where it's solid enough to ship. V1 is a hack job/proof of concept, V2 is complete but buggy, V3 is solid.

Mind you, that's what works for me, and I'm a much higher level programmer than pmk. For example, my latest project was done in Director. It's very pretty. It's also going to be great three months after it ships. :)

(Oh yeah, one more - You always need another week. You'll never get that week. C'est la vie, I guess.)


Is this post not nifty? Sluggy Freelance. Worship the comic.
[ Parent ]
Don't be scared to start over! (none / 0) (#77)
by CaseyB on Thu Jan 18, 2001 at 10:20:36 PM EST

Great stuff.

I would add another point: if during development you see a clearly better way of doing things -- DO IT! There is usually great resistance to rearchitecting code after it is written, and this resistance increases exponentially as more developers are added. In my experience, the process of ripping out old code and replacing it with something better is always less painful than anticipated. And the benefits over the long term, in both productivity and developer contentment, can be immense.

Also, it is perhaps the most satisfying task a programmer can perform.

[ Parent ]
It helps if you believe (3.50 / 2) (#62)
by dagoski on Wed Jan 17, 2001 at 12:44:46 PM EST

The thing that makes me keep working on a project and trying to improve it is whether I believe its worthwhile. Right now I'm putting together a web portal that gathers all the diverse resources of my university's library in a customizable portal like myYahoo and others of its ilk. Its a complex project dogged by obscure legacy code, organizational politics, and its own scale. Yet, I generally look forward to tinkering with it because its something that I would have found very useful when I was in college. But, like the authors says: what if you're stuck on something that's useless crap? Well, it also helps to remember that you're probably getting quite a good paycheck for what you do. Meanwhile, if you're doing volunteer work on something you don't believe in, then quit. In the meantime, if I have to code up something pointless, I don't put a huge amount of effort into, but I do use good top down design principles and usually I write a lot in the way of specifications and pseudocode before I ever get down to programming. Another trick often overlooked by programmers who've been raised on IDEs is the good old flowchart. Flowcharting even minor parts of a big project really saves time when you get down to codeing. You come into the programming process already knowing what it is that you're going do. Spending time flowcharting and developing algorithims on paper--or pda--saves a lot time in debugging and quality control.



Get a degree and learn how to write English (2.00 / 6) (#63)
by LordNimon on Wed Jan 17, 2001 at 01:09:31 PM EST

I have a Master's Degree in Computer Science, and I'm also very good in English. Because of my formal education, I feel that my programming is much better than it would be otherwise.

If you're going to college and you feel that you're better than the instructors teaching the CS classes, then you just need to go to a better school. Believe me, there are CS curricula out there that will challenge you, no matter how good you are.

--

--
Lord Nimon
Yes, I use OS/2 Warp.

What's your point? (4.00 / 2) (#64)
by cezarg on Wed Jan 17, 2001 at 01:42:19 PM EST

I graduated with my second degree back in 1996 and have two degrees behind my belt. I'm a B.Eng in Electronics and a MSc in Software Engineering, both degrees from highly respected UK universities.

I don't believe that a degree a great programmer makes but it is a necessary ingredient. I think that you and I have a consensus here. However, your comment about writing better English is pretty hard to swallow since it isn't my first language and some grammar errors always creep in regradless of how many times I revise my posts.

I don't think you've really grasped the theme of my article. I'll give you a hint: it is NOT a "help me for I can't code" rant. Did you post your comment after reading just the title?

[ Parent ]

A few degrees short of anything useful ... (4.66 / 3) (#66)
by mx on Wed Jan 17, 2001 at 05:11:04 PM EST

I also slugged through college, at the pace of the slow and generally not-so-bright. Throughout my entire college experience I expected something challenging or useful *just* around the bend ... next semester, next course, next year, next college. It never happened. Did college make me a good programmer? Not at all. Are there better colleges? Certainly, but none will make you a good programmer.

Has college made any of the people I've interviewed this year a good programmer? Not even close. I've interviewed several dozen graduates, some with experience, and found that there were very few good programmers.

What makes a good programmer? The same thing that makes anyone good at anything ... practice, focus, ability, knowlege, learning, etc. Every 4 year program I've seen is a great start, but requires more. Add to a degree hundreds of hours of applied learning, broad historical knowlege, raw talent, and a focused/open attitude and one has started along the path of becomming a great programmer.

Greatness is measured in magnitudes.


- mx
[ Parent ]
Do you have any recommendations? (5.00 / 1) (#68)
by marlowe on Wed Jan 17, 2001 at 06:46:49 PM EST

I'm not actually looking for a college. I'm just trying to find out of you know what you're talking about.

-- The Americans are the Jews of the 21st century. Only we won't go as quietly to the gas chambers. --
[ Parent ]
When there's too many problems.... (3.33 / 3) (#67)
by krogoth on Wed Jan 17, 2001 at 05:35:43 PM EST

work on a different part of the project. I have 2 programming projects right now (i'm actually controlling myself, and saving ideas for later), so when I have some difficulties with one I just go work on the other, and when I come back I solve the problem.
--
"If you've never removed your pants and climbed into a tree to swear drunkenly at stuck-up rich kids, I highly recommend it."
:wq
I am exactly like you. (4.57 / 7) (#69)
by fross on Wed Jan 17, 2001 at 11:02:59 PM EST

I have to admit it, and it's been one of the things I've never wanted to say. I've been a programmer since before I hit double figures (18 years ago), and made it my profession 6 years ago.

There have been projects all over the place, half-finished incredibly cool things, great ideas scribbled down furiously then either worked on until they do what the idea was (but with no practical external use), or just half-finished somewhere around pre-alpha.

The last 25% *is* the hardest, because it's proper work. You've already proved it's possible, and wasn't that what the idea was about in the first place? Now you've just got to make it faster, more secure, more dependable, more useful. Make an interface for it, write some docs. boring stuff. It takes self-discipline, first and foremost, and then a shift in willingness, not from "can i do this?" or "can this work?" through to "can i _finish_ this and release it?"

over the last few years i have to say i've improved, and i can attribute it to a few things. Here are some pointers:

a) Responsibility. When other people are depending on your project, whether professional or not, there is a whole new incentive to getting it done. If it's just your own thing, the only person who is disappointed in its incompletion is yourself. And you couldn't give a monkey's because you're busy on the next great idea ;)

b) Control your ideas. Don't get too caught up in them - indulge them to begin with, but WRITE THEM DOWN! make notes you can come back to. On reflection, the bad ideas will look as such, and you can concentrate on the good ones, and come back to them and flesh them out.

c) Make notes and plan. When you decide to work on something, don't just get stuck in. Sit down for half an hour and write down what it is you're going to do. Doesn't have to be in massive detail, but a picture of the whole thing will help. A list of later desired features is a godsend as well. When you have this bit of scribble later on, it will remind you of what you wanted to do with the project, and will give you a kick in the backside to keep going. It won't seem so daunting when you can address the points one by one. This will give you a good work ethic and will keep you disciplined.

What got me into these patterns was having to do it for a living, in an increasingly "strict" environment (ie more responsibility, more deadlines, more coordinating, more important systems); instead of just tinkering around as and when i wanted, things had to be done according to certain rules. These are some of the "work ethics" you should apply to your own project, as it makes doing the boring stuff easier to deal with.

Best of luck!

David


Michael Abrash's Tips. (3.50 / 2) (#74)
by broody on Thu Jan 18, 2001 at 01:50:45 PM EST

There are some excellent tips from Micheal Abrash here that seem relavant enough to be a reply to this discussion. The article begins here.


~~ Whatever it takes
I am similar in some ways.. (3.00 / 1) (#78)
by chutzpah on Fri Jan 19, 2001 at 10:59:25 PM EST

I am similar to you that way, sometimes I will start something then leave it half-finished, but I find that once I reach a certain point, I get obsessed in getting it perfected. I think there is something beautiful about a 100% working, secure and stable piece of software, admittedly I have never really done any large projects, just smallish ones, but I do tend to keep my focus in until it's done.

Questions ... (4.33 / 3) (#80)
by aphrael on Sun Jan 21, 2001 at 07:21:49 PM EST

I would like to know what makes people like you tick. How do you manage to stick with the code when bugs seem to multiply with every line of code added? How do you stick with it even when it seems that some "issues" just aren't resolvable? Do you work to a predefined schedule or is your work driven by bursts of inspiration?

This is a difficult question to answer; it goes to the heart of why I am a programmer, and what I hope to get out of it other than money --- and it touches closely on my relationship with my employer and our code base.

I'm happiest when i'm figuring out why something works the way it does and how I can make it work differently --- testing, playing, probing, investigating. I *can* build systems from scratch, but it isn't as much fun in some ways ... except that six months later, when i've forgotten what I was doing, the rediscovery is easier than it is when i'm probing someone else's code to understand it.

All problems are fixable. The problem is time: if it's going to take me two months to fix something, and management has a schedule that it feels it needs to keep that requires that I be working on something new instead of something old, what am I going to do? I can collect the bug reports until the weight of them forces someone to do something about the problem (and get massively cynical in the process), but that's about it ... so at some point I stop caring about the success of the project and just start caring about the *problem*. Management doesn't like this, I suspect, but it keeps me happy and productive.

I don't think I can keep doing it forever; at some point, I want to do something I think *matters* again. I'm not even convinced I'll stay in software at that point; I don't believe things are any better anywhere else. Even now, I can go weeks without being productive and then get two or three weeks of intense productivity bursting in from nowhere ...

I don't really know; I'm confused. I'm hoping that over time I'll figure it out. :)

To strive, to seek, to find... but where? (4.50 / 2) (#81)
by sleight42 on Mon Jan 22, 2001 at 04:17:30 PM EST

I've been coding professionally for 5 years now and have been a 1) government contractor, 2) product (R&D) developer, and 3) full-blown ratbert (read: consultant). Out of all of these jobs, I have yet to find the right combination of criteria to have a lasting pleasant experience. My greatest lament is that, while I had one company that was intent on rigourously writing good code, the environment totally sucked. What I'm wondering is how the heck I can find employers/clients that actually give a damn about quality while providing their employees a good working environment and overall pleasant experience!? Bodyshops (a.k.a head hunters, placement firms, etc) are only interested in finding you a position where you'll earn them money. However, companies with the big advertisements are usually those with the big bucks and big staffs -- and, as most of us know, big companies are usually too busy watching their earnings reports to care about writing good code. So where does one begin looking? Any pointers?

my experience (4.00 / 2) (#82)
by flash91 on Mon Jan 22, 2001 at 09:48:48 PM EST

commercial projects usually start with someone having a vision of how they want the solution to work. Crystalize it, make mock-up screens, then force adherance. Scope creep, unrealistic scheduling will be your worst enemies. The same people who come up with these neat ideas often change their minds. Unless the original idea was crapola, stay with it until it is complete. If you have multiple programmers, have one person who is responsible for completion, code review, and adherence to specification. I've done it, despite management cutting my timelines in half (oh, you programmers always pad your time) and letting go of my staff members (100% turnover) on their "perceptions" instead of my reports.

In pursuit of perfect code... (5.00 / 2) (#83)
by dbustin on Sat Feb 03, 2001 at 02:29:09 PM EST

This article should be named "In pursuit of perfect code", it's author is too hard on himself. With only three years experience as a programmer each new project is just a learning opportunity, to learn the tools better, the language independant solutions better and the process better. I have written alot of code that I am proud of, that doesn't mean that I couldn't make it better if I were to rewrite it now, nor does it mean that it is in the same league as other products of their genre. What it does mean is that they represent individual accomplishments and growth in my skillset.

If your looking for a product to be proud of, as opposed to your contribution to a project, then shop jobs very carefully for the right team, with preference given to small, talented & autonomous. The only way to guarantee a product that you will be proud of is to find an idea that inspires you, find some programmers to share your passion, hang up an e-shingle, and make damn sure the marketing guys answer to you!

Just remember most software is crap because, the people creating it either aren't as bright as they think they are, or aren't that motivated. The pursuit of excellence will set your code and you apart. IMHO I know that Jamie Zawinski is plenty smart, but it sounds as though his leaving is exactly what Mozilla needed, either as a kick in the pants or by losing someone who had lost the passion and was infecting the project from within.

Confessions of a crap programmer | 83 comments (81 topical, 2 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!