• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

Qs about becoming a computer programmer?

Thirty years in the field and I'm still supporting a company that has programs that run on COBOL. So I can't really give you much advice on other necessary skills.
 
I appreciate all the comments and the advice. I think what I'm discovering is the very simple fact that I don't know enough to know what I don't know, if that makes any sense :/

This whole line of questioning came up because one of my colleagues suggested I look into technical writing. (long story). I was casually searching for tech writing jobs and saw a lot in the programming/networking fields, so I thought, "Well here's a field I find interesting but know nothing about," went to Lynda.com, and watched those "Fundamentals of Programming for People who barely know their way around in html" videos. That led to Microsoft Virtual Academy, and playing around with C#. PLAYING is about the best description. I can see how it would be a fun hobby, and briefly toyed with the idea of learning what I could and trying to work in the field.

Having slept (and done some research) since then, I now realize I was REALLY jumping the gun. I figure I have a LOOOOOOOOONG way to go before I can even consider programming a hobby, but now that I have the info you guys gave me, at least I know where to go once I have some clue about what I'm doing.

Thank you so much for the thoughts, links, suggestions, and guidelines. It may happen that I fall so in love with doing this, that I DO want to pursue it as a career, but right now it's a worry for a far future day!

Great thoughts though, and I thank you! I did buy the Ruby in 21 days book, since someone on another forum suggested that was an easy one to start with, and inter-library-loaned the K&R "C Programming Language" which was also recommended as a great book but incredibly complicated. I thought the two might balance each other out :)
 
My rule of thumb is that if you don't already have programming as a hobby, you're probably not ever going to be a programmer.

Maybe you're one of the lucky few who picks it up late in life and turns out to have a natural affinity for the work. If so, you'll know soon enough.
 
This whole line of questioning came up because one of my colleagues suggested I look into technical writing.

Technical writing is an excellent skill. It can be very difficult to write clearly to convey programmers' descriptions of things into user understandable terms. I have one who is very good at pointing out 'that's implementor speak' (amongst other things).
 
Technical writing is an excellent skill. It can be very difficult to write clearly to convey programmers' descriptions of things into user understandable terms. I have one who is very good at pointing out 'that's implementor speak' (amongst other things).

I hate when programmers say, "I need to talk to you in person; I can't explain it in an email." To which I reply, "Well, why not?"

When people talk to you in person they interrupt your train of thought, often derailing it. Especially when they can't organize their thoughts well enough to put it in writing.

I don't like that.
 
I hate when programmers say, "I need to talk to you in person; I can't explain it in an email." To which I reply, "Well, why not?"

Particularly bad since programming itself is explaining something, in writing, to the computer.
 
Particularly bad since programming itself is explaining something, in writing, to the computer.

I dunno... I'm in production operations, so it falls to me to maintain the programs the programmers write.

Sometimes, twenty minutes chatting in front of a whiteboard, is worth more than hours of trying to get all the concepts clearly delineated in writing.

And being in prod ops, my job is interrupt-driven anyway. At this point in my career, I'd be ashamed of myself if I were still complaining about my customers disrupting my train of thought.
 
Sometimes, twenty minutes chatting in front of a whiteboard, is worth more than hours of trying to get all the concepts clearly delineated in writing.

Would be nice if the computer could be in on that whiteboard discussion. Until then, at least one of those humans still needs to be good at the clearly-delineated-in-writing bit.
 
I think it depends on the market. I've done technical interviews for hiring. East Coast US companies would think I brought in roadkill if I told them to look at a resume with no degree.

Many (most?) Silicon Valley companies don't ask about it or worry about it. There's a lot of companies there that got founded by dropouts and it completely changes the culture.
My bad then, thx for that info.


When the Y10K problem comes around in 7,985 years, there will probably still be systems running on COBOL.
And tons of people will sucker companies into hiring them, thinking they need to hire specialists to take care of the "Y10K" issue so their information systems won't explode when that year hits. :rolleyes:
 
Would be nice if the computer could be in on that whiteboard discussion. Until then, at least one of those humans still needs to be good at the clearly-delineated-in-writing bit.

It seems like you've misunderstood me.

Obviously the developer is good at "delineating things in writing"--that is, writing the code that runs on the servers.

But it's a large and complex system, with a lot of dependencies, endpoints, and contingency mechanisms. In order to support it effectively in production, I need to have a clear understanding of how it works, and what the implications are of any change or addition.

Sometimes, I can get that understanding much quicker, easier, and better, by having a quick chat with the Engineer, rather than asking him to type up a detailed--and accurate--description in email. Especially the part where I have questions, misconceptions, information to pass back to the engineer, etc. I've seen that process take the better part of two days. It's excruciating.

One of the most valuable soft skills in my role is recognizing when such an email thread is starting, and cut it off at the knees by getting up, walking over to the engineer, and talking to him for 20 minutes.

Sure, being able to clearly and correctly describe your code in writing is good, and sometimes necessary. All I'm saying is that in my experience doing production support of your code, it's not always necessary, and is sometimes contra-indicated.
 
One of the most valuable soft skills in my role is recognizing when such an email thread is starting, and cut it off at the knees by getting up, walking over to the engineer, and talking to him for 20 minutes.
This is a valuable skill in many areas where email exchanges are used. After a couple of back-and-forths, it's time for a phone call or face-to-face meeting.

~~ Paul
 
It seems like you've misunderstood me.

Obviously the developer is good at "delineating things in writing"--that is, writing the code that runs on the servers.

But it's a large and complex system, with a lot of dependencies, endpoints, and contingency mechanisms. In order to support it effectively in production, I need to have a clear understanding of how it works, and what the implications are of any change or addition.

Sometimes, I can get that understanding much quicker, easier, and better, by having a quick chat with the Engineer, rather than asking him to type up a detailed--and accurate--description in email. Especially the part where I have questions, misconceptions, information to pass back to the engineer, etc. I've seen that process take the better part of two days. It's excruciating.

One of the most valuable soft skills in my role is recognizing when such an email thread is starting, and cut it off at the knees by getting up, walking over to the engineer, and talking to him for 20 minutes.

Sure, being able to clearly and correctly describe your code in writing is good, and sometimes necessary. All I'm saying is that in my experience doing production support of your code, it's not always necessary, and is sometimes contra-indicated.

Yep, I understood what you meant, I was just adding that other side to it.
 
...which means she probably wouldn't have to take most of them again.

If you're saying she doesn't need an I.T. degree of some kind to break into development, sorry, the job market on the whole disagrees.

Bingo. My point. :) But an I.T. degree - nobody will hire her based on a humanities degree.

I would say that is quite rare. You need to bring something to the table and there are tons of people out there who DO have IT degrees and/or experience nowdays.

Yeah. At McDonalds. ;) Seriously, I think the odds of getting a job in IT wiht no IT degree and no experience are slim. If she got some certs, maybe.

I guarantee people are winning the lottery too. I'm sorry but your "guarantee" (or mine or anyone else's, nothing against you) means nothing here.
I am not making this up, or speculating. People in the valley are getting jobs every single day w/o a degree. Almost every graduate from these hacker schools are getting multiple job offers. If I recall correctly you are in the East coast; I moved from the DC area in '08 and I agree that at least at that time you needed a degree over there. But not over here. I'm not making it up, people ARE getting hired. You cannot argue against empirical evidence - it's irrational.
 
Having slept (and done some research) since then, I now realize I was REALLY jumping the gun. I figure I have a LOOOOOOOOONG way to go before I can even consider programming a hobby, but now that I have the info you guys gave me, at least I know where to go once I have some clue about what I'm doing.
Naw. Download Python, take the 2 day google python class (free on the web), get the book Think Python (free on the web, also on dead trees for $), or take the introductory course on programming on Coursera. Then set yourself some projects and just do it. Ain't no thing.

Another 'no degree' data point. We have a contractor working for us for non development stuff. I had him download python, take the google course (you wee where this is going), and he is starting to program for us.

Don't expect to compete with graduates from Stanford, but you can do this, if you have the passion for it.
 
...which makes it hard to wow them. ;)

Don't kid yourself that a 4 yr degree isn't important in getting your foot in the door if one has no experience.

This. It at a minimum shows that you can earn a 4 yr degree in a field of your choice. Anybody can claim to program.
 
I appreciate the conversation. I started with Ruby, but I keep seeing recommendations for working in Python (especially from other Mac folks.) I found a couple of Perl books online, but haven't started reading them yet. So far I'm still having fun, but like I said, I'm still very much in the "raw beginner" stage.

Do most people just pick a language, and then just move on to other languages that fit the kind of problems they're trying to solve?
 
I appreciate the conversation. I started with Ruby, but I keep seeing recommendations for working in Python (especially from other Mac folks.) I found a couple of Perl books online, but haven't started reading them yet. So far I'm still having fun, but like I said, I'm still very much in the "raw beginner" stage.
Both Python and Ruby have great things to recommend them. As I said before, I still do most of my programming at home in Perl, but that's primarily because I've worked with it for a decade and know it well. But for starting out you've be better off with Python or Ruby. Python is gaining traction as a language being used for a lot of utilities in Linux. Ruby is popular in small businesses these days, primarily due to the strength of the "Ruby on Rails" development platform.

Do most people just pick a language, and then just move on to other languages that fit the kind of problems they're trying to solve?
Pretty much, yes. A good programmer can pick up a new language very quickly, because it's a matter of "how does this new language do (loops|regexps|case|control flow|OO|variable scoping)?" and getting to know the standard library.

It's also huge bone of contention between I/T departments and HR. HR insists on advertising for hiring people with X years of experience in language Y, and throwing out resumes because the applicant may have X*2 years in a similar language but not very much experience in Y.
 

Back
Top Bottom