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]
Differentiating Developers

By czth in Op-Ed
Fri Feb 01, 2002 at 11:37:53 AM EST
Tags: Software (all tags)
Software

What makes a developer great?

What's the difference between the developer that can write crisp, clean, bloat-free - perhaps even, gasp, well-documented, tested, and robust - code and a klutz who couldn't implement bogo-sort without six wizards and a walkthrough?


No, don't give me the "I'm an MIS and while I may suck at developing, I can kick your ass at brown-nosing and preparing insipid PowerPoint™ presentations, so there" line. I don't care. That's not what this article is about, although despite the sarcasm I recognize that there's far more to software development than coding (consider, for example, the description of the Enabler in this article). But here I want to focus on development, from design to implementation but mostly implementation.

There's a great deal of difference between the bad (take a look at the hall of shame and yes, this is from production code), the average, and the great. I've tried to pinpoint these differences: what the bad lack and the great perfect and do naturally.

I'm a bit of a minimalization freak. Small code is good code, because there's less to take in when it comes time to maintain it. As well as compactness, this also means making things modular; like Unix tools, a function should do one thing and do it well and do nothing else. If a function gets big and complicated, break it into more functions, perhaps even its own class if data needs to be shared between otherwise clearly distinct subproblems. Divide and conquer. I've seen functions that were over 7000 lines long, and there was no need for it. It's a maintenance nightmare, especially when the function is "pure" C and all the variables are waaaaay back at the top of the function (or globals). In my own code, I sometimes take "small" over "readable to Joe Coder" but in shared production code, wizardry should be toned down a little - or at least well commented.

Larry Wall (creator of perl, for which I will be forever grateful) lists three virtues of a programmer, which are dead on, and motivate many of the suggestions in this article.

Traits of a good programmer

I don't claim this list is complete. I don't claim it's true for all good programmers nor that all good programmers have all these traits. I do believe these points outline what makes a good programmer, and I'm not just theorizing, I've worked at a few different shops with a lot of different people. But you may disagree, or think I missed the absolute greatest ever trait of a good programmer: if so, I'm open to learn about it.

  • Independence

    Despite ideas like pair programming, most of one's time writing software is going to be spent alone. A good developer needs to be one that can find things out for himself[1] and is self-managing to the point that he can work at a problem until it is complete. No, you don't work in a vacuum; feedback is good, but developer's shouldn't need babysitting. RTFM, STFW, ask co-workers; be self-guiding. If a problem does come up, take initiative to seek out a solution rather than to wait to be asked. Take responsibility and handle it well and you'll be trusted with more (just be careful not to become lion food).

    How? For the first area, write code. That's all. Pick a project - address book, IRC client, rogue knockoff, draw a rotating cube, even if it's been done a million times the creation of it can still help you learn. Theory is good but there's no substitute for doing. For the second, make sure when you say something is done, it is done, tested and handles anything the user can throw at it. Reliability engenders trust, trust responsibility, and so on.

  • Assimilation

    Fitting closely with the previous point, the ability to learn new material quickly is a must. I think the main difference between university and college is that university is more of a place to stand while you learn to learn, rather than passively been taught the latest soon-to-be-obsolete whizzbang technology. Not that[2] a programmer has to be a university grad, of course. The ability to read and comprehend technical documents (such as RFCs) is a must. I picked up XS and MakeMaker (the Perl C extension interface and build tool) in about an hour a few days ago, by reading docs and tweaking examples. You should be able to pick up a standard like ISO C++ and answer the issue at hand "according to the scriptures" as it were.

    How? Read. Learn by doing - although you may be able to mentally go through example code, sometimes it's better to cut and paste it and give it a run. Don't skip terms you don't understand; stop and look them up - use google or try something like FOLDOC.

  • Specialization

    Doctors do it; lawyers do it; so do engineers[3]. Pick something you're good at and like, and become the local expert in it. This helps to set you apart from the rest, which might aid in gaining (or keeping!) a job. Don't just specialize in code; diverse external interests (for example, one of mine is photography) also mark you as someone with an interest in spending time to learn and to grow.

    How? Just pick something you like and learn about it: search the web, subscribe to periodicals, read news sites, talk to gurus, follow mailing lists and newsgroups.

  • Well Armed

    Equip yourself with a good set of reference books, from favourites like Knuth, CLR (Introduction to Algorithms, Second Edition, by Cormen, Leiserson, Rivest, and Stein), and selections from the O'Reilly stable, to more esoteric aids that you find helpful. Keep a good list of links, too, like this invaluable C++ library reference. I like to maintain my links on a local wiki; it's far more orderly than a long menu of bookmarks, and easier to organize. As well, if you choose your terms carefully you can find almost any algorithm described on the web.

    As well as books, keep a library of code snippets you use often. I just added template classes to return all n-combinations or permutations of a vector<T> to mine. When you write code, think with reuse in mind (see next point), and copy it to a snippets directory or a wiki page. But don't reinvent the wheel... a Jedi's power comes from the force that is already present within all life, that is, the standard libraries present on every system. For C, libc; for C++, the STL and the rest of the standard library; perl has CPAN, etc. If you're hand-carving square wheels, you'd better have a good reason for it. Even before you learn the library, learn the language - don't let me catch you doing something redundant like if(pointer) delete pointer;!

    Next, arm yourselves with good tools. Find yourself an editor you like; if you like pico, I won't flame you (much); I use mainly vim and (at work) the Visual Studio editor, but I also know my way around emacs. I use perl a whole lot for code changes (usually as a filter through vim when vim's own search and replace can't hack it), it's truly the "Swiss-army chainsaw." Make is also good to know; I wish I could convert this VC++ project at work to use it; most of the time, Studio is fine, but when you need power, it fails utterly. I also find cygwin a lifesaver on NT.

    Finally, your co-workers can be your greatest asset. If they've "been there done that", and are willing to mentor you (and you do your part by reading and experimenting for yourself and not pestering them with every little problem you have), you can save a lot of time. These are the people you spend about a third of your life with; it behooves you to get along with them, to recognize their knowledge and when the time comes, be willing to give them a hand too; even if you don't have much experience, sometimes a bug (like writing if(i = 0) instead of if(i == 0)) just needs another pair of eyes.

    How? Experiment with various editors and other tools. Teach yourself perl; it's structured so you can learn a bit as a time as you need it. When you notice yourself repeating something, especially a mundane task, ask yourself if it can be efficiently automated (the fundamental question of computer science). And talk to your co-workers, go out for lunch with them, tell jokes; it may not come as naturally to you as some, but work at it; as this article reminds us, life is about people, not machines.

  • Pattern Recognition

    It's amazing how much duplication bad and average coders do in code. So-called clone-and-hack coding becomes a maintenance nightmare when you need to make a change. Refactoring is key. Cut out whatever is reduplicated and make it a function, inline if you're worried about efficiency. This point is critical. I have had to work with 20,000 line files that could probably be refactored to less than a quarter of that. Design for reuse - although, as XP (see next) mandates, don't write code you don't need.

    How? Reading code helps, although perhaps this is one of those "either you have it or you don't" skills (just like, I am told, there are people that don't "get" pointers; which is sad). Those with a strong mathematical background should be good at it too. And make sure to get hold of Design Patterns, one of the canonical works on the subject.

  • Software Methods

    Software development, in general, scales poorly (Brooks, The Mythical Man-Month). Even recent open-source developments have hit bottlenecks. By being familiar with using and implementing an arsenal of development "meta-methods" such as these, time can be saved, errors reduced, and efficiency increased.

    Source control is required. CVS is probably the most common. Having a central repository makes code-sharing easier, allows easy viewing of changes and project history, extraction of previous versions, and acts as a backup (but the CVS server itself should still be backed up). Such a repository also aids in doing automated daily builds of a project; it's quite easy to write a perl script (or find a tool on freshmeat) to check out the files to a build server, and have it report errors to a web page or even email them to the last person to check in the file. The next step is automated testing. Two good sources for software methods and ideas are Extreme Programming (XP), and Joel on software. Don't throw the baby out with the bathwater, however! Rather than "XP says to do pair programming, and we can't do that so forget it", pick and choose the parts of it that will help your individual situation.

    Another important point is to know and keep in contact with the client (user). If you ask your boss, "How is this going to be used" and they don't know, find out. A programmer is often the worst person to make usability decisions about their software - we like solutions that are "interesting" to code, elegant, and tunable to the nth degree; the real world isn't always like that.

    How? You may have to just go at it yourself: if there isn't a build server or source control, install it on your machine or scrounge an older unused machine, and convince your co-workers and boss of the advantages; it will become an integral part of the process on its own merits. Be eloquent, if people want studies give them studies. Make it convenient for people to use (e.g. daily build results on a web page, or set up a CVS client for them).

  • Consistency

    I don't care (much) what your coding style is. Just be consistent. If you want to prefix your globals with g_ and members with m_, be my guest; if you want to use Allman or the one true brace style, take your pick, just keep on doing it. But, if you have the liberty, try to get some minimal naming and formatting conventions - nothing draconian - established for a project. Where these don't exist, my rule of thumb is that a module's style is dictated by whoever wrote the most code for it (usually the creator). If you're counting sheep, call it sheep_count or num_sheep or uiNumSheep or NumSheep or numSheep or even, if you must, NUM_SHEEP, just make sure you enumerate cows the same way. Be able to defend your choices.

    Document whatever you think the average programmer working on a project won't understand. If you comment to the level of the bad programmer your code will end up completely encrusted with comments, and assuming the next person to work on the code (yes, I know it's absolutely perfect in every way, but hypothetically) is a wizard is a good way to get your code thrown out (and you with it, no matter how clever it is. I'm trying to wean myself off this practice, by sporadically showing people code and asking them about it). Separating code and documentation (except for higher level overviews and algorithm descriptions) is a bad idea; for the same reason cutting and pasting code is bad: I probably won't remember to update in both places. Make it easy on yourself.

    How? Develop good habits, and use them. Write a description of your coding style - naming conventions, indentations, when and where you comment, to get it clear in your mind. For example, I write a comment at the top of a file to describe what it does (but I use CVS to store the change log), at the top of a function to describe inputs, outputs, and, in high level terms, what it does, and at the top of a block of code if it is at all complicated. Pretend you've been given the code and told to fix a segment fault when the user clicks the Whizbang button, and ask yourself how easy it would be to find the code.

  • Eloquence

    A good command of language - the human variety - is essential if you want to be more than a code grinder. Unfortuantely, we developers aren't renowned for our powers of expression. And we do have to write: clear code, descriptive yet succinct comments, and, at least in my experience, most of my bosses want documents on whatever part of the system we're modifying - how it works now and proposals for how to effect the changes we want. With (horrors) real sentences and paragraphs, not just strung together haphazard but with some sort of coherency (how dare they?!)[4]

    I was fortunate in that I grew up without a TV (since we would only have been able to get four channels, I wasn't missing much), so I read a lot; to that I attribute a fairly good command of the language (E&OE). I also got involved with my school paper and have done a lot of writing on my site.

    If don't think your writing or presentation skills are up to par, take some English courses - as electives if you're in school or enroll in a night course at a local college otherwise. They'll be valuable to you and make you more valuable. I used to be shy, I wouldn't say I am any more, but when I'm nervous I stutter. The key for me in presenting to people is knowing my material cold: no more nervousness, and everything goes smoothly. And you have to present things to people all the time, formally or informally: a problem with code to a co-worker, a idea to improve the project to your boss, even telling a joke. And remember that you have to know the rules to break them :).

    Some consider grammar and spelling, especially online, to be irrelevant: if you can understand it, hu karez how its speld (and note I'm differentiating between typos and not knowing how to spell or form sentences)? To me, a spelling or grammar error is like a bad taste in the mouth. It says that the writer doesn't know or care enough to even ensure that the materials that compose their argument are sound, and, sometimes not even intentionally, I place less value in the argument. The medium is the message - trite, true. And if I reject bad writing, how much more, then, are those who professionally deal with documents daily?

    In the same presentation vein, to communicate you want to understand your audience. I joke about managers being lion food, but I talk with my manager and understand his deadlines and requirements, and what his superiors need from him: a programmer that is interested in and respects his superiors (and co-workers)' goals is a valuable asset, because they're focused on a bigger picture than writing "fun" code and trying to convert the company to Lunix.

    If this is the biggest section, it's because people and communication are the biggest neglected area for programmers. Give and ask for frequent feedback (don't wait for reviews). Be the exception.

    How? I sense a theme in these "How?" sections, and it's go and do. Same here: practice. Talk to your mirror if you like. Write a proposal for redesigning your home page. Whatever. And get as much feedback as possible.

  • Debugging

    Your code will have bugs. Being able to quickly hone in on the location, fix the bug, and then write code to ensure it won't happen again is a mark of a great developer. Assert liberally, it costs nothing in a release build. Can't happens do and will. Know how to use the debugger for your platform (Visual's integrated debugger, gdb, DDD, dbx, etc.). In some cases you may have to resort to more primitive means, such as "comment-jitsu", commenting out portions until the code works, especially for (internal) compiler errors, or sprinkling debugging print(f)s in the code (however, even debug statements can throw off the timing of something sensitive like an OS, leading to nasty Heisenbugs).

    How? It's an art form developed by practice. What, you expected me to put something different this time? There is no magic pill. Read your debugger's man page or look at the VC++ menus; learn how to watch and examine variables, set (conditional) breakpoints, examine the call stack.

  • Enthusiasm

    I don't mean jump-up-and-down pep-rally type. Just that if you want to be a good programmer it'll take time. Your own time, usually, because it won't often be the direct result of doing the letter of school assignments or the sort of quantifiable self-improvement that you can count as "work." You have to keep current in your field, just like any other, whether it's by subscribing to magazines (like C++ Users Journal or Dr. Dobbs) or reading news sites. You have to have the kind of attention to detail that can debate and defend what operator+() should return, when to use const, and design choices (yours and others'). The sort of thing they say introverts (INTJ or INTP on the Meyer-Briggs personality test) are good at, if you're into personality tests.

    In short, it won't work if it's just work.

    Now, I'm not advocating you abandon humanity and sleep in favour of coding, although a short period of that - often referred to as larval stage - is reputed to be beneficial (no comment). As I've already said, diverse interests make you a better person, never mind a better developer. But I can talk shop all day, if people let me, and my non-coder friends know that I like to do 16 push-ups during commercials because "it's a nice round number in binary." My most recent project is to set up a site for helping me organize and show to friends photos taken with my digital camera, using a short custom PHP script.

    How? Wait for inspiration to strike then code like a demon (daemon?) Seriously, though, you need to develop (no pun intended) an interest in how computers work and "what can be efficiently automated" and hone your skills through practice.

  • Wizardry

    Despite all that has been mentioned, is there still a "je ne sais quois" that "hackers" have? Unquantifiable, it cannot be found, but rather finds you, an innate wizardliness? Or can anyone, if they want to, become a wizard? Me, I like to think the latter, but fear that the former is true.

Conclusion

So what's my point? Just elitism? I hope not, since there's already enough of that going around. I think the first point is: there is a difference, a big difference between the bad, the good, and the great. If you're a programmer, you can use this list as an informal self-test. If you're hiring programmers, this gives you some idea of what to look for, rather than asking questions about what sort of tree I'd be if I was a tree, which I patently am not. (You might be surprised at how few employers actually get prospective hires to write code; I've been through hundreds of interviews for co-op and not many did. Sure, it's good to get an idea of how people think and solve problems, but it's nice to have some concrete examples of what the employee will be spending most of their time doing too.)

May you be a worthy representative of your profession, whatever it is you do.


[1] I'm going to use the male pronoun. Deal.

[2] I'm sick of all these disclaimers. But if I don't throw them in then someone will tell me e.g. university isn't necessary to be a good developer, and they know so and so who worked at McDonalds / attended DeVry / whatever and then one day saw the light and overnight became the best developer in the world and is now working for $BIGCO and making $BIGBUCKS. Maybe it happens, but it's the exception, not the rule.

[3] Interestingly, practitioners of these professions are regarded as "professionals" while developers are not. Why not? Well, in part because Computer Science is a relatively young discipline, and also because a lack of regulatory bodies (compare the P.Eng. designation for engineers). We need an equivalent P.Dev. (Professional Developer) examination as part of our discipline's maturing process.

[4] Kudos if you caught the irony.

Sponsors

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

Login

Related Links
o Google
o Freshmeat
o robust
o bogo-sort
o this article
o hall of shame
o Larry Wall
o perl
o three virtues of a programmer
o pair programming
o lion food
o code
o RFCs
o FOLDOC
o photograph y
o Introducti on to Algorithms, Second Edition
o O'Reilly
o C++ library reference
o wiki
o code snippets
o CPAN
o vim
o emacs
o cygwin
o fundamenta l question of computer science
o this article
o clone-and- hack coding
o Refactorin g
o Design Patterns
o The Mythical Man-Month
o bottleneck s
o CVS
o freshmeat
o Extreme Programming
o Joel on software
o my school paper
o my site
o Meyer-Brig gs personality test
o larval stage
o site
o hiring programmers
o co-op
o Also by czth


Display: Sort:
Differentiating Developers | 89 comments (77 topical, 12 editorial, 0 hidden)
An example of actual irony! (4.42 / 7) (#1)
by DesiredUsername on Fri Feb 01, 2002 at 10:14:34 AM EST

"I'm a bit of a minimalization freak."

If you don't remember who said this, scroll up several pages until you find it. 8^)

Play 囲碁

Your sig... (none / 0) (#24)
by Shovas on Fri Feb 01, 2002 at 11:54:04 AM EST

Greetings,
"Knee jerk pacifism is not a feasible approach to foreign affairs."
--trhurler
As I glanced over that the first time, I looked at 'is not a feasible approach', looked at 'foreign affairs', and then looked at 'knee jerk pacifism', all in the glancing over the page, probably taking nearly a millisecond.

I thought to myself, ahh yes, knee jerk military action, or knee jerk hawking.

I just found it funny how it was applied against supposed pacifism, yet I took it, at first glance, to naturally be about right-wing hawks. Ahh the inconsistencies of perception!

Farewell,
---
Join the petition: Rusty! Make dumped stories & discussion public!
---
Disagree? Post. Don't mod.
[ Parent ]
Re; *your* sig (none / 0) (#48)
by gblues on Fri Feb 01, 2002 at 05:46:41 PM EST

I suppose the old saying "You have two ears and one mouth. You should listen twice as much as you speak." doesn't apply when you're using a keyboard? Slashdot and Kuro5hin would certainly exemplify this breach.
I may have two ears and one mouth, but I have ten fingers. Therefore I should post ten times as much as I say and five times as much as I hear.

Nathan
... although in retrospect, having sex to the news was probably doomed to fail from the get-go. --squinky
[ Parent ]

Two eyes (none / 0) (#73)
by A Trickster Imp on Sat Feb 02, 2002 at 09:13:44 AM EST

You have two eyes, too, so you should read as much as you hear, and type five times as much code as you read.

...which would explain the last large project I worked on quite well.




[ Parent ]
The difference (3.25 / 4) (#5)
by Pac on Fri Feb 01, 2002 at 10:30:01 AM EST

Were it Monday I would answer that the difference between the developer that can write crisp, clean, bloat-free - perhaps even, gasp, well-documented, tested, and robust - code and a klutz who couldn't implement bogo-sort without a six wizards and a walkthrough is that the former does not exist while the latter all work for me.

Being it Friday, though, I will refrain from spoiling anyone's weekend...

Evolution doesn't take prisoners


ask candidates to write some code (none / 0) (#51)
by svillee on Fri Feb 01, 2002 at 06:58:17 PM EST

...while the latter all work for me.

What actual code did you ask them to write during the hiring process?

I didn't think so. There are plenty of programmers out there who can write robust code, but as long as your main hiring criteria are college degrees and years of experience, you won't recognize them.

[ Parent ]

Write code in an interview? No. (4.00 / 1) (#58)
by phliar on Fri Feb 01, 2002 at 10:15:05 PM EST

What actual code did you ask them to write during the hiring process?
Never. (You don't work for Micros--t, do you?) There are people -- some of the best hackers I've known -- who absolutely could not have done this. (I'd refuse to, but that's just because I'm a crusty old curmudgeon who was hacking when PDP-11s still roamed the earth.)

Besides, think of this: in an interview the longest coherent piece of code a person could write is probably ten or twenty lines. How useful is that? I want someone who can write and maintain well-designed and well-documented systems that have ten or twenty thousand lines.


Faster, faster, until the thrill of...
[ Parent ]

Jugglers (3.00 / 1) (#60)
by blues is dead on Fri Feb 01, 2002 at 10:40:13 PM EST

Well, if you were hiring a juggler, you wouldn't just take his word for it, would you?

The code needn't compile. And you don't have to be watching over her shoulder. Just see how she attacks things.

Someone once related to me the story of working for a fast dot-com. A coworker of his actually implemented a linked list with 30 bugs. My friend realized it was time to leave.

[ Parent ]
Jugglers and Hackers (none / 0) (#63)
by phliar on Fri Feb 01, 2002 at 11:43:33 PM EST

Well, if you were hiring a juggler, you wouldn't just take his word for it, would you?
When I hire a developer, I don't care how fast he can type.

Writing code (in which I include design) is best investigated through sharing and being sensitive and sitting in chairs in special config -- er, sorry, sorry! Those damn management training flashbacks!

I find it more productive to find a large problem and go through a collaborative design exercise. (Hey, I used buzzwords!) The interviewee gets over any anxieties and I see him/her in more of a situation that will arise at work. That also tells me if the person is going to be awestruck or diffident in dealing with any bogosities from senior members of the team.


Faster, faster, until the thrill of...
[ Parent ]

Hmm... (none / 0) (#72)
by blues is dead on Sat Feb 02, 2002 at 09:06:05 AM EST

Well, I don't think we disagree a great deal. When I say 'code', I don't mean typing. I don't type when I'm thinking of how to solve a problem; most of my coding is on paper or mental.

For me, a coding interview question would be an interesting puzzle. Going straight to the keyboard would be an error, unless it's to think about the problem, or because she already knows the answer. The keyboard doesn't even need to be touched, as far as I'm concerned; I just care about the approach.

Now, if your focus is on design, there is nothing wrong with that. But design is influenced by the micro-designs of the things underneathe -- an appreciation that you may need different Strategy patterns for different algorithms, etc.

I will say it's very smart of prospective hires to bring portfolios. Not required, but it can do nothing but help them.

[ Parent ]
need for objectivity (5.00 / 1) (#74)
by svillee on Sat Feb 02, 2002 at 10:35:24 AM EST

...some of the best hackers I've known - who absolutely could not have done this.

I keep hearing about these fantastic programmers who somehow cannot write a dozen lines of actual code on demand. I have been in the business a little over twenty years, and still have not actually met such a person. My suspicion is that these hackers are friends of yours, and your judgment of their abilities is tainted by your friendship.

In an interview the longest coherent piece of code a person could write is probably ten or twenty lines. How useful is that?

The purpose of such a test is not to decide who is a good programmer, but rather to decide who is not a good programmer. I have used these tests when I have hired people. The candidate is given access to the appropriate language manual, i.e., it is not a test of syntax knowledge, but rather a test of problem solving. If the candidate was just having a bad day, he is welcome to come back the next day and I will give him a different test. What I find is that less than 20% of the candidates can actually write the dozen or so lines of correct code. About 50% are unable to write any code at all. And there is no measurable correlation with years of experience claimed on the resume.

So yes, I find it very useful as a way of screening people. The 20% that remain are not necessarily good programmers, but they have passed the first test and are worthy of an actual interview.

There are companies that ask candidates to send in solutions to programming problems. One example is ITA Software. I do not work for them, but I applaud the practice.

[ Parent ]

The 'It'll never happen' syndrome (3.50 / 2) (#7)
by greenrd on Fri Feb 01, 2002 at 10:40:22 AM EST

Assert liberally, it costs nothing in a release build. Can't happens do and will.

Good advice! I haven't gotten into the habit of asserting liberally yet, but in Java I do always write:

catch (Exception ex) {
throw new UnexpectedException (ex);
}

(where UnexpectedException is a subclass of RuntimeException), instead of:

catch (Exception ex) {
// This will never happen
}

which would be a really bad idea. If it never happens, it will cost you nothing except a few seconds typing and a few bytes. If it does happen, it's useful to have an exception, rather than something else go wrong possibly minutes later which makes no sense, until you realise that you commmitted the cardinal sin - ignoring an exception which shouldn't have been ignored.


"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes

Warnings (none / 0) (#11)
by blues is dead on Fri Feb 01, 2002 at 10:56:35 AM EST

Doesn't your compiler flag a warning when you do this? Catching RuntimeException doesn't throw a warning, but catching plain Exception does.

At least Jikes does this; jdk 1.3 downwards are not as compliant.

A firm problem with just catching plain Exception is that InterruptedException is a direct subclass. I hate that, because if you want to kill a thread safely, you don't want InterruptedException to be caught and the thread to stay alive.

InterruptedException is not a subclass of RuntimeException, so this problem isn't encountered when you catch RuntimeException.

Out of curiosity, why do you wrap runtime exceptions into UnexpectedException? That might be very good practice, I'm just wondering your reasons for this.



[ Parent ]
Because (none / 0) (#26)
by greenrd on Fri Feb 01, 2002 at 12:10:47 PM EST

Out of curiosity, why do you wrap runtime exceptions into UnexpectedException?

Because I might be overriding a method that has no throws clause, therefore I'm not allowed to throw say a NoSuchFieldException if I'm using reflection - but I want to do something with it, not just ignore it.

This mini-pattern is so common that in JDK1.4 Sun is making all throwables in the JDK nestable, so you can just say:

throw new RuntimeException (ex);

to wrap one exception in another.

You can still catch an InterruptedException this way if you either (a) put the catch (InterruptedException ..) before the more general catches, because earlier or inner catch statements have priority, or (b) remember to unwrap the exception later and check if it's an InterruptedException.


"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
[ Parent ]

Interestingly, though (none / 0) (#27)
by aphrael on Fri Feb 01, 2002 at 12:17:38 PM EST

I find that there is a set of exceptions that i always ignore, and with good reason. :)

One piece of code that i'm involved with walks through the windows registry building up a list of properly registered interfaces. It's not uncommon to encounter a few improperly registered interfaces; when that happens, the code that is trying to read the value for a certain key throws. I ignore the throw, and my code has a comment saying 'it's perfectly safe if [x] throws because of [y]'. :)

[ Parent ]

help the poor american out (3.33 / 3) (#9)
by karb on Fri Feb 01, 2002 at 10:47:47 AM EST

what's the difference between college and university? I'm assuming college is probably a tech school, and university is what we refer to as 'college.'

In the states, I think there are some technical differences between them ... but for a student, it's pretty much the same thing.
--
Who is the geek who would risk his neck for his brother geek?

C vs U (4.00 / 1) (#13)
by garlic on Fri Feb 01, 2002 at 11:03:50 AM EST

U.S.: a college has a focus. i.e. College of Arts and Science, College of Nursing, College of Engineering, Business College. A university contains multiple colleges.

HUSI challenge: post 4 troll diaries on husi without being outed as a Kuron, or having the diaries deleted or moved by admins.
[ Parent ]

Graduate studies? (none / 0) (#67)
by JWhiton on Sat Feb 02, 2002 at 02:19:03 AM EST

I'm going to go out on a limb here and venture a guess. I think that colleges in the US are classified as being primarily places of Undergraduate study. Y'know, for a bachelor's degree. Whereas Universities are places that have graduate programs.

Although other English-speaking besides the US seem to use the word "university" in the same context that people in the US use "college". For example, they might say "I'm going to university next fall" or "Jeremiah lost his leg back at university." Personally this irks me to no end, but then again so do those extra u's that the metric English-speaking nations throw in their words. :P

Now, for the disclaimer: I've yet to attend any sort of college/unversity and this is all just speculation on my part.

[ Parent ]
nope. (none / 0) (#86)
by garlic on Mon Feb 04, 2002 at 02:21:49 PM EST

no, you're wrong. The technical difference is as I described, but most US people just call it "going to college"

HUSI challenge: post 4 troll diaries on husi without being outed as a Kuron, or having the diaries deleted or moved by admins.
[ Parent ]

University vs. College (in Canada) (none / 0) (#79)
by janra on Sat Feb 02, 2002 at 03:56:07 PM EST

Universities can issue bachelor of x degrees (and master and PhD), while colleges can at most issue 2 year certificate programs and offer 1st & 2nd year bachelor program courses, for transfer credit to a university. Some colleges will have some sort of a deal with a university where they can issue bachelor degrees, but strictly speaking the university is the one issuing the degree and the college is providing classroom space, lab space, profs, etc. The university has to check up on the program to ensure that the program meets their standards, though, because the degree has their name on it.

At least, all the ones I've ever looked at.


--
Discuss the art and craft of writing
That's the problem with world domination... Nobody is willing to wait for it anymore, work slowly towards it, drink more and enjoy the ride more.
[ Parent ]
Close, but not quite correct (none / 0) (#81)
by Rizzen on Sun Feb 03, 2002 at 02:13:35 AM EST

In Canada, colleges offer <= 2 year programmes. Generally, the 1 year programmes are certificate programmes, and the 2 year programmes are diploma programmes.

Universities offer degrees, whether they be Bachelor, Master, or Philosopher.

Technical insitutues and trade schools are different and can be combined/housed on the same campus as colleges or universities (and some places have colleges on university campuses).

Then, there are University Colleges which can offer tech/trade programmes, college certs/diplomas, and university degrees, all on the same campus, under the same instution name.

Thus, in Canada, college is *very* different from university.

What Americans consider "college" (as in College of Sciences) is known as a School or Faculty up here (as in School of Arts or Faculty of Science).

"And know you know ... the rest of the story." -- Paul Harvey
The years of peak mental activity are undoubtedly those between the ages of 4 and 18. At age four, we know all the questions; at eighteen, all the answers.
[ Parent ]
Guilds (3.66 / 3) (#14)
by blues is dead on Fri Feb 01, 2002 at 11:06:37 AM EST

We need an equivalent P.Dev. (Professional Developer) examination as part of our discipline's maturing process.
Hidden in a footnote. This is the incendiary point of them all. In fact, you've been stuffing the footnotes with these things. :-)

Anyway, as everyone knows, discipline is for disciples.

I'm all for certification (none / 0) (#19)
by porkchop_d_clown on Fri Feb 01, 2002 at 11:40:39 AM EST

I think certs are a great way to tell the "can"s from the "cannot"s - but for them to be useful, the technical environment has to be stable long enought for a cert to be valid for longer than one summer. I figure that will happen about 5 years after Moore's Law runs out of gas.



People who think "clown" is an insult have never met any.
[ Parent ]
Invoking spectre of Peopleware (none / 0) (#21)
by blues is dead on Fri Feb 01, 2002 at 11:47:47 AM EST

Here is DeMarco's argument against certification. Tom DeMarco was co-author of Peopleware, which I have right in front of me, and is likely the best book on managing software dev after Mythical Man-Month.

He argues:

Though the rationale for certification is always societal good, the real objective is different: siezure of power.


[ Parent ]
Certification (4.00 / 1) (#25)
by vambo rool on Fri Feb 01, 2002 at 12:05:09 PM EST

Be careful. Certifications have to be done by someone who is independent and neutral. Yes, you can read that as NOT MCSE, CCNE, &c &c. All that does, especially the MCSE, is show that you've been indoctrinated into the Microsoft (or whomever) way of doing things. It's less true for hardware, although it still applies.

To be CNE, you need to understand network topologies, protocols, &c, which *should* be independent of vendor. To be CCNE, you need to understand the Cisco-specific way of instituting that topology.

Likewise, for a CSE, you need to understand methods, algorithms, stacks, queues, lists, sorts, pointers, inheritance, polymorphism, and on and on and on. You do not, necessarily, need to understand the Microsoft Windows API. That makes you a MCSE, not a CSE. From the people I've dealt with, all that an MCSE says about you is that you've got the $400 per year (or whatever it is nowadays) to keep the certificate current.



[ Parent ]
Ah HA! TLA trouble!! (none / 0) (#54)
by bADlOGIN on Fri Feb 01, 2002 at 08:01:24 PM EST

MCSE stands for Microsoft Certified Systems Engineer. MCSEs do IS work like installing patches and service packs, setting up virus shield programs, fighting the latest NIMDA or "I LOVE YOU" and the like. An MCSE certificate means, "Microsoft says I know my way around Windows". They're all quite nice people, but they can't tell you the merits/costs of differnet sort algorithms, know inheritance is something that would let them quit thier job if they had a rich relative, and would say polymorphism was an attribute on their favorite AD&D character sheet had back when they played it in middle school:)
Sigs are stupid and waste bandwidth.
[ Parent ]
You're dethpicable. (none / 0) (#57)
by vambo rool on Fri Feb 01, 2002 at 10:11:16 PM EST

You know, I always thought that meant MC Software Engineer.

Shoot him now, shoot him now.



[ Parent ]
Actually... (5.00 / 1) (#66)
by fanatic on Sat Feb 02, 2002 at 01:59:21 AM EST

Microsoft Certified Solitaire Engineer.

[ Parent ]
Also known as: (5.00 / 1) (#87)
by bADlOGIN on Mon Feb 04, 2002 at 04:26:20 PM EST

Minesweeper Consultant, Solitare Expert
Sigs are stupid and waste bandwidth.
[ Parent ]
intuitively obvious (4.60 / 5) (#16)
by wiredog on Fri Feb 01, 2002 at 11:16:58 AM EST

This is a response to a comment by the author which he posted as editorial, darnit.

Is it all so intuitively obvious that I shouldn't have bothered writing it down?

To those of us who've been doing this a while, yes. But not to the students, or to the people newly in their first job. I kept nodding my head and saying "Yeah, I've seen that."

Someday I'm going to sit down and write an article, with code samples (if I can find them) about the 100,000 line, uncommented, C Program From Hell. Everything was global. One comment (which I treasure in my memory) was "Why did I do this?". On the bright side, once I figured the program out, I was unfireable.

Peoples Front To Reunite Gondwanaland: "Stop the Laurasian Separatist Movement!"

answered your own question... (none / 0) (#38)
by mulvaney on Fri Feb 01, 2002 at 02:48:22 PM EST

One comment (which I treasure in my memory) was "Why did I do this?".

I think the answer is:

...once I figured the program out, I was unfireable.

On a related note, I've written that comment a few times myselft. Usually it is because I failed to comment something strange the first time I wrote it, and couldn't figure it out when I looked at it later. I hope I went back and figured it out, and then either explained it or removed it...

-Mike

PS Then again, if they fire me, they deserve all that unmaintainable code. :)

[ Parent ]

No no no! (none / 0) (#55)
by wiredog on Fri Feb 01, 2002 at 08:56:57 PM EST

That wasn't my comment, it was the original authors. That was my first job and I learned quite a bit from figuring out that guy's code. Mostly what to avoid doing. Comment everything, even if it looks obvious, because 6 months from now it may not look obvious, and the guy who comes after you may not find it obvious either. Unless you are referring to movement, or graphing, don't name variables "x" or "y". Global data, in large amounts, is Evil, and should be avoided at all costs. The only system (as opposed to file) global function is main(). #define should be used in moderation.

Peoples Front To Reunite Gondwanaland: "Stop the Laurasian Separatist Movement!"
[ Parent ]
Response to comments (3.33 / 3) (#20)
by czth on Fri Feb 01, 2002 at 11:47:23 AM EST

greenrd: Your Java remarks look like an extension of Henry Spencer's sixth commandment (The Ten Commandments for C Programmers). The idea of having an empty catch block scares me, too :).

kubalaa says there's too much personal information. The other extreme is too much airy theorizing, which I guess I avoided ;). I think in an article like this it's good for people to know where I'm coming from. I put a little bit of my soul into my articles, so please handle it with care. And I do have quite the link farm, don't I? But it's proportial to the size of the article, which, as DesiredUsername and j1mmy point out is pretty big (and I make no apologies). I have seen too many MLPs and too few worthwhile articles recently; I have certain ideas on certain topics, and I think k5 is a great forum for discussion with my peers.

Durn. "Greatful" slipped by. Hopefully an editor can fix that, too, as well as the other thinko/typo that slipped by me. Yes, I read it over several times and even had some others look it over, but things to sneak in, even to published works at publishing houses where editors pay people to check. There's also a superfluous "'s" (after the parenthetical note about personality tests).

To karb: yes, "college" here is more of a tech school, and "university" you might also call college in the US. In situations where programs are offered at each (Computer Science being my prime target), I'm skeptical of the college version.

j1mmy: I agree about "I think", I tell people the same thing, I hope I didn't overuse it. And I also have to endure a lot of legacy code, which is held sacrosanct and can't be changed (for political raisins). I do overuse notes in parentheses, I admit it, but I think most in the article are justified, although some could be moved into the main text. And I think the conclusion is warranted, maybe not labelled as such but I wanted to set it off from the list (perhaps labelling it something else would have been better). Thanks for your insights, they will help me improve my writing style.

blues: Haha, you're absolutely right; actually, I was thinking of writing a whole article about the idea of a P.Dev., but didn't think I had enough material. I may look into it further (find out more about the P.Eng., see which existing regional bodies (ACM?) would be competent and suited to administer a P.Dev., etc.) and write the article yet. Discipline for disciples? Discipline is for everyone, athletes, writers, coders, whatever.

wiredog: I've only had to deal with the 20,000 line module from hell, although the program is about 1,010,000 lines and growing (that doesn't include libraries to which we have the source). It bothers me immensely that better design and coding could make it probably a quarter of that.

By the way... I'm curious and haven't been able to find it on the site: what determines if an article is posted to the FP? A certain percentage of "+1, FP" votes?

Also, a question: would it be better if I write responses as (here, about 6) individual comments replying directly to the source, or is this format acceptable?

Finally: I posted some editorial comments about some errors (extra "'s", the extra "a" in the first paragraph, and "greatful" someone else mentioned); now that the story is posted, can those not be fixed, or will the editors get to them when they have time?

czth

about scoop... (4.00 / 1) (#28)
by hurstdog on Fri Feb 01, 2002 at 12:25:11 PM EST

By the way... I'm curious and haven't been able to find it on the site: what determines if an article is posted to the FP? A certain percentage of "+1, FP" votes?

It needs to have a majority of Front Page votes, when it hits the threshold (which is 80 votes, right now). So if it has a score of +80, and it has mostly +1 section votes, it goes to section, if mostly +1 FP votes, to FP. If -20 votes, then it drops. Also, if a total of 350 people vote on it and its not yet at a threshold, scoop gives high rated comments attached to the story a +.3 bonus to the score, and low rated -.3 (the +-.3's might be wrong, I haven't checked lately).

Finally: I posted some editorial comments about some errors (extra "'s", the extra "a" in the first paragraph, and "greatful" someone else mentioned); now that the story is posted, can those not be fixed, or will the editors get to them when they have time?

We can edit stories anytime, I just fixed the errors you speak about, also one I found :) ( from the O'Reilly from the stable -> from the O'Reilly stable). Reply if you need any more fixed.



[ Parent ]
A word or two on SCM (3.50 / 2) (#22)
by imrdkl on Fri Feb 01, 2002 at 11:47:56 AM EST

It sucks. Yes. You didn't mention it formally, perhaps for that very reason. :) But it's worth learning something about, especially if you have to work on a large project. There are plenty of source control tools out there, and some are better than others, but the underlying concepts are pretty much the same. Reproduceability, change management, and release engineering.

Most universities still do not teach the practice and methods of SCM, yet it is by far the most important part of good software development.

SCM can't be readily learned from a book, as you allude to with coding. It must be done, regularly and methodically, to understand it and gain the value it offers. So, check-in early, and check-in often, as they say. And no changes without a ticket. And no tickets without approval. And... ad nauseum. But important.

bland.... (3.20 / 5) (#23)
by kimpton on Fri Feb 01, 2002 at 11:49:27 AM EST

The article gave me the impression that the writer was more interested in showing you what a good programmer he was, rather than objectively describing an ideal programmer. Too many sections had examples of what the writer did to qualify for that 'perfect programmer' criteria.

It didn't really say anything that interesting or original either. Roughly the sections are:

Be able to work without support.
Be a fast learner
Specialize in certain fields
Reuse code
Use source control
keep code style consistent
Be able to communicate
Be keen

Bland assertions that could be applied to most working environments.

Minimal Coding (4.40 / 5) (#30)
by dachshund on Fri Feb 01, 2002 at 12:30:14 PM EST

I used to be very much in your camp. Code should be tight and elegant, I felt, or... I don't know. The compiler wouldn't like it? It'd run slower? I wouldn't understand it anymore if a function stretched over two page-downs? I'm not saying I wrote messy code, but if I could put an assignment and a test into one line, I felt that I was doing the right thing. If I could test for a condition by simply writing "if (!foobar) ..." instead of "if (foobar == NULL) ...", this was the way it should be done.

Then I started working at a research lab, with people who've been writing code since before the the teletype, and my opinion swung 180 degrees in the other direction. It's not that all of the researchers' code was unreadable (though it often was), or that it made the examples in your "hall of shame" look like good solid engineering (though, unfortunately, most of it did.) What got me was when I became responsible for transferring it into production, and I was able to contrast this "elegant, tight" code (even the decent stuff) with the effusive, hyper-detailed developer's code.

At first the development code seemed hopelessly overdone. A simple function could expand by a factor of three (though most of this was comments) when it went into development, but gradually I came to appreciate it. As far as I'm concerned, I'll take a clear-- even space consuming-- comment before each action, over a tight, one-glance (should) tell you everything knot, anyday. Because it's in those elegant constructs that the glitches hide. And I have no problem if a code file reads like a manual, or if I have to move my eyes a little further in order to cover an entire function. Oftentimes, it doesn't require more time to code like this (good code writing is often more, er, brain-bound than I/O-bound.)

Everyone has their own style. I like mine, and I think it's clean, easy to debug, and ridiculously easy for others to work on. But I suppose others might find it aesthetically insulting. My point (I think I have one) is that neither style is really a requirement of "good programming", except in the minds of some programmers.

Humans have limited short-term memory (4.00 / 1) (#64)
by valency on Sat Feb 02, 2002 at 12:02:24 AM EST

The size of your short term memory is (unfortunately) a huge factor in your programming productivity.

Long functions that stretch over pages require keystrokes and additional eye-to-page resynchronization. Across the millions of such operations you perform in a single day, this added lag makes a huge difference.

If you were just doing rote code translation, this probably didn't matter much -- that job is mostly a top-to-bottom pass through a file.

Comments are an entirely different matter -- I advocate liberal commenting (but usually just one large comment at the top of the function). Tight code can be read and modified more quickly though.

---
If you disagree, and somebody has already posted the exact rebuttal that you would use: moderate, don't post.
[ Parent ]

Maybe (4.00 / 1) (#77)
by dachshund on Sat Feb 02, 2002 at 01:25:04 PM EST

The size of your short term memory is (unfortunately) a huge factor in your programming productivity.

A lot of people will disagree with me on this, but I believe the step-by-step approach is the best way to deal with the short-term memory problem. Certainly, you can just dive into a function and code the entire thing quickly enough that you don't lose track of what you were doing. However, for some more complicated applications, that's not necessarily a bulletproof approach.

Laying a function out as a set of steps can be extremely beneficial if you're worried about losing your concentration. You can be interrupted in the middle of writing the code, and reorient yourself quickly. Bug fixes are much more straightforward.

I was concerned about many of the same things that you argue, when I first adopted this approach. Retrospectively, most of my fears appear not to have been justified. Whether rewriting code, or writing from scratch, I feel that I've gained a lot from a more structured approach to coding. But heck, that's just me.

[ Parent ]

Correct, but... (4.88 / 9) (#31)
by trhurler on Fri Feb 01, 2002 at 12:41:03 PM EST

You missed the interesting bits, I think.

First of all, there are at least two variants of the "great programmer." One of them, the "obsessive technophile," usually has horrendous language and interpersonal skills, writes godawful code, but produces it in large quantities and with few mistakes, and is best kept hidden in a closet. The other is a fanatic about proper written language, whether natural or otherwise. He may have quirks that differentiate his text from "the standard way of doing things," but he's consistent, readable, and in person, is fun enough to hang around with. He doesn't produce quite as much code per hour, but he fits into organizations a lot easier and is less prone to "not invented here" syndrome.

Second, "wizardry" is primarily just focused expertise. Yes, I am fully capable of writing Unix kernel code, or producing a new operating system from scratch. I can't fix a Windows driver problem unless it is trivially easy, though - because I never cared to learn. I had better things to do. There is a second component you need to reach the highest levels - theoretical knowledge and knowledge of what has been done before. This does not necessarily mean school, but that is an easy way to get it. No, your mastery of pointers and linked lists is not what I'm talking about.

In any case, the author is dead wrong about regulatory bodies. Simply put, civil engineering doesn't change all that much. You can "test" for competence there. You cannot test for competence in software development, and you never will be able to do so. Maybe you could test for specific knowledge, such as "can he develop C programs on BSD systems?" but that's no basis for a regulatory scheme, as it leaves too many exceptions - the majority of the industry is always in "new" stuff, and probably always will be due to the malleable nature of the world we work in.

By the way, one thing about those who rise to the top of the heap: they always(and I do mean ALWAYS) find friends who know more than them on their way up. Not teachers(though a teacher could qualify as a friend also,) not objects of worship, but friends. People to sit around and shoot the shit with for hours on end, people to get help from, people to help out where you can, and so on. You will almost certainly not rise much beyond the best of your friends, until you're really good. Then, you can do more, perhaps by yourself, perhaps by reading others' work, and so on.

The fundamental skill of programming, though, is no different from the fundamental skill of mathematics. Abstract thinking. Grunt programmers are like the human calculators of old. Great programmers do that stuff, but they live in a larger world, and they create it as they go. They follow patterns they've seen and admired, but they also create entirely new things. Learning math won't make you as superior a programmer as mathematicians would have you believe, but if you can't do both given time and effort, you're probably not going to be all that great at either one.

The only other thing I will say is that the key points of the story, while true, are not absolutes. For example, I don't use code snippets. I tend to use others' libraries instead, or else produce whole libraries of my own, and I tend to solve a problem in a generic enough manner that I can hit the next nail with the same hammer on a much bigger scale than just "a snippet." I have a small set of good books, but I ignore most of the (IMO crap) books that the Internet boom generation uses. (I prefer the Addison-Wesley professional computing series to O'Reilly, for example; I don't need to be talked at like an idiot.) If you're trying to follow some premade cookbook recipe for great programming, you won't get there.

--
'God dammit, your posts make me hard.' --LilDebbie

'Code morality' (5.00 / 2) (#43)
by schlouse on Fri Feb 01, 2002 at 04:23:43 PM EST

Your comments on the variants of programmers you've observed is interesting. One thing I've been mentally toying with for several years is the concept of a kind of 'code morality'. Coders with bad code morality are much more likely to not have the discipline to avoid coding themselves into the center of a minefield. On the other hand, coders with good code morality may not be able to always avoid laying minefields, but at least they'll put a flag near each mine and not end up in the middle of it. Code produced by individuals with bad code morality is much more likely to be stuff that you look at and say "we need to throw this shit away", but have a hard time justifying it because it does actually work.

It seems to me that young programmers are at an unstable equilibrium and they can roll one of the two ways, depending on the code morality of the person who took them under their wing. Unfortunately, in the bad case, once this happens, it appears to be somewhat permanent. It also seems to me that workers not in it for the enjoyment of programming are much more likely to go to the dark side. In my experience H1B's that see technology as a ticket to the USA can have particularly bad code morality.

Mark S.

[ Parent ]

One feature of good programmers (4.83 / 6) (#45)
by Simon Kinahan on Fri Feb 01, 2002 at 04:48:01 PM EST

Is that they delete code. They don't comment it out. They certainly don't leave unused code hanging around. If I understand you correctly, this is a major element of "code morality".

One of the most satisfying feelings in programming is to select a few hours work and press "delete" then have the whole thing working again, and better, within a few minutes. In my experience, people who don't delete code are a danger to those around them.

Simon

If you disagree, post, don't moderate
[ Parent ]
Re: One feature of good programmers (none / 0) (#46)
by schlouse on Fri Feb 01, 2002 at 05:09:53 PM EST

Yes, that's one of my pet peeves too. There's certainly no use for huge #if 0 blocks or commented-out code hanging around cluttering things up because somebody's too lazy to remove it. If we need the old code again, well, that's what source control is for!

Rarely, in my experience at least, is the whole picture fully understood at initial design time for a project, even for one of small to medium size. When it is finally understood, the differences between programmers really stand out because the good programmers do exactly what you do (ie refactor small modules), while not-so-good ones embark on a frenzied hacking session scattered through several intertwined modules. And after you get several of the modules really solid, it's like a snowball turning into an avalanche and before you know it, you're done. Well that's the theory, anyways :-)

Mark S.

[ Parent ]

Goddammit! (5.00 / 1) (#53)
by jacob on Fri Feb 01, 2002 at 07:25:42 PM EST

Stop saying things I agree with! I'll have to conclude that I'm an asshole, too!

Just kidding.



--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]
-1... (3.00 / 6) (#32)
by bugmaster on Fri Feb 01, 2002 at 01:16:08 PM EST

...Is what I would vote for this. The article basically sounds like an "I am better than you, and here's why" rant. Notice that you might in fact be a better coder than everyone else on k5; that is not really relevant here. What is relevant is that your advice, while sound, comes off as elitist and bland. I personally think that one very important thing that a programmer should learn is,
Not everyone is as smart as you are. Deal.
Once the "hey, maybe I am not a genius" mentality sets in, it becomes much easier to notice your own mistakes - and people seem to generally like you more.
>|<*:=
I think you've got it the wrong way round... (none / 0) (#35)
by Stick on Fri Feb 01, 2002 at 02:04:52 PM EST

Perhaps you're the one thinking he's better than you. Think about it.

I actually feel czth did a good job examining what makes a programmer good without sounding like some teenage elitist BSD user. You try writing an article like this and avoid sounding in some way like you're bragging. It's not an easy task.


---
Stick, thine posts bring light to mine eyes, tingles to my loins. Yea, each moment I sit, my monitor before me, waiting, yearning, needing your prose to make the moment complete. - Joh3n
[ Parent ]
Er, that was my point... (none / 0) (#36)
by bugmaster on Fri Feb 01, 2002 at 02:41:21 PM EST

...to me, it seemed like he was bragging, albeit in a very articulate manner. And, like I said, it's probably true that he is a better coder than most of us here... which is irrelevant, as I said in my earlier comment.
>|<*:=
[ Parent ]
Advice (none / 0) (#39)
by ucblockhead on Fri Feb 01, 2002 at 02:50:53 PM EST

One would hope that anyone giving advice on coding was a better than average developer.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
That's your perception then (none / 0) (#41)
by Stick on Fri Feb 01, 2002 at 03:08:57 PM EST

But to me, I didn't feel that he was bragging, and he doesn't come off as a better programmer than most people here to me (not that he might not be, but he didn't give any information in the article to me that he was even above my level). And I'm sure if he wanted to brag he could have done a much better job of it. But again, you try writing an article like that without some people feeling like the writer is an arrogant dick. I think there's some penis envy going on here.


---
Stick, thine posts bring light to mine eyes, tingles to my loins. Yea, each moment I sit, my monitor before me, waiting, yearning, needing your prose to make the moment complete. - Joh3n
[ Parent ]
Curse you, biology (4.00 / 1) (#44)
by bugmaster on Fri Feb 01, 2002 at 04:30:22 PM EST

It would be extra-ironic if I were in fact female... But I'm not, so I guess the political warfare aspect of this comment is wasted.

Anyways, the reason I am suspicious of writeups like this one is because I have experienced them before; in fact, I joined my previous company based on a series of similar writeups. Inevitably, people who post in the form of, "you must follow these 10 rules in order to become a great programmer", turn out to be much more competent at writing English than they are at programming. Not that there's anything wrong with being able to write in English. Also inevitably, when I met the writeup authors, they turned out to be jerks.

So, having been burned by experience before, I am now very suspicious of anyone who tries to hand me a mandate for better coding. I'd have to see something more than an attractive writeup in order to be convinced.
>|<*:=
[ Parent ]

Altered perception (3.00 / 2) (#33)
by czth on Fri Feb 01, 2002 at 01:48:27 PM EST

I've heard a few arguments about the "P.Dev." certification idea here (especially blues is dead's link to DeMarco's argument), and I've changed my mind about it: I was most swayed by the points that it's too much of a moving target, the main reasons for it are control and exclusion, and that companies should do their own screening. Thanks for your comments.

I disagree with kimpton's comment that the article is bland and boils down to some short generally-applicable points; I provide the details to go beyond the general.

Some also accuse me of setting myself up as the perfect programmer. I think I'm a good programmer - privileged to be part a great company - with potential to be great; time will tell. Yes, I gave personal examples; I don't have anyone else's experience to share :). Forgive me if I appeared boastful. I am good at certain things. While pride is bad, so is false modesty. I like to provide links and let the reader judge for themselves.

I like minimal code myself but I recognize the need for more documentation ("document for the average coder" as I said in the article) and I still don't think that comments or code should be written in the equivalent of "baby talk."

trhurler doesn't really disagree with me I don't think. I agree that aptitude ("fluid intelligence") and the general principles and techniques you get from experience are more important than knowing e.g. how to use a particular API. And as it happens, I'm a BMath. I hope I never asserted any point as an absolute (heaven forbid anyone say anything is absolute, or true...!) just gave examples and suggestions.

czth

beyond the general? (none / 0) (#68)
by kimpton on Sat Feb 02, 2002 at 07:31:13 AM EST

I disagree with kimpton's comment that the article is bland and boils down to some short generally-applicable points; I provide the details to go beyond the general.

Can you give me an example where the details take the point beyond the general?

[ Parent ]
Code Reviews (4.25 / 4) (#34)
by octothorpe on Fri Feb 01, 2002 at 01:57:46 PM EST

One of the best ways to learn good coding that I've seen is to participate in code reviews. I know that this is not an uncommon practice but it's been so useful to me that I thought I should talk about it. When a project gets roughly to an 'alpha' state, we schedule a code review with the whole team. The way we work it is to print-out the code a week or so before hand, give a copy to everyone in the team and scedule a conference room for two hours. Teams are made up of about five to ten programmers who all work on the same product. Everyone comes to the review with their own copy of the code, hopefully liberally marked up with a red pen and we sit and go through the code line-by-line. It's understood that reviewers are to be as brutal as they can and shouldn't hold back out of politeness or respect. If it's your code it can be an ego brusing experience but you always come out of it with a better understanding of your project and programming in general.

Enjoyed (3.00 / 2) (#37)
by webwench on Fri Feb 01, 2002 at 02:41:29 PM EST

I have to say I really enjoyed this article, especially some of the links included.

I'm a programmer who is proficient in other languages than C++, and have just been assigned to an in-progress C++ project. I read the "hall of shame" links and am ashamed to say that I didn't know a few of them (all my example texts, and the others on my project, have used #include <something.h> for example). And so much of the included examples and documentation are intended for average-and-above C++ people. The problem is moving from newbie to at least average -- that's where the fun comes in.



<whatever.h> (4.00 / 1) (#40)
by czth on Fri Feb 01, 2002 at 02:53:21 PM EST

It isn't such a big deal, but combined with everything else it doesn't help. Using e.g. <fstream.h> was once correct, I think, but no longer. And <cmath> should be preferred to <math.h> etc. The "Effective C++" book by Scott Meyers (link on the hall of shame page) also has a good set of do's and don'ts for C++, with explanations, and Marshall Cline's C++ FAQ lite is also very good.

I should have written a disclaimer that the article's examples are very C/C++-centric - not because that's all I know but because that's what I've been working on most recently (and we don't even want to talk about bad Perl code ;) and C is fairly well known, even by those that don't use it at work.

czth

[ Parent ]

hall of shame (none / 0) (#42)
by ucblockhead on Fri Feb 01, 2002 at 03:37:44 PM EST

Not only did <fstream.h> use to be correct, but it was the only way to do it, not all that long ago. (Five years or so?)

There were a few entries in your hall of shame that are like that. I personally have trouble remembering not to do "if(foo) delete foo" for the simple reason that I coded in C++ for ten years before that become ok. "new" didn't always throw an exception.

It could be that some of that "bad" code in the wild was written before it was bad. This is especially true because not all compilers fully meet the standard. You mention a bare "return;" at the end of a function. I found that amusing, because just the other day, Visual C++ forced me to write code like this:

#ifdef _MSC
#define VOID_FUNC int
#define RETURN_VOID return 0
#else
#define VOID_FUNC void
#define RETURN_VOID return
#endif
VOID_FUNC Foobar()
{

//do stuff
RETURN_VOID;
}

But really, I've seen much, much worse stuff "in the wild" then anything there. Look at Microsoft's ATL, for example, to see a living, breathing example of why you shouldn't use #defines in modern code.

And then there was the code that not only used 'i' as a global variable, but also used it as a local in some functions, while using the global version to pass data into other functions!


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

_Here's_ the Diff... (3.33 / 3) (#47)
by jazman_777 on Fri Feb 01, 2002 at 05:14:47 PM EST

What's the difference between the developer that can write crisp, clean, bloat-free - perhaps even, gasp, well-documented, tested, and robust - code and a klutz who couldn't implement bogo-sort without six wizards and a walkthrough?

The former doesn't exist but in theory, and the latter is all too prevalent in reality.

A reading list (4.00 / 1) (#49)
by selkirk on Fri Feb 01, 2002 at 06:01:05 PM EST

Nice article.

Here is my short list of books that every programmer should read:

Refactoring. The chapter on code smells should be beaten into every junior programmer until they can recite it from memory. Focus on chapters 1 through 5.

Design Patterns. The patterns can be derived using fundamental principles, but its handy to have the catalog. The refactoring book mentions some patterns from this book by name.

Fundamentals of Object-Oriented Design in UML. This is a good companion book to the previous two, although it doesn't specifically mention patterns or refactoring. You can skim Part II on UML, the real meat of the book is in Part III: The principles of OO Design. This part helps you understand why things are done the way they are in Design Patterns and Refactoring.

For an alternative view of the profession including licensing see Software Craftsmanship



Got any online links (none / 0) (#50)
by Stick on Fri Feb 01, 2002 at 06:40:14 PM EST

I'm just after paying for a bunch of books and I'm being chased for rent money, so money is an issue right now.


---
Stick, thine posts bring light to mine eyes, tingles to my loins. Yea, each moment I sit, my monitor before me, waiting, yearning, needing your prose to make the moment complete. - Joh3n
[ Parent ]
UML (4.66 / 3) (#71)
by A Trickster Imp on Sat Feb 02, 2002 at 09:03:39 AM EST

I've greatly soured on UML after using it on two large projects in a row (buzzword...must use UML...must use UML...)

As for describing a list of features, it is a lot of bloated extra work where a list on a sheet of paper would be just as good.

As far as capturing complex interaction problems, well, we still stumbled into all of them anyway.

As far as preventing massive design flaws early on, well, we still had problems because of things no one thought of.

Still, since it's a buzzword, I list it on my resume and brag about it.




[ Parent ]
darn... (5.00 / 1) (#52)
by xriso on Fri Feb 01, 2002 at 06:59:46 PM EST

Here I was expecting an article about the Calculus of developers! (differentiating.)
--
*** Quits: xriso:#kuro5hin (Forever)
Waaay back (2.00 / 1) (#56)
by phliar on Fri Feb 01, 2002 at 10:06:37 PM EST

...function is "pure" C and all the variables are waaaaay back at the top of the function
It saddens me how many people don't know that variables can be declared at the beginning of every block.


Faster, faster, until the thrill of...

The problem with trying to pin it down... (4.50 / 2) (#59)
by Scandal on Fri Feb 01, 2002 at 10:36:58 PM EST

Eventually, I find someone who fits outside the mold I've constructed.

To me, the best developers, the really good ones, have a single thought in mind throughout the development process, and that is: "How's the next guy going to see this?"

You can easily break this down into every rule anyone has ever thought of, but behind all those ideas, if the developer is thinking of the next schmoe who's going to be stuck debugging this code, then he'll already be following all the rules naturally.

For example, is this bit of code easy to read or difficult to understand? If it's difficult, does it need to be, or can I simplify it? If I cannot simplify it, can I explain it enough to help the next guy understand why I had to write it this way, and maybe provide hints as to how it might be made simpler?

Consistent coding rules and style follows from this, too. If the next guy always sees that your global variables begin with "g_" and your member variables begin with "m_", for example, and you never waiver from that, then that's one less thing the next guy has to think about. Even if he doesn't care, you'll know that you're not putting roadblocks to his understanding of the program flow in place.

Another example might be in the development of a library or API. How easy is it for the user (the next guy) of this library to use it? What does the user really need to be able to do, and are you forcing him to do other things beyond merely using the library?

For example, I worked on one project where, with every function call, I was required to specify about ten different arguments which were specific to the communication mechanism (such as transmission speed, various delay parameters, etc.), none of which I ever varied. The developer in question was very, very proud of his API, but I wrote macros to pass in merely the relevant arguments (the data to be transmitted), and all the rest of the arguments were filled in with fixed values which never changed from call to call. So why include them? Imagine if, with every file operation, you had to specify the precise block on the hard drive where the data was located, rather than using a file handle! That's basically what I was being asked to do with this data transmission between two computers.

While this architect was capable of providing a great deal of flexibility, he never once had to use his own API without seeing the cleverness of it all, and thus he never appreciated how much extra, unnecessary data he was forcing programmers to provide with every call. He never really put himself in the place of the next guy -- the user of the API -- and so his code was far less elegant than it could have been.

And so it goes with every other trait. I'm pretty sure even the enthusiasm trait easily follows from someone with this forward-looking viewpoint, since someone who can't even see what kind of impact his own code is having on another is not likely to be very proud of his own code (or will be falsely so, but that's manic glee, not enthusiasm).

And so, I say, look to the intent of the programmer to determine his greatness or his potential. If he looks out for the next guy, he will be great, and he will embody all the traits we attribute to the great ones.


*Scandal*


So... what's the difference? (4.00 / 1) (#61)
by phliar on Fri Feb 01, 2002 at 11:05:19 PM EST

First, your article is waaaay too long.

Second, it's more of a "how to learn programming" or "learn how to program" than an analysis of the difference between Hackers and hacks. Not that that's a bad thing, of course, but an accurate title would be nice.

Now, about Hackers and hacks: all the modern buzzwords like extreme programming or design patterns -- crap! That is, a Real Hacker [TM] doesn't know (or care) about the buzzwords. Those tricks -- sorry, I mean methodologies -- are trying to figure out what it is that the Hacker does that is so like magic, that mere mortals might use some of His or Her techniques. They can write code in any language, and when other programmers look at it... perhaps I should illustrate the point with a little story.

Legend has it that after Bird (Charlie Parker) was gonged off the stage as a kid, he went into hiding, working on his music, inventing bebop. When he emerged after a couple of years, full-formed, in all his glory, he went back to that jam session. He got his chance to solo -- and he let them have it. Another tenor player who had been present at that earlier occasion -- one of the prominent hecklers -- now stood with jaw agape. He stumbled from the bar. On his way home he was walking on a bridge -- he looked at the water below, and threw his horn into the river.

Apocryphal? Almost certainly. Sentimental crap? Absolutely! But...

I do know this: Hackers are never one-dimensional. The greatest correspondence with other traits I've seen:

  1. strong linguistic skills
  2. strong musical skills, if not talent
They read voraciously -- everything they can get their hands on; they write; they are [in the western environment] classically trained musicians; they are experts in a huge number of varied fields. They are practitioners of obscure folk-dances practiced by one tribe in the central Mato Grosso. They are competitive sailors who who cross oceans solo. They are mercurial and hard to get along with.

Some of your traits are spot on -- independence, assimilation of other ideas, eloquence. However, consistency - I don't know. People change and grow. Authors' writing styles certainly change over the years; why shouldn't a Hacker's?

Note: I detest using the words coding and programming. Hackers don't code; neither do they program. They write code.


Faster, faster, until the thrill of...

Linquistic and mathematical (none / 0) (#69)
by A Trickster Imp on Sat Feb 02, 2002 at 08:37:15 AM EST

I recall reading somewhere that there are only two true types of savants: mathematical and musical. That they might be linked is obvious.

I consider myself an excellent programmer (who doesn't) and test extremely high in both mathematical and verbal areas. I once debugged in 10 minutes (by simple inspection) a bug that another programmer with a higher degree and two on-site Microsoft specialist support programmers (@ 1k$/day/per) couldn't in two days. Take that for what that's worth in this subject.








[ Parent ]
keep your ego in line (none / 0) (#75)
by core10k on Sat Feb 02, 2002 at 10:37:09 AM EST

Take that for what that's worth in this subject.

Nothing. No offense, but you come across as young and naive.



[ Parent ]
"Hackers" (4.00 / 3) (#78)
by ucblockhead on Sat Feb 02, 2002 at 03:47:44 PM EST

Now, about Hackers and hacks: all the modern buzzwords like extreme programming or design patterns -- crap! That is, a Real Hacker [TM] doesn't know (or care) about the buzzwords. Those tricks -- sorry, I mean methodologies -- are trying to figure out what it is that the Hacker does that is so like magic, that mere mortals might use some of His or Her techniques.
This is so utterly wrong it isn't funny. It is typical, though, of "hackers" who think that because they could write a nifty utility at 18 that they don't have to learn anymore. They fail to understand that what makes a good programmer is not knowing obscure syntax tricks in particular languages and it is not inborn. It is learned.

Good coders never stop learning, and good coders understand that learning how others code (in books like Design Patterns is both valuable and essential.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

"Real Hacker" Crap (4.66 / 3) (#80)
by Simon Kinahan on Sat Feb 02, 2002 at 05:40:53 PM EST

I used to have a certain sympathy with all that "real programmer" business, but I don't any more. Certainly there are genuine prodigies out there, but there are far more egotistical pricks with no communication skills who think they God's gift to the industry because they know Duff's device. No-one is borne with the ability to code in any language after a glance over the BNF grammar. No-one is borne with the ability to pick up any instrument and just play. No-one is borne with the ability to tell whether a twenty digit number is prime.

People who can do those things learn to do so through very hard work. That hard work may be highly enjoyable, so enjoyable they don't think of it as work, but it still takes a lot of time. Through that hard work they gain a truly deep understanding of the underlying structures and patterns of their field. I'll wager that even the autistic savant whose only satisfaction, and only talent, is to be able to identify 20 digit prime numbers, got that way through spending an awful lot of time looking at and thinking about numbers: its just that he cannot explain what he's doing. When it comes to actual work, thats done it teams and sold for money, even a prodigy is no use if he can't explain what he's done and help others. Fortunately, the truly talented, rather than egotistical pricks, generally are good communicators.

Now, I'm no prodigy, and you're probably not either, so the question is, when it comes to us mere mortals, what can we do ? Well, we can try to find the Magic Trick, or we can actually put in the hours and learn the same things the prodigy knows. He may appear to have known them since he learned to talk, but in fact he had to work to learn it too. Some people I know who practice ceremonial magick have a moto "There is no such thing as Magic" (note the spelling). It applies in programming too: to achieve anything in any field, you have to work.

So when it comes to technologies, we have to ask: does this help me towards a deeper understanding, or is it someone trying to work a Magic Trick ? Often the same thing in the hands of two different people can be both things. For some reason, project managers seem even keener on Magic Tricks than programmers, so there's much more cargo cult crap in that field than in actual development.

The reason I'm bothering to write this screed is the parent post mentions two things I find quite valuable, and dismisses them as tricks. Design patterns have given rise to something of a "I have this hammer, now wow look at all these nails I never noticed before" thing, but they've also formalised a language for talking about stuff any decent OO developer did anyway. They've helped raise object orientation from an era where you could still go on training courses and have the lecturers use taxonomies as examples, or look at people's code and find a class called "Main" that did all the actual work, and have no firm basis for saying these were wrong, to a level where there's an accepted set of tools and techniques and people use the features of OO as tools, rather than a religion. Its helped, in fact, to give the rest of us a language in which to understand what the prodigies understood anyway.

XP is something of another matter. Its a bit of a "do this, and the world shall be saved" thing, and like any other such messianic prophecy its attracted some true believers who bow before the however-many-it-is-this-week practices every morning, and a certain number who have taken from it want they wanted to hear: that its OK to just fire up the editor and start to hack. But there's important stuff in there about how to actually go about a project thats going to have to be maintained, in the absence of formal requirements. Thats important, and its wrong to dismiss the whole thing as a Magic Trick because some lazy project managers are using it as an excuse to bring back Worst Practice.

Simon

If you disagree, post, don't moderate
[ Parent ]
ok.. (4.00 / 2) (#83)
by erlando on Sun Feb 03, 2002 at 09:32:53 AM EST

First, your article is waaaay too long.
...
They read voraciously -- everything they can get their hands on;
So I guess you're not a "Real Hacker"..?

Now, about Hackers and hacks: all the modern buzzwords like extreme programming or design patterns -- crap! That is, a Real Hacker [TM] doesn't know (or care) about the buzzwords. Those tricks -- sorry, I mean methodologies -- are trying to figure out what it is that the Hacker does that is so like magic, that mere mortals might use some of His or Her techniques. They can write code in any language, and when other programmers look at it...
What utter bull! Programming is craftsmanship. Nothing more. Some of us are good at it, some of us are excellent. There is no such thing as a "Real Hacker". Anyone experienced with their head screwed on right can learn a new programming language. The paradigms are the same. 99% of the time it's only a matter of syntax.
perhaps I should illustrate the point with a little story.
No thank you. Your story is irrelevant and romaticizes the issue.

Of course there are coders whose code is beautiful. But they are in no means deities as you will have them seem with your use of "His" and "Her".

Note: I detest using the words coding and programming. Hackers don't code; neither do they program. They write code.
Please enlighten me. Wtf is the difference other than meaningless hairsplitting..?

[ Parent ]
Business and methodologies (none / 0) (#84)
by Roman on Sun Feb 03, 2002 at 12:31:44 PM EST

I've being contracted by this company (formerly known as Optus and was bought out by Symcor) for over a year now. My first task was to help with an on-going insurance system project. I was supposed to make certain functionality work in a smooth fast way (pdf generation) and the way it was built before I started was stuggering. (a j2ee project but a pdf generation was done by synchronous batch processes ... basically very problematic). I had to redesign the approach, desynchronize pdf generation with message queue I wrote [yeah, yeah, it was a year ago, bea5.1 did not work with jms too well, rewrite pdf generation itself] Later I had to save a large piece of code called the Question Engine, which did not fit characteristics of an engine. I had to document the entire code base created by 20 people within 1.5 years. Then I had to find ways to optimize the code and I was able to increase overal performance by a factor of 12. from 25 user support to over 270 user support on the same hardware! it is possible to do if the code has so much implicite redundancy built into it [too many db calls, too large session objects and too many of them, xml reparsing everywhere....]
Anyway, at the end of this mess, I talked to the managers responsible for this project and I basically made them understand that without a process in place to somehow standardize their project development they will have the same problematic situation over and over again. You see, by the time this project was over I (a contractor) knew about this project more than any full time employee and this of-course is problematic, since even the top architects did not know how the entire project works.
For the past 2 months this company has being working on their internal methodology and actually working on an internal project to test this new methodology. This methodology is a set of standards described as templates that cover all project phases as described in RUP. From inception to transition. You know what, it is a difficult task to try and build a large project which is completely documented, explained, architected, designed to the point of class skeletons with methods commented to the point where any developer can be brought into the game within mere minutes. But it is worth it.
When I am writing my own utilities and games I do not need any methodology, I code. I have everything in my head, it is my own problem how I am going to remember everything and support this code after some time passes by. But for a company, it is vital to have a methodology in place to be able to successfully deliver a project/product and to be able to maintain, version control, support this code flawlessly even if all original architects and coders are gone and new ones are brought in. Thinking that methodologies are for hacks and real hackers never need them is nearsighted and a business can not afford that.

[ Parent ]
What are we? (4.00 / 1) (#62)
by phliar on Fri Feb 01, 2002 at 11:19:35 PM EST

Interestingly, practitioners of these professions [doctors, lawyers, engineers] are regarded as "professionals" while developers are not. Why not?
Because we're not mere "professionals"; we're artistes!

If I may quote from Joel on Software:

Programmers ... have weird bugs that you would never tolerate from a bridge built by a civic engineer.

The unique thing about software is that it is infinitely clonable. Once you've written a subroutine, you can call it as often as you want. This means that almost everything we do as software developers is something that has never been done before. This is very different than what construction workers do. Herman the Handyman, who just installed a tile floor for me, has probably installed hundreds of tile floors. He has to keep installing tile floors again and again as long as new tile floors are needed. We in the software industry would have long since written a Tile Floor Template Library (TFTL) and generating new tile floors would be trivial.

Jokes aside, I see the work of some Hackers and I feel that I have seen the Platonic Ideal of the problem. That's the difference between good code and great code. The former solves the problem and is maintainable, but the latter reveals to you the very essence of the problem.


Faster, faster, until the thrill of...

not quite right.. (none / 0) (#89)
by andrewm on Wed Feb 06, 2002 at 03:52:00 PM EST

We in the software industry would have long since written a Tile Floor Template Library (TFTL) and generating new tile floors would be trivial
Nonsense! Each time we had a new tile floor to install, we'ld say 'that TFTL wasn't made here by me, so I'm writing a new one'

Alternatively, each TFTL would be 'designed' for exactly one specific floor, and any other floors that are even a tiny bit different will require a whole new TFTL.

It's a nice theory though :)

Oh, and if I wanted something pretty to look at, I'ld hire an artist. If I actually wanted to get to the other side of a river, I'ld make damn sure it was an engineer who designed that bridge.

[ Parent ]

Debugging (none / 0) (#65)
by www.sorehands.com on Sat Feb 02, 2002 at 01:44:10 AM EST

He talks about getting to know the debugger.

Bull! You should avoid using the debugger, except as a last resort. It is hard to find 1 mistake when tracing through 25,000 lines of code. When using a debugger, you should know what you are looking for.



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

Testing (4.00 / 1) (#76)
by milksop on Sat Feb 02, 2002 at 01:11:40 PM EST

Why should you know what you're looking for when you're using a debugger? I know what I'm looking for I guess: the null dereference. Where is it? Who knows. If it crashes and I get a stack trace in the debugger, it's going to be pretty quick to find (as opposed to binary searching with printfs I guess?)

There's other reasons to use the debugger than for "debugging". I think it's pretty normal to use it for testing and code exercise. It's especially convenient if you have a good way of doing "Set Next Statement" and tweaking variables so that you can test all possible inputs to a block of code without even re-running: just modify the variables in your watch window, move the PC to the beginning and step through again.
--
i make games.
[ Parent ]

Debugger (none / 0) (#82)
by erlando on Sun Feb 03, 2002 at 09:15:12 AM EST

I couldn't disagree more. IMO the debugger is the most important tool in a programmers box-of-tricks. Especially when working with polymorphy and the likes.

But you are right on one point. You need to know what to look for. But if it's your code you already have (at least I hope you have) a general idea where the bug could be. That is more than enough knowledge necessary for finding the bug with the debugger. And it sure beats printf-debugstatements. It takes a lot of them to find 1 bug in 25.000 lines of code if you don't know what you are looking for.

[ Parent ]

More observations... (none / 0) (#70)
by A Trickster Imp on Sat Feb 02, 2002 at 08:57:24 AM EST

> Loop through a linear range merely to increment a counter
>
> if(donaldDuck[idd].goofy.size() > 0)
> {
> for ( i = first; i < last; i++ )
> {
> i2++;
> }
> }
>
> Come on now. What's wrong with if(donaldDuck[idd].goofy.size()>0) i2 += last-first+1; ?

Because that would give the wrong answer. You mean to use i2 += last - first, according to the "bad code"'s intent. Loss of the .h in the inclusion line has a definite "packagey" feel to it, which is unsettling.


> Use the old-style C++ headers, even though they've been deprecated for several years now. (no ".h")

I did not know this. I'll worry about it, though, when my compiler warns me on high warning levels.


> Put 'return' at the end of a (void) function
>
> There's no reason for that. Just be minimal and let it "fall off"
> the function; it's safe, trust me.

It's not a bad idea as you might add a return value at some point in the future. The return will balk on subsequent compiles, and if you don't have high warnings set, falling off the end somewhere without a return will be a Bad Thing.








Closing remarks (4.00 / 1) (#85)
by czth on Sun Feb 03, 2002 at 10:50:03 PM EST

Let me tell you a story. Once upon a time, a father and son were going to market, and they brought a donkey with them to carry their purchases. Now as they walked by the village, the villagers working in their yards saw them pass by, and they looked at the two of them and mocked them for both walking while their donkey was doing nothing. So the father gets on the donkey, and they go on for a while. And then the villagers complain that the father is making his kid walk, so they trade places, etc. etc. until they finally decide to both ride the poor beast and break its back.

The moral of this story is that you can't please everybody all the time. Heck, if you can please most of the people some of the time you're well ahead. Let me say again, and I believe I said it in the article: I'm not trying to make rules. Still, personally I'd be pretty scared working beside someone that posessed none of the traits I listed. Likewise for things like XP: take what works, leave what doesn't; even they say that (Fix XP when it breaks).

Sure, maybe there's still a place for the stereotypical longhaired geek with no social skills who can code like a maniac. I don't think I personally have abandoned the "hacker cowboy" mold, but built on it and matured. Because there are other people out there that you and your code have to work with. Even the strong musical skills suggestion is bull as a generalization. Young hackers may very well be 1D, but (one hopes) they grow out of it and find other things they love, and, by dint of the natural aptitude and ability to tightly focus energy on learning a specific skill that I maintain is general, they can become very good at those things.

Yes, I know that variables can be defined at the top of a block, even in C (I elected to write a C compiler as part of my education). Evidently the original writers of the code I was describing didn't. I also thank Trickster Imp for pointing out the error on my hall of shame page (fixed).

I apologize if you think I was using my article as a platform for boasting. That wasn't the intent. I am good at certain things; so is everyone. And I only have my own experience to draw on, not anybody else's. Both pride and false modesty are barriers to good writing.

Thank you for your comments and compliments on the article, as well as diverse viewpoints and discussion, which I take as a compliment in itself.

czth

Differentiating Developers | 89 comments (77 topical, 12 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!