Slashdot Mirror
Making Software Suck Less, Pt. II
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.
I think nobody teaches new programmers how to write their code so that other people can read it. This includes writing comments for everything you do, indenting correctly and creating variable names that actually make sense. Effective coding style makes it easier to debug and release code faster. I believe that you can easily judge how long a person has been coding (or how well he knows programming) by looking at a snippet of his code. MT
Windows ruins all
My kernel module won't load
Stop and fill timesheet
The only thing that we learn from history is that nobody learns anything from history.
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
Sir, you are undubitably correct. Undubitably I say.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
Why not mention IE? IE seems to be stable and functional under Windows2k. I run Linux on one box and Win2k on another. They both have relatively similar uptimes. IE is by far the best browser available currently. Konqueror is nice, but I do not see too many plugins available for the linux platform. I use my linux box as a server and firewall. My Win2k box is my documentation/development box. Both work fine. I fail to see why everyone is so damn rabid about one or the other. I just use what ever works and gets my intended job done. I have no politcal ambitions, no hidden intents when I decide to pick up a piece of commercial software. I also have no "stick it to the man" ideology when I decide on using a piece of free software.
I really fail to see where and why all this politcal b.s. got started. It is not "us" against "them." There is no us and there is no them.
Regards,
cats
Another thing that big companies do, that open source developers often don't (flame gates are now opened, commencing in 5...4...3...2) is contributing resources completely and totally to bug fixing. Think about it this way, if a big company wants to use a program and they've commited themselves to it, they will lose a lot of productive time if their developers/users are held up by bugs. It is in their economic interest to hire people to squash these bugs so that their resources will be able to work w/o having to implement work arounds and things of that nature.
To your average user, the program crashing every once in awhile isn't the biggest itch in the world (its a bit annoying, but we can live with it usually because what we are working on is more of a liesure quality than a life and death quality). A big company, on the other hand, is in more of a life and death situation, thus this is not just an "itch" perse, its more of an inflamed rash that would be rather nice to get rid of.
Now, as far as contributing to mozilla, I guess that's a personal thing for each person... I could see it being a major world of suck if you had to download the entire source tree over a 56k connection (its not all that wonderful over DSL as it is), but that's the unfortunate fact about a product that is that big.
Let him know what you think is good and bad, sure, but for don't actually use the term "sucks" in your email ;) That'll turn most people off.
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.
--
+1 Insightful, -1 Troll. What can I say, I'm an Insightful Troll.
Then I realized that this is not what you were saying, so can I add this in as well? ;)
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)
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
--
+1 Insightful, -1 Troll. What can I say, I'm an Insightful Troll.
I'm an embedded/DSP guy and I'd kill for a debugger. The only thing I have for debugging are outputs and inputs. Everything else is a black-box, with no way to see interactions within or between processing units.
Not everyone programs PC's, keep that in mind.
-tjb
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
These kinds of programs are already out there.
At my high school, last year I took part in a Cisco networking course, all about how to design, implement, and maintain networks (of course, using Cisco technology every step of the way), how TCP/IP works, structure of a packet, and other stuff.
While I lost interest right about where it said "ISDN is the prefered method of adding high speed internet connections to homes, remote sites, etc" and "Some users who are willing to buy expensive modems have 33.3 connections, but not everyone will...." but a lot of other students found it extremely useful, and it got them interested these fields.
(the other half of the class who decided it was just too hard for them and spent the rest of the year playing TetriNet)
That Cisco class would have worked out quite well, had the information been more current, but as it stands, I still learned a lot, and I hear things are better this year.
In short, it does work, and a lot of students are interested in taking advantage of Cisco's offer of $30,000/year right out of high school, or continuing to take Cisco sponsored coursework through college and earning more later on.
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/
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
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.
---
---
"Of course, that's just my opinion. I could be wrong." --Dennis Miller
This is because most programmers hate testing. Programmers see testers the way sysadmins view the first level tech support staff. As a direct result testing rarely gets a lot of attention. One of the basic rules of testing is that the extreme odd cases are the most important to check (and often the simplest). One of the signs of a really good programmer is how well they debug and test their code. The very best have lots of neat debugging techniques (like this one).
btw: Thanks for the breakpoint thingy. I usually check every branch but (as you discovered) the breakpoints will confirm test coverage. I expect similar results.
...and if you don't have a debugger put a unique print statement in each and check em off on paper until you hit em all.
Fsck cluebie moderators. I'll say what I want, offtopic or not. And fsck having to qualify every bloody statement just
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
That's cool. You can never be too careful in today's politically correct saturated society. :)
I had sex with a camel!
#include <memory>
#include <iostream>
using namespace std;
struct tst
{
};
typedef auto_ptr<tst> p_tst;
int test(p_tst x)
{
}
void main()
{ }
It would work with simple poiters, but will segfault with autopointers...
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!
Will someone mentor me on using OpenGL which I only started recently, I am on a Maths degree, I live in the uk and Im willing to do it by e-mail.
Mail me
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.
The paper means nothing...
I am a software developer..
I have no "paper" that says I know what I am doing, I just do know what I am doing.
Let me put it this way, I have neded up training and babying and then firing guys five years my elder with CS degrees because they couldnt handle the work they said they could.
I am 20 and I have proven myself through my work.
I design large scale applications.. Do I need a piece of paper to do so if it works and people praise me for my work?
Jeremy
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.
Check out Althea for a stable IMAP email client for X. Now with SSL!
Vanders wrote: "And no, outside of unit testing, the coder cannot teste their own code properly!"
I'd take exception with your exception. In managing programmers, you should always have someone else review test cases, including unit tests. One of the most common reasons for malfunctioning code is programmers misunderstanding the requirements. I guarantee you, if they don't understand the requirements when they write the code, they won't understand when they write the test wrappers and/or stubs, either.
It's good to have programmers write test code and devise test strategies. It makes them think. Having them do test code/specs for each other, too, makes them think even more.
I'm sure, however, since Vanders does testing for a living, he (?) will agree that a professional fulltime tester brings yet another perpective, and will find problems the programmers don't find.
The more testing methodologies you employ, the more problems you find.
The earlier you start thinking about testing, the less problems there will be to find.
The more problems you find in released code, the more there probably are still waiting to be found.
- 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.
- 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).
- 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).My problem isn't with non-obvious code. Such code is often necessary to squeeze performance or flexibility out of a language or system. My problem is with non-obvious code that ISN'T COMMENTED or documented in some way. If the code isn't self-documenting or easy to follow, it is the responsibility of the developer to document what is going on.
I think that the book _Code Complete_ by Steve McConnell should be required reading for everyone who calls themself a developer. Yes, the book is published by the evil Microsoft Press, but this book is truly noteworthy. It describes an approach to code-writing that is practical, efficient, and responsible. Get your hands on a copy if you can - you won't regret it.
I seriously believe that there is a vast difference between a programmer and a software engineer. And I think that as time goes on, we will see programming become more like other engineering disciplines, because customers are becoming less tolerant of late, over-budget software projects that miss the mark.
I think that many open source projects could use a bit more application of software engineering techniques, and less seat-of-the-pants coding sprees. Yes, the latter puts something out there sooner for people to bang on, but oftentimes that something is a big buggy pile o'crap. In the long run, software engineering techniques will deliver a higher-quality application that people will actually be able to use.
One problem with Computer Science is students get little education in physics or technology. The more often receive all their computer knowledge from university and have little breadth of experience. Engineers on the other hand generally get only 2 or 3 computer courses, but have broader experience and interesy both inside and outside of school which more than compensates. I would advocate the transfer of CS departments from Math faculties to engineering as a result (this seems to be a growing trend). Note that certification programs like MSCE, etc. carry zero weight with us and are almost a negative.
The teaching of Java in school is particularly troubling. Students who mainly have background in Java often really don't have a depth of understanding on how the computer works. This results in bloated kludges in whatever language they work in.
Example - anybody can put together an HTML web page. But, it requires a real depth of knowledge and breadth of experience to architect a commercial web application which doesn't suck. This 'big picture' view is what I try to hire for.
I am a mentor and have been for years. I worked under my own mentors before that. The problem is it has gotten increasingly hard to do this because of politics- and this is at a university, mind you. I can only imagine what it's like at places even more pound-foolish.
I like to hire students to work for me when they're pretty fresh. Mostly because I want to keep them around for a few years, but also because I'm hoping they've picked up fewer bad habits already. The planned arc is I keep them for three years or so, then they graduate and either come on full-time or go make the big bucks elsewhere (usually the latter, as you'd guess).
The problem is that people above me in the administration Don't Get It. They think it's a waste of resources to pay students who are a) busy enough with school that they can't work a lot of hours, b) only hang around a couple of years, and c) go take all our mojo and use it elsewhere.
My usual response is ``Excuse me? I thought it said "university" on the front door. We're supposed to be filling up their heads and unleashing them on the world.''
I then explain that you can't find people ready-made to work here, or I think as systems administrators or large project developers in general. They need to learn by doing it. It's that cycle people whine about, you can't get a job without experience, etc. Well, here's an in, folks. I'm just looking for people who are willing and able to learn.
This is my third department and fifth set of higher ups. Fortunately the first set of which Got It, or I wouldn't have come up in a good environment myself. It's been an ongoing battle with the subsequent regimes to keep things going.
I think the problem (like a lot of problems in computer related fields these days) is the public perception that because computers are commonplace (unlike fifteen years ago when I started), all things related to them are easy and competent workers are plentiful. Wrong and wrong, as slashdotters know.
A similar problem is with the students themselves who tend to underestimate the scale of the problems or overestimate their abilities. That's nothing new, though- been there myself- and both of those are pretty easy to improve, given a good environment. If only I could really provide one. :-(
Not to sound like the silverback hacker I am, but I fear for the future. If a university like this one can't provide a good breeding ground for technical people, who will?
I haven't given up hope yet, but I'm getting close. Anyone got venture capital for setting up a geek incubator? If the university won't guide eager students, somebody else should. Set up shop near each of your major universities and you'd get first pick of each year's crop of disciples for feeding to headhunters or whatever other businesses you have.
If it's cool and credible enough, people will work for you for peanuts (people offer to work here for free all the time). What're headhunters paying these days? Between that and pimping out whatever they're doing on the job to get experience, this could even make money.
When you want a branch here, give me a call.
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.
--
I guess I would have to put myself in the category of intermediate/advanced Java coder. And I've often thought that I could contribute to some free software project, but where? I guess from my perspective, it would be easier to start my own project than to try to decipher someone elses and start contributing to it.
And with only a couple hours a week maximum to spend on it, how much help would I be?
Did this post have a point?
I don't think GC will be truly accepted in the hard-core, must-collect-manually community until it's predictable enough to be used in hard real-time applications.
We need to be able to say, "Automatic GC will not prevent us from guaranteeing allocation and deallocation times, and we will not fail if there's still N bytes available (that is, we can make solid predictions about fragmentation)"
Not to worry, we're working on it :)
-----
Kvetch is Yiddish for "throw an exception" --Dr. Ron Cytron
First of all, that wasn't a spelling error, it was a typo. Secondly, I never claimed I was "above" anyone or that I anyone is inferior. What I stated was that there are not enough competent people in the field, which is a fact. If this were not true, then there would not be such a demand for IT people. I respect people and I expect the same from others. My point however, was that software sucks because the competent people get stuck with ALL the work (which is an enormous amount), while the incompetent get paid the same and do nothing 90% of the time.
Don't test me on this, I'm knee deep in it. And in the future, don't try to warp my words into me sounding like an asshole.
God I hate that.
So, does this mean we'll have a website with thousands of half-finished flowcharts? :-)
--
+1 Insightful, -1 Troll. What can I say, I'm an Insightful Troll.
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.
Unisys
Quit. Your. Job. Now.
All your hallucinogen are belong to us.
Will I retire or break 10K?
Mozilla is not yet at a 1.x release, thats why it sucks. Theres been a code freeze for quite a while. There just doing optimization and bug fixes now.
His head should roll for that!
I'm too sexy for you.
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? How do you debug a fullscreen application (game, media player, etc.) if you can't see GDB's window?
All your hallucinogen are belong to us.
Will I retire or break 10K?
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.
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.
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/
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
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!
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.
.. if only.
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!!
hmmmm?
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....
... 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...
É que os desafinados também têm um coração
Of course no one will deny that GC (as it exists currently) is not ideal for certain uses (e.g. real-time applications, as you mention). The problem is that there are so many things where the small potential penalty for using GC is far outweighed by its benefits, and yet it's still not popular for those things.
Hopefully Java is beginning to open people's eyes to said benefits, though I'd still rather have people come around and work in Lisp and Smalltalk. That's a different war, though. :-)
I'd have to say my experiences have been different. We've had repeated problems with IE not handling standard stuff in anything like a normal method and being forced to do frequent upgrades to fix these problems as quickly as possible as well as writing our code around the bugs. Stability has been somewhat of an issue in IE and Win2k also. Last week for example we had to completely reinstall Win2k Pro and all apps on a machine just to keep IE from crashing. These machines are brand new (from a good company) and have very clean installs of their software and run almost nothing besides Office 2000 and IE so they shouldn't have much to conflict with. Under any version of Windows I've tried IE has been fairly sucky.
:)
We also run MacOS 9 which has an entirely different set of IE problems but usually does somewhat better.
Netscape is just as bad as IE and is full of bugs on Windows, MacOS, and on Linux. While it usually handles http/html stuff better than IE it has less conformance with newer standards and crashes more often.
Konqueror is okay for a very light yet somewhat usable browser and may turn into something nice but so far I don't see it even counting.
Opera is okay but doesn't seem worth the cost to me and I'm not going to look at ads.
Mozilla is a little tricky as you still have to find a good build but there is plenty of community support for making this easier and usually it isn't that hard to find a good one that is recent. It is fairly full featured, standard compliant, fast, and stable on Windows, MacOS, and Linux. Even components such as Mail/News and the HTML Composser are shaping up really well. The fact that it is so cross-platform is also really good IMO. On the average day I work with Mozilla as my browser and mail program for around 10 hours and really beat the crap out of it and it rarely has any problem.
I don't care about 'sticking it' to anyone but I like software that doesn't suck and my experience has been that all software sucks and with commercial software you are stuck up a creek without a paddle. With open source I can either fix it myself or get online and get a fix often within minutes or hours. It isn't often closed source software has that good of turn around. I just wish I could find an open sourced bandwidth provider (whatever that would mean) cus companies are a pain to work with. "Ughh well we can have it done sometime a month after we promised." Of course some companies are better than others and so is some software.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
"It often also *seems* easier to rewrite something than to learn how somebody else's code works."
.. ?"
Rewriting IS easier sometimes while other times it only *seems* to be as you say. I think if a function or component is well designed, you don't even need to look at the code, you can just use it. However, if it relies on global variables or has other non-local effects, it's going to be difficult to interface with. Another problem is when a component has compound functionality and you only need a portion of it. In those situations, it may be faster to write your own version than to figure out the side effects.
"It doesn't always turn out like this though - some projects are clearly "the" projects in their class, e.g. Apache, GIMP. I wonder why
I suspect that the successful projects have the benefit of good timing and knowledgeable implementers. I think it's also an advantage to limit the number of contributors until the project is well established.
Java is worse.
I think the problem with Mozilla is that they implemented an 'ideal' architecture in terms of extensibility and cross-platform-ness, and made the decision that certain other things (conformity with the host interface, sparing use of resources, etc.) weren't important.
I think the problem with Mozilla is that it is version 0.8. As for the originator of this thread, who says the you can't get acclaim for fixing noticeable bugs? I mean adding a new feature is kewl, but so is finding a good way to speed up the app, or fixing some annoying bug. YMMV.
Fanatically anti-fanatical
> Garbage collection is for kids who haven't learned to reference count.
C++ is for kids who haven't learned to do everything in asm
asm is for kids who haven't learned how to do everything in s&k combinators
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
I think the problem with Mozilla is that it is version 0.8.
I think that commercially, one of Netscape's problems is that it has taken them this long to put out what amounts to a v0.8. Consequence of the bloated API? Who knows. It ceased to matter after the AOL buyout, anyway...
deus does not exist but if he does
It's like the BASF ads: "We don't make the things you use, we make the things you use better."
-bluebomber
The Daily Build
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?
/*doesn't mean shit */
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 =
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
No, problem solving is probably the biggest part of the equation. Sure, anyone can think up a brute force solution and code it up. It works, right? But if there is thought put into the algorithms, processors won't be bogged down, memory won't be taxed, everyone will be happy. I'm taking an algorithms class right now, and I'm surprised at how many problems can be solved simply, but even more surprised at how a nonintuitive (or more intuitive, depending on how you think) algorithm can produce a much more efficient solution. In other words, solving a problem is usually trivial. Solving a problem efficiently is a whole new problem altogether, and sometimes a more important one.
Here's an interesting presentation by Felix von Leitner called "Writing Small and Fast Software" . Unfortunately, it's a PDF but it's worth reading. Felix is the author of the "diet" libc, a lowfat reimplementation of libc inspired by DJ Bernstein's minimalist C coding style (qmail, djbdns).
cpeterso
The quote line at the bottom of this article happens (at this moment) to be:
"The whole world is a scab. The point is to pick it constructively. -- Peter Beard "
heh, quite the coincidence eh?
(stolen from DaBum) I am dyslexia of borg - your ass will be laminated.
You obviously know a lot about databases and database design, so I ask you... How are IDs non-relational?
I tend to use them because I like to map relational models to an object model, and IDs are very useful for this purpose.
Need a Python, C++, Unix, Linux develop
Add this one to the list:
A Garbage collector for C and C++
Don't bother with manual memory management unless you're writing OS kernels or device drivers. A good gc *will* do it faster than you, especially in a multithreaded program. If you *are* a memory management guru who knows how to optimize it better than any gc, you've probably written your own gc anyway and don't need this link. Otherwise, just get it, use it, and #define free(x) from now on.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
There are a dozen folks on my programming team, and we get to code and maintain the software that literally runs the flight operations center for a major airline.
It's fascinating work, the software has a lot of history (the application started being written in 1967), and the end result is used by a large number of very intelligent and appreciative users that we get to have first-hand contact with.
No way. I wouldn't leave this job for the world.
Besides, isn't everyone converting to PNG to get aware from CompuServe's proprietary format?
--
-Rich (OS/2 Warp 4 and Linux user in Eden Prairie MN)
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Have you tried to use Mozilla lately.
Yes, have you?
It's loaded with bloat and crappy features I'd never want to use
Apparantly you are talking about the default distribution on mozilla.org?
when it comes down to it, Mozilla is absolutely horrible as a web browser.
I disagree completely, it's good and getting better as they progress.
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.
That's a load of shit. Yes, there are some people that only want to add new features, features they want or need. That's the nature of an OSS project.
However, the VAST number of real engineers working on Mozilla are fixing bugs submitted by users and other developers. Take a look at Bugzilla if you don't believe me.
I'd like to see this issue addressed more often in programming circles, because something desperately needs to be done.
Herein lies the beauty. If you don't like the way Mozilla is being run, grab the source tree and branch off into your own group of coders that concentrate entirely on the current feature set, no bloat, and bug fixes only.
"And like that
Then any comments on signitures become orphins.
Table-ized A.I.
I think schooling can help a lot, if you are really serious about programming, then I think a well-schooled person generally grasps new concepts faster and adjusts more easily to different paradigms. Not to knock engineers, but I knew quite a few electronic engineers at university that were self-taught, and thought they could program really well, that they could program as well as the best comp sci students. After examining some of their code and their coding practices though, it becomes quite clear that their knowledge is not that broad (e.g. they'll say they know all about classes, when they don't really understand even virtual functions). The lack of schooling shows too; they will learn techniques slooowly, through trial and error, that are learned quickly when taught. I guess it depends on the individual though. I think some of the people I'm talking about were fairly arrogant, and would say stuff like "pah, computer science is such a joke, I don't need books and lessons to learn the stuff". Then their code shows that they haven't read books or taken lessons! But I guess if those same individuals were a bit more humble, and actually read some books first, then schooling wouldn't be so useful. So I guess if you *aren't* going to do a comp sci course, then at least adopt the right attitude :) Myself, the most useful things I learned at Univ. was NOT programming, but all the other things that I would not have had the initiative to pick up a book and teach myself, e.g. all the math, phsyics, electronics, AI etc. That stuff is pretty useful in my job.
If you believe (as I do) that programming is more a craft than it is an art or a science, then the apprenticeship model makes a lot of sense.
---glv
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.
--
Sheesh, evil *and* a jerk. -- Jade
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.
Heh, and he thought unaligned access was rough when it was slow... how about when it doesn't work, period? (odd addresses on MC68000)
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...
É que os desafinados também têm um coração
You two sluts better stay away from cyber monkey His 2 inch dick is all MINE!!!!
Trust god and don't fuck your camel!
Seems to me to be one of the myriad of ways of getting to know someone is by posting messages and seeing how they respond. :-)
Need a Python, C++, Unix, Linux develop
Garbage collection is for kids who haven't learned to reference count.
Mike
-- Could you use my software consulting serv
Uh... you wouldn't happen to be a MICROSOFT developer, by any chance, would you?
"Freedom means freedom for everybody" -- Dick Cheney
I know I'll be modded down for this, but I have to say it:
IMHO Mozilla is a perfect example of the "beauty" weakness in open source. Not all code is pretty, not all code SHOULD be pretty. I've seen lots of people (particularly academics) that focus a lot more on getting the most elegant or most technically correct solution instead of the one that works the best in real life. Mozilla has a beautifully designed interface system, that is scriptable and modifiabe...that takes a full 1/2 second to draw a menu on a PII 400 with 128MB of memory. I've not seen menus move this consistanly slow since my Mac LC (16 Mhz 68020 w/4MB of memory) days. In addition, Mozilla has taken approximatly forever to write (granted a web browser is a pretty compilcated thing to write).
Yes, I know the mantra: put out (code) or shut up, but quite frankly, I'm only one man, I can't contribute code to the dozens of programs I use regularly (although I do file bug reports whenever I can get a good backtrace and reproducable crash).
Beautiful code is one thing, fast and useful may not be be the same.
Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs.
I read the internet for the articles.
If you are looking for 'mentees', start with your local Linux Users Group (or Windows Users, or Mac Users (or Amiga BSD users if you like)). Especially with Linux, you are likely to find some imtermediate level users who are ready to learn new skills and move to a higher level of computer usage. If the group you find consists completely of college aged CS majors, encourage them to expand their membership, taking in some high school students, or technical professionals from local companies who are interested in improving their skills.
Developers testing thier own code is unproductive, because any situation they can think of to test, they would have already handled in the code. The proper way to test is to provide input the developer wasn't expecting; naive users are much better at this than programmers, who have learned to limit the things they do with computers so as to prevent crashes. Hence the need for Alpha and Beta releases...
"Freedom means freedom for everybody" -- Dick Cheney
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.
Amen to that. What has repeatedly disgusted me about education in the US is the dependence on procedural modes of teaching. When I began learning HTML in 1996 I almost went out of my mind at the sheer amount of useless 'web secrets' sites that merely regurgitated secondhand 'do this...' information. I was fortunate enough to stumble upon zeldman.com, but years of procedural education prevented me from making the best use of his wonderful information.
As redundant as it sounds, most of us need to focus on learning how to learn. Are there any books on object oriented thinking?
A Student of/for Life,
Ethan
Open source is a terrible way to develop software, except when compared to all the others. While it's true that "big" contributors to open source software want to contribute a big feature, open source is largely about the ability to scratch an itch. Lack of big flashy features don't generally itch, problems with existing features I want to use do. I've contributed minor bug fix patches to a number of open source projects but I doubt I will ever contribute a patch to mozilla. Why? Bandwidth. Downloading and building the entire source for mozilla is a complete PITA. Here's an idea. Configure build environments so that individual source files (and maybe include files) can be downloaded from CVS, compiled locally and relinked into their appropriate shared libraries. A lot more small itches would get scratched that way.
I learned this myself a year or so ago, and since then all my programs have been [more] neat and tidy.
A travelling programmer came to the cubicle.
"I seek Elegance" he said.
"Why have you come here?" asked the Master.
"Because I have read much of your code, and it is elegant. I have come to
find the source of it, so that I may write good code also."
"Then you have come to the wrong place." said the master.
"But are you not the writer of the code?" said the programmer.
"How did you know the code was elegant?" asked the master.
The programmer was enlightened.
Jeremy Lee | Orinoco
While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.
I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:
Haim can write the most difficult code, and it doesn't just work right, it is unquestionable.Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)
If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.
For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:
-
The Forum on Risks to the Public in Computers and Related Systems,
with such anecdotes as:
-
The Sinking of the USS Gitarro (because of either poor training, poor UI, or both)
-
The scary MSWord residue feature - exchange Word documents during legal negotiations?
- Also see the book
Computer Related Risks by Risks moderator
Peter Neumann
Reading Risks for many years is what has made me such a zealot for software quality. It has also made me tend to avoid using software for anything of real importance in my life, and to feel uneasy while flying aboard modern aircraft - even though, with a B.A. in Physics, I am very comfortable with the aerodynamic principles that hold airplanes up and used to enjoy flying as a kid.If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.
But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:
-
The ACCU Book Reviews Section
The ACCU is interested in more than just C and C++ these days, if you program in those languages, Java or (dare I say it) C-sharp you should join. The mailing lists is pretty low traffic and has some of the best signal-to-noise ratio of any list I've seen (except Risks). The ACCU's technical journals, with articles written by the members, are a valuable source of information on such things as how to write exception-safe code.(Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).
And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.
If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:
- Effective C++ - ACCU Review - be sure to get the 2nd Edition
- More Effective C++ - ACCU Review
After reading Effective C++ and More Effective C++, if you're programming with g++ (or using gcc to compile ".cpp" files) then you should use the -Weffc++ option to g++ to warn you about style problems. From the GCC Online Manual: Importantly, in any language, make sure your code compiles cleanly without warnings with all the warnings enabled in the compiler - use the -pedantic option in gcc.C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:
- C Traps and Pitfalls -
ACCU Review
People who write in any programming language, from assembler on through C and way out to prolog, really should go back to our roots and read the early book:- The Elements of Programming Style
Sadly, this book is out of print, but see the "E" Titles Section at ACCU for other Elements of Style books.Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.
Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:
- PC-Lint and FlexeLint
- CodeWizard - Linux Journal Review
Looks like I missed one when I spoke about Bounded Pointers for GCC, Spotlight, etc. in my previous post. Parasoft offers:- Insure
But note that these products use patented algorithms - number 5,581,696 and 5,860,011.You can search by patent number here.
And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?
Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:
- Useit
- Ask Tog
Finally, to make sure your HTML is valid, test it with the W3C HTML validation service. You have two choices of how to get your documents processed:-
By uploading static files from your browser - most convenient during hand composition
- By entering its URL in a form - best for dynamic pages and final tuning of static pages
Try this link for an example of running a popular web application through the W3C validator.Mike
-- Could you use my software consulting serv
I think the main reason that programmers start new projects instead of contributing to existing ones is simply that programmers naturally just want to rewrite everything. Its more fun. They would rather rewrite something than use somebody else's component. I think when one is trying to use someone else's stuff, one tends to often think "this is not exactly how I would have designed this" or "I would have named this function differently" or "I can write a better class than this" etc. It often also *seems* easier to rewrite something than to learn how somebody else's code works. This problem can be alleviated by teaching programmers to be disciplined about documenting their code nicely. But quite frankly it is usually more fun to write something yourself (the fun part is solving the problems) than wading through documentation learning how to use somebody else's existing solution.
I believe the OSS world could benefit a lot from an attitude change, more people working together. Take a look at just how much effort is being duplicated just between KDE and gnome. So rather than having one good 3d modelling program that rivals 3DSMAX, we have 5 or 6 crummy ones. Rather than having one good development environment that rivals Visual Studio, we have about a dozen (ranging from crummy to mediocre). Rather than having one good DirectX-equivalent, we have about half a dozen (ranging from crummy to fair.) And I think it makes it that much harder for newcomers to join a project. For example, I'd like to contribute to building a Visual Studio equivalent, but quite frankly, I'm stuck in indecision as to which of the several contenders might succeed. It seems impossible to predict. Perhaps this also causes people to start new projects - they see that there are 5 or 6 *crummy* ones, so they think "we need a *good* one", and off they go starting yet another mediocre project. Gosh, I'm rambling now.
It doesn't always turn out like this though - some projects are clearly "the" projects in their class, e.g. Apache, GIMP. I wonder why .. ?
For quite some time before that I have been writing GoingWare's Bag of Programming Tricks, a collection of articles on the business and practice of programming. Of most interest in learning how to program well would be:
- Study Fundamentals Not Tools APIs or OSes
- Properly managing memory returned by transcode() in the Xerces library (while about an obscure problem, it illustrates more general principles in a useful way)
-
Secrets of the Debug Meisters: MacsBug Tips and Tricks (MacsBug is a Mac OS assembly debugger)
I worked on an article on C++ programming style that is not done yet, and has some errors in it. But I'll post the URL here with the understanding that you're to take is as a preview and not gospel truth:-
Pointers, References and Values - Passing Parameters, Returning Results and Storing Member Variables, with Musings on Good C++ Style
Finally, if you program in C or C++, you need to be using one of the following tools, appropriate to your development system and platform:-
Bounded Pointers for GCC
- Spotlight for Mac OS PowerPC
- BoundsChecker for Windows
- Purify for Windows and Unix (but I think it doesn't support Linux)
If you use Java, you don't have to worry about dangling pointers, but you do have to worry about memory leaks (quiz: why do you in a garbage collected language?), deadlocks and so on. For that we have:- OptimizeIt
Don't let another day pass without availing yourself of one of these tools. I know most aren't Free Software and some are very expensive. I want to tell you that the money I spent on Spotlight is some of the best money I have spent on anything in my life. I wouldn't dream of shipping a Mac application to my clients unless it tested completely cleanly under Spotlight; on the other hand, the first time I'm given a client's code to work on, Spotlight usually reveals a multitude of sins.Mike
-- Could you use my software consulting serv
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.
so true... but then the slashcoders would have to admit that they all know almost nothing about real database work...
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.
That's quite a high school. Are the Computer Design, Semiconductor Physics, and Electronic Engineering departments nearby?
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.
as a senior Mac tech, guys like that keep me in steak and whiskey
Veteran, Bermuda Triangle Expeditionary Force, 1992-1951
Why are they 120 characters instead of 128?
Trolls throughout history:
Jonathan Swift
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.)
No Laughing Allowed!
great site for ultra newbies such as myself
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?
/. land is in the NYC Metro area and wants some help with Java, let me know.
If anyone out there in
"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.
Number one thing almost all OSS projects I've been with is lack of organization. Often times its hard to make heads or tails from the source. I never expect people to actually comment the code well (as well as they should anyway), but the organization of the code is really fairly bad.
Often times there is a large section of code used repeatedly in a program, which is intended always to do the same thing (such as getting player info from an id number or something). Rather than writing a function (so that the code would always be in one place and its purpose obvious) they instead scatter the same code several times throughout the program. That way, without commented code clearly explaining what is happening, it may not even be obvious that the code is doing the same thing. Is there something special about this instance? Some detail that is different? No, just repeated code. Then suddenly someone needs to change it. Rather than simply going and fixing the one area that has the code, now you have to find every section all over the code and fix it.
This same problem also reflects itself if you are trying port the program, for example from MySQL to PostgreSQL. Ideally the database layer would be mostly hidden from the program itself. Perhaps there is a section for db specific libraries or whatever, but usually the databases are accessed directly in the code. The explaination given is often "I'm using some features that other databases don't have". This is a pretty rediculous answer though, because that only makes it more important to isolate the database specific information. Often times the differences can be made up for programmatically, but its clearly going to be easier if the database code is seperated than if it is intermixed with unrelated code.
Perhaps this should be called modularization, but I think that there are many other areas that could use organization as well. For example, the data structures are often totally disorganized. Classes have come a long way in helping that, but its still a problem in a lot of programs.
Really, I suppose the key problem is that programmers often learn syntactically how to program, but not stylistically. Most of the newer programmers I talk to know all the functions, but they don't think algorithms and data structures are so important. Why should they since outside of a good CS class you almost never hear anything about them. We need ORGANIZATION and STYLE guides for newbie programmers most of all.
--Braeus Sabaco
This is SO educational! -- Kintaro Oe
Currently I'm expanding upon a project that has a few thousand lines of code, and it's hardly documented.
the question then becomes: are you adding the missing documentation? i bet you aren't. and neither would i.
So, when the name of the record company changes from "CBS" to "Sony" we have to update thousands of records?
An ID can remain unchanged forever. Ted Codd, the inventor of the relational model, thought IDs are so important he made them built-in, i.e. mandatory, in his book The Relational Model for Database Management Version 2 (Addison-Wesley, 1990). If he can't say what's relational, who can?
In what way are IDs non-relational in your point of view?
Software engineering is hard. Very hard. Did you know software people are considered to be #2 on the 'Smartest People' IQ list? (doctors being #1). The average software engineer IQ is 130 (source: www.mensa.com), which is well above average (108). Anyone can write a program, big deal. The vast ocean of Visual BASIC Programmers proves that (Beginners All-purpose Symbolic Instruction Code). But only a few can write software. Too bad none of them work at Microsoft. Bw
Wow. Sounds almost exactly how IE is designed: a collection of scriptable objects. Of course, you can use any scripting language that understands COM, not just ECMAscript. Interesting coincidence.
Java is the blue pill
Choose the red pill
"Make sure you buy or use open source" applies to in-house projects only, of course.
And "make clean;make" was a recommendation, not a rule, just because of the reason you mention, since it can take too much time. We use make + Java, and it I'm not sure it works that well. Is Ant the solution?
http://jakarta.apache.org/ant/index.html
I'd suggest all of you who teach at any level to encourage your students to contribute to an on-going open source application as their class project. I do this for my web enabled database development class for UMASS and I think if nothing else it's exposed a lot students to a cooperative method of developing software.
If you take this route you'll be rewarded and they will also as their project will live on instead of being part of the academic waste heap.
I also had my eyes opened- most of my students work in the "industry" but maybe 10% of them are aware of open source or what Linux, BSD et al are all about. If nothing else, you can use your classroom to spread the good word.
Justin
Average IQ = 108?
I thought that by definition the average IQ was 100.
----
Off topic aside: I once received a set of puzzles and 'mind' games published by Mensa as a gift. They didn't hold much interest for me, and shortly thereafter I moved. Moving always involves ridding oneself of detritus (like puzzles), so I scheduled a pick-up by the local charitable organization for my box of Stuff That Somebody Might Want.
It was only as they drove off that I realized I'd just donated a collection of Mensa puzzles to the local Association of Retarded Citizens.
I think we should be teaching kids how to be better independent testers as well as better programmers...it will cost everyone less time and money in the long run if there is a good plan for independent integration test, requirement verification test and system test. Just think of all the X.Y.Z releases we could avoid by having robust testing during the entire sdlc...Unit test is fine, but you can't think of everything yourself.
Consider the quote from Vanders (found in Pt 1 of Making Software Suck Less)
"...why is it that so little OSS software goes through any sort of structured testing phase?
Most testing of OSS seems to be:
Developer can compile & run code. Unit testing
Developer releases code as an "Alpha". Component testing
Fixes bugs, releases "Beta". System testing
Fixes bugs, releases final build. Testing over!
Sorry, that isn't a proper structured testing scheme. Beta & Alpha releases are no good other than for limited releases. If you don't know what uses your users are putting to software too, some features may never get tested until it is too late.
Developers seem to view testing as a neccesary evil, but are happy to release fix, after fix, after fix for eternity, rather than writing & following a test plan. Honestly people, it saves time in the long run! "
-Dynoman7
Blarf.
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.
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.
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!
Syllable : It's an Operating System
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).
Ha -- you thought you could instruct him in the ways of the Jedi, and he turned to the Dark Side. Shame shame :)
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
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.
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?
Engineering and the Ultimate
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.
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...
How's my programming? Call 1-800-DEV-NULL
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
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.
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.
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.
"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 :)
You can't handle the truth.
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.
I am !amused.
Mike
-- Could you use my software consulting serv
Click here to validate:
- Slashdot's homepage
-
This article
I think the situation could be improved a bit by adding a DOCTYPE declaration at the beginning (for a DTD). DTD validation, yeah right.If you're writing files by hand and prefer to upload them for validation from your local hard disk, try this form.
Mike
-- Could you use my software consulting serv
before you can tackle the problem of sucky software.
There are different criteria for sucking. Most of what the article goes into (which is what most of the Linux world is focused on) is suckiness that falls along the lines of security holes, crashing, bloated code, inefficient algorithms, etc. But there are other types of suckiness that exist
For example, to people who simply want to get their work done in an easy and efficent manner, software with an ill-designed, illogical, and confusing graphical interface sucks. To people who don't want to spend hours on end mainting their computer and updating and reinstalling things, software that easily breaks other software or easily gets broken by other software sucks. To someone like a cashier, software that was written by a programmer who has never been a cashier and has never processed data the way a cashier does sucks (take my word for it. I've been a cashier who's had to deal with sucky software. It sucks).
I think part of the thing that is really dogging open source on the desktop is that many of the people working on open source software have a very limited definition of "sucks". As long as software doesn't suck according to their personal criteria, the software doesn't suck. Maybe it's time that the open source world took a good long look at The People On The Other End Of The Software(tm) and incorporate some of their ideas of suckiness.
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.
-atrowe: Card-carrying Mensa member. I have no toleranse for stupidity.
The real problem isn't a particular methodology like XP (which does have good ideas in it), it's the complete lack of professionalism in the software industry.
How many times have people heard of programmers with no degree working on or designing large-scale projects? It's insane. No one would hire an architect or mechanical engineer who didn't have at least a piece of paper from a college. But it happens all the time in software. The costs of the defective systems being turned out by untrained programmers is starting to matter.
Even a CS degree really isn't a sufficient solution to the problem. Software Engineering is NOT computer science, just as Chemical Engineering is not Chemistry. You need knowledge of the latter to do the former, but there is a different skill set which must be learned. Unfortunately, I'm not aware of any school which is teaching it to potential software engineers. When they do, real software development can finally begin.
Conformity is the jailer of freedom and enemy of growth. -JFK
Don Knuth (the author of TeX) once made a comment in one of his books that if I were an engineer it would be very easy for me to go out and study great buildings but it is very difficult to find "great code" which we can hold up as an example to budding programmers. There is an interesting exchange in one of Knuth's books (the literate programming one I think) where he creates a program for a task using his self documenting and logically ordered language. Another leading computer scientist was then asked to respond. he called it a "Faberge egg" of a programme. Exquisitely structured, beautiful to look at, but the same result could have been achieved using 3 unix commands and two pipes! For me, as a a teacher of programming, I would love to see a resource of great code I could refer to which had been peer judged as worthy of imitation.
As Knuth says:
:-)
"Premature optimisation is the root of all evil".
Of course, he'd probably have said it with a z.
--
http://www.gimbo.org.uk/
High school CS department? DEPARTMENT? Where did Timothy go to school? Most high schools are lucky if they just have a programming class.
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.
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?
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.
www.HearMySoulSpeak.com
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...
Bizar technology?
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!
-
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.
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
Are there any Mentors (Elves) out there willing to listen to the same old questions being made by some beginner?
Every problem has a better solution when you start thinking it differently than the normal way.[Steve Wozniak]
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.
-"Those who fought today will die tommorow."-
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.)
Does my bum look big in this?
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.
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
since I'm only 12 I am very open to almost anything
Trust god and don't fuck your camel!
No-nonsense SW Development Process, version 0.01
By Mats Henricson
Rule 0: Don't break a rule unless you have a very good reason for doing so.
Rec: Make sure a project manager is dedicated to your project.
Rec: Have regular project meetings, typically once a week, with all participants, where all kinds of project issues are discussed.
Rec: Manage risks (by using the likelyhood * severity formula)
Rule: Involve the user in the process. (This is the single most important reason why projects are successful).
Rec: Select a set of tools that works well, document its use, and make it the default tools for the project.
Rule: Use a version management tool, such as CVS, to handle your code and documentation.
Rec: When checking in code, write meaningful descriptions for the changes.
Rule: Before developing a completely new product, make sure you can't buy a similar product, or use an open source product.
Rule: Use short release cycles.
Rec: Create Use Cases (or stories) for how features are used by the customer.
Rec: Let developers estimate their own tasks so that they are realistic.
Rec: Use the Stories as the basis for writing test cases.
Rec: Write test cases for new features before you implement the feature itself.
Rec: Make sure test cases are easy to configure, run and automate.
Rec: Automatically run the test suite after each build.
Rec: Update the list of desired features after each release cycle.
Rec: Write a Release Note after each release, where all known issues are listed.
Rec: Use a programming standard.
Rec: Use a code style standard.
Rec: Review eachothers code.
Rule: Don't leave commented out code in the files, unless you explain why it is there.
Rule: Check in files in the correct order, so that the risk of corrupt intermediate checkouts by your coworkers are minimized.
Rule: Make a diff on your changes before you check them in.
Rec: A function should do one thing and one thing only.
Rec: You should never make. You should always "make clean;make".
Rec: If you've changed a file, don't ever close it until you've checked it in, since open files are a good way to remember which files you've edited and needs to be checked in.
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
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