Is there any future in programming?

Great Debates
21

Yes indeedy! Assembly teaches you the down and dirty, nitty-gritty aspects of programming- like what a pointer REALLY is, and is the knowledge that spans the gap between EE digital design (K-maps, flip-flops, etc…) and high-level programming(C, C++, Java, etc…)

One thing that people haven’t mentioned about programming is that there will probably be a reasonably stable market for programmers willing to do customization work on big software packages (ERPs, CRMs, etc…). Granted, it’s not the sexiest of programming tasks, but it does pay the bills, and won’t be outsourced anytime soon.

Another thing that people have mentioned, and I’ll try to sum up is that it’s not sufficient anymore to be a crack coder, but instead you have to have some knowledge/experience/whatever in some other area. In other words, an accountant that can program is vastly more valuable to many companies than a crack coder who doesn’t even know a debit from a credit.

22

Here’s an area of specialization that many tech people overlook - being a system engineer for a vendor. This is basically a pre-sales support function helping the company and salespeople address the technical issues that arise during the sales process (in some, typically smaller, companies you might also be doing some work after the sale is made (post-sales)). Vendors usually pay very well and this job is generally very secure.

You need not only tech skills, but also the skill to deal with all different types and levels of people (customers and salespeople (although some might say that salespeople shouldn’t be classified as people :smiley: )). Virtually every vendor has one to many system engineers. You might be supporting a salesperson during a customer presentation. You might have to construct a technical presentation and give it to prospects. You might do a Web-ex demo. You might be doing a network evaluation. You might be acting as a project manager for the implementation and testing of the company’s product at a prospects site. You might be doing a performance study or writing code for a custom extension that a prospect needs to to close the sale. You might be acting as the field liaison between the customer and the company’s programming staff, trying to find out why a product doesn’t work right. The number and variety of tasks is endless.

23

IMHO, I say Java is the best programming language for a beginner. Ten years ago, it would be Oberon, but Oberon doesn’t have objects AFAIK. For a beginner, Java is better than C++ because it’s a stongly typed language and the compiler is picky. It forces you to pick up the good programming habits.

24

Say for instance finance professional with indepth programming skills, or programmers with indepth finance skills?

25

I have to admit this sounds like it might well have a certain Dilbertesque quality when the salesdroid promises the customer that the servers will able to talk to customers in English and will also hover 1cm above the floor using anti-gravity. :smiley:

That’s sort of what I’d be afraid of…

26

Where I am, I see ads all the time for people with programming skills, but a lot of them are not actually for a job with the title of “programmer.” Programming is useful for a lot of IT jobs, like system administrators, database administrators, network administrators, etc. There is still a ton of competition for these jobs, just as in programming, but I think it is a lot harder to move those jobs to somewhere that is offsite.

Though I think programming jobs haven’t hit bottom yet, I also think that eventually companies will figure out that sending programming jobs overseas is often not cheaper. In the short term, it may be, but things like oversight, quality control, support, and maintenance become a bear when you are working with programmers on a different continent.

Contracting as a whole is overused. There are twice as many contractors working for the US government than there are government employees, it is often more expensive to add the middleman (company that gets the contract), and yet often adds no advantages over a federal employee, especially when you’re talking about positions for which there will always be a need (help desk for one example).

Anyway, the bottom line is that programming jobs are fairly hard to come by right now and probably will be for a while.

27

Here’s an interesting article:

http://heather.cs.ucdavis.edu/itaa.real.html#tth_sEc10

28

Yes, there’s a future in programming.

Basically, there’s very little real innovation in the software development industry. Don’t be confused by all the buzzwords–nearly everything is just a new name and implementation for a rehashed idea, possibly with an insignificant new twist thrown in. Thus, getting a solid education in CS, including a good dose of pure math (take an abstract algebra course!) and plenty of “theory” (i.e., courses on algorithms, both on the “here’s how to implement a b-tree” and the “Prove this problem is NP-complete” levels) will prepare you for a solid career just as well now as it did 10 years ago. Of course, the other thing most important to securing a solid career is networking with people…

As for languages, start with both a language widely used in industry (Java is a good choice) and a language that will expose you to a variety of powerful concepts and ideas. Common Lisp is the most powerful programming language in existence, and is good for this. You could also compromise between the two and pick Python. :slight_smile:

Of course, I’m leaving the programming arena to go more to the DBA track, but that’s a different story :wink:

29

Yeah, now. That’s still where the jobs are going.

Someone with in-depth skills in both finance and programming.

30

…and pure programmers write perfect and beautiful programs about nothing. :wink:

Ok, I was joking, but it is important to realize that the truth lies somewhere in between. e.g. my subject, computational linguistics, was created because people realized that sometimes computer scientists won’t do the trick. They lack in-depth linguistics education, classic linguists on the other hand learn virtually nothing about CS or programming.

kellner,
domain-expert-who-programs in training

31

The ACM held a conference on the future of the American computer field just last April.

Their conclusions were that while a number of jobs were being outsourced, most computer jobs have stayed right here. Only the largest hirers of programmers have begun to outsource overseas. They predict that as companies begin do deal hands-on with the unusual issues of dealing with a distant programming force with language issues, many of those jobs will come back here (indeed, I’ve heard from people within the industry that it’s almost impossible to get changes made with this system). Also , outsourcing is only one of the reasons for a drop in IT hiring.

The main reason is that management is simply sick of their computers and their computer poeple, considering the money they spent on Y2K and then the internet bubble. Recently, they’ve simply been loathe to pour any more money into their information infrastructure. As those infrastructures become outdated, hiring will start to pick up again.

I myself graduated last Spring with my BSCS, having given up on completing my Music degree from years before, and eager to move out of education into something else. The job market was truly dismal, and I spent a depressing summer calling disconnected phone numbers, and interviewing for paltry entry-level jobs whose average salaries had plummeted from just a few years earlier. I am now right back in education, teaching Computer Science at a private school in Anaheim. I beat out 200 other people for the position, as I was the only one who knew what I was doing in front of a group of students. The others were all out-of-work IT professionals. I hear from the people a year behind me that the prospects have not yet improved much. I am perfectly happy to wait out the slump right here for now.

I have faith that programming will once again be a viable option for Americans in the not distant future, so if you are interested, you should probably take into account the results of a poll that Computer, the IEEE Computer Society magazine, published in May 2000. Hundreds of professional programmers responded to a survey of just what topics that may or may not be taught in a college program turned out to be useful on the job.

The top twenty-five necessary skills for a programmer at that time, according to those in the field were:

[ol]
[li]Specific Languages[/li][li]Data Structures[/li][li]Software Design and Patterns[/li][li]Software Architecture[/li][li]Requirements Gathering and Analysis[/li][li]Object-Oriented Concepts[/li][li]Human-Computer Interaction/User Interface[/li][li]Ethics and Professionalism[/li][li]Analysis and Design Methods[/li][li]Giving Presentations[/li][li]Project Management[/li][li]Testing, Verification, Quality Analyisis[/li][li]Design of Algorithms[/li][li]Technical Writing[/li][li]Operating Systems[/li][li]Databases[/li][li]Leadership[/li][li]Configuration/Release Management[/li][li]Data Transmission[/li][li]Management[/li][li]File Management[/li][li]Software Reliability/Fault Tolerance[/li][li]Systems Programming[/li][li]Network Architecture[/li][li]Negotiation[/li][/ol]

Also important are the so-called “gap” skills, those that are far more important in the field than their emphasis in university programs might indicate. According to the survey, the ten greatest “gap” skills, by size of the gap, were:

[ol]
[li]Negotiation[/li][li]Human-Computer Interaction/User Interface[/li][li]Leadership[/li][li]Real-Time Design[/li][li]Management[/li][li]Cost Estimation[/li][li]Software Metrics[/li][li]Software Reliability/Fault Tolerance[/li][li]Ethics and Professionalism[/li][li]Requirements Gathering and Analysis[/li][/ol]

There’s only so much you can do about the state of the job market. If you position yourself as the master of these skills, you may find yourself first in line when it rebounds.

In addition to these, it also couldn’t hurt to stay abreast of the progress in the Agile development community (Scrum, Extreme Programming, etc.). While the zealots of these disciplines are overly positive, and their detractors overly negative, they are starting to show a track record for getting quality software out the door relatively quickly and cheaply. Once the dust settles over specific methodologies, I think those with an understanding of the principles behind such practices will be ahead of the game.

32

No fight here. We’re just emphasising different things.

The incident I referred to happened in the '80s, when digital phone switches were pretty new. Unlike the big companies (Nortel, AT&T, Siemens, etc) that started off with huge digital switches and eventually worked their way down to smaller and smaller switches, this little company started with little digital switches and worked their way up. The electrical engineers that worked there were brilliant… electrical engineers. They did lots of really hard things (hybrid analog/digital chip design, unique packaging, board design, etc), and when it came time to program the beautiful pile of silicon and ceramic, they figured “this must be easy”. After all, they know assembler!

Wrong! Real time programming is hard! They fooled themselves for a time, because their first products were really small - 8, 16, 32 phone lines max. Even a horribly written controller will work under these circumstances. When they went to a bigger switch, that could handle thousands of lines, they upgraded the processor (old one was 6809, new was 68010, I think) and patched up the code. It fell flat on its face due to lousy algorithms.

Another more recent example. A big client of mine had a server program that would death spiral when the load was bumped up just a little bit. They fretted over it for months, then let me take a look at it. After profiling it for a few hours, I looked at a few things. I soon found that they had done FIFO buffering using Rogue Wave string (RWCString). :rolleyes: It was created by one programmer, maintained by a group of 5. All 5 had decent education and a lot of experience (one I talked to had a masters in CS from a well known US university and ~20 years experience).

Regardless of degree, some people “get it”, other’s don’t. However, to “get it”, you have to understand algorithms, and to understand algorithms, you’ve got to understand math, and lots of it.

33

I guess I’m agreeing with a bunch of you since I found attacking a problem abstractly to be the most important problem. I simply mean when you need to write a program the first big thing is figuring out what you need and what you want. (So if you can say Boss I can give you A, B, and C in 3 weeks but if you need D I need another week you have a little more leverage.) Of course then the next is figuring out how to divide up this work intelligently and how to interconnect the parts that do each thing. Finally just typing code. So I guess I’m a big “do all the design work first and don’t worry about the language.” It’s been my experience the worst programmers are the ones that want to immediately bang out the code when you first explain it to them.(Since often the code doesn’t do what it’s supposed to, and even when it does it’s really hard to read since they’re actually coming up with ideas as they write the code.)

Oh, and one other thing please comment your code.(I’ve heard the old “I understand code as well as english.” from people but I haven’t actually met anyone where that was actually true.)

34

Hikers say “Trust the terrain, not the map”. Compiler writers say “compilers don’t read comments”. The two phrases are equivalent.

Comments are nice and all, but limit them to what this function/method/module/etc is supposed to do, why it works the way it does, and why other obvious approaches were not used. Overcommenting can be worse than no comments at all.

35

Another idea that no one seems to have suggested is to become an entrepreneur. Write a smallest program that solves a problem and then out it out as shareware. If you charge $10 a pop and get 1000,000 to register out of the 300 million or so Windows users, you’ll be doing quite well. And you won’t have to depend on any corporations for a job.

36

Hate to burst your bubble but I doubt that most shareware even gets 1,000,000 downloads. And what’s the registration rate? Maybe 1%. So that’s more like $100,000. Nice - pay off your debts, car and part of your house, and then keep working for THE MAN. I know, I’m a buzzkill sometimes.

37

Even 1% is hopelessly optimistic. I just open source my little stuff, shareware isn’t worth the bother.

38

You bring up a good point, 5cents– comments should be used as a “handrail” rather than the “stairs.”

Taking the map analogy a little farther though: if the map I am using seems to be missing a river, or a city, etc., I begin to question the skills of the map’s creator. Personally, I am happy to see a comment:code ratio of about 1:3 (but, I’m sort of a Comment Nazi). But I agree that there is a thing as “too much” commenting… though it seems to be something to worry about only in theory (i.e. how many times have you seen code that’s been “too commented?” I haven’t seen anything like that yet…).

Example…


("Too much commenting")
// If blnIsSomething is true, then
//  perform the function Foo1.
// Else Perform the function Foo2.
if(blnIsSomething)   
{
   // Perform some operations on the data
   //  entered by the user.
   Foo1();
}
else
{
   // Get some input from the user.
   Foo2();
}

"Good commenting - IMHO"
// If blnIsSomething is true, start modifying
//  the data entered by the user.
// Else get the data from the user.
if(blnIsSomething)   
{
   Foo1();
}
else
{
   Foo2();
}

Obviously not a great example, but I don’t really feel like grabbing some actual source code to demonstrate with right now, so… :slight_smile:

LilShieste

39

I tend to use just enough comments so that I can skim through the code, looking only at the green lines (or blue lines, depending on the IDE), and see which part of the code I need to look at to find a certain feature. If I actually need to understand what’s going on in that part, I can look at the code itself.

For complicated algorithms with a lot of steps, I’ll write the comments first (one for each step) and fill in the code later, ensuring that every step of the algorithm has a comment.

40

Both of your examples have way too many comments of the wrong kind. Why describe the if…else when it is plainly obvious? If you change foo1(), are you going to remember to change the comments everywhere foo1() is called? I’d use none of the comments.

Here’s a better example, IMHO:



/*
 * Modify user data
 *
 * Modifications include:
 *    - sort alphabetically
 *    - throw away every second record
 *    - avoid pacman monsters
 *
 * We throw away every other record because we don't want too much data.
 * Avoiding pacman monsters was chosen because you can't always find a
 * power pill when you need one.
 */
void
foo1(void)
{
    // sort alphabetically
    [10 lines of code]

    // throw away every second record
    [15 lines of code]

    // avoid pacman monsters
    [7 lines of code, and one comment in the middle to explain a not-so-obvious dodge]
}