What do programmers learn during the career?

[Atreyo Bhattacharjee]

I'm trying to learn computer programming so I can get a job in the industry when I'm older. I was looking at Java's version history, and so many thing have changed over the years. Do programmers have to relearn stuff everytime a new version comes out? Could you have to relearn a language entirely? What are some of the things programmers have to keep up with in the changing industry, and what are some of the things they just have to keep learning?

 

[yakaman]

Most of the time changes pile on top of the previous version and don't make everything you've learnt irrelevant - one recent notable exception being the complete rewrite of Angular's syntax.
You won't have to learn everything from scratch though, even when switching across languages.
The logic remains the same, and a lot of design patterns are found in multiple languages.

But you will certainly have to keep learning throughout your career and stay well informed to keep up with the changes that occur faster than ever these days.

 

[mwryder55]

One thing to keep in mind is that even though an "update" may come out for a language used at the place you are working they may not use those changes. Many programs can be broken by some of the changes and if the program is critical to the company they may not wish to risk the chance. Also a lot of companies use programs written in "dead" languages like Cobol because the time and expense to change to a new language is not available as management may see no reason to fix what is not broken.

This does not mean you should stop learning what is out there as one day you might be asked if you are familiar with language X because some manager read something in some trade magazine or you are looking for a new job.

 

[CaptainCretin]

Most programmers never seem to learn how important, accurate documentation of their code is; they seem to think that as long as THEY understand it, that is fine.

An article surfaced just this week about a stock brokerage company running a program with a basic error in the code that completely broke their compliance mechanism, because the programmer didnt document the code, took a few short-cuts and made a mistake; one "+" sign missing from a single line of code could have cost the company millions, if not billions of $$.

Someone like yourself, reading to code to see how it worked, picked up the error over a year after the software went live.

 

[Ralston18]

When faced with an application project there are two parts: 1) Strategy - being able to work out and plan what is to be done. 2) Tactical - how it is done via some programming language(s). All based on the project's objectives and requirements. Many different methodologies are used.

Most programming languages support the same concepts: loops, logic, functions, variables, and so forth. The syntax and structures are often similar.

So once you have learned a language or two, you will find that you can, at least, conceptually follow script in other languages.

And if the programmer did, as mentioned by CaptainCretin, document their code the program will be even easier to follow and understand.

Kids are coding nowadays. Take a look at Scratch2 via MIT. May seem childish at first, but then try writing your own script to actually do something. You will learn quite a bit about logic and structure. Good for any programming language.

Likewise: Python and Powershell. Very powerful and gaining some understanding of how they work and can be applied will be very helpful.

Yes, indeed, read code/scripts.

Try writing, simple at first, then do more involved projects. If you like hardware, get a Raspberry PI and work with it - some robotics. Or purchase a Sphero. Both are educational and fun! 🙂

Classes: Logic, Geometry, Math, Electronics. The more you can learn overall, the better programmer you will become. Even with changes.

Coding is a matter of details and nuances matter.

Also, to help document: take a technical writing course/class. Good communications skills are a must. The best programmers I knew and worked with were very capable writers, speakers, and communicators. And listeners - understanding what needs to be done and sometimes the "how" takes work and effort.