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."
Practical application is the only way (Score:5, Interesting)
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.
Re: (Score:3, Insightful)
Actually I think you should take this a step further, not just taking a program you could write, but one you have written already. This turns the exercise from a programming-from-scratch to a porting one: All logical problems were solved when you wrote the original version. Now you can concentrate on the details of the new language/framework/whatever.
Re:Practical application is the only way (Score:5, Interesting)
Actually I think you should take this a step further, not just taking a program you could write, but one you have written already. This turns the exercise from a programming-from-scratch to a porting one: All logical problems were solved when you wrote the original version. Now you can concentrate on the details of the new language/framework/whatever.
This will work well except when you are switching to a new programming paradigm. If you rewrite a program you originally wrote in a procedural language in a mixed or object oriented language (python, java, scala, ruby, etc.) you will have to work very hard not to code a procedural solution. Similarly with a functional language - but you are more likely to struggle to write something procedural in haskel or ocaml.
Re:Practical application is the only way (Score:5, Insightful)
That might happen if you try to translate it routine by routine. The result will be similar to if you translate a text using only a dictionary; as my Latin teacher used to say, "Don't translate the words, translate the ideas."
The right way is to treat the version in the old language as a specification or a reference version.
P.S. Avoid the temptation of adding fixes, enhancements etc, at least until V1.0 is done; if you're going to drift off the model, you might as well say sod it and make something new.
Re: (Score:3)
but the new frameworks aren't for that.
they're for essentially reconfiguring a program someone else made and scripting some additional functionality into it. maybe he should instead try something like QT, instead of all the myriad openmonoraildjangobangopingoflexs's that are out there and in "demand" (there's no ruby jobs out there but plenty of RoR jobs oddly enough)..
I'm pretty sure he would have no problem picking up android or windowsphone programming either(and both are arguably "frameworks" too).
Re: (Score:2)
I mostly agree with this. One of the first things I do approaching any new language is port some of my little personal utilities to it.
You need to be careful here about a few things. One you need to pick a project of adequate complexity so you actually explore the new languages feature set. You need to make sure you are architecture where necessary to use the canonical design patterns and practices in the new language. Could you do a pretty much line by line port of a C program to Python or Ruby? Yes.
Re: (Score:2)
amen to that.
I'm a C/C++ dev by history as I've been dong this shit for ages and today its all C# , so to learn this new stuff I browse around the information about the language from sites including /. and then stepped into trying it out for a semi-real project (ie a tool to do some DB updates). Turned out to be really easy and now I can do the C# stuff with just the usual amount of googling (as whatever you do in C# its all bloody different thanks to MS changing stuff all the time, and partly because I ju
Re:Practical application is the only way (Score:4, Funny)
Exactly. Old C programmer here, it took me exactly 8 days to learn coding for OSX and iOS. It's just wrapping your head around things. and don't be afraid of saying ,"what nimrod thought that was a good idea" at times, because I see a lot of idiocy inside the frameworks.
I also chuckle at things when I see what amounts to devolving to perl obscurity in a lot of the new stuff. People trying to save keystrokes and sacrifice readability, damn kids get off my libraries and frameworks.
Re:Practical application is the only way (Score:5, Interesting)
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.
My GOTO program for this is Tetris.
It has everything from input to timing to graphics, audio, network state synchronization, even custom asset data storage of the shapes or push notification of high scores. You can make it in everything from Ada to Brainfuck, on any output from printed paper to LEDs connected to a parallel port, from the command terminal to 3D data visualizers. The state is minimal enough to manage in 100 DWORDS, but complex enough to learn the efficiencies of joins, etc. in a SQL DB.
It's simple enough to code in a few thousand chars, yet can cover all the bases esp. if you factor in "cheat prevention" (read: server side validation and user authentication).
In my experience the older you get the more efficient you are at learning a new platform. Programming becomes a meta task of translating solutions into the platform's problem space. Do it long enough and you'll end up writing your own compiler for a meta language so that you can simply add a new platform "runtime" to the supported target language lists, check off which subsystem to output in what language, and deploy existing solutions faster than these noobs can say "expressive"...
Re:Practical application is the only way (Score:5, Funny)
Dude, don't you know by now that GOTO is considered harmful? And you call yourself a programmer!
Re: (Score:2)
Re: (Score:3)
This, but also get a mentor. I more or less took a guy through this type of exercise and had him rewrite the same application four times to teach various concepts. But by being his mentor, he was able to grok the design considerations of the new technology to even know what to look up......
Rewriting an app the same way you always have but in a new platform doesn't teach you the best practices and new approaches. And not having the knowledge or experience to know the better ways makes it really hard to se
Re:Practical application is the only way (Score:5, Insightful)
Now for the unprogrammable task: try to convince management that you can still code after 40.
Re: (Score:2)
Re: (Score:2)
If you want to learn something, I'd go with Java and Android now (with Eclipse), its the future.
I'd bet against that.
Re:Seconded (Score:4, Insightful)
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).
Re: (Score:3)
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
Re: (Score:2)
Another moral might be "have a backup," I think. Now I'm curious, which Mac game are we talking about, and did your friend ever talk to the developer/publisher?
what you need them for? (Score:5, Interesting)
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.
Re:what you need them for? (Score:5, Insightful)
I agree on the framework quality. Also, their primary use is to allow people that cannot program well to get something done (badly). Last time I looked at a Java-Framework, I came to the conclusion that using it is a gross violation of all standards of professional code generation. One effect is that it takes people months before they can do even simple things.
Fortunately, my current project requires speed and efficiency, so no frameworks, but raw C from the ground up. (Libraries like OpenSSL or PCRE are fine.) The project before that I used Python as glue and C as worker. Still no frameworks.
Personal recommendation: Avoid frameworks. They create far more problems than they solve. And they slow everything down.
Re: (Score:3, Insightful)
Oh, and ignore all the assholes here that think your question is not worthy of a genuine answer. They likely do not even know what a c-compiler is.
Re: (Score:2)
Personal recommendation: Avoid frameworks. They create far more problems than they solve. And they slow everything down.
No need to make it personal, that's solid advice.
Re: (Score:2)
Thanks!
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?!
Re:what you need them for? (Score:4, Insightful)
In many ways, learning or utilizing a framework is not about what it gets you technologically, it is what it gets you socially. It gets you on the same page as other developers, using the same tools, talking the same language, etc. Even if the tech itself does not make the project go any easier, the commonality does.
Plus, once you know the framework well enough, it gives you enough background TO agree or disagree with others on a project rather then not be able to participate in design discussions. For instance if I had not taken the time to learn and work with Spring on a major project I could not really threaten to break the fingers of the next developer to utilize dependency injection, at least not with any credibility.
Re: (Score:3)
"I came to the conclusion that using it is a gross violation of all standards of professional code generation. "
Amen brother. Kids today cant be bothered with good code, and their spaghetti crap ends up as a "standard" in some places. look through a lot of the TI MSP embedded libraries and frameworks. We dont use ANY of it as it is all a bloated mess for a small embedded platform.
Hell it's a bloated mess for any platform.
Re: (Score:2)
"I came to the conclusion that using it is a gross violation of all standards of professional code generation. "
Amen brother. Kids today cant be bothered with good code, and their spaghetti crap ends up as a "standard" in some places. look through a lot of the TI MSP embedded libraries and frameworks. We dont use ANY of it as it is all a bloated mess for a small embedded platform.
Hell it's a bloated mess for any platform.
I'm not a kid, but I didn't get paid to write good code. All they wanted was to get it done fast and get it done cheap. When I tried to write good code - or better yet, good design, I got dinged for taking too long.
Re: (Score:2)
I agree on the number of good developers. However, from what I see, the mediocre and bad ones that make this their profession do more harm than good. For example, a while back I did a (very partial) review of a project that was aimed at replacing a piece of critical infrastructure in a large company. The project was convoluted, slow, had extreme algorithmic errors (I accidentally found a quadratic sort that could have very large input), was very hard to get an overview over, etc. The project was canceled a
Re: (Score:3, Interesting)
I love how the OP is asking about how to stay current with new languages and technologies that employ the programmers of today and tomorrow, and the best you can come up with is some working-class hero grey beard defamation and unfair characterization of the "bloated inefficient framework". You sound like a person that tried one framework with little guidance that turned out to be bad, or it turned out that you didn't like not having fine control over every byte of memory so you wrote them all off as being
Re:what you need them for? (Score:4, Insightful)
I am actually a person that does code reviews (among other things). I don't mind that my statements make me sound out of touch, because the mess that is going on today with frameworks is nothing I would ever want to touch as a developer. As to "hard to maintain", you seem to have no idea how bad the "modern" style is. Things that could have been done with a few compact binaries and shell scripts to link them together, are done as a mess with hundreds of files, toolkits, "engines", frameworks and the like that nobody can really read or evaluate anymore. Even the developers don't know half the time what it does exactly after working with the stuff for years. That is not progress. That is erosion of technological competences.
As to IDEs, there are two kinds of users: Those that can produce good code without and those that cannot produce anything without. The second class is very likely to produce utter trash even with an IDE. The problem is that an IDE helps you write complex code. Complex code is by its very nature already broken. A competent developer simplifies, an incompetent one throws more code at the problem. As a result, for competent coders, it matters very little what development environments they use as they are not writing that much code for a specific problem and spend much more time thinking than typing.
My advice to the OP is to focus of the segment of the market where there still is some understanding of what quality code is. Not only is that segment not going to vanish when the next fad comes around, it also pays better and working conditions are better.
Good perspective on frameworks (Score:2)
The biggest thing about frameworks is that they are supposed to give people the ability to learn one way of doing things that provides a structure to solve just about every use case for a particular type of problem and in doing so, make it easier for teams to collaborate. That's why Rails and it's clones have taken off so much. You learn rails and you can jump from project to project without having to figure out exactly why/how each individual programmer decided to do things differently. Additionally, they
Re: (Score:2)
Re: (Score:2)
alas, what you say is true.
But there is a huge amount of effort being spent in using these things, to the point where you go for an interview and they're not interested in what language skills you have, but whether you know framework x or y.
So that's why you want to learn them, shit reason really :(
Yes (Score:2)
I've never been able to learn "frameworks" from books. I've tried, not my thing. Documentation on the other hand is usually a good start, especially if it's written to be short and to the point. Most important, look at code. There's a ton of free/open source software which you can look at, learn from, contribute to. Find a small bug, learn how to fix it, make a patch, send it in.
Specialism (Score:5, Interesting)
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.
Re:Specialism (Score:4, Interesting)
What surprises me most about that is not so much that they aren't familiar with Outlook configuration (webmail has butchered general knowledge that 'email' is even something that you don't just get from a website, and Outlook's heaviest presence is in corporate/institutional where IT tends to automagic as much of that as they can, lest they have to walk you through it.); but that someone of their demographic (junior, recent graduates, presumably comparatively young) wouldn't Just Fucking Google It before asking a potentially embarrassing question. Especially given that googling around a bit is more or less the standard response to a situation where documentation is lacking or unclear on some programming matter.
The fact that they lacked specific knowledge of a given mail client isn't too surprising(though Outlook isn't rocket surgery, so failure to figure it out is a little weirder); but how does somebody make it through programmer school without picking up on the fact that the internet is a repository of many secrets and asking it can save you a lot of time and trouble?
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
Re: (Score:2)
This is great stuff and is helpful advice to me as well. Thanks you old bastard.
You have already given up... (Score:5, Insightful)
If you think fifteen years in the profession makes you an 'old programmer'.
Re:You have already given up... (Score:4, Insightful)
If you think fifteen years in the profession makes you an 'old programmer'.
Depending on how old you are when you start, the amount of time required to become 'an old programmer' can be identical to the amount of time required to become 'a programmer'...
Re: (Score:2)
:-)
I don't see myself as an old programmer. I started programming in 1978.
Re: (Score:2)
:-)
I don't see myself as an old programmer. I started programming in 1978.
That was my thought too. I've been coding for 35 years, and earning my living from it for 30 of those years. There's always new things to learn. That's what makes it fun!
YES! (Score:2)
Learning is just about putting in the work. If you decide that you want to learn emacs LISP, and want to implement a project in it, it's possible if you're willing to put in the work.
As others have pointed out, the more salient question is, why? If you really have progressed up the ladder, then presumably your focus is no longer about daily programming, but more about project management and general management. At that level, it becomes less important to be able to implement a widget in the newest shiny l
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.
Re: (Score:3)
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.
Quite possibly. I think that programmers of a certain sort are used to hard problems, like delving into the guts of hardware for a driver or a triky algorithm, to solve a task in cunning, but more efficient way. The frameworks aren't any of those types of h
It's Never Too Late! (Score:5, Interesting)
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!
I've been learning new things for 30 years (Score:5, Interesting)
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.
Re: (Score:2)
I wrote my first bit of code in 1970, in FORTRAN, and now, at 59, I still like coding. It's not where the money is, so I mainly do architecture, but coding is much more fun.
Is it hard to learn the new stuff? Yeah, it is. Definitely harder. The new frameworks tend to be pretty huge, and rely on lots of fairly random assumptions - "convention over configuration". You need to pick up a big heap of conventions, which is painful.
On the other hand, the basic structures still shine out. Async here, sync there, mes
Translation (Score:5, Insightful)
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!
It's okay to be tired of programming (Score:5, Insightful)
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.
Re: (Score:2)
Probably the best advise I've seen. I'll try it myself.
Re: (Score:3)
I think in my 20s I just didn't know how to recognize burnout. Combined with the usual invincibility complex and with an image as a caffeine-fueled wunderkind to uphold, I ended up burnout incarnate.
Now, when I feel unproductive for a several days running, I know I need to take a week or two and just do something else. I'm a better coder for it, and a better person too.
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: (Score:3)
If the slashdot-asker is asking because his boss wants a problem that isn't a member of that category solved, or the cheap offshore labor has gotten adequate at solving that class of problems for peanuts, he is undeniably in serious trouble; but the mere existence of greater complex
Re: (Score:3)
Education vs training argument (Score:2)
Open your mind (Score:2)
There are other programming languages besides those listed in the article. It's interesting there is a whole resurgence of new programming languages.
Some people need a little encouragement. Write formally verified code and learn Coq. Learn a functional programming language like haskell or take a blast from the past and learn smalltalk.
You might never use these for anything practical, but what you learn from them is invaluable. You need to constantly be learning new things.
Re: (Score:2)
In that case I would not learn such worthless stuff. Sorry, but 'you might never use these' is worthless in my book. When I feel the need to train my learning muscle it is stuff like OpenGL, video encoding, OpenMP. Stuff I can use and do with the languages I already know, but are new to me. Just learning a new programming language becomes sooner or later brainfuck. It i
Rediscover your joy (Score:2)
As others have said - find something you enjoy programming. I started making games for mobile a couple of years ago using Unity3D [unity3d.com] 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 o
Pick a problem first, not the solution (Score:2)
I've been programming longer than you have and I'm still learning new things every day. That's not an exaggeration - we have so many cool projects at work that I can't stagnate.
The key here is to have a problem to solve, then learn whatever you need to learn to solve that problem.
You don't decide 'Well I should learn PHP now... okay, now what do I do with this?' or 'I hear Java is good on a resume.' You find a problem that's interesting to you (I want to make a game that... I want to make a neat device tha
Yes (Score:4, Interesting)
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.
Maybe (Score:3)
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.
You appear to not know fundamentals. (Score:5, Insightful)
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
Re: (Score:2)
Re: (Score:2)
And what, exactly, does using an "interface builder" to build a GUI program teach you? Nothing. Respectfully, it seems that you seem to be part of the problem rather than the solution.
Commercial IDEs from vendors like Apple and Microsoft are "better"? Better for what? I think that after a statement like (in addition to the "gui builder") that you need to take a step back and consider what your stance is and how well you really understand things.
Tell me, what is the "order of the algorithm" that the gui builder generates?
If you're trying to learn to use a framework properly, then I posit that interface builders will help you do exactly that. You'll learn how to wire up all your controls and to handle the framework callbacks properly. I am not saying that you'll learn how to write the UI code, but it will at least force you to learn how to research frameworks and their use. The interface builder doesn't actually write your framework code for you, but it will help you learn what the framework needs you to do in order for y
Re: (Score:2)
Better as in faster deployment, more reliable programs, more likely to use source control, and better at breaking things down into discrete components.
you know, better.
I've been writing a lot of 6502 assembler lately (Score:2)
Too old to learn is an excuse (Score:3)
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.
book recommendations (Score:3)
- 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.
wow (Score:5, Interesting)
Someone broke Betteridge's Law [wikipedia.org]. 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?
Programming Old School (Score:5, Insightful)
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 ;-) ]
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.
Get used to a poorly designed environment (Score:5, Insightful)
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 [wikipedia.org]. 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.
Get rid of the poorly designed environments. (Score:3)
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 Rac
Re: (Score:2)
Mod parent up.
Young programmers can eat large amounts of hip, carelessly designed defacto syntactic sugar and not get diabetes.
You don't want to (Score:2)
Actually, as a programmer, you don't want to learn new tricks. The "trick" you should master is to write decent code and to be curious after the tools you can use to write that code. It doesn't really matter what programming language you use if you have the skill to quickly learn the specifics of that language. Once you know a few, you see the general pattern, and you know them all.
Burnout? (Score:2, Interesting)
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
Projects, not languages (Score:2)
Merely speaking a language may not be interesting enough to rekindle your interest and encourage growth. But there hundreds of good open source and freeware projects that would benefit from your insight and experience. CPAN, github, GNU, and Apache all host projects that may interest you nad have relevance to your work, without being part of your daily grind. Perhaps you'd enjoy a chance to refine some familiar old project?
Your question makes no sense at all (Score:2)
Every human is able to learn new things. It is in our nature. Most people stop learning in a school way after school and switch to experience learning. However, in the IT industry you always should learn new things from books or tutorials. If you have not studies CS at university (which is IMHO the only way you could not have heard anything about frameworks) then it is time to learn theoretical foundations of your field. It will mix perfectly with your experience and of course challenge one "fact" or anothe
Wrong study techniques (Score:2)
You are clearly a reasonably intelligent and capable person, and that doesn't go away with age. It does become harder to memorize things as you age. (Remember when you were 6 and could recite whole episodes of cartoons that you had only seen two or three times? That's not happening again.)
Whenever you spend time studying and fail to learn it's always because of one of two problems: lack of smarts, or the wrong studying techniques / studying environment. In your case it must be the latter. Did you go to coll
Re: (Score:2)
"Remember when you were 6 and could recite whole episodes of cartoons that you had only seen two or three times? That's not happening again
what do you base that on, and a personal anecdote, I am well into middle age and just started learning music and I can memorize sheet music and songs as well as I cold memorize anything when I was six.
Personal anecdote being what it is i.e. not data.
": lack of smarts, or the wrong studying techniques / studying environment.
nope. Smart only indicates how long. Sometimes n
Old dog (Score:4, Informative)
You're not old or particularly experienced ... (Score:2)
You're not old nor are you particularly experienced at programming. Fiddling with web stuff for two decades doesn't make you an expert programmer. On the contrary, in the battle you learn lot's of bad habits. I should know, I'm in roughly the same position as you. Mind you, hacking together a messy system that has the customer satisfied two weeks from now and has the varnish of feature-completeness is a skill on its own, but it's only remotely to do with proper programming.
The problem with applied programmi
Damn (Score:3)
Can an Old Programmer Learn New Tricks?
Talking about self-deprecating titles. The problem here is not age, but confidence, direction and determination.
No Old Programmers (Score:2)
Old Joke: "What do they do with Engineers when they turn 40?" A: Buy them a birthday cake then take them out to the parking lot and shoot them.
18 years of experience probably means you are either getting close to your 2nd cycle of becoming an "expert" in a technology area or you've been doing the same 2 years work 9 times in a row. Either way, it's time to get out of your current sweet spot and learning something entirely new. You need to get "leverage" with your experience. Really learn something like Agil
Yes Yes Yes (Score:2)
My wife, who started programming in the late 1970's went back to College in 2008 to complete her BS degree. She learned PHP, Java, Java script, CSS. Graduated with honors from UCF. She is very skilled at web development now. She is 53.
She even completed a MS style Thesis in the honors in the majors program.
http://explorer.cyberstreet.co... [cyberstreet.com]
Ruby on Rails (Score:2)
Ruby is the scripting language, and Rails is the framework that includes everything you need to quickly and easily make web applications. RoR emphasizes DRY and RESTFUL techniques that you can carry over in to any other langauge you use.
I know everybody here hates RoR because it's noobish and popular, but there are jobs for it and it's very easy to quickly whip up some sample web apps you can put on a resume. There are also tons of books and online tutorials. I rather like Railscasts [railscasts.com]
Re: (Score:2)
I hate it becasue it's poor and adds nothing to the industry.
If it's easy, then it should have almost no value no a resume.
To ask the question is to answer it. (Score:2)
If you can't do it, you can't do it. Don't assume it's because of your age.
as others have said: scratch an itch (Score:2)
Just find a personal itch to scratch and scratch it.
Doesn't have to be something you'll release, but being able to show it in action is an interview booster (thus, if it is mobile, all the better). The fun part is that once it is scratched and you decide to move it somewhere else into the cloud for more permanent hosting, there's another itch to scratch.
Case in point, I put together a shopping list manager using node/express/mongo and jquery/jquery mobile/stativus. Then found that if I were to deploy it a
Not if they are (Score:2)
asking stupid questions like that.
As an old programmer who has spent his life constantly learning, there aren't new tricks, just more learning.
Perpetual Learning (Score:2)
How to young programmers get to be old programmers? By learning.
I've been programming for forty-five years; FORTRAN, COBOL, ASSEMBLER, PL/I, RPG, Pascal, Basic, HTML, JavaScript - you name it and I've written bugs in it. You MUST evolve or get left behind in a home for obsolete programmers.
Based on several recommendations, I am now learning Ruby On Rails. Not because I can't make PHP dance on the head of a pin, but because my customers want to hear those three magic words. What they want to buy, I will
Re:If you need to ask, then for you the answer is (Score:5, Insightful)
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.
Re: (Score:2)
" 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"
Agree 100%. Often they're written by idiots just out of university who've read a couple of design patterns books and now think they've got the inside view of programming. All they end up doing is creating a top heavy behemoth that is all structure and no functionality - perf
Re: (Score:2)
The problem is a lot of managers that cant even understand programming 101 have latched onto framework crap like it's the holy grail.
Code quality across the board has dropped by a magnitude over the past 5 years out there.
Re: (Score:3)
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 imagi
Re: (Score:2)
I must agree with this. It's possible for some, but you need to have an explorative mind, that apparently you don't have if you have to ask here.
I first learned to program in Fortran, way back, in university. In my first job I did Cobol, then I switched to C and C++. After that, from 1995 on, I did Java, and now I do Android and Java. On the side I did Prolog, some php which I hate, and all the other stuff that you run into and you try out for a while. I'm sure I'll make more switches before I retire.
Re: (Score:2)
I must agree with this. It's possible for some, but you need to have an explorative mind, that apparently you don't have if you have to ask here.
Or maybe the guy is just experiencing some self-doubt, and needs some encouragement from others who have faced similar challenges and prevailed.
Re: (Score:2)
I'm going to disagree. It's a good discussion, and there are a lot of other people out there wondering roughly the same thing. I'm not a programmer, just a hobbyist, and I've wondered multiple times whether I should spend my limited free time trying to learn more about a language, or more about a framework. The few times I've looked at frameworks, it's seemed like I needed a whole book to figure out what it actually did, and after a few hours I bailed in favor of just focusing on the language and learning h
Re: (Score:2)
Probably not as well as you think.
Do they come untied when you don't want them to? If so, you fail.