Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Making Software Suck Less, Pt. II

timothy posted more than 13 years ago | from the he-ain't-heavy-he's-my-code-gnome! dept.

News 209

Not long ago, chromatic wrote about one aspect of the quest to create software that doesn't suck. This time he's back with a proposal that's simultaneously practical and idealistic. Namely: If you as a whiz at a certain language or other aspect of programming want the world of programming to be better, you can help other people become programmers, or better programmers, with well-considered instruction. I hope someone in the Computer Science department at a high school near chromatic gives him a call, because he outlines here something more important than a "learn to program" curriculum.

Making Software Suck Less, Pt. II

Coders Code Whether You Like It Or Not

The insidious thing about Free software, the really subversive part, is that it takes so little to start writing it. Anyone with a few tools, spare time, and the wherewithall to start hacking can. Witness the long listings of low-version-number IM clients and MP3 players on software announcement sites. People like to code.

Every new project represents a coder who wants to write free software, but chooses not to work with an existing project for whatever reason. How many more people would like to contribute but don't know where to start? Hundreds, even thousands of free software projects could use another coder, some testers, and someone -- anyone -- offering suggestions and attaboys. For each veteran programmer, battle-hardened and wizened by experience, a dozen novices spend evenings honing their skills.

Mentoring Beginning Programmers

The obvious solution is to match availability with opportunity and enthusiasm with experience. The free software community can produce better programmers by giving new recruits mentors to emulate. It offers the possibility for programmers to learn by improving existing projects, instead of reinventing wheels. This doesn't require expert programmers. It takes people with practical experience, patience, and the willingness to invest time in another person's education.

Though this article draws from experience with free software, there's no reason similar procedures could not succeed in commercial settings. Computer science sophmores (and higher) would benefit from internship programs organized similarly.

The Usual Suspects

Candidates for mentoring exhibit a combination of at least three different characteristics. These are expressable as three different archetypes: the self-taught hacker, the computer science student, and the new programmer. Individual personalities and experiences also come into play. These are gross generalizations, but serve the purpose of categorizing the types of information to present.

Self taught hackers learn by experimentation. They dissect existing code, copying and modifying implementations. Their technique gradually coalesces from dominant influences. Hackers often amass a library to improve their education. One danger for members of this class is that they may pick up questionable practices from questionable code ("cargo cult programming").

Computer science students learn theory and are expected to teach themselves various languages and implementations. (This category does not cover degrees like 'information services.') The education covers ideal solutions, often emphasising aesthetics and mathematical perfection. Students may not be exposed to practical issues in specific languages and techniques, focusing on working code.

New learners enter the world of coding with a strong sense of need. Management might pick a hapless victim for a project of undefined scope. A home user may just wish to do more with her computer. People in this category often don't know where to turn. They may not all grow into dedicated coders, but can fend for themselves with some guidance and direction.

Besides these categories, recruits may include artists, musicians, writers, and testers. Though direct mentoring from programmers may not awaken nascent coding abilities, these folks are certainly welcome. Even experienced programmers new to the idea of free software or to a class of software can benefit from directed guidance. (Many people in this position just need to see how to contribute.)

Course Requirements

Mentoring must provide examples of secure, clean, and idiomatic programming. It should also include issues related to the practice of programming -- time management, software design, tools and classes of tools, and project leadership. Additionally, mentors should introduce their students to a network of peers, whether on IRC, through mailing lists, or in user groups.

Benefits of Mentoring

Besides the warm glow of humanitarianism, being a mentor bestows personal benefits. Your project immediately gains an extra set of hands and eyes. Each new person brings a fresh point of view, with different expectations and stories for the code and unique experiences. At first, the additional overhead of explaining will slow progress; wise mentors invest slightly more time to turn these lessons into improved documentation and tutorials. After a short period of training, the project gains another person familiar with internals.

The discipline of explaining your personal technique, especially the more reflexive elements of your coding style, will also improve your skills. ("Why do I do it that way?") Describing system architecture and complex codes in words forces you to organize your thoughts. It can even clarify future design decisions. Your student must be free to ask questions and to challenge your assumptions. Either strengthen your arguments or discover a better alternative.

Leaving the Nest

If you've mentored correctly, at some point you'll have taught every lesson you can. The student will have met the right people and will have tasted the fruit of hard work. Your example will still teach him, but he will make his own way. You will be peers.

Prepare for this from the beginning. Allow the student to lead subprojects with the freedom to make mistakes but the supervision to produce working results. Provide opportunities for personal growth. Your job is to remove obstacles from the path of enlightenment. Writing good software is hard, but teaching people to contribute is very rewarding.

cancel ×

209 comments

Developer's Haiku (2)

Art_XIV (249990) | more than 13 years ago | (#413510)

Windows ruins all
My kernel module won't load
Stop and fill timesheet

Hey CmdrTaco! (5)

Shoeboy (16224) | more than 13 years ago | (#413511)

Rob,

I'm willing to be you mentor.

I've seen the database structure for slashcode. I know you need some help. I'm willing to offer it.

Our first lesson will be on denormalization for better performance. I'll try to be a patient and dilligent instructor, but the fact that you fetch the sig from the users table for every comment rather than storing it in the comments table may render that impossible. It's quite possible that I may have to beat you. Particularly when I look at some of the 3 and 4 tabe joins you do for really common operations. I know Hope College isn't much of a school, but surely at some point they explained that joins were slower than single table selects, right?

Anyway, I'm more than willing to help you with your database design and implementation problems.
Drop me an email.

--Shoeboy

Re:Programming has nothing to do with schooling (1)

fizban (58094) | more than 13 years ago | (#413517)

I will take my current company as an example. We, the developers, are given ample time to seriously think about our problems and develop robust solutions. This method of development actually came about because they did it the other way the first time around.

My company went through the stage of "making it work" and ended up with software products that had to be constantly supported, patched, re-coded, etc., and it's costing them. So they decided to do it better the 2nd, 3rd,...,nth time around the track. Maybe companies do need to go through this stage to learn these things, a "trial by fire" sort of thing, but why waste the time and money on inadequate solutions when there's a better method just a few more steps down the road? My company realized it needed to spend more time developing better solutions, rather than spending less time developing any solution.

I'm just saying that there are companies out there who know that the time spent in development is worth the cost, in the long run. Of course, if they only need to get something out there today and don't care if they exist 2 years down the road, that's fine also... I just won't work there.

--

Some environments don't *have* a debugger. (1)

Richard Steiner (1585) | more than 13 years ago | (#413519)

At least not a formal one.

In the mainframe-based transaction environment that I work in (modified TIP/1100 environment on a Unisys 2200), for example, all we can do is put octal and character snaps in the code and generate a trace file when executing the transaction.
--
-Rich (OS/2 Warp 4 and Linux user in Eden Prairie MN)

Re:One simple "trick" for not sucking (1)

fizban (58094) | more than 13 years ago | (#413520)

What the hell platform are you writing code on that doesn't have a debugger??? This is one of the most common tools in software development.

--

Re:Don't teach them to program. (1)

joecool12321 (313452) | more than 13 years ago | (#413522)

I completely agree with the importance of "problem solving". I'm a "new learner" becoming "comp. sci. student" simply because, like chromatic says, "People in this [new learner] category often don't know where to turn." But one thing I can do -- I can algorithmicly solve just about every problem I've had to deal with. I've done some work with one of my friends, who is a Flash "programmer". I now know ActionScripting fairly well, but originally I would write the "psuedo code" and he'd implement it.

All of that to say...it's not easy, or at least it wasn't for me, to find a mentor. I guess I still don't have a mentor, I just finess projects untill they're *relatively* bullet-proof. For example, I just did an infix-to-postfix lab, in which we had to use stack implementation. After finishing the program, I fed it it's own source code, and it didn't crash. Now, that's not *elite* or anything, but for those of us that "drift", it's the best we can do.

It would be nice if there was a way to get in touch with people who want to mentor hungry students. If there is anyone who is interested, my e-mail is joecool12321@yahoo.com.

--Joey

Re:Suggestions for better software (2)

Mr. Slippery (47854) | more than 13 years ago | (#413524)

Open Source software very rarely seems to go through a proper build, test, fix stage.

Yes, but that's because software very rarely seems to go through a proper build, test, fix stage! B-(

Tom Swiss | the infamous tms | http://www.infamous.net/

How to use a debugger (3)

AntiFreeze (31247) | more than 13 years ago | (#413525)

I think one major point which has been missed in the previous discussion was the aspect of debugging code.

I know when I started out, I rarely used a debugger when coding. I'd print out hard copies of my code, go over it with a pen, show it to others, but never touch a debugger. I know many professional programmers who also don't know the value of a good debugger.

My point is simple: teach aspiring programmers that no one can code perfectly, and show them how to debug their code appropriately. gdb is fine. ddd is better for beginners. There are other debuggers for other languages. I have no clue what can be used under windows or on a macintosh, but I'm sure there are good debuggers for them too.

One of the tenets of being a good programmer is writing solid code and knowing it's limitiations. Stress testing extreme conditions, and not being afraid of sanity checks. I've seen professional apps die from OBOBs (off by one bugs), come on guys, that should never happen, it's so easy to test for.

I know I've been babbling, so this is my last point. Teach people that just because a program compiles and runs without crashing, doesn't mean it always will.


---

Re:Hey CmdrTaco! -- first lesson: (2)

Shoeboy (16224) | more than 13 years ago | (#413527)

Good point. MySQL is closer to access than it is to a real database. It'd be hard to do proper database development on MySQL just because of all the limitations. I wasn't aware that it didn't have the equivalent of page level or row level locking. That's awful.
Why do people insist that it's a real database again?
--Shoeboy

Re:Software apprentices (1)

cavemanf16 (303184) | more than 13 years ago | (#413528)

That's cool. You can never be too careful in today's politically correct saturated society. :)

Re:I'm akarma whore (1)

Heidi Wull (318504) | more than 13 years ago | (#413529)

why? I've got plenty of room for them in my mouth!

Why the discrepancy? (1)

AintTooProudToBeg (187954) | more than 13 years ago | (#413531)

Hardware works. I've never had a problem with my processors, sound cards, network cards or any such hardware. And this is complex stuff!

Software sucks. I've had constant problems with software... even complex ultra-popular stuff (MS). The worst are custom programs companies pay $50,000+ for (e.g. fancy warehouse stuff or some insurance billing database)... man that stuff really blows.

Anyone go into a Pep Boys about 4 years ago? I sure hope they're not using it anymore, but their cash registers ran a win 3.1 VB application... complete with 150x150 pixel "CHANGE" and "RECEIPT" command buttons. BARF!

Could mentoring turn into a guild or a union? (2)

typical geek (261980) | more than 13 years ago | (#413533)

Do you think that if we got enough of a mentoring organization together, we could perhaps turn the programming field into a guild or a union?

Now, rub your knees for a minute from jerking and hitting your desk bottom, don't think of union as a janitor's or autoworkers union, where most of the members work 2 hours a day, and pay a small fortune to the union bosses, but rather think of a group of like minded craftsmen, who only want to see their field prosper, who only want to pass along the best techniques to their journeymen and apprentices.

Perhaps a Guild is a better image. We senior programmers could pass along good programming tips and technics, as well as a good sense of programming ethos to younger, more impressionable programmers. We could instill a much greater sense of professionalism in the field.

Eventually, we could assert our power for the good of the field, perhaps modeling ourselves on the AMA. We could certify certain schools, and not allow programmers to be board certified if they didn't graduate from our chosen schools, and pass our chosen board tests. Really, you wouldn't let any quack operate on you, or any hack defend you in court, wouldn't you feel better knowing a professional, certified programmer was writing your web page?

Thanks for reading this, and thinking about it.

I agree with the analysis (2)

wmulvihillDxR (212915) | more than 13 years ago | (#413535)

I agree that there are so many projects out there that start because someone scratches their itch and then gets bogged down in finishing it and documenting it. Mentoring is a wonderful idea.

I am a fairly good coder and have a couple of projects going on. I think I would certainly welcome any help on those projects and would easily be flattered and appreciative of beginners trying to contribute. I think the problem is that people think that they must be 1337 coders in order to contribute to projects. So I say to beginners out there, come to my projects (see sig)! Help out! I'm willing to train with the fairly good skills I have.

Management and algebra problems (2)

michaelmalak (91262) | more than 13 years ago | (#413537)

Three obstacles with the suggestion of mentoring:
  1. Management has to be completely on board. Management often evaluates individual rather than team performance, and monthly rather than decade-long performance. Currently, potential mentors often get in trouble for mentoring.
  2. With job changes about every year or two, it becomes more difficult for employers to measure and reward the effectiveness of mentoring (unless some royalty or residual renumeration were set up).
  3. Finally, three women can't make a baby in three months. Saying "mentoring programming" is like saying "mentoring algebra". It takes time and practice on the part of the student to grok. Yes, it goes several times faster with a mentor, but there is an "aha!" that takes a while to acquire.
Without addressing these obstacles, the suggestion is merely just a start of an idea (and one that frequently comes up anyway in researched software engineering "process" and "culture" literature).

Re:Suck Less (4)

rw2 (17419) | more than 13 years ago | (#413541)

Of course with most free software, since there is no one promised a product that withdraw their money if it doesn't happen there aren't many deadlines.


Except that tons of software is written as a kind of modern day duel. Why else would someone write a message board when ten already exist? To scratch an itch? Partially, but that only explains why they write it, not why they gift it. They gift it in order to win the acclaim of their peers.

In order to win said acclaim you must be current. The deadlines are therefore sometimes much more onerous because they are less tangible. More like a nightmare where you are terrified and running, but you don't necessarily know from what instead of a deadling where you are running, but it's only because your boss said so and he has no spine, no brain and no power. The worst he can do is fire you and then you'll just go somewhere else for more money.

--

Re:another thing this does: (1)

fizban (58094) | more than 13 years ago | (#413547)

Basically a software development site for free software...

So, does this mean we'll have a website with thousands of half-finished flowcharts? :-)

--

Re:Hey CmdrTaco! (1)

b100m (69755) | more than 13 years ago | (#413548)

Amen.
___________________________________________ ______
$which weed

I disagree. (1)

Rotten168 (104565) | more than 13 years ago | (#413549)

Problem solving is a piece of the equation, but it's a small part. A lot of sloppy code is written because people just don't have intimate knowledge of the language. Wasted resources is a major problem with today's applications.

Consider Windows. It solves all of our problems, but it really doesn't do it that well. It has a GUI that one can use applications with, and an interface, but underneath all of that there are memory leaks and really buggy software problems.

It's almost as if the coders followed your advice but then didn't take the requisate step to consider the potential problems their code might wreak upon systems (Windows seems to do it's worse when it has +30 apps installed on it.

I've personally seen apps that "solve" the problem at hand, but bog down resources WAY more than they should. That "trivial" work is the most important work of it all, after all, a computer cares nothing for theories or algorithms, all it cares about is the array of instructions it needs to process.

GET A DIFFERENT JOB (2)

yerricde (125198) | more than 13 years ago | (#413550)

Unisys

Quit. Your. Job. Now. [burnallgifs.org]


All your hallucinogen [pineight.com] are belong to us.

Mmm (1)

SexyAlexie (217702) | more than 13 years ago | (#413552)

His head should roll for that!

printf() debugging (2)

yerricde (125198) | more than 13 years ago | (#413553)

What the hell platform are you writing code on that doesn't have a debugger???

In some environments, the only debugger you have is printf() or the equivalent. How do you run GDB on an embedded system such as a cellphone or a game console [parodius.com] ? How do you debug a fullscreen application (game, media player, etc.) if you can't see GDB's window?


All your hallucinogen [pineight.com] are belong to us.

Suck Less (3)

clinko (232501) | more than 13 years ago | (#413554)

There's a deadline, and how much you're going to do. As time approaches deadline, the suckfactor goes up. It's a simple equation. :)

And software is NEVER finished.

Re:Programming has nothing to do with schooling (2)

Mr. Slippery (47854) | more than 13 years ago | (#413555)

Most professional programmers that I know of have never taken a single computer class...In addition, many professional programmers have no time to write 'good' code.

Gee, maybe if your friends took the time to learn about their chosen field, they'd come to realize that writing "good" code ultimately saves time.

That's why you don't see too many comp sci people making the big bucks as professionals.
Interesting...I've worked at companies like TRW, IBM, and Raytheon, and I think 95% of the professional programmers I worked with had CS degrees. (Yes, one can be a good programmer without a degree; however, without at least some classes, I'd say it's very very unlikely.)

Where are all these "professional" programmers who've never taken a class working? I'd like to know so I can be sure to avoid their products...would you go to a dentist who proudly claimed he'd never taken a class? Or even a mechanic who bragged about never taking even auto shop?

Tom Swiss | the infamous tms | http://www.infamous.net/

Re:Making VA suck less (1)

Anonymous Coward | more than 13 years ago | (#413556)

It never ceases to amaze me how the trolls, spammers and idiots around here can take ahold of something with moderate humor value and bludgeon it to a slow, bleeding, moaning death. It was slightly funny for one day, it was less funny the next, and now it is just about the most goddamned annoying thing I can think of.

At least get creative with it, something along the lines of:

All your Natalies are belong to us!
What you say?
Someone set up us the grits!! You are on the path to burned genitals!

Those who can not....teach (2)

gus goose (306978) | more than 13 years ago | (#413557)

It takes people with practical experience, patience, and the willingness to invest time in another person's education.

To this you have to add that the person also has little else to do.

So, this is the flaw with the above. In any environment (other than an academic envoronment), the people who an actually do the work best spend their time doing the work. This is why we have schools, colleges, and universities. That is where the people go to get the "practical experience, patience, and the willingness", and they get it because they pay.

Mentoring is inefficient in a business environment because it reduces the productivity of two people to the average of the collective.(you have a 100% productive person and a 50% productive person producing at 75%. It is better to not have mentoring because your productivity doubles (150%))

Thus, in a business perspective, if mentoring happens, it is quickly realised that the solution is to put the mentor back to work, and in extreme circumstances, to replace the 'trainee' with a person who does not need mentoring.

Hard, cold, fact of life.

another thing this does: (1)

perrin5 (38802) | more than 13 years ago | (#413558)

If this is adopted widely (and I hope it is) there are two major effects I can see coming out of it:

1) Programmers will have to have flowcharts for the little projects they're working on. It may cut down on the number of submissions to freshmeat, but the code will be better.

2(and more interesting) A new website could come out of this: I am working on this, contact me for more information, a flowchart, and an area to work on....Basically a software development site for free software, with project managers and everything.

AWESOME!!

Re:Suggestions for better software (3)

schulzdogg (165637) | more than 13 years ago | (#413559)

Have you tried to use Mozilla lately.

Mozilla is A good web browser, not spectacular but decent. It is a spectacular architecture. the ability to write code for many different platforms, to expose that code to scripting languages so relative neophytes can code applications is extremely powerful.

A brief explanation of XUL/XPCOM/JavaScript:

Most of mozilla's core class's are built in XPCOM objects. Certain methods of these objects can be exported as scriptable, meaning they can be run from javascript code.

XUL is a layout language, similiar to HTML, that uses CSS to define it's appearence. Javascript can be embeded in XUL.

The result is an architecture that allows anyone to creat an application (chrome) as long as they can learn javascript and XUL. Heavy lifting can still be done in C++ behind the scenes and then exposed to Javascript. Dev time (once you get past the sizeable learning curve) is small. The resultant apps are cross platform and fully skinnable (because they're appearance is defined in stylesheets).

Everyone should check out www.mozilla.org and learn about this. It's a much better rapid development enviornment than VB, and it's cross platform, and open source.

I sound like a groupie, but mozilla is a beautiful thing....

Writing good software is impossible... (3)

Bug2000 (235500) | more than 13 years ago | (#413560)

... most of the time. Because there is not one person alone who can build a whole system, you need to do team work and dispatch responsibilities. You need some managers who usually are quite distant with technical realities (deadlines, budgets). You need techies who are quite distant with the real world (what do you need a GUI for ?). You need a nice working environment and what's more you need to communicate. Eventually, you need a customer who knows what he wants and have precise ways to describe what he wants. In addition, get me some heavy competition and so the problems start!

There are already different methodologies to enhance the quality of the work like Rational Unified Process or Extreme Programming which correspond to different project scales. Mentoring is very good if good techies were no so contemptful with junior programmers. None of these techniques will be enough to counterweigh the human factor though. This is why I believe that writing good software all the time is impossible.

Also, it is a complete misconception that good software is only a question of technique! A good software is a software which is widely used and that people are happy with. Customers, programmers, managers and marketing people are people before anything. And this is why I strongly believe that good software is much more a question of people and not of methodologies.

Look, for the biggest majority of the users, Microsoft Office is a very good product. For the geeks community, Linux is a good software. The notion of "good" is sooo variable... :)

Re:But that's not FUN (1)

bluebomber (155733) | more than 13 years ago | (#413570)

Of course its fun! You haven't spent enough time debugging/reverse engineering/redesigning hairy code. About 95% of my paid work is maintaining/extending/debugging other people's code. Mostly the crappy stuff -- IME, the good code doesn't need much maintenance. You do this for long enough, you start to like it. It's really just problem solving of a different sort. But instead of inventing something to solve a problem, you have to figure out why a problem occurs and fix an existing invention.

It's like the BASF ads: "We don't make the things you use, we make the things you use better."

-bluebomber

Re:Suggestions for better software (2)

Shotgun (30919) | more than 13 years ago | (#413571)

Might there not be other reasons for not trying to pick-up and fix someone else's work? Have you not considered that trying to fix someone else's code is a lot more difficult that implementing a feature from scratch?

I code professionally, and the hardest part of the job is trying to understand the mindset of the programmer who wrote this code originally. Most commercial code is worked on by a lot of hands, and it shows. You see the same problem solved in different ways in different places. Some of this may be because programmer B didn't know that programmer A had already implemented a function to handle the problem. It may be that programmer B did not like programmer A's implementation. How many times have you heard a programmer proclaim 'this code' sucks, only to replace it with something that is marginalling 'different'.

Regardless of the reason, being programmer N, I pick up this morass of code, and think that the whole thing needs to be thrown out and re-implemented.

With OS code, seeing as the programmers are volunteers, they get to work on what ever makes them feel good. What feels better, implementing a feature and actually making something work, or digging through someone else's obfuscated idea of code in order to fix an obscure bug?

In my opinion, new programmers would be willing to work on bug fixing if UNIX programmers would use real names for variables.

void *p = /*doesn't mean shit */

Don't teach them to program. (5)

Black Parrot (19622) | more than 13 years ago | (#413586)

Don't teach them to program at all -- teach them to solve problems. After you have a sensible solution strategy, expressing it in the syntax of a given programming language is trivial (boring) work.

The problem that I see over and over and over again, among both students and "professionals", is that they sit down and start throwing code at a problem without knowing a solution strategy for that problem. And for many of these people, if you try using the Socratic method to bring out their solution strategy you'll find that they not only don't know what strategy they're trying to encode, but that they also don't even want to talk about strategies -- they want to talk about the details of the incorrect code they've already written.

I'm not against hacking, and I certainly don't think every program anyone writes needs to be supported by an engineering discipline, but I do feel, very strongly, that people need to think of programming languages as a tool for expressing a solution to a problem, not as being the solution itself.

--

To further what you are saying (2)

Sycraft-fu (314770) | more than 13 years ago | (#413587)

I've noticed that not only do some people have a problem with documenting their code, but documenting their program, which in some ways is even more important. If you are writing your program just for you and maybe friends/coworkers, then you don't necessiarly need docs, since you can explain everything as needed. However, if you intend to release your program to the world, good documentation is a must. Prentend like your users are complete idiots (sometimes a valid assumption) and write your documentation accordingly. Throughly explain all the options, even if they seem a little obvious to you. If you have good documentation (as well as a generally intuitive interface) you'll find a lot more people using your program and a lot less requests for help with it.

Re:Suck Less (2)

kevlar (13509) | more than 13 years ago | (#413588)

This is so true. This is the root of the suckness of software.

On top of such suckiness is the competence of the coder. Not everyone in the industry is competent. In fact, I'd say that the vast majority are incompetent and that there is a select few who actually get the work done. This increases the load on the competent while the incompetent weazle by managing the build and doing other such simple tasks.

Re:I tried this with assembly coding, once (1)

weasel (8923) | more than 13 years ago | (#413589)


Heh, and he thought unaligned access was rough when it was slow... how about when it doesn't work, period? (odd addresses on MC68000)

RTFM (1)

Bug2000 (235500) | more than 13 years ago | (#413590)

Also, when I started programming, I often asked stupid questions to good programmers who told me RTFM. I'm not talking about newsgroups, just working environment. A good mentoring practice could have been for example to tell me which manual to read (where to get the info) or to explain the important part of the manual and then tell me that if I want to know more, I should investigate myself. But no! RTFM...


Re:I want it NOW! (1)

Hiedi Wall (318437) | more than 13 years ago | (#413591)

You two sluts better stay away from cyber monkey His 2 inch dick is all MINE!!!!

But that's not FUN (3)

dissipative_struct (312023) | more than 13 years ago | (#413608)

Presumably, people who write Open Source code are doing it for their own enjoyment, which means they will tend to concentrate on the things they enjoy (adding new features) not the things they dislike (debugging someone else's code, documentation). This is one area where I feel the Open Source methods can be weak... there's no real imperative for quality control, since everyone's doing it for the enjoyment. A prestigous project may be able to enforce some quality, but for smaller projects, I can't think of any way to induce people to concentrate on the necessary but boring tasks as opposed to the fun (and maybe not necessary) tasks.

hahahahahahahahahahahahahaha (1)

Anonymous Coward | more than 13 years ago | (#413609)


so true... but then the slashcoders would have to admit that they all know almost nothing about real database work...

Re:hahahahahahahahahahahahahaha (2)

Anonymous Coward | more than 13 years ago | (#413610)

you assume they use a real database -- which they don't. MySQL is a real database like a Camaro is a real sports car.

One simple "trick" for not sucking (4)

Wordman (79573) | more than 13 years ago | (#413611)

Most of you will read this suggestion and snicker at it. I know I did when I first heard it. I've since learned how blind I was.

There is one simple thing you can do to make your code a lot better. It takes a bit of discipline, but once you do it for a while, it becomes second nature. It is this: whenever you write new code, make sure that you walk through every new line with a debugger. That's it.

At first blush, this seems kind of like a "duh" sort of step. After all, most people run their code through a debugger to check it. The key to it, though is the phrase "every line". Put breakpoints in every branch of the code you write. When you get into that branch, remove the breakpoint. When you think you are done, check for any breakpoints that are left. I was extremely surprised the first time I did this. I thought I had been thourough, but I hadn't checked three different branches. And there were bugs in two of them.

What I have learned after doing this for a number of years is that programmers pay more attention to the important part of a loop or branch and ignore the fringe cases. What ends up happening, then, is that the fringe cases contain a proportinally large number of the bugs. Worse, because they are fringe cases, they don't happen often, leading to bugs that are hard to reproduce.

C.S. H.S. ? (1)

SEWilco (27983) | more than 13 years ago | (#413612)

"...Computer Science department at a high school..."

That's quite a high school. Are the Computer Design, Semiconductor Physics, and Electronic Engineering departments nearby?

Programming has nothing to do with schooling (1)

NineNine (235196) | more than 13 years ago | (#413613)

Most professional programmers that I know of have never taken a single computer class. Most good professional programmers are good because they work hard, learn what they need to know, and make the programs work.

In addition, many professional programmers have no time to write 'good' code. Taking time to write something elegant or pretty is simply not an option if you want to stay employed, in many cases. In many professional projects, there's barely time to make code that works, never mind code that's 'great'. That's just a fact of life. Most college computer science kids never get this. That's why you don't see too many comp sci people making the big bucks as professionals. Being a successful programmer isn't about great code. It's about pragmatism.

Re:I tried this with assembly coding, once (1)

Maserati (8679) | more than 13 years ago | (#413614)

as a senior Mac tech, guys like that keep me in steak and whiskey

And speaking of SIG's (1)

MeowMeow Jones (233640) | more than 13 years ago | (#413615)

Why are they 120 characters instead of 128?

That's just mismanagement (1)

SnakeStu (60546) | more than 13 years ago | (#413616)

This isn't a cold, hard fact of life, it's a cold, hard symptom of mismanagement. Any manager worth his/her position knows how to do the work, but does not do it because his/her knowledge is better applied strategically than tactically. The same can be said of the mentor in this case.

Using your productivity percentages, you have two scenarios: The 100% productive person does or does not mentor the 50% productive person. If the mentoring does not take place, you're guaranteed a continuing productivity of 150%. If the mentoring does take place, you're stuck with a 75% (or less) productivity for the short term but a 200% productivity in the long run.

If you "don't have time" to make strategic investments, you're simply mismanaging the situation. If you think you can bring on someone who needs no mentoring at all, you have one of two problems: a) It's true, because your situation is so bad that any Joe off the street with technical skills and no knowledge of your business can be 100% productive fixing technical flaws in your system, or b) It's not true but you're ignoring the mentoring that will be required to give the new person non-technical knowledge (i.e., the business background so they can understand how to apply their technical skills). The only people who truly need no mentoring (when there are not abundant, glaring flaws in whatever you're working on) are those people already working on the system.

Given that non-technical business background knowledge can take a lot longer to acquire than some technical skills, there are certain positions (e.g., Web development) where I would rather take a non-technical person already in the business with all of the background knowledge in place and mentor them technically, than pull in a "tech-ready" new hire who has no clue about the business, the corporate culture, etc., and lacks internal contacts and such that augment the technical side of things. (This clearly doesn't apply in all areas -- for something like assembly programming for embedded systems I would probably take the opposite approach.)

http://www.programmingtutorials.com (1)

The Blackrat (255469) | more than 13 years ago | (#413617)

great site for ultra newbies such as myself

Right, now where do I find people to mentor? (2)

Blackjax (98754) | more than 13 years ago | (#413618)

I agree with the concept and began doing this last fall, however I have only been able to find one student. I've approached teachers at a local university about sending me people who might want some free tutoring, but I was met complete silence. Does anyone have any suggestions for good ways to connect mentors and students?

If anyone out there in /. land is in the NYC Metro area and wants some help with Java, let me know.

Re:Programming has nothing to do with schooling (1)

Lt (31829) | more than 13 years ago | (#413619)

While I will assert that great programmers are "born", what college gives the average programmers, is a sense of what had already been done, and what is imposible. Notice how many psuedo-random one-time pad generators are created every year, by people who didn't do the proper research. College at least forces you to have minimal exposer to say Big-O, Godel's Theorem [? [google.com] ], Data Abstraction, CPU and Memeory Architecture, etc. College is not a requirement for briliance (if your of the Good Will Hunting type, but for most of us it gives us an advantage.

Be flexible (1)

ClosedSource (238333) | more than 13 years ago | (#413620)

"Every new project represents a coder who wants to write free software, but chooses not to work with an existing project for whatever reason."

One of the reasons for choosing not to work on a project may be the rigidity of low-level coding standards. Naming conventions, indentation style, bracing style etc. may have more to do with our ego and our compulsion for order than it does with good programming practice.

If a project lead is less anal about these rules, it encourages other programmers to participate since they don't have to follow arbitrary religious beliefs.

Re:But that's not FUN (2)

GypC (7592) | more than 13 years ago | (#413634)

This may be a weakness, true, but since the source is open if a truly useful program sucks in certain ways it will eventually get fixed by whatever hacker loses patience with it first :)

The Bible is not my book, and Christianity is not my religion.

Programming isn't Just About Functionality (2)

The Infamous TommyD (21616) | more than 13 years ago | (#413635)

Over and over, we see people talk about programming and how to improve the coding that's being done. One thing that the current system emphasizes is that code that just works is OK. i.e. given ok input, we get good output

One problem I see is that we don't penalize people when they write something that takes bad output and produces unexpected results. i.e. how many of your programs can handle random input without crashing or worse? Got fixed length buffers? Ever think about what happens if the file your code depends on is suddenly changed by someone else?
This is why systems crash. This is why security is so poor in software.

The teaching system rewards code that works but doesn't try to penalize code that has extra unintended features.

Software apprentices (1)

cavemanf16 (303184) | more than 13 years ago | (#413636)

Sounds like chromatic is describing the old system of apprenticeship as a means to developing good programmers as it has existed since the beginning of civilization. I for one, am all for this idea. The hacker approach can be sloppy for large projects if not done properly, while the theoretical learning from a comp. sci. student can sometimes not make sense in the real world when quick fixes are needed that can only be tackled with some quick and dirty code. Of course, everyone learns differently, but this is definitely a way of learning that I think is all too often overlooked as a positive option.

Re:Suggestions for better software (4)

Vanders (110092) | more than 13 years ago | (#413637)

For a troll, I have to agree with you. Open Source software very rarely seems to go through a proper build, test, fix stage. They just throw the software out to the users and let them find, and in a lot of cases fix, the bugs. This isn't good.

I'm a software tester by trade, and I code in my spare time. There are some cardinal sins that any peice of software can commit. They tend to be:
  • Not having a clear set of features that you want in your code for at least version 1.0
  • Not writing proper specs before any code is written
  • Not having testers, or having testers and not listening to them
  • Not having a defined roadmap or plan. At a minimum, this should cover the planing, and upto the second build of your software
Now on smaller projects, it's usually fine to sit down and start coding. With larger projects, you're going to be royally screwed about 50% ofthe way through your project, when you find you'll have to re-design part of your project to add functionality you didn't know you needed.

If you don't have testers (And no, outside of unit testing, the coder cannot teste their own code properly!) your software will be full of bugs you just don't know are there, until your users start using the software under normal conditions. You'll then find you need to recode large parts of your software to fix even small bugs.

Release early, release often, is good provided you have proper controls in place before your first release!

Re:Programming has nothing to do with schooling (1)

NineNine (235196) | more than 13 years ago | (#413638)

I've been a professional contract programmer for years, and I've never seen a company who'll let an employee take time to figure out the elegant way of solving a problem. It's just not realistic. Generally, if it works, it works. It's just not a luxury that most companies can give their employees (whether contract or 'permanent'). Gov't agencies and universities are good about this, but most programming projects that I've worked on focus on getting the project out of the door, ASAP. If I were to take an extended amount of time to solve a problem, generally, I'd be out the door.

Re:Suggestions for better software (4)

Lucretius (110272) | more than 13 years ago | (#413639)

The problem that you speak of is not new at all, and is definitly not confined to the realms of computer programming. When it comes right down to it, nobody wants to do the dirty work that is required to get a project done (i.e. bug squashing, documentation, general project managements) , they would rather go out and do the new and fun stuff (which in this case is adding new features).

This is just a fundamental flaw in human nature. People want to get all the glory and credit and nobody wants to do the background work that is required to make something actually work. Look at politics... everybody wants to be president, nobody wants to be his aides that actually run around and get the shit done (well, some people do, but most don't).

This was also a problem in ancient Rome, when you actually look at it. Everything used to be paid for by donations from the rich folk. However, everyone wanted their money to pay for something big and wonderful that everybody loved (such as theathers and circuses, etc), but nobody wanted to pay for the smaller bits of infrastructure that held everything together, as they wouldn't be remembered eternally if they gave money for the roads to be resurfaced or for general maintenance of the aquaducts.

Its the same thing with programming. Nobody thinks they'll get any credit for the bug fixes that they work out that makes the product actually work, they want to be known for the feature which they implemented (even if nobody actually needs it or wants it in any way).

Re:I tried this with assembly coding, once (2)

hugg (22953) | more than 13 years ago | (#413640)

Ha -- you thought you could instruct him in the ways of the Jedi, and he turned to the Dark Side. Shame shame :)

Re:Hey CmdrTaco! -- first lesson: (2)

heller (4484) | more than 13 years ago | (#413641)

The first lesson I believe you should offer is the concept of "right tool for the job".

For instance, when you have a database that's supposed to be receiving many inserts (as say, one that accepts lots of comments for posts or changes to user profiles) it's a very bad idea to use database software which does full table locks.

Right tool for the job.

** Martin

I Was an Apprentice (3)

ec_hack (247907) | more than 13 years ago | (#413642)

My first real job out of college was with a small startup doing a turnkey system for medical labs on PDP-11s. I was an Astronomy BA with a couple of coding classes (FORTRAN, APL and PL/I) under my belt and a couple of summers working in the DP shop (COBOL, RPG II, and PL/I) of a Fortune 500 company as an operator and programmer. I'd read a few classic books on programming and software engineering. In other words, I knew enough to be dangerous.

I joined a team of 4 other programmers that were under tight deadlines to rewrite a medium-sized database and reporting system. Despite the time pressure, the lead programmer/architect made me do a several month long apprenticeship under him, where all my code was reviewed by him before released. All the programmers that joined the company, no matter their experience level, had to do one also. It made me a better programmer, and it had the side effect of forcing a common style on the entire programming staff, easing maintenance. As programming is essentially a craft, an apprenticeship is a good way to learn from a master. Just make sure you apprentice from a master and not a poseur.

Re:Suggestions for better software (2)

johnnyb (4816) | more than 13 years ago | (#413643)

I think you're forgetting something. Who are the testers of open source projects? The _users_. That's why they let untested software out to the users, because they _are_ the testers. If you don't want untested software, either (a) use well-commended versions of software, or (b), test it yourself. You might say "Oh, a commercial organization shouldn't have to test software itself!" But then you would be living in a dream world. Every medium-to-large organization has to test its software. If you pay millions of dollars to Oracle to get the latest version of Oracle Applications, then you, yes you, will still have to put in a LARGE amount of work testing. In fact, some releases of Oracle Applications are completely non-functional. AND THIS IS WHAT THEY ACTUALLY SELL TO END-USERS! So, as the user, you have to test free software. And you have to test proprietary software, too. Which would you choose?

No debugger? (1)

dstone (191334) | more than 13 years ago | (#413644)

That is the stupidest crap I have ever heard. What if you don't have a debugger?

Ok... I'll bite... If you don't have a debugger, you have no business writing code.

Maybe you have a future in technical writing or user training. Or marketing. ;-)

The Way of the Bard (5)

Ricdude (4163) | more than 13 years ago | (#413645)

A more applicable model might be similar to the way of the bard:

Seven years learning
Seven years playing
Seven years teaching
Repeat.

The idea is that the would-be bard spends some period of time under the apprenticeship of one learned in the art. After acquiring some basic skills (melody, harmony, scales, etc.), and some examples of how to combine those skills (a repertoire of songs), the bard is then sent off to earn a living in the world. While doing so, the bard experiments with new ideas, merging them with the body of knowledge acquired from the master. After some time, the bard takes on apprentices, and shows them what they've learned from their master, and from their own experimentation.

All too often, what's lacking in the free software world of half finished IMs and mp3 front ends, is the "combinations" of those skills. A lot of these programmers barely understand pointers and event driven programming, yet they're building full GUI programs as a method of learning more about how to program. Frequently, they bite off more than they can chew...

Re:Programming has nothing to do with schooling (1)

Neumann (240442) | more than 13 years ago | (#413646)

I admire the person who can sit down for two days, learn the essential elements needed for the task at hand, pound out a bunch of code and have it running fairly smoothly. I admire even more the person who spends a month researching all aspects of a topic, thinks about several different solutions to his problem, laboriously works through his code, tweaking it thoroughly, develops a beautiful structure, excellent documentation and clear, elegant code But who would you rather pay $100 a day to?

"Computer Science" at my school is a joke. (1)

jrcamp (150032) | more than 13 years ago | (#413647)

My state (South Carolina) requires a "computer science" class to graduate. Guess what they define "computer science" as? Microsoft Windows and Office. My highschool doesn't offer *any* real classes pertaining to programming, but they think they're really on top of this technology stuff. Unfortunately, they don't realize that there are other aspects of computing other than "point 'n click." Hell, weren't public schools teaching Pascal 10 years ago? I'd settle for a class in that.

In the past, they have offered Visual Basic as a course, but it never took off because not enough people signed up for it. I didn't even sign up for it because I knew that one of the ignorant Windows/Office teachers would end up teaching it and it'd just be a waste of time. Hell, this teacher can't even get a decent webpage together:

http://www3.teleplex.net/dhs [teleplex.net]

Next year is my senior year. It's too late to get some real computer science classes incorporated into the curriculum, but I'm going to try and inform those in charge of the curriculum what a horrid job they're doing in the area of computers so that people like me may have a chance in the future.

Danger Will Robinson... (1)

Gadgetmeister (194993) | more than 13 years ago | (#413648)

I agree that this is a lofty, laudable goal. Maybe there always needs to be a drive in this direction.

Unfortunately, there are human beings involved. Some of these human beings, both on the mentor and student side, may seem quite nice on casual observation. Indistinguishable from people that are what they say they are, that they care about quality and learning and doing the right thing. Some of these individuals will stab you in the back. Some are incapable of 'getting it'. Some are much more interested in what your project can do for their resume than in actually doing the work. Some are, in addition, good politicians. Better politicians than you are. You can wind up royally screwed.

In summary, I'd recommend that you choose who you work with carefully.

Re:Programming has nothing to do with schooling (1)

Lt (31829) | more than 13 years ago | (#413649)

Make that link to Godel's Theorem, EveryThing2 [everything2.com]

Hey CmdrTaco! -- second lesson: (1)

shagster (2319) | more than 13 years ago | (#413650)

The second lesson would be desgin around the process not around the tool (Okay, ties into the first, but it still is important). If you are picking the right tool then this will not really be a problem.


Writing software to accomplish a process will almost always force you to use the right tools and allow you to switch easily to a differnt tool if need be.


Coding around problems with your design choices is just a bad idea.

Re:Suggestions for better software (1)

roman_mir (125474) | more than 13 years ago | (#413651)

"Not having testers, or having testers and not listening to them " - as extreme programers believe there is no need for testers if you do your junit right :)

Some software has to suck... (4)

11thangel (103409) | more than 13 years ago | (#413652)

There are too kinds of software that you'll find on download sites. Software that is intended to get the job done and software that is intended to help the programmer learn wtf he is doing. You'll very often find more of the latter than of the former, but each plays its own role in the programming community. If you see a piece of software that sucks, dont just delete it, email the author and tell him that it sucks. Let him know what you think is good and bad, so he can learn. Who knows, you may be helping out a future alan cox.

Suggestions for better software (4)

atrowe (209484) | more than 13 years ago | (#413660)

I've got a suggestion that I believe will help improve the quality of software, especially open source software. It seems that whenever an open source project is out there, coders seem to be overly focused on adding new features rather than improving/fixing existing ones.

Have you tried to use Mozilla lately. It's loaded with bloat and crappy features I'd never want to use, but when it comes down to it, Mozilla is absolutely horrible as a web browser. When the Mozilla project was begun, I thought that it was an noble idea, and was eager to start contributing code, but I soon realized that human nature goes against the open source model by seeking out self gratification and promotion, often against the benefit of the group as a whole. This is an inherent flaw in the open-source philosophy. Everyone is seeking their own selfish gratification in being recognized for adding a new feature to a program, but no one is willing to try and make the existing features work properly.

I'd like to see this issue addressed more often in programming circles, because something desperately needs to be done.

Re:Could mentoring turn into a guild or a union? (3)

hta (7593) | more than 13 years ago | (#413670)

Sure. Join the ACM.

Re:Don't teach them to program. (2)

Baarrff (166323) | more than 13 years ago | (#413671)

Finally someone who gets it!!

Lines of code are no different in principle than the tools used to cut a beam that is used in a bridge to cross a stream.

Really good software comes from people with problem solving skills, not coding skills!!.

Re:Programming isn't Just About Functionality (1)

mark_lybarger (199098) | more than 13 years ago | (#413672)

This is so true!
One of my first assignments out of school was to write a "reformatter" because a file format from the vendor was changing. It was a horrible mess of FORTRAN, but got the job done, for about a year anyway, until the format changed again. I quickly learned the power of perl, and put it to use.

Re:Also a great way to even out the "Classes" (1)

elflord (9269) | more than 13 years ago | (#413673)

I don't think your idealistic and stupid at all. I read an article in the NY Times about big companies setting up tech training programs in homeless shelters (!)

BTW, I didn't have any skilled instructors in my school and I did OK. As long as computers are cheap (and cheap they are -- if you don't require the latest and greatest.) they will be accesible to those who want them.

a guild... hmmm... (1)

acmwallace (213050) | more than 13 years ago | (#413674)

My current favorite thought about programming: Always code as if the person responsible for maintaining your code is a maniac serial killer who knows where you live. Too many coders forget that. I actually like the guild idea myself. Good programming is a bit of an art-form, a craft, so why not a guild?

There's a "leap" that you just can't teach (1)

dmorin (25609) | more than 13 years ago | (#413675)

In all my years of coding, the best way I can sum up the experience of trying to teach people to code is that one day they make a leap at which time things become obvious. Sometimes they can't make that leap. You see it in their eyes. I fondly remember the experience of teaching a consultant a new proprietary app server. He stared at me with glossy eyes. The next morning he was waiting for me in my cube. "I get it!" he cried, with a spark in his eyes. And I knew that he did. He went on to be one of the best resources that team had. For every good story like that, I have a dozen not so good ones of people who have to be told the same thing over and over and over again and just never grok it. We as mentors can probe and prod that particular area of the student's brain that controls the leap, but I've always found it to truly be a quantum thing. They either make it or they don't.

I'm in a position where I get handed problems after the team has pulled their hair out for days or longer. When I solve those problems, I send out an email detailing (or attempting to) my thinking process on solving the problem. It's weird, because on one hand I'm thinking "I'm writing down obvious things here, aren't I?" but obviously they're not. How do you teach that?

A consultant that floated through my place of business used a term I don't hear that much -- "The ability to internalize the code." I like that. If they don't internalize it, they'll never generate quality code.

I'm all three of these programmers... (2)

drnomad (99183) | more than 13 years ago | (#413676)

and I'm sure a lot of Slashdotters are.

In my opinion, if you want people to be able to program, then you should think of your brother/sister or neighbour participating in the programming world. First the apprentice sees is the Presentation of the application, then it's the data they'll see, and lastly you could bother them with the algorithms used for the data-flow-processes. If they can handle this, bother them with quicksorts and hashtables. Can they handle that? Let them enter the world of Lex and Yacc.

What you can see is that levels are going from up to down. Not everybody is able to program at deep levels, but everybody should be able to make themselves useful. In order to do this, I think certain programming model (i.e. based on n-tier systems) should be made. People can focus into the level they want, and hop upwards and downwards at their own will. Perhaps a new programming model should be designed for something like this, I'm not sure it's possible...

Re:Those who can not....teach (2)

bmongar (230600) | more than 13 years ago | (#413677)

I disagree on several accounts. First my company does consulting,mentoring, and education. The people who teach the classes also program and mentor. And the teaching pays better, so those who can teach at my company. Also the loss of productivity for mentoring may be like you described for a short period of time, but the person being mentored improves his effieiency, so there is an upfront hit in productivity but over the long run you gain as the student learns and no longer needs mentored.

We have had a great deal of success with our mentoring program. We have gone in to many companies, helped design architecture, mentor the team on OO methods and Java, and help with the first iteration. Those companies usually have us back when the have new products because the projects we started were successful

Re:Programming has nothing to do with schooling (1)

fizban (58094) | more than 13 years ago | (#413678)

Guess you didn't go to school, huh?

Most computer science "kids" know better. They realize that programming is just one aspect of a bigger picture. They are being trained in the science of software engineering, not just programming. Some fail in this, but most come out of these programs with excellent training, especially if it's from a major University.

The idea that we should program to "make it work" causes more problems in the software world than any other item. If we spent time analyzing our work, developing more elegant solutions and thinking about the future effects of our immediate development efforts, we'd have much stabler, faster, and overall better working software than our counterparts who just do it to get it done.

I admire the person who can sit down for two days, learn the essential elements needed for the task at hand, pound out a bunch of code and have it running fairly smoothly. I admire even more the person who spends a month researching all aspects of a topic, thinks about several different solutions to his problem, laboriously works through his code, tweaking it thoroughly, develops a beautiful structure, excellent documentation and clear, elegant code.

And to say that it's not possible to stay employed working in this manner is not true. It's only a problem if you work at a company who doesn't understand the realities of bad software development. And you've seen where most of those companies have gone in the past 6 months...

--

Re:Suggestions for better software (1)

Vanders (110092) | more than 13 years ago | (#413679)

You're right, the users are the testers. But my point was, that there is no structured testing done.

If your users need to be your testers, you could at least supply some form of test plan and ask them to try and follow it and report back. That way:
  • You can be sure that the testing being done at least covers all the functionality of the software
  • You can track what has and hasn't been tested in your software, and if need be, carry out the remaining tests yourself
Maybe it's just a pipe-dream, but its something that is sorely needed in a lot of Open Source projets.

The most important thing is Documentation (3)

rebelcool (247749) | more than 13 years ago | (#413680)

I wish that schools would teach how to properly document your code. All too often I download something from sourceforge, only to find it be a horrible mess of code that has perhaps 3 or 4 lines of documentation in the entire file.

Without proper documentation, an idea or program is next to USELESS to future viewers.

All the greatest ideas have been well documented..take the RFC documents as an example. They are very rigoursly reviewed and follow a very strict code of documentation. And they form the basis for all that the internet is today.

Document your code!

Re:The problem with bad code (3)

Samrobb (12731) | more than 13 years ago | (#413681)

...they just write code that works, but don't worry about "elegant," algorithimically well thought out code.

Hmm. There's can be a vast difference between "elegant" code and "code that works". I've seen beautifully written, well thought out code - written by incredibly knowledgeable folks with CS backgrounds - that did just plain damn stupid things when you considered the hardware or OS. Things that resulted in programs running about 10% as fast as required, or using about 10 times more memory then available... but boy, it was sweet code to review :-/

OTOH, working code - code that does the job to spec (speed/memory), runs on the target hardware - can be just plain damn ugly. Not unused-variables-scattered-all-over-the-place and no-error-checking ugly, but convoluted, non-obvious, "we did it this way to squeeze a 2% performance increase out of the system" or "we did it this way to avoid an obscure error condition" type of ugly.

There's a time and a place for both types of solution. Knowing when you have to do something ugly is as important as knowing when you need to put the thought in and come up with something elegant.

Re:Programming isn't Just About Functionality (3)

john_many_jars (157772) | more than 13 years ago | (#413682)

Excluding multi-process/multi-thread timing conditions, politics of design, promises made by salespeople, and ill-formed specifications, this is a reason why systems crash.

My current project at work has a very fluid specification. I cannot tell you what is garbage and what is good for a particular module until the module is written and given for inspection to those who are designing the overall process to use the software. That means I have to make guesses about something I know nothing about so as to make a design that will work with something. All I have are guidelines. Should the guildelines change a week before delivery, in goes the fix--sans testing and sans rational design philosophy. In a word, I knowingly write shoddy code to fit political design decisions to meet deadlines set by ill-advised individuals who know not the first thing about how a computer operates.

Quite possibly, the single biggest problem with coding is the concept of a deadline. The second, almost because of the deadline, is the "I'll figure that out later" philosophy. Without a full blueprint of an application or system, (hell, I'd be happy with an accurate spec once in a while) it is impossible to make sound decisions. Ergo, bad software.

What you speak of are luxuries to your average code-for-a-living individual.

PerES Encryption [cloverlink.net]

Re:Software apprentices (2)

chromatic (9471) | more than 13 years ago | (#413683)


I tried to avoid the term 'apprenticeship' because it might bring to mind unpleasant connotations, and because it assumes that all people being mentored are less capable programmers than their mentors.

Interestingly, the Perl 6 community has had a similar proposal [mail-archive.com] since I wrote this article. The objective there is to get capable programmers familiar with Perl internals. It's possible to help out beginning programmers, too, but someone who already knows how to code fairly well could get into the guts of the regex engine or optimize pp_hot.c better with guidance from someone who's already been there.

(OT Sig comment: If I could pick a guitar mentor, it would be Michael Roe.)

--

Hello Mentors! (1)

4eek (302404) | more than 13 years ago | (#413684)

Are there any Mentors (Elves) out there willing to listen to the same old questions being made by some beginner?

The problem with bad code (5)

Faizdog (243703) | more than 13 years ago | (#413685)

Is partly due to the inexperience/naiveness of the coders. But another factor IMHO that i've noticed in my experience has been big is simply human laziness. So many coders I know don't document, "can't be bothered to", they just write code that works, but don't worry about "elegant," algorithimically well thought out code. You can never just sit down and begin to code. And please don't tell me you can, I can just sit down and crank out a buncha programs too, but I mean well thought out plans. ( I dont' mean the BS stuff like Requirement's Engineering, Software Architecture, etc. although that stuff is sometimes useful), but just to sit down and think about what you wanna do and what's the most efficient way to do it.

I'm not trying to be troll at all, so please don't think that. I'm just saying something that I've noticed. Plus I can't emphasize the importance of documentation. Currently I'm expanding upon a project that has a few thousand lines of code, and it's hardly documented. Hacking the code and trying to figure out what it's doing is tedious. Please document, it doesn't mean you are a bad programmer, actually means you are a good one.

I tried this with assembly coding, once (4)

kyz (225372) | more than 13 years ago | (#413687)

I'm on several mailing lists, including ones regarding oldskool music ripping. One particular person had written a ripper in a high level language, and wanted to know more about assembler language so he could make it rip much faster. I quite happily offered to help teach him assembler.

He understood most of the assembler instructions, by my comparing them to the high level constructs, and showing how they are built. However, the point he got really stuck on was optimisation (which is really the point of asm coding nowadays), particularly memory access. He didn't see why accessing unaligned data was bad. So I showed him how memory is logically addressed versus the physical bus requests the CPU has to put out. I think this was the straw that broke the camel's back. He said 'thanks, but I think that's too hard for me', and he's now a Visual Basic coder. (No, really. This isn't a joke.)

Also a great way to even out the "Classes" (3)

Kostya (1146) | more than 13 years ago | (#413691)

The haves and have-nots will become even more sharply divided in the years to come. Technology is quickly becoming a requirement for work experience. But how many lower income area schools can afford technology, let a lone instructors skilled in teaching that technology?

I have had this idea for a while, but it is taking me longer to implement it.

Enter a non-profit/profit company combo. It teaches, instructs, and mentors young under-privileged children in IT skills (specifically programming). It then turns around and seeks business support from the community: i.e. a local business has the company build their website for a cut rate, and the company uses the local kids exclusively for the project. Kids then get work experience and knowledge. The key focus being training the kids and getting them work experience--not necessarily profit. It wouldn't be the latest greatest way to make millions.

Perhaps I am idealistic AND stupid, but this seems like an effective way to reverse the tide a little bit. Local programmers could volunteer time for instruction, whereas someone would have to work full-time for the company to take care of project management.

Re:Suck Less (2)

bmongar (230600) | more than 13 years ago | (#413694)

Of course with most free software, since there is no one promised a product that withdraw their money if it doesn't happen there aren't many deadlines.

Suckfactor in free software is often due to inexperience or people not putting enough effort into it because they aren't getting paid.

I get paid to program all day and I sometimes teach classes in programming in the evenings, when I get home I am not motivated to do program anylonger. Especially not for free.

Re:I'm akarma whore (1)

Hiedi Wall (318437) | more than 13 years ago | (#413695)

since I'm only 12 I am very open to almost anything

Re:Programming has nothing to do with schooling (1)

fizban (58094) | more than 13 years ago | (#413700)

The one who spends time developing a better solution. The cost savings will be realized in the long term.

--

Re:Suggestions for better software (2)

update() (217397) | more than 13 years ago | (#413701)

Everyone is seeking their own selfish gratification in being recognized for adding a new feature to a program, but no one is willing to try and make the existing features work properly. I'd like to see this issue addressed more often in programming circles, because something desperately needs to be done.

I agree with you about the problem but there's no reason why debugging, usability improvements and documentation have to be considered less important contributions than adding new, marginally useful features. The celebrity-worshipping pecking order that's built up around free software makes that judgement. Slashdot raves about shaded transparent pull-down menus and the guy who added them - not about the person who translated the app into Japanese, wrote the documentation or made the interface more intuitive. If that situation were reversed, you'd see a lot more people doing translation and documentation and fewer stupid features like text preview in file manager icons.

Everyone knows who Miguel is - how many people can name the heads of the KDE and Gnome documentation projects?

Re:Suck Less (1)

GreyLurk (35139) | more than 13 years ago | (#413704)

My guess is that a lot of people write already existing programs from the ground up and release them because the previously existing programs don't have quite the functionality they are looking for, and adding the functionality to the exisiting programs would be more work than a fresh project.

Of course, in the wild, one of them always rises above the others, and will be extended to envelop the functionality of the others...

Another reason for the massive number of message boards and web-mail interfaces in the public domain, is because they are easy to write. They make a good "first time" project, becuase they are simple enough to allow one programmer to see them through from beginning to end. It's not so much a competition, as a tutorial.

Re:Suck Less (2)

rw2 (17419) | more than 13 years ago | (#413707)

You seem to have focused on the 'scratch the itch part'. If it isn't acclaim (and, of course, I didn't invent this idea. ESR popularized it in our culture) that drives people the release as I claim, then what is it in your explaination?

--

Re:Hey CmdrTaco! (5)

Shoeboy (16224) | more than 13 years ago | (#413709)

Hi,
Your comment on denormalization demonstrates a lack of real world experience. Denormalization on databases where reads massively outnumber writes (which is slashdot) is a very useful thing.
As far as making it difficult to make future modifications goes, this is complete B.S. As long as you encapsulate your data retrieval and manipulation through stored procedures (which slashcode doesn't do) all changes to the database schema are easy to make and very few modifications to front end or middleware code are ever required.
The simple fact is that no perfomance critical system should ever run in 3rd normal form. Period.
--Shoeboy

Re:Suggestions for better software (2)

Jason Earl (1894) | more than 13 years ago | (#413710)

You're right, the users are the testers. But my point was, that there is no structured testing done.

Actually in almost every single Open Source project that I can think of there is the equivalent of the "unstable" and the "stable" branch. The unstable branch generally has some nifty new (but untested features). The users that actually need those features excercise them (often in real world conditions). When it looks like it works as advertised it gets rolled into the "stable" branch.

There is no need for a more formal set of tests for the simple reason that the people testing the software are generally in close touch with the people writing the software (ie, there isn't a focus group in the middle). In other words the features generally get specified due to specific needs, and testing against these needs is very straightforward. If you have features that no one is willing to test, then you probably should consider removing those "features" for the good of the project. Clearly they aren't useful.

Now, the best projects do have a set of regression tests. That way you can excercise the various components of your software individually and as a whole. This is quite helpful to make sure you aren't introducing any new bugs in your software.

Planning, good design are key (1)

b100m (69755) | more than 13 years ago | (#413711)

I agree on the laziness factor, but I think that
spending time on design is often overlooked. If you can't get a project done with a good design that can be verified by your peers in the time allotted, you're doing the wrong project.

Secondly, document, document, document. I have adopted a saying that I heard long ago: "Not everything doing is worth doing well." Now that may appear to fly in the face of what I have been espousing, but a hack that works and is documented is much better than something brilliant that isn't easily maintainable.

I just wish the developers in the early '80s who wrote this legacy app that I'm supporting had learned to plan, design and document. <grumble> Remember that what you write today may stick around for a long time. At least make it maintainable. You'll make junior coder's life a lot easier in the future. : )
_______________________________________________ __
$which weed

Re:Suck Less (3)

Mr. Slippery (47854) | more than 13 years ago | (#413712)

Why else would someone write a message board when ten already exist? To scratch an itch? Partially, but that only explains why they write it, not why they gift it. They gift it in order to win the acclaim of their peers.

Sure, words of praise are nice, but that's hardly the only benefit from giving.

If you've written mainly to "scratch an itch", there's little reason not to give it away. You can gift it, try to sell it, or keep it for yourself. Keeping gains you nothing (unless you've written The Program That Will Enable You To Take Over The World); and as for selling, the population of people who have the same itch and are willing to pay to have it scratched could be very small.

When you've put time into something, you want it to be seen and used. I've spent years working on projects that never amounted to anything except a dusty tape on someone's shelf - that sucks.

If you gift it, they will come - maybe only to snag parts for other program they're writing, maybe to take what you've written and keep it alive and growing. A program that only I ever use is like a poem that only I ever read...I don't share my poetry primarily for acclaim, I share it because I'm wired to delight in infecting others with my memes.

Tom Swiss | the infamous tms | http://www.infamous.net/

Re:Suck Less (1)

alprazolam (71653) | more than 13 years ago | (#413713)

i think the problem is probably more related to the fact that there are a lot of stupid people writing software, and it only takes one stupid person on a team to make the end product crap. also in business software you have people buying software that their employees use. the managers don't use it though so they ignore bugs and buy based on features, then software companies compete based on features, and you have crap like mentor graphics stuff (well its not really crap but it could be better if it had less features and more stability).

I will say this... (3)

jallen02 (124384) | more than 13 years ago | (#413717)

The "network of peers" cant be expressed enough.

ALmost every programming language and application out there has a community of some sort.

Being involved in the community and being able to hands on talk with people who have been doing it a long time and have these gurus respond to you the little guy and see how they would do something can give a new programmer more insight in one email post than four chapters from a book.

Learn about the thought process from a brilliant mind and how to analyze a situation rather than learn about a specific way a book says to do something and again you have just made huge leaps and bounds over where you previously were.

Enthusiasm can take you a very long way, never giving up persistence and above all studying others works.

Its just like at chess, if you always play people worse than you your not learning much, whereas if you play someone who beats you in three or four moves the first time you play them you must work that much harder and you will become a much better player as a result. Just like having a mini Linus Torvalds with you as you write a new kernel module the benefits are quite obvious..

you will find that langauges and platforms with the etter communities can some of the time attract developers much easier than other language.

:)

Jeremy

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...