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."
If you need to ask, then for you the answer is no. (Score:1, Insightful)
You have already given up... (Score:5, Insightful)
If you think fifteen years in the profession makes you an 'old programmer'.
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: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:Practical application is the only way (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: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:what you need them for? (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.
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: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.
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 ;-) ]
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.
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: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: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.
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: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.