Slashdot Mirror
What are Your Programming Goals?
Crutcher asks: "I've been walking the murky path to one day becoming a Systems Programmer, and I was wondering what other not-yet-gurus like myself saw as their ultimate goals, and why they choose those fields? Do we all want to hack kernels, or do more want to be UI Gurus, or Deamonic Masters? It would help if we (the proto-gurus) had clearer understandings of where we could go, and what it takes to get there." This is an interesting question. I've discovered however, that the more I learn about coding (including new paradigms and languages), the more my goals have changed. What are your thoughts on this?
My goal is to write code that doesn't break. I prefer not to do medical or aircraft work where someone dies, focusing instead on systems that would simply cause anouther depression if it breaks. (Which probably kills more people in the long run)
I tried writting user interfaces. I hated that work. I work with folks who love that work. I like flipping bits and watching them cross several busses and appear (inverted) at a different processor. I love yanking out processors that are running my code, and have my code automaticlly move to a different processor. To me that is cool, to others around me it is just a lot of work.
In other words, we are all different. I'm no better or worse then my peers. We work differently, and like different areas. I can do the work that others around me do, but they like it I don't, and vise versa.
You end up having to try things to decide if you like them. Some folks work on KDE, others userland of FreeBSD, others the Linux kernel. Given enough time one person could do all of the above to the same quality, but they would hate some tasks and love others. ANd of course as time goes on your grow, so a task you hated before you might like now, or something you used to love now just bores you to tears.
Don't be inflexable. Someday the inflexable will find that nobody cares about the awesome system he wrote and he no longer can get a job. Because he is unwilling to learn something new the inflexable person is lost. (The mainframe is a classic example, it is slowly dieing. Not because it is bad - though we have learned much about comptuer design since it was made, but because it is out of style. Do you really want to be on a sinking ship, without knowing how to use the life boat? There is a lot of money in mainframes today, but you better know something else)
Don't be too flexable. Sometimes you have to say "I can do this, but it isn't right." Or maybe you are so flexable that you get a new job every few months. You need to see a project through to completion, see what customers really think. (Open source isn't such a problem here, but in buisness you cannot contribute to two different companies at a time.)
I like where I am now, and what I'm doing. I could have - perhaps should have taken an opertunity to transfer to a different department. Only time will tell what would have been best.
Why is it that in the year 2000 we're still writing our operating systems and most of our programs in C (or C++, which, although messy, is not truly high-level)?
Because these are decent languages for the job?
[grins, ducks, and runs...]
Why is it that garbage-collection has never truly come out of the closet?
Because you lose some control over execution of your code, and in a lot of situations that's not desirable at all (real-time systems is a classic example).
Why is it that Java is compiled in byte-code rather than native code - and why is it so slow?
The native code of which processor? If you recall "write once, debu^H^H^H^Hrun anywhere" was the Java's big selling point and a explicit design goal. In any case, native Java compilers are starting to appear.
As to the slowness -- that's exactly because Java is a "more" high-level language. TANSTAAFL.
Why is it that no programming language that I know of is able to handle program invariants and proofs that are any bit more complicated than ("i is an integer") (nothing like "i is a power of 2" for example).
Well, you can always write a C++ class with properly defined assignment operators, etc. which will enforce "i is a power of two". Quite trivial, really.
On the other hand, you've been complaining that Java is slow... I don't think you'll like the speed of any high-level language.
Why is it that anyone who wishes to program anything still has to spend half of his time writing things like if ( retval == -1 ) { perror ("frobnicating"); exit (EXIT_FAILURE); }?
First, even in C there are such things (evil, I acknowledge) as macros. Second, sometimes you may want to frobnicate and sometimes you may want to discombobulate. Sometime you will just exit, and other times you'll try to recover gracefully. It all depends and that's why we spend time writing code like this.
Why is it that buffer overruns still exist?
As usual, it's a trade-off. You can run your programs with run-time memory checking (very, very useful during debugging). Memory checking, though, like almost everything else, imposes an overhead. Sometimes it's OK, sometimes it's not.
In any case, if you are programming in C++ and are using a decent library, you should have very few memory access problems. Writing in C and in the usual C style is another matter entirely.
To summarize: TANSTAAFL.
Kaa
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
so that I can afford to spend my time writing free software, while keeping a roof over my head and a car in my garage and food on my table.
Ultimately I want to spend my time providing cross-platform tools so that the same bit of code can be compiled on the Mac, Windows and Linux and run correctly. But at the moment, the project has to languish so that I can write a web-based appointment scheduling system for a fellow whose having fantasies of getting rich in the New Economy...
Systems Pukes - Arrogant bit-twiddlers who sit around doing work no one understands but everyone needs. Occaisonally, they purposely break the system and put it back together to prove their worth.
Application Programmers - smug resume monkeys who make prostitutes look like nuns. Most of their day is spend looking for another job. The rest of the time they are avoiding meetings and hunting free food. They will leave a company for $1 more an hour but will remain loyal to a department for an $8 pizza.
Analysts - Programmers who can't code. Their functions including stating the obvious and avoiding responsiblity. The chief aim of the analyst is to create a system without a spec thereby rendering them blameless.
Project Leaders - the dumping ground of IT. Drooling pirates who will swing into meetings and lash each other with promises to the amusement of management. Then they will stagger back to the staff and announce some impossible deadline that was born to be pushed out to sea. The sworn enemies of programmers everywhere. See also "Euthenasia"
DBA's - Anal-retentive spellcheckers whose chief purpose is to slow work to a crawl.
If you aren't part of the solution, there is good money to be made prolonging the problem
I gave up the option of programming for a games company to go do a CS degree. It was a bad mistake for me, as the degree started out good but drifted away from what was relevant and cutting edge and in the end I came out behind of where I would have been.
The most important thing is knowing how a program should be written and the most effiecient way of writing it while making it maintainable. Some people have the knowledge naturally, but its not a thing that can be taught.
When I'm hiring people I hire based on how quickly they can catch onto ideas and implement them, not on how many degrees they have. One of the best programmers I have came straight out of high school.
The important thing is not to dig your self a big hole by becoming too specialised - become a generalist - be adaptable - than you can follow your interests as they develop. There will be cool interesting technology to play with along the way and if you become too specialised you will eventually find yourself stuck doing the same thing over and over and over again.
The other thing that I think is a usefull (non-programming) skill - become a 'self-starter' ie don't need a lot of management to get your work done - let your enthusiasm drive your work - you'll probably get ahead a lot faster and you'll be able to work in smaller more cutting-edge companies
For me programming is a break from reality. Naturally having a goal in mind makes it more interesting, but in general I just do it for the hell of it. I mess with all sorts of languages but rarely take the time to become proficient with any particular language--unless it's simple enough to learn before I find something else interesting to learn. While I'm programming it's as if I've left my body and I've entered another dimension. I don't hear people talking, see the monitor, or feel my fingers on the keys. I'm just somewhere else entirely.
numb
My programming Goal is to finish the Do Stuff(c) Functions a Libraries. //or your languages equivalent //again your language equivalent //ditto }
A program that will Write your programs for you by simply declaring the dostuff function. Basically
#include "dostuff.h"
void main(){
dostuff();
Viola You are done My Only pittfall has been, actually writing it. I designed it to write itself Recursivley.. But so far my hardware doesnt want to comply.. And yes I wrote the original Segfault story on this so it _is_ original even if you have read it there before.
--------========+++Dont Feed The Lab Techs+++========--------
The more you know, the more questions you ask.
"`Ford, you're turning into a penguin. Stop it.'" -THHGTTG
Outstanding expression of your goals. Expressed elegantly in clean, aesthetically-pleasing, efficient statements. In short, I suspect this is the whole ball of wax when it comes to programming. I'm brand new at it, and you've quite eloquently mapped out precisely how I feel about programming, and why I enjoy it. I think I'll hang on to this as a reminder for those frustrating days when I wonder why I chose this field. ( which are few & far between )
Make it simple, easy to understand and maintainable.
Do not make it cool. Do not show me how well you know C++, Perl or Java. Do not make it subtle. Do not make it fast. Do not make it cute. These things hurt code.
Make it simple to understand and work on. Make it look like a Model T engine. Comment everything. Refactor for simplicity whenever possible. Speed will come as things develop. If it is too slow, profile the code and fix the slow bits. Follow these steps and the system will be easy to maintain. Customer ordered changes can be quickly and painlessly accomidated. And, when your contract ends and you have more interesting work to do, you can hand the code to anyone and they can maintain it. Job security sucks, it chains you to one spot, ends your career and keeps you at work away from your wife.
Mr Huber
Ex Building 17 Orange Badger
Kraaash your enemies...
see dem driffen before you...
und hear de lamentations uf dere wimmin...
Actually, my main goal in going into Systems Analysis/Programming was to only have to relearn half of what I knew every two years, instead of all of what I knew (when I did hardware).
I try not to get to hung up on OS, or Programming Languages - they're just tools we use to provide frameworks for solutions. Each has it's quirks.
To contribute to society - that's one of my goals. I used to want to code the best game simulations - somehow, that went out the window. Once you've got a bunch of money, that ceases to be such a big deal - so skip that as a motive.
To design a system that, while not the most efficient or fastest, allows one to get one's job done in an elegant and robust fashion - that's what I like doing. I may not make the best wheel, but my wheels allow you to change the tires while driving and use bigger wheels with different treads. I've found my code being used by other people more than ten years later - because it just keeps working. Elegence, simplicity, robustness.
The rest is all carp. A thousand years from now, all the things you think are important will be, at best, a joke.
Will in Seattle
I don't have goals in programming, except for specific projects. Goals are limiting, and only suited to the short term in such a dynamic field.
I have values: it is good to become a better programmer, it is good to learn more mathematics (the better to create accurate computer models of problems), it is good to learn more about how people interact with machines and what they want from them, it is good to learn more about my own mind and how I learn and how I work... I could go on for pages describing what I value.
The important thing is that general "goals as a programmer" are not worth having. Whole fields may become irrelevant by the time you master them, so you must always be learning. The programmer must be a generalist in principle, even though he spends a year or twelve with his main focus on one particular area, because any specialized field will eventually be made trivial by an advance in the state of the art (and the obvious reasons to delve into a particular area are that there's work to be done, you find the work interesting or profitable, and you think you can do it). Today's divisions into "interface design", "systems programming", "language design", "web scripting", "graphics engine programming", "hardware design", etc. (let alone narrow subdivisions like "Windows programmer" or "Playstation developer") are all arbitrary categories describing certain temporary conditions that must be dealt with. Twenty years from now, there will be a whole new set of programming tasks (though some of the names might be the same, the problems will be entirely different ones), and you'll probably still be programming. Prepare for it, by preparing for anything.
'Intelligence is life's response of "I can do anything!" to a universe that threatens with everything.'
-Frank Herbert in "Destination: Void" (quoted from memory; not exact)
My goal would be to make high-level languages (functional if possible) really usable - and really used.
Why is it that in the year 2000 we're still writing our operating systems and most of our programs in C (or C++, which, although messy, is not truly high-level)? Why is it that garbage-collection has never truly come out of the closet? Why is it that Java is compiled in byte-code rather than native code - and why is it so slow? Why is it that no programming language that I know of is able to handle program invariants and proofs that are any bit more complicated than ("i is an integer") (nothing like "i is a power of 2" for example). Why is it that anyone who wishes to program anything still has to spend half of his time writing things like if ( retval == -1 ) { perror ("frobnicating"); exit (EXIT_FAILURE); }? Why is it that buffer overruns still exist?
My goal as a programmer is to continually increase my fluency in
I hope to get there by three main methods:
I've been at it for 20 years, and am still learning every day. I get just as many thrills from it all today as I did when I started.
TomatoMan
-- http://frobnosticate.com