Ask Slashdot: Can an Old Programmer Learn New Tricks? 306
An anonymous reader writes "I have been programming in some fashion, for the last 18 years. I got my first job programming 15 years ago and have advanced my career programming, leading programmers and bringing my technical skill sets into operations and other areas of the business where problems can be solved with logical solutions. I learned to program on the Internet in the 90s.. scouring information where ever I could and reading the code others wrote. I learned to program in a very simple fashion, write a script and work your way to the desired outcome in a straight forward logical way. If I needed to save or reuse code, I created include files with functions. I could program my way through any problem, with limited bugs, but I never learned to use a framework or write modular, DRY code. Flash forward to today, there are hundreds of frameworks and thousands of online tutorials, but I just can't seem to take the tutorials and grasp the concepts and utilize them in a practical manner. Am I just too old and too set in my ways to learn something new? Does anyone have any recommendations for tutorials or books that could help a 'hacker' like me? Also, I originally learned to program in Perl, but moved onto C and eventually PHP and Python."
yes (Score:5, Informative)
Although 18 years of programming is barelly adolescence ... (I started with fortran IV because fortran 77 was still being implemented ...
Now let's assume that you want to learn to write Fubarish code, you'll find out that there are at least five major languages/IDEs/Frameworks to Fubar...
Choose one, preferably one of the "bigger ones" and make sure it's activelly maintained...
And then take a deep breath, and know that IT WILL TAKE TIME .... the issue is not that you really need to "learn new paradigms" in most cases it's just rather minor variations of old ones (some time very neat variations, that is the fun part)... the issue is that you "almost understandn but yet it does not seem to make sense"...
The issue is similar to adult learning new languages vs children learning... adults do not really learn slower than children, but they want to express themselves correctly and speak about "interesting things"...
Kid's are happy to say "see spot run, give ball me !", adults feel frustrated by this and have trouble making the initial steps...
So be patient and for instance try something like meteor or angular and try to make an ugly "hello world" app... (or what ever is relevant to what you'd like to build ...) ... "I did it !" ....
then "hello world, AGAIN and I'm the best" app...
then "hello "
etc...
at some point after five time more time than you initially thought it will hit you
Good luck youngster :) ...)
(and now get off my lawn
No (Score:5, Informative)
Am I just too old and too set in my ways to learn something new?
No. This question> [slashdot.org]comes up [slashdot.org] all the time [slashdot.org] on Slashdot [slashdot.org].
Honestly, from your description (which is too short to be certain, of course), and based on other programmers I've known with similar symptoms, you give up too easily, and that is your problem. Every programmer eventually runs into something that is hard. The key is to keep at it until you understand. Read through the Javadocs for Java [oracle.com] until you understand how they are organized. Or whatever framework you want to learn.
It's primarily a matter of not giving up until you have it learned.
Complexity (Score:4, Informative)
I learned to program in a very simple fashion, write a script and work your way to the desired outcome in a straight forward logical way. If I needed to save or reuse code, I created include files with functions. I could program my way through any problem, with limited bugs, but I never learned to use a framework or write modular, DRY code. Flash forward to today, there are hundreds of frameworks and thousands of online tutorials, but I just can't seem to take the tutorials and grasp the concepts and utilize them in a practical manner.
I can see where the problem is. You just have to accept that everything is million times more complex than when you started. The new big frameworks and sophisticated build systems are going nowhere. You are were used to writing relatively simple programs. Today you need some serious grit to get through projects.
Re:what you need them for? (Score:5, Informative)
And which framework was that? If it's targeted at "enterprise" use, then speed and efficiency won't be one of its core features, not with runtime annotation processing...
For example, Apache Wicket is a gross bloated thing to avoid the "horror" of learning how to program a web UI in JS that communicates with the backend server using sane RESTful APIs. OTOH it saves you from writing those APIs and keeps your codebase in a single object oriented language.
Hibernate is a gross-but-cool thing that saves the developer from touching JDBC. It's overhead pales in comparison with the network latency/RTT and database effort though, and it allows the programmer to again do database operations at a decent OO high level. Personally, I prefer JDBC but that can end up with a lot of boilerplate code to do simple operations. But OTOH you could end up with dodgy DB code, failure to try/catch/finally properly, etc. HQL can DIAF.
And Spring ... Spring does everything. Dependency injection is a major advantage (until you use it, you might wonder why your "EntityManager" class is not good enough), interceptors, etc. Ignore the MVC crap, that's old hat.
And tooling is another thing. Maven is essential for the Java developer today. Until I used it, I was happy with Ant and manually updating dependencies. Selenium is an essential web UI integration test tool too. Anything that makes testing, integration testing, etc, easier should be welcomed with open arms. Team-based development is a recipe for breaking code contracts in multiple places.
There are a lot of new tricks that a programmer that has stayed in a comfortable role for a long time could have missed, and find problems when looking for a new job. Luckily, a good C programmer is unlikely to be applying for Java roles, and roles are often now in the embedded marketplace where frameworks are less common over raw C with common libraries.
And there will be plenty of people that disagree with everything I've written. The joy of programming, eh?!
From someone who's been in the same position (Score:3, Informative)
Starting from the position of an "old skool" programmer and trying to learn all the new tricks at once is difficult. You're absolutely right about that. Don't let that discourage you though.
The reason it's difficult is because if you're trying to learn one of the common frameworks from your position, you're basically trying to learn a whole shedload of new things all at once. There's a ton of buzzwords and jargon that you'll need to work through, new concepts, and of course the conventions of the framework itself. It's too much to try to learn all that in one hit.
What you need (and what all the framework authors and tutorial authors seem to miss) is to take things a step at a time. You'll probably be able to get through things pretty quickly that way.
I'll assume you're familiar with OOP already. If not, that's where to start because most of the modern concepts that you're talking about hang off of having a structured object model. Make sure you have a grasp of the more advanced OOP concepts like inheritance, polymorphism and the like; they're all actually fairly simple concepts once you get past the jargon, but again key things to know before tackling the next bit.
Now you can start thinking about "Design Patterns". This is another topic where there's a lot of people spouting jargon in a way that makes it virtually impossible for the uninitiated to understand what they're talking about. The basic thing to know is that design patterns are just ways of writing software. They've all been around for a long time, and you're probably using a lot of them already without even thinking about it just because they're the obvious way to achieve things. They key thing to know is that in the mid-90s, a book was published [amazon.com] which described the common patterns, and gave them names. These names have become the standard ways of referring to them, so you'll find people talking about Factories, Adaptors and Singletons and expecting you to know what they mean. You may want to consider getting a copy of that book.
Next thing to learn about is a concept called MVC. Where design patterns describe ways of writing individual classes or linking them together, MVC is about the architecture of your entire application. Virtually all the common frameworks these days use an MVC architecture, so you really do need to know what this is before you'll get anywhere with a framework. MVC divides your code into business logic ('Models'), user interface ('Views') and code to manage the interface between them ('Controllers'). As with design patterns, the basic concept of keeping your business logic separate from your user interface has been good practice for decades, but has been formalised with concepts like MVC.
Those are the core things you need to know. Additional concepts (you mentioned DRY in the question) will show up along the way as well but you can pick them up as you go.
Old dog (Score:4, Informative)