Slashdot Mirror
Ask Slashdot: Can an Old Programmer Learn New Tricks?
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."
You have 18 years of learning by doing.
Classes and tutorials are not what got you there. You did things.
Name a program you could make in C or perl that you know well. Now try one of the new languages you wish to learn and set the goal of making that program in that language.
Then do it.
You'll have to look up syntax etc for every little operation. But you'll learn. And once you know how to do that you'll have the confidence and core knowledge to bootstrap yourself further.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
maybe that's your problem. just taking a framework and using it for nothing leaves you with nothing.
most "frameworks" are just gobbled up shit anyways, quite often now consisting of other frameworks which consist of other frameworks and so you end up with something that serves a tcp/ip connection, serves 100kb of files but somehow manages to take up 300mbytes of disk space and 600mbytes of ram...
so whats a hip framework today? is it hip because it's actually good? unlikely. as proof just check what was hip and cool 10 years ago, 9 years ago and so forth.
world was created 5 seconds before this post as it is.
I'm in about the same situation, except that I'm not 100% autodidact (I *did* learm programming at school, back in the 1970's), and I sometimes feel the same.
There's one observation though: we've got a number of 'junior programmars' here, fresh from school.
They're all extremely good at what they do, much better at using a framework than I am, but at the same time they're not even competent in stuff I consider elementary.
Among them are 4 (four) Flash developers. As a test, when we moved to another building and they all got new computers last year, I made them configure their mail reader (MS Outlook) by themselves. Just gave them each a piece of paper with everything they needed, set them loose, and observed.
One immediately came back asking for help, and two of the others wouldn't have got it working without assistance from the fourth.
Those same four are proficient in Perforce (source management) because they were taught how to use that that at school, and when they were hired, the person who hired them (who left the company since) installed a Perforce server especially for them. When I tried to make them switch over to Subversion because that's what I and everyone else uses here, three out of four complained that it was too difficult. Even with Tortoise as a client.
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
If you think fifteen years in the profession makes you an 'old programmer'.
-- This sig is only a test. If this were a real sig it would say something witty. --
Am I just too old and too set in my ways to learn something new?
No. This question> comes up all the time on Slashdot.
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 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.
"First they came for the slanderers and i said nothing."
I've been a programmer (mostly) for the past 25 + years.
At 16 I wrote my first computer game, love it and then... Stopped.
Used Fortran, Cobol and stuff and eventually Java Enterprise stuff.
Realised I HATED IT!!
At 46 decided games were my passion (should have continued from my first game at 16).
Fast forward 3 years I feel proficient in Objective-C, Cocos2D and other game frameworks - I absolutely love it. 3 published games later and a pile of other stuff - Having the time of my life.
Do what you love is all I can say to anyone readying this.
And if you want to learn IOS there is NO BETTER COURSE out there (yeah I like capital letters) than the free Stanford CS193P course on iTunes - Google it.
Paul Hegarty rocks as an instructor.
Embrace it, I am living proof its never too late!
Games Programmer And Designer
I started to learn programming at the age of 11, and two years later had a 'summer job' writing software for a contracting firm in central London. That was in 1984. I'm now 43 years old, and am still learning new things. I stopped contracting a couple of years ago for a simpler life, and my software development is more about scratching my itch rather than a clients, and it is certainly more interesting that way. If you're not motivate to learn something new just for the sake of it (I'm a big fan of Duolingo and Khan Academy) then you're going to have to find that itch for yourself.
Any fool can talk, but it takes a wise man to listen.
"I played around at writing code, but I never actually learned any of the other skills that are just as much a part of being a programmer."
If you haven't learned those skills in fifteen years as a professional, the problem isn't your age. I became a professional programmer at the ripe old age of thirty-six, and learned all the skills you're afraid of in my first year on the job. I had to!
Years ago I actually burnt out. I felt like I couldn't learn anymore. I kept sitting down in front of my editor and going through the motions, wondering where the inspiration was, never able to click into the zone, chasing focus, being unproductive.
I took three years away from code. I got married and started a family. I worked at a relative's construction company. At first I had to force myself not to think about tech. Then I found myself actually forgetting about it because I was doing other interesting stuff. Eventually I realized I needed some software to do something, so I sat down to build it and the old joy was back. Everything felt fresh again.
Recommend you take a break and do something completely different - for years if necessary. You only live once. You might come back to software, you might not. Do what's right for you. The programming world will still be here rediscovering old design patterns and handwaving about the latest development process fads if you choose to get back into it.
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.
As others have said - find something you enjoy programming. I started making games for mobile a couple of years ago using Unity3D and Mono/C# - it ticks a lot of boxes for me, just enough coding, just enough creativity and other bits, just enough story telling. If you get bored of one bit you try another and eventually you get there. Plus you learn something about your target platforms along the way.
Games or mobile might not be the way you rediscover your joy but there is bound to be some great tech out there that you just can't wait to get your teeth into. Word to the wise - Kinect and Leap are not it.
Yes, you can learn new tricks, but like everything else you have to work at it. I've been programming in some fashion for close to 30 years but I'm still learning new stuff all the time (getting employed on the basis of the new skills is a bit harder, but not giving up yet).
If you are struggling to come to grips with frameworks, might I suggest that you are probably not getting 'why' they are written, or what they are trying to achieve. Not getting that means you are trying to memorize a whole bunch of stuff that doesn't seem to make any sense, and that is basically impossible.
The easiest way to understand the 'why' of a framework is to start trying to write equivalent things yourself from scratch.
Once upon a time I installed Django and worked through the tutorial. Admittedly I was pretty impressed with the inbuilt admin interface that you got for very little code, but beyond that it all seemed too long-winded and abstract for what I wanted to do. So I decided to not use Django and just write my own application directly using wsgi.
I spent a day or two happily coding up a number of functional pages and a rudimentary menu system. Then I realized that some of my code was getting a bit unwieldy. Functions to parse the url and call the appropriate function were getting too long, and code that produced the output was starting to be duplicated in numerous places. I sat down and had a good think about how I could refactor stuff to be more maintainable when suddenly it hit me... "I'm re-writing Django (though much more poorly)".
Once I realized that, and I understood the problems that Django was trying to solve it all suddenly made a lot more sense and I found it easier to get my head around it all.
It sounds like you don't really have 15 years experience. You have a few years experience that you've been repeating over the last 15 years. You also tend to sound more like a scripter than a programmer (not that there's anything wrong with that!). Becoming a fully fledged programmer would therefore be the next step for you, and you could certainly take it, but I doubt you will. You are lacking one or more of these:
* confidence
* direction
* motivation
Learning ability is not likely to be the issue, it's the lack of desire to learn that is at the root.
Find something you are really passionate about and make that happen using whatever tools are considered the best in that domain. Many older programmers unwind and expand by writing games or personal projects that scratch their itch. Find something that interests you and get coding.
Personally, I'm working on a pair of games right now. One with a team (8-16 month duration), and one that will take the next few years of my life which I am starting work on solo. They give me reason to fire up the compilers, read the docs and flex my chops.
All those moments will be lost in time, like tears in rain.
You appear to not know fundamentals.
This is very common with self-taught programmers, or programmers who came up through either vocational training, or programmers who were apprenticed into their jobs. Unfortunately, this makes you much less valuable, because you probably don't know the proper terminology to use when referring to a specific algorithm, or you do not have a working knowledge of rarely used data structures, or you do not know object oriented programming paradigms. Minimally, you are going to be handicapped when you are trying to communicate about these things with your peers - in other words, people who have a formal education in these things can use a shorthand you can't, and as a result your communications bandwidth is considerably less than theirs, when talking about technical aspects of the work.
The first key to understanding frameworks is that there is an inversion of control: the framework dictates the control flow, not you. This may come from after you call into a framework functions, but in the simplest implementation, it comes from you not getting to write your "main" function. If you have used yacc, and did not supply your own main because you have linked to liby.a and used the liby.a supplied main() and yyerror() routines, then you have used this type of programming. If you have used rpcgen and used librpc.a to supply the main() for your program, you've also done a similar thing.
The second key to understanding frameworks is that you are allowed to extend, but not modify, a framework. Extension is done by overriding callback methods, or by providing additional event processing by hooking the default action, which is typically an error action. For this to be understandable, you need to have a minimal understanding of object orients programming. It's perfectly possible to do object oriented programming in C (in fact, libXt and libAw and other widget toolkits in X Windows did exactly this, prior to wide availability of inexpensive C++ compilers. If you've ever had a pointer to a structure that contains function pointers, and substituted one set of function pointers for another by setting the structure pointer through which you call things to one structure instance or another, you've done this. In simplest terms, you can write a function that gets called when you press a button, but you can't change the fact that it's a button, or the fact that when the UI sends an event into the framework, that causes your function to get called when the user clicks the button.
The third and final key to understanding a framework is that things have default behaviours. If you don't supply a function to handle a particular event, then the framework is going to supply one for you. For example, if you have a menu bar with drop down menus, the main menu will probably have a quit option. If you don't supply a function to implement the quit (e.g. popping up a dialog and asking if the user wants to save their work, if they've done any), then the default action will happen instead, and the program will quit - without saving the changes, since it's your responsibility to know that there were document or settings changes, and it's your responsibility to warn the user, if the user needs warning.
You might have some minimal knowledge, through use of Python, of the very basics of frameworks, but since the language doesn't actually force their use, then you probably don't have a very good understanding beyond that.
My suggestion would be to take a class or seminar on object oriented programming; one thing that's pretty popular is the Stanford series on iPhone programming using Objective C, which will also teach you concepts about object instantiation and messaging, which are things you might need to know on top of just object oriented programming.
You'd also do well to learn a compiled object oriented language, like C++, if you opt out of learning Objective C, rather than relying on "getting it" by using a language which doesn't force object orientation on you. At the v
If you have to ask Slashdot, then I'm afraid that the answer is no,
Nope, this answer is utter horseshit.
I've encountered the same framework madness as the OP. I've come to the conclusion that 99% of them are utter drivel and it's almost more work to figure out how to use it than it is to code it from scratch, which makes it kinda useless as in the latter case you get much better flexibility.
Basically, it seems like they make the easy 80% of a problem tribial and the remaining 20% nearly impossible. Better to stick to good libraries instead.
Elaborating a bit, the GP like me learned from lots of available material in the old days. In those days, the lack of frameworks and general flatness made things a bit more straightforward. Basically you could figure out what things meant at a fundemental level fairly quickly. With the vast modern frameworks, there seems to be much more trusting in the magic of them, and that doesn't sit well with someone who has a decent nuderstanding of programming, operating systems and architecture.
My advice, ignore the mega frameworks if possible, and don't onfuse them with handy platforms and avoid those as well.
SJW n. One who posts facts.
Unless you have some kind of brain problem (learning difficulty, Altzheimer's etc), you're never "too old to learn". "Too old to learn" is I think an excuse much of the time, learning can be difficult and it's human nature to avoid difficult things much of the time and instead take the path of least resistance. So understand it's going to take some real effort and try to take a structured approach to whatever you're going to learn. If you learn best by doing (or enjoy learning most by doing) then structure your learning by using practical tasks.
When learning a new programming language often you spend a lot of time in the reference manual simply because quite often things surrounding a framework or language are fairly complex - this makes progress seem slow and difficult, but if you can focus on a task and complete it and keep doing it, it gets easier.
As others have written, have you learned the fundamentals? You may want to go back to basics for a while and really make sure you understand some of the basic CS types of things if you find you're reading documentation on some class library and it mentions things like linked lists or other data structures and you're not sure how that would be implemented.
Oolite: Elite-like game. For Mac, Linux and Windows
If you have to ask Slashdot, then I'm afraid that the answer is no, you have reached the end of learning new tricks if you cannot figure something this simple out on your own.
Right answer, wrong reason.
Every good engineer I know, software or otherwise, can't resist learning how the next new shiny works and seeing if they can't put it to good use. In fact I sometimes feel guilty of wasting inordinate amounts of time doing that sort of thing. Thus I know I can learn new tricks because I do it all the time.
They reality is it I hadn't done that all my life, I would be in the dust bin now. I learnt to program in the 70's, on punch cards. Our uni lecturers tried to get us to imagine the shiny's we would have now, I guess as a way of preparing us for continual learning. It's funny now I look back on it, but among the many things we didn't think of are the internet, mobile phones, public-key cryptography, or cryptographic hash functions. It's been a remarkable time to live through.
If the submitter doesn't know he can learn new things too, he is in deeper shit than he realises. It's not a question of whether he can or can't - he almost certainly can. But if he hasn't been doing continually, there is soooo much to catch up on.
Read the following two books, that is how I learned to go from qbasic to object-oriented python using design patterns:
- code complete
- design patterns
After that of course you need practice.
By the way, it is worth it and makes code more easily reusable because it allows to make small changes to existing code more easily. Although this does not teach you to use frameworks, the logic of thinking in patterns and how to do object oriented programming properly is a very good start.
Someone broke Betteridge's Law. That's quite a lot more interesting than the actual question, which is, of course, dumb.
That only young people can learn is one of those myths that get debunked all the time and no one ever pays any attention. You know that bullshit about language and how children pick up languages (including their mother tongue) magically while adults struggle so much? Yeah, it's total bogus, in fact adults learn languages faster and better than kids with the same investment in time and dedication.
The main difference is that young people in practice learn faster because they have little else to do. If you'd get the same exposure and personal teacher attention as a small kid does, you'd pick up a new language in half the time.
So the real question is: How much time and effort are you willing to expend? Is it something you really want and are willing to spend a few hours a day on?
Assorted stuff I do sometimes: Lemuria.org
Programming was done and dusted as a discipline in the sixties, got creative in the seventies and has been taking the piss ever since. New programmers need to stop learning tricks and learn to write good programs that work on minimal resources and work under strain and with no guessing games involved, just like the Space Shuttle people did, and learnt the beauty of purity that Lisp showed, the beauty of simplicity that Forth showed, and redevelop the lost art of programming. Modern day computing is ugly. [ Here ends the rant of an old school fundamentalist ;-) ]
John_Chalisque
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 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.
To a significant extent, all the practices that make a workable environment were abandoned for the internet. It's likely that the learning curve problem you are experiencing is a reflection how bad things have become for coders.
Take languages. With the possible exception of Python, all the languages associated with web development have glaring flaws. PHP is conceivably the worst language to ever gain broad acceptance. JavaScript does objects wrong and has evil lexical scoping rules. You have to be very careful or you can step on an assumption made by object in a library that you don't even know was loaded.
Thoughtful system design has been replaced by object oriented programming. The failed assumption is that if you have an object model, you must be doing a good job. This is a prime example of magical thinking. Just because it's all objects does not mean that it was done right. (I'm talking about you, Java).
Then there are the "non-standard" standards. The poster child is HTML in the browser. To reach the full user base web pages must code for multiple incompatible implementations. Chalk up a lot of this to Microsoft, but even they had a lot of help creating the garbage dump called web standards.
Frameworks take the mindset of spaghetti code, force it on the coder and then claim that they are really great. Take Cake/PHP. Using it is the equivalent of chewing on a mixture of crushed glass and push pins. It only seem useful if you have been swimming in the cesspit of PHP.
To be fair, I must say that JQuery is one of the best examples of software out there. I demonstrates that even given a flawed language like JavaScript, and the snake pit of inconsistent DOM implementations, elegant and useful software is possible. It's just too bad that there are very few tools that do such a good job.
So don't blame yourself. You are as smart and capable as you ever were, it's the work environment that has become degraded. If you come to grips with the current crop of shoddy software you can achieve your ends. A more fundamental issue is if you want to work in such a terrible situation. After having the experience of being productive, it's a real let down to experience using such a crap set of tools.
Why is Snark Required?
It's possible that you are experiencing symptoms of burnout. I get this from time to time, I can't focus enough to learn new stuff. Try taking a few weeks off (at least evenings) and do something completely unrelated, like play video games or just concentrate on your sex/love life for a while. Eventually you'll be chomping at the bit to get back to the computer, and then you'll be fresh and better able to move your mindset onto unfamiliar ground.
But you better believe that learning new stuff is the bread and butter of a programmer's career; you don't just stop, ever. I mean I've been programming since 1982 but only last year I learned the theory of Kalman Filters and this year I'm diving into some Support Vector Machine stuff, as well as ramping up on the PS4. Mind you, this is pure CS stuff; learning frameworks-du-jour has never really interested me all that much. This also may be an issue for you - you may suspect in the back of your mind that learning these modern frameworks is a waste of time, and you may be right ...
I started programming 45 years ago. Over the years, I've learned to write code in about 12 languages, six of them professionally. I coded in PL/1, Fortran, BASIC, lisp, Pascal, Ada, FORTH, C, C++, Delphi, Java, Python and a bunch of assembly and shell script languages. I admit that I find it harder to learn a new language nowadays but some of that is because the languages have become more complex. It's been about five years since I had to learn a new language (that one was Python), so I expect I'll be teaching myself something new soon -- and I'm 65. So, I guess I'd have to say you have no excuse not to study another language.
Can an Old Programmer Learn New Tricks?
Talking about self-deprecating titles. The problem here is not age, but confidence, direction and determination.
Or find a better one. I recommend you try "How to Design Programs", an intro to Scheme, which, despite its syntax, is a very decently designed language. You can buy the book for money, or download it for free. (there's two versions. The newer one is more fun. The older one is more finished.) Racket is the implementation that's designed to work with it, and is available for Windows, Mac, and Linux. For free.
The book is about program design, not about piecing together fragments found on the web.
The Racket mailing list is a place where students can actually ask questions and often get the language designers and implementers to answer even trivial questions.
Try it. It won't take long, and you will learn.
To the extent you are already experienced, you will find the beginning a bit tedious. So skim through until you reach your level.
-- hendrik
I agree. I think the current "future" is Single Page Applications with HTML and Javascript (subject to change at a moment's notice).....whether it's Angular or Knockout based, SPA apps seem to be the way to go (for now). It's probably the closest we've come to the write once / run anywhere......it works on the desktop and on the device, doesn't require anything other than a decent browser, and requires very little infrastructure (a basic web server).
I had mod points but couldn't decide to respond with "Funny" or "Insightful". Seriously. There are elements of both in your statement.
Being an old fart myself, I grew up in the era of C, C++, VB, DELPHI, JAVA, JS. Today, the platform of choice is not the desktop, it's mobile. The SPA style makes it possible to target mobile either as responsive format or as a hybrid using something like PhoneGap/Cordova. Granted, someone still needs to write the frameworks and interpreters to run the SPA so the other tools and skillsets are still a necessity. But, a programmer can make a good living if they know how write a SPA.
As for learning new tricks? I see two approaches: 1) Refactor, redesign and recode an existing program you've written and know well in the past using the new paradigm or 2) Start with something new.
In the early 80's a friend of mine decided to learn to program. He decided to write a game for the Commodore PET (okay, you KNOW I'm old). He started with an idea, asked for assistance when he needed to learn a new construct for the hackers around him. His game was character based (we didn't have the graphics cards at school). The game became immensely popular among students and evening adult students. One morning, he came and the disk he shared (for him, he considered it PD) and was developing on was missing (they only gave us one). Our guess is that someone really liked it. Two years later, a game came out on the early Mac. It had REAL graphics. But, it was HIS game now being sold commercially.
Moral? Just because you don't know something now, you can still make a contribution.