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.
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.
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.
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?
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.
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).