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.
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. The good news, from the experience of an even older programmer, is that this does not happen to everybody.
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.
Old Judges? Old Lawyers? Old Chemists? Old Teachers? Old Cops? Old Comedians? Old Reporters? Old Mechanics? Old Authors? Old ... WTF!?!
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.
No, please retire so I can have a job, thanks, bye.
PS: I don't reply to ACs.
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
I am in the same age as you, and I learn all the time. The day I stop learning it is time to get another job. But take it easy, there are so many tutorials out there written by someone who understand half of what they are writing about. Framework of the week etc. They write the tutorials because they learn at the same time and that is fair enough. The signal to noise ratio is pretty low, but you can always buy a book on the subject, and start playing with Obj-C or whatever. For me it's always good to have a left hand project where I try out new techniques and knowledge. If you have the people skills, management could also be a way forward. Listen to this: http://www.manager-tools.com/2... If you are considering management, subscribe to a podcast! Good luck
If you used functions in your programming style, they you already applied the DRY principle. With functions for example you encapsulate a set set of instructions to perform a task. If this set of instructions changes, this affects only the implementation of the function (one place). All the calls to the function stay the same.
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. --
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 language, but to be able to bring the project (successfully) to completion.
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."
wtf bro
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.
Learning new tricks is the easiest part.
Getting excited about half baken technologies that offer only part of the solution is the hardest part.
The more experience one has the easier it gets to debunk all the 'magic' and merits of most popular new technologies.
Since most people have only touched very few other languages and platforms, they are very biased towards the technologies they favor most.
You and I have a similar number of years programming and working. I'm still learning new things every day. In the early 90's there was a relatively small number of choices to get the job done, usually just pick a language and go do something. Now just the breadth of it can be overwhelming.
The really great thing about today is you can go to your favorite search engine and type "[language] [what you want to do]" and it's likely going to be the first result on stackoverflow (unless you choose Go as a language). Beats going to the index of all those reference books.
If you're out to learn I suggest focusing on the area that interests you most: web, devices, web services, databases, etc. From there pick the platform (Win, *nix, Android, iOS, etc) and start narrowing down your language choices.
Here's the stack I use in daily life: Visual Studio, C#, ASP.NET MVC, jQuery, Angular, Bootstrap, Web API, WCF, Entity Framework, SQL Server. Visual C# Step-by-Step is a decent intro book http://www.amazon.com/Microsoft-Visual-2012-Step-By/dp/0735668019. I also recommend CLR via C# by Jeffrey Richter once you've mastered the basics.
If that doesn't appeal to you pick your own path by what interests you and what you see a decent number of jobs for in your area. Give yourself a project you want to make, something kind of simple, then set out to do it using that new language. This is the best way to learn a new language or framework, at least for me.
I enjoy http://pluralsight.com as well. The videos can take some of the fear and anxiety that comes from "I have no clue what I'm doing" out of new topics which will help give you confidence to explore more on your own.
My concern is why you got out of programming as a career in the first place. Is it something which truly interests you? Can you enjoy the mundane along with the exciting greenfield development? Can you handle struggling to get what you want? If so, march on and good luck!
...yes, you are too old.
Who are what I would call "old programmers", I'd have to say no.
They don't even want a new desk or laptop. change is evil.
Learn by doing. Tutorials won't get you there.
Most of the frameworks are just bloated rehashes of someone else's badly implemented framework in the 'flavour of the month' language. Generally created by people who are incapable of actually focussing and solving real problems. "Me, I'm working on the framework code, not blocked"
Find a project that interests you, implement it.
Training gives you only the VB or dotnet of the month. Education means you can sort out sorts in all sorts of languages because you know what should happen instead of just what to write.
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.
I more or less started programming in the same way. DIY, no frameworks or anything.
The only difference is I never stopped learning. For example I tend to learn at least 1 new language a year... well I at least try and sometimes fail. For example I really hated perl and PHP, really. But when I decided I need one editor to rule them all i.e. emacs I started to learn lisp (which appears to be never ending process with elisp), and when I needed a scripting language to do all of my scripts in I learned python. When I needed to do some micro controller home automation stuff well I learned assembler for AVR just because the arduino library was too big. and so on there is always something to learn you just need to have the right incentive.
My point is. In the process of learning new languages one usually get exposed to new ways of thinking, which may include one or more frameworks :), that keep your mind moving. So instead trying to learn a framework I suggest you try to do the thinks you do anyway in with different language but try to stick to the new language de-facto standards. Take python for example it has so many modules that you don't need to reinvent the wheel every time so using python is more about finding the right module then doing it yourself. If you can make a module better you can always contribute your version the the rest of us :).
As others have said - find something you enjoy programming. I started making games for mobile a couple of years ago using Unity3D and Mono/C# - it ticks a lot of boxes for me, just enough coding, just enough creativity and other bits, just enough story telling. If you get bored of one bit you try another and eventually you get there. Plus you learn something about your target platforms along the way.
Games or mobile might not be the way you rediscover your joy but there is bound to be some great tech out there that you just can't wait to get your teeth into. Word to the wise - Kinect and Leap are not it.
Ditto. I'm a contractor developer (mainly Java, but C, C++ and hey I can build a PIC board if I have to :-) ) - no single job > 3 years, and I'm just coming up to 55. So I've been developing for 39 years ... damn! Started with a Pet and ZX Spectrum, Z80 etc and worked up from there.
My last contract was very Spring/Hibernate oriented - I'd never really used them in anger, but now I can handle the key parts with my eyes closed. Previous one was a fast trading system - lots of Java concurrency and messaging, again, I'd played but I hadn't fought. Before that, it was a big govt project - not much new tech, but a nightmare team organization which I hope I did a lot to straighten out. Before that I was writing an XHTML/CSS parser/renderer for a mobile phone company.
I read a book on a new thing and then try it. I'm reading about ReST and Node at the mo' because I encroached on it before and it was sort of a mess, and I need to tighten it up. Starting a new contract is generally a whirlwind of new stuff - but I love that! It's like being on fire.
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 that...) and then you learn whatever it is you have to learn. For instance starting to deal with firmware, motors, devices, etc is like a rebirth for a lot of people compared to the boring ennui of database and web services. It's amazing how much you can do with a little Arduino or Raspberry Pi or the equivalent, and that's often enough to kick you out of your stupor.
If you can't think of anything, or if coming up with a game or trying a neat little embedded system doesn't put you back into obsessive creative mode then it's probably time to consider a new line of work, or just how to ride out your days till retirement.
Ask your collegues to review your code also pair programming. Use that to discuss DRY concepts and other desirable quality attributes.
With pair programming you (the newbie) are the driver (typing) and your collegue (experienced modern languague programmer) the navigator (correcting you, thinking about what comes next).
I recently moved from Assembler on punched cards to the new-fangled Cobol language on a green screen!
I find that for me, trying to learn some new tech or framework without a real project behind it never works. I just can't go through a tutorial without having a real use for it. I will simply stop at some point.
What sig ?
I'm old (50's) switched from C++ Windows to Java/Android. I've failed to pick up Java before, but once I had a goal in mind, it all became very very easy. Now I'm a great Java programmer (well highly paid anyway).
I think I failed before because I didn't *use* it, I *learned* it, and once I learned it, I forgot it quickly. Now, I actually use it to make money, and solve real problems, its all so trivial to now, its become second nature.
'Frameworks'? If you want to learn something, I'd go with Java and Android now (with Eclipse), its the future. For web? LAMP still is fine, you have Perl, and PHP they're still fine tools in common use.
Yes, you can learn new tricks, but like everything else you have to work at it. I've been programming in some fashion for close to 30 years but I'm still learning new stuff all the time (getting employed on the basis of the new skills is a bit harder, but not giving up yet).
If you are struggling to come to grips with frameworks, might I suggest that you are probably not getting 'why' they are written, or what they are trying to achieve. Not getting that means you are trying to memorize a whole bunch of stuff that doesn't seem to make any sense, and that is basically impossible.
The easiest way to understand the 'why' of a framework is to start trying to write equivalent things yourself from scratch.
Once upon a time I installed Django and worked through the tutorial. Admittedly I was pretty impressed with the inbuilt admin interface that you got for very little code, but beyond that it all seemed too long-winded and abstract for what I wanted to do. So I decided to not use Django and just write my own application directly using wsgi.
I spent a day or two happily coding up a number of functional pages and a rudimentary menu system. Then I realized that some of my code was getting a bit unwieldy. Functions to parse the url and call the appropriate function were getting too long, and code that produced the output was starting to be duplicated in numerous places. I sat down and had a good think about how I could refactor stuff to be more maintainable when suddenly it hit me... "I'm re-writing Django (though much more poorly)".
Once I realized that, and I understood the problems that Django was trying to solve it all suddenly made a lot more sense and I found it easier to get my head around it all.
It sounds like you don't really have 15 years experience. You have a few years experience that you've been repeating over the last 15 years. You also tend to sound more like a scripter than a programmer (not that there's anything wrong with that!). Becoming a fully fledged programmer would therefore be the next step for you, and you could certainly take it, but I doubt you will. You are lacking one or more of these:
* confidence
* direction
* motivation
Learning ability is not likely to be the issue, it's the lack of desire to learn that is at the root.
Find something you are really passionate about and make that happen using whatever tools are considered the best in that domain. Many older programmers unwind and expand by writing games or personal projects that scratch their itch. Find something that interests you and get coding.
Personally, I'm working on a pair of games right now. One with a team (8-16 month duration), and one that will take the next few years of my life which I am starting work on solo. They give me reason to fire up the compilers, read the docs and flex my chops.
All those moments will be lost in time, like tears in rain.
You appear to not know fundamentals.
This is very common with self-taught programmers, or programmers who came up through either vocational training, or programmers who were apprenticed into their jobs. Unfortunately, this makes you much less valuable, because you probably don't know the proper terminology to use when referring to a specific algorithm, or you do not have a working knowledge of rarely used data structures, or you do not know object oriented programming paradigms. Minimally, you are going to be handicapped when you are trying to communicate about these things with your peers - in other words, people who have a formal education in these things can use a shorthand you can't, and as a result your communications bandwidth is considerably less than theirs, when talking about technical aspects of the work.
The first key to understanding frameworks is that there is an inversion of control: the framework dictates the control flow, not you. This may come from after you call into a framework functions, but in the simplest implementation, it comes from you not getting to write your "main" function. If you have used yacc, and did not supply your own main because you have linked to liby.a and used the liby.a supplied main() and yyerror() routines, then you have used this type of programming. If you have used rpcgen and used librpc.a to supply the main() for your program, you've also done a similar thing.
The second key to understanding frameworks is that you are allowed to extend, but not modify, a framework. Extension is done by overriding callback methods, or by providing additional event processing by hooking the default action, which is typically an error action. For this to be understandable, you need to have a minimal understanding of object orients programming. It's perfectly possible to do object oriented programming in C (in fact, libXt and libAw and other widget toolkits in X Windows did exactly this, prior to wide availability of inexpensive C++ compilers. If you've ever had a pointer to a structure that contains function pointers, and substituted one set of function pointers for another by setting the structure pointer through which you call things to one structure instance or another, you've done this. In simplest terms, you can write a function that gets called when you press a button, but you can't change the fact that it's a button, or the fact that when the UI sends an event into the framework, that causes your function to get called when the user clicks the button.
The third and final key to understanding a framework is that things have default behaviours. If you don't supply a function to handle a particular event, then the framework is going to supply one for you. For example, if you have a menu bar with drop down menus, the main menu will probably have a quit option. If you don't supply a function to implement the quit (e.g. popping up a dialog and asking if the user wants to save their work, if they've done any), then the default action will happen instead, and the program will quit - without saving the changes, since it's your responsibility to know that there were document or settings changes, and it's your responsibility to warn the user, if the user needs warning.
You might have some minimal knowledge, through use of Python, of the very basics of frameworks, but since the language doesn't actually force their use, then you probably don't have a very good understanding beyond that.
My suggestion would be to take a class or seminar on object oriented programming; one thing that's pretty popular is the Stanford series on iPhone programming using Objective C, which will also teach you concepts about object instantiation and messaging, which are things you might need to know on top of just object oriented programming.
You'd also do well to learn a compiled object oriented language, like C++, if you opt out of learning Objective C, rather than relying on "getting it" by using a language which doesn't force object orientation on you. At the v
The perfect answer. And you can see for yourself, by a casual glance at Stack Overflow, that there's no shortage of new programmers without a clue in their head, and who expect people to solve problems that `give me the error` but who don't think it's important to include the actual error (as if there's only one possible error that could be provoked in that situation) or who demonstrate an utter lack of any resourcefulness, inquisitiveness or common sense.
Few things will force change like changing jobs. Find one you like, make sure to interview them and if you "like eachother", go for it. Sounds like you are bored, or like others said, you need a break.
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.
... for the Commodore PET. http://pettil.tumblr.com/ But now my code is better than it was in 1979, and by now I have used dozens of other languages and operating systems. Am I "expert"? No. I take the approach of learning the minimum I need to accomplish the mission (usually delivering maintainable code) plus whatever else I become curious about along the way. What usually works best is to combine a new project with a new set of tools, so I'm learning the new tool while trying to finish the project. I describe the approach as "You are here and you want to get there." or "Lewis and Clark" approach. If you started with Perl, learning Ruby. Consider learning something old school, like Forth. Install Linux on your desktop. Force yourself to live in it by deleting Windows first. In short, become uncomfortable. The best learning occurs in that space.
never ask a question you don't want to know the answer to
Just learning new tools seldom works for hackers. Hackers invariably look for efficiency which means the right tool for the job. There is not much sense in using for example C to write a wrapper or a log parsing script and likewize there is not much sense in using perl to write an operating system , Do more . u'll need more and u'll consequently know and learn more
Unless you have some kind of brain problem (learning difficulty, Altzheimer's etc), you're never "too old to learn". "Too old to learn" is I think an excuse much of the time, learning can be difficult and it's human nature to avoid difficult things much of the time and instead take the path of least resistance. So understand it's going to take some real effort and try to take a structured approach to whatever you're going to learn. If you learn best by doing (or enjoy learning most by doing) then structure your learning by using practical tasks.
When learning a new programming language often you spend a lot of time in the reference manual simply because quite often things surrounding a framework or language are fairly complex - this makes progress seem slow and difficult, but if you can focus on a task and complete it and keep doing it, it gets easier.
As others have written, have you learned the fundamentals? You may want to go back to basics for a while and really make sure you understand some of the basic CS types of things if you find you're reading documentation on some class library and it mentions things like linked lists or other data structures and you're not sure how that would be implemented.
Oolite: Elite-like game. For Mac, Linux and Windows
If you have to ask Slashdot, then I'm afraid that the answer is no, you have reached the end of learning new tricks if you cannot figure something this simple out on your own.
Right answer, wrong reason.
Every good engineer I know, software or otherwise, can't resist learning how the next new shiny works and seeing if they can't put it to good use. In fact I sometimes feel guilty of wasting inordinate amounts of time doing that sort of thing. Thus I know I can learn new tricks because I do it all the time.
They reality is it I hadn't done that all my life, I would be in the dust bin now. I learnt to program in the 70's, on punch cards. Our uni lecturers tried to get us to imagine the shiny's we would have now, I guess as a way of preparing us for continual learning. It's funny now I look back on it, but among the many things we didn't think of are the internet, mobile phones, public-key cryptography, or cryptographic hash functions. It's been a remarkable time to live through.
If the submitter doesn't know he can learn new things too, he is in deeper shit than he realises. It's not a question of whether he can or can't - he almost certainly can. But if he hasn't been doing continually, there is soooo much to catch up on.
Read the following two books, that is how I learned to go from qbasic to object-oriented python using design patterns:
- code complete
- design patterns
After that of course you need practice.
By the way, it is worth it and makes code more easily reusable because it allows to make small changes to existing code more easily. Although this does not teach you to use frameworks, the logic of thinking in patterns and how to do object oriented programming properly is a very good start.
In a way you sound like me, but aren't.
I learned programming out of a drive to actually fix what I saw were problems (that turned out to be really terrible coding by the original author, or just a lack of care.)
In C land, I'm not afraid to use a library if what I need is in that library, but I loathe C++ and OBJC "frameworks" because these add layers of unnecessary trash on top of efficient code. I do understand C++ for the most part, but I find a lot of what is written in C++, is needlessly written in C++ out of some inane desire of a "team" to standardize on a coding style rather than a practical reason that means using a OOP language.
I ripped out a proprietary scripting language and replaced it with JavaScript in one project and had that work relatively well. So it's not like I ever felt there was a reason to stick to coding an entire program entirely in C. However when it comes to OOP things, I find the cruft that has been added to languages like Perl and PHP are out of some desire to make the language more irritatingly like Java and C++ instead of, you know, useful.
What you need to learn depends on what you actually hope to accomplish. I ported RLE code from C to a proprietary scripting language, back while I was in high school, because I wanted to do -that-. I glued image-capture code into an open-source project so I could capture screenshots from the application. I glued in code, into two different gameboy and nintendo emulators so I could learn what notes are being played by the sound system in a game. The stuff has application somewhere else, but generally would be considered a waste of time to have done it had I not wanted to learn something specific.
My interests in programming often involve image manipulation or compression. Do I hope to be hired by Adobe or Bioware or something? No. If my ultimate goal was to work for either of these companies I would have just went to school 15 years ago and stuck to it. But as it turns out, had I done that, I would likely not have been employed by simply taking the local college's classes. Those turned out to be horrible. The college hired people when "Java" was the buzzword and not a single professor during that semester could actually program in it (oh lovely Java 1.0x code mixed with JDK 1.1 books they had us buy.) I knew more than the professor teaching the class, and as a result the students asked me for help with everything. I kinda just went "screw this, I'm not paying to teach a class" and withdrew from the program. In hindesight, I'm glad I didn't stick with it because both Java and Macromedia director, are pretty much not used by anyone doing multimedia. (They should have stuck with C++.) I should have just went to Digipen if I wanted to make games.
But back to the frameworks, I don't like them. I find I don't generally care for "OOP for the sake of OOP" programming. As soon as you see words like "factory" in the source code, run, run away. DRY means "don't repeat yourself", translates to if someone has already done it, don't do it again. The practicality of this depends on what language you use, (eg scripting languages often involve having to use C libraries or built-in functionality, writing libraries -in- the scripting language is a foolish thing to do.) If you primarily work in C code, then it's very easy to use "standardized" libraries like zlib or libpng without a second thought, because nobody else has written an alternative better code (lzw, lzma, etc) that can be applied. For example if, I rip zlib out of libpng and replace it with lzma, it would make it super slow and only produce png files that can be read by my application. That's a pointless endevor for the sake of saving a few bytes in the resulting images. I did this with a video codec (saving a few bytes across a few million images is more meaningful) and ultimately came to the same conclusion that even though switching the compression algorithm saved either time or space, the resultant incompatibility didn't provide a meaningful excuse to not use the sto
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
Get hold of the code generation tools from imatix.com . Specifically the gsl. This will bridge the gap between custom routines, and packaged libraries, by teaching yourself how to generate the libraries from a core requirement definition. It's a lot easier for old programmers to 'get' the gsl than it is for the current crop of IDE developers. Once you get your head around how that works, you will better understand the 'modern' approach, and especially it's limitations and drawbacks when it comes to performance and re-use. Complexity is a manifestation of poor code design, and somehow complexity has become cool.
The old way of doing things is still the best... But it doesn't promise cheaper labor like the new way does, framework reuse by abstraction... I don't really get it either... As an Electronics Engineer, I learned to write code in HEX and assembly on microcontrollers like the Z80 and 68HC11, just as you describe. I believe this is still the best way for mission critical applications. Also I find it nearly impossible to understand what the code is actually doing in the hardware with higher level languages... I'm a bit biased being a hardware guy at heart, I'm not happy unless I fully understand the state of the machine at all times...
Anyway, given the fact that code written in years past, seems, to be of much higher quality, I'd say the guidance to find the cheapest and fastest way to abstract and reuse code, has failed, so your not alone my friend.
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 have been writing software since I was a kid using a ZX81. I have been through many phases in my development from assembly, procedural and then OO. At times you get in a rut and locked in your ways. I recommend some of the following to help you break out of your rut
1) Change jobs so you are exposed to different code and ways of working
2) Learn a new language from a different paradigm. Functional or some other area that is new to you
3) Learn unit testing with mocking etc
4) Write a roguelike on your own time and use it to explore new techniques and ways of thinking
For me it has been the journey into functional languages and agile techniques that has given the spark back again :)
Hi
I am 50 years old and learnt to program in COBOL in 1982. I nevere really 'got' Object Oriented coding, but I'm just coming to the end of the Amplified MOOC of Java Programming, and it now makes perfect sense. In my day job I write in Perl, but now I would rather code in Java, as it makes more sense.
https://course-mooc.amplify.com/course
Tim
I'm very old, IBM 360 anyone! It's much better if the subject matter is interesting. I've worked on all sorts of problems from accounting (ugh) to robotics (Yea) in many countries in the world. Currently I'm working on a way to use computers to help seniors and their carers live better lives. The carers are busy and there are more seniors than ever before. It's called Stay-in-Touch.ca and runs on an Android tablet or a dongle. I have a specific need (apart from meeting a super salesman) to port some functionality to send pictures to grandma from an iPhone, from facebook, twitter and so on. We can do it from Android, of course. Work on your own and sell the apps. I provide the API. There is an infinity of projects in this vein. (Apparently this old programmer can't figure out new lines in slashdot!)
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.
no, I don't have a sig
" 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 - perfect for a degree dissertation, useless for the real world - and a royal PITA for anyone to use properly which usually ends up with everyone subclassing the framework classes and rewriting half of the functionality themselves anyway.
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.
no, I don't have a sig
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.
Do not look at laser with remaining good eye.
It's possible that you are experiencing symptoms of burnout. I get this from time to time, I can't focus enough to learn new stuff. Try taking a few weeks off (at least evenings) and do something completely unrelated, like play video games or just concentrate on your sex/love life for a while. Eventually you'll be chomping at the bit to get back to the computer, and then you'll be fresh and better able to move your mindset onto unfamiliar ground.
But you better believe that learning new stuff is the bread and butter of a programmer's career; you don't just stop, ever. I mean I've been programming since 1982 but only last year I learned the theory of Kalman Filters and this year I'm diving into some Support Vector Machine stuff, as well as ramping up on the PS4. Mind you, this is pure CS stuff; learning frameworks-du-jour has never really interested me all that much. This also may be an issue for you - you may suspect in the back of your mind that learning these modern frameworks is a waste of time, and you may be right ...
But I finally got them to work.
That's because all these frameworks are a bag of shit.
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?
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 another.
However, being 18 years into programming would make you not old. At least not if you started as a kid. With my background it would make you 30. This is not old. That was the time where I reentered university.
You're not a *real* programmer until you decide to write your *own* framework. Your framework won't be useful to anyone else, but you'll think it's the best way to do things because it reflects the way you *want* to do them. You'll spend months or even years hacking away at your framework, ship it, and then some poor slob will try to download and use it.
That is the ugly truth about 99% of frameworks. They're hack jobs by one or a very few people that deal with a very specific problem or code style, and are useless for anything else.
Most frameworks don't "make sense" because they only make sense to the people who wrote them. Everyone else just goes through the motions, crosses their fingers, and hopes that it doesn't break because they haven't the foggiest idea what to do if something goes wrong.
I do not fail; I succeed at finding out what does not work.
No. Everyone should die at 30. In a carousel
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 college and if so did you study math and other technical subjects or did you study fussy things like English? If you've never learned how to learn then the place to start is to Google "studying techniques" and become an expert at that.
For example there are many technical concepts that are best learnt by drawing charts and diagrams on sheets of papers, crumbling them up and throwing them away and redrawing the charts and diagrams on new sheets of papers until you get something that corresponds to what the texbook is telling you. Also, just copying diagrams and other drawings straight out of textbooks can help. It's a cheap trick, but it works. There are lots of these "cheap tricks". Learn them.
tlambert hit the nail on the head. Go learn the fundamentals, either through coursework or through self-taught methods. Once you understand the fundamentals, you will find it much easier to grasp frameworks and "modern" technology.
Started with PERL, eh? I started with BASIC, PASCAL, and assembly on the 6502. PERL didn't exist then. I'm still going strong with modern languages though I do fall back on C for most things embedded that I work on. I work with modern frameworks, OO languages, and old fail procedural stuff. If I can do it so can you, you young whipper snapper.
Now get off my lawn!
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.
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 programming on the web is that it's a steaming mess and constantly moving and evolving. I recommend that you specialize in one field - let's say Android Development and dive into the accompaning technologies. Learning OOP and OOAD does not happen when you use frameworks or toolkits, it happens when you learn to build your own.
Perhaps you should get some certification alongside your field you want to specialize in. And again, be warned: PHP + JS + CSS + MySQL + jQuery + Zend/Symfony/CakePHP/FrameworkXVZ + fiddling with x-browser compatability + a litte image and/or video editing here and there does not make you an expert.
Dive in and learn OOP with a mature non-messy technology and you'll eventually get there.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
I've been a C++ programmer for 10 years, going from 3D programming to embedded computing. This year I started doing C# WPF/WCF with dependency injection and MVPVM pattern, it's a whole new world.
Can an Old Programmer Learn New Tricks?
Talking about self-deprecating titles. The problem here is not age, but confidence, direction and determination.
Really? 99% of all frameworks are useless? Please excuse me while I roll my eyes. Aside from the obviously ridiculous made up statistic that you pulled from the nether, your comment generally isn't that helpful. I'm not entirely sure why you're marked up as 5, Insightful.
Seriously, it seems like this question comes up every few (2-6) months. Can we have the submitters just search the archives before posting? It's not like there's been some sea change in IT world that would preclude the same answers.
Over and over.
And over.
Can we just get back to stale tech news already?
There was a time it was the youngsters who'd better learn from seniors... Sign o' the times I guess.
Or find a better one. I recommend you try "How to Design Programs", an intro to Scheme, which, despite its syntax, is a very decently designed language. You can buy the book for money, or download it for free. (there's two versions. The newer one is more fun. The older one is more finished.) Racket is the implementation that's designed to work with it, and is available for Windows, Mac, and Linux. For free.
The book is about program design, not about piecing together fragments found on the web.
The Racket mailing list is a place where students can actually ask questions and often get the language designers and implementers to answer even trivial questions.
Try it. It won't take long, and you will learn.
To the extent you are already experienced, you will find the beginning a bit tedious. So skim through until you reach your level.
-- hendrik
Yes, if the old dog is alert and interested.
I've been learning new stuff for 40 years.
10 years ago, I learned to fly.
That's a much steeper learning curve that just learning a new framework.
(Including weather, aerodynamics, ATC, and especially human factors.)
Your brain is a really neat gadget, but the manual for it says use it or loose it.
Get off you butt and get with it.
(But be smart and use the tips for doing it the easy way from the rest of the folks on this site.)
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 Agile Processes, Project Management, Finance, a critical business area, requirements management, Continuous Integration/deployment tools, DevOps, etc. Don't try to recreate the same old skills in a new programming language -- it's a dead end.
Me? I started programming 40 years ago in high school and have over 30 years industry experience. I've tried to learn something new every 18 months and have managed to survive so far.
Good luck, the next 10 years of your career can either be the best decade or the hardest depending on how flexible you are.
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...
It's not really "kids these days" so much as you have a lot more people developing at different skill levels. There are plenty of young developers doing great things. There are plenty doing bad things, but that's because we have the tools where people with less skill can still be productive in some way.
When I was growing up, only a handful of people I knew had computers. Now they're everywhere. Getting started in development is easier than ever. There are on-line resources of various qualities, and I had magazines and books to learn off of, and they could be hard to attain as a child/teen.
So you can do more quicker now, and there's a lot less quality... but that doesn't mean the number of truly talented developers has gone down. The number of developers has skyrocketed, and the number of good ones is about the same or slightly more. :)
Truth is, if you ask a question like that, you've already given up. Me, I've been programming now for more than 25 years (started when I was 18). I took a slightly different path than most, as I started on little 8 bit microcontrollers, worked my way up to PCs, and now am doing website and networked app stuff.
Languages I have used (from the beginning to now) - Fortran 77 (in college), Motorola 6502 Assembly, C, Intel 8051 Assembly, C++, VB 6, Delphi 1-6, VB.NET, C#.
I will never to old to learn, in fact this is what keeps me doing this job. Taking and evaluating technologies and applying them to solve problems for my employers is quite satisfying.
Truthfully, I think what a lot of people miss is that all programming, frameworks, IDEs, etc. are tools to solve problems. Find new problems to solve and solve them using tools and frameworks.
If you aren't programming for a living, pick up an open source project that interests you, look through the bugs and feature requests and solve the problems.
Can say a 50 year old learn to code? I always see it referred to as a young person job, and only for young people to learn, I never see anything on an older person learning to code.
Is this unheard of? Does it happen? Has any one here learned to code at an older age, say above 40?
"If any question why we died, Tell them because our fathers lied."
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.
Taking guns away from the 99% gives the 1% 100% of the power.
I would like to take the opposite position from just about everybody on this forum. Frameworks are vital to modern programming. Not using frameworks is like reinventing the wheel for every program. If you had to drive a nail into a piece of wood would you first forge a hammer? Frameworks help you avoid writing mundane code that has been written a hundred times over, and focus on the new creative stuff.
I have noticed a lot of this anti-framework sentiment is fueled by performance concerns. First of all early optimization is the programmers greatest foe. The most important thing is to just get something down, a rough draft. Later you can come back and optimize. But remember in the real world there are deadlines and your boss doesn't care how little memory and cpu time your program uses if it doesn't do what he/she asked. Second, if you work at a company they are most definitely going to be using frameworks that you have to be familiar with. You can't just submit code to your team that uses your homebrew framework instead cause you say it's more efficient. They probably wont believe you.
I don't know what frameworks you guys are using, but many of them are powerful and highly optimized. I'd love to see someone here write a better physics engine than Box2d or a better Json library than Gson in under a year. And why would you? Again the whole point is to focus your time on writing the specific code that will solve the problem at hand, thats the fun part.
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 bit later. It had been the 3rd failed attempt. The problem is that while these people had a lot of developers, they did not have any good ones or the good ones could not perform because all the "helpful" tools and processes stood in their way. Now, if those people had 20 really good developers instead of several hundred mediocre to bad ones, they would never have gotten into that fix. Coding is hard. In order to have a positive productivity, you need to be pretty good at it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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 automate a lot of the repetitive processes and code that people continuously reinvent.
For web projects, this is great but it's not without it's problems. Web projects GENERALLY follow the same type of behavioral requirements, so in 95% of cases a framework can handle it well. The down side is when people get MARRIED to their frameworks and start ignoring good architecture in favor of the best way to do things within the framework. The creator of rails itself, DHH, is the single worst offender in this regard because he advocates doing almost nothing in the database itself which is like building a person with only one leg.
Frameworks aren't for every problem and a lot of successful web projects get mired down into a huge main app and then spend a couple of years having to refactor parts of it out into services. The key word there is successful though, because they can afford to take the time to refactor because they got to market and made money. Rails gets you to market quickly with all of the capabilities that you need to get the job done. Successful app after successful app have been launched with Rails as it's backbone and that's EXACTLY what it's supposed to do for you.
However, if you're dealing with an existing application or an enterprise scenario where you will be integrating with a legacy database or throwing an existing user base at a rebuilt system...it is not the right place for a framework. In those scenarios you're effectively already at the "successful now refactor" stage.
Everything has it's place.
"Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
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
We don't have a state-run media we have a media-run state.
It helps that most of the "new" tech either builds on or borrows from the imperative programming foundations laid by C. I've transitioned from Perl to stuff like Java and Javascript/HTML5 without a lot of pain. Over the years, I've occasionally revisited stuff like Lisp and Scheme, but that seems a bridge too far. Yes, John McCarthy, I'm doing it wrong, but I'm too old now to give a shit...
I'm in my mid 30s, and it's exactly like toys and video games, you just can't enjoy it as much as you did when you were young.
If you can't do it, you can't do it. Don't assume it's because of your age.
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 at my webhost, I don't have mongo so I then needed to learn an ORM system for node to mysql (using bookshelf js right now). Similarly if you build something in mongo, you can look to learning AWS or Google Cloud Development and get the app out there and there's another skill on the resume checklist.
In fact, doing the database port actually helped me develop and refine unit testing so my data-access layers had the same front API - knowing you're replacing a single piece actually encourages writing the pieces to be more modular and independent.
All javascript, plenty of html5 modern architecture skills learned or refined, and this from someone who spent most of the mid-late 2000s as a J2EE w/ Oracle guru.
So really, the short answer is: just do it.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
I've been programming for 30+ years and not a year has gone by that I haven't learned some new skill or trick. Sometimes I've been guided into different practices grudgingly, but even if there is something you dislike, learning is almost always worthwhile.
The "nuderstanding" typo is in fact a great term to describe thorough understanding, or understanding without the hindrance of semantically empty layers of nonsense.
Stop whining about being to old to learn. Just STFU and start doing.
The only difference between now and then is you have to be willing to sweat out learning the new stuff the same way you did 18 years ago.
Right now you're just old, well paid, and too lazy, yeah that's right lazy, do actually do something new; because doing something new is hard.
asking stupid questions like that.
As an old programmer who has spent his life constantly learning, there aren't new tricks, just more learning.
The Kruger Dunning explains most post on
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 how to code what I needed, rather than learning how to use what other people coded that I might be able to make use of.
But I've *also* wondered many times whether I just wasn't getting it, and if maybe I was spending far too many hours recreating wheels when if I'd spent another five minutes understanding someone else's wheel + cart + horse combination I could be saving myself tons of trouble, and possibly get the benefit of things I wouldn't even think to do on my own.
I'm very curious about this discussion, and I think I'm getting some useful information out of it. Whether or not it helps the OP, this is definitely a case where he's asking what I was thinking, and I doubt I'm the only one.
The Quirkz Handbook of Self-Improvement for People Who Are Already Pretty Okay
What a lot of business / hiring people don't realize is that not only can you have a 10x developer, you can have a -10x developer. You can actually hire a developer that has negative productivity by botching up existing code that must now be fixed by someone else. In the worst case, it can fail the project, or set it back years.
And this is what the company's infrastructure resides on. It's a wonder companies don't pay more. Too many degenerate gamblers out there in hiring positions.
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 sell them. I can, and have, done OOP in assembler, but there's no market for that.
The Internet makes it easier to get the information, but it does not make it any easier to cram that information into your brain. It still takes time and energy and effort to remember whether the IF statement parentheses are prohibited or optional or mandatory.
Personally my all time favorite language was Pascal, because it reads close to English. I used words, not funny braces and brackets and abbreviations. Ruby insists that I write "def": instead of "define"; I don't know why, but that's what I must write this year.
- www.andycanfield.com
I've been coding for 20+ years and get excited when I see new technologies/languages/frameworks to learn. Bring it on--and don't stop. I just wish there were more flexible developers out there.
No, it is never too late for someone who is willing to learn ...
My career spans some 30 years, and I did reinvent my skills every now and then.
I changed careers to computers in the mid 1980s, from pharmacy, of all things. Started with playing around with a Sinclair ZX Spectrum. A year later, I got a job doing programming in COBOL on mainframes, along with PCs. A couple of years after, it was finally UNIX, where I realized this is the system for me. Some years after, it was Linux. Several years after that, it was LAMP (Linux, Apache, MySQL, and PHP).
Now I do consulting on open source exclusively, as a small business owner.
Just have to learn new things every now and then, and do actual projects with them.
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
They can give you some direction, and, in some cases, help you navigate the framework hellscape. Pick a topic, and see if you can find an online class for it, either with a University or a MOOC. You may also notice that with your experience, you can run circles around some of the other students. Incidentally, having worked with a few self-taught duct tape coders - who tried to build the whole system out of duct tape, not that you are one, I'm just saying - a generic, high-level "Software Development" course where they teach design patterns, software architectures and practical development, may be in order.
I think of it as a 4.5 level language experiment.
I think the biggest problem we encounter when moving to a new platform is looking at it and seeing everything that's wrong with it. Moving from C# Windows apps to HTML/JavaScirpt/CSS has been very frustrating because nothing works the way I think it should. It's a terrible platform, but that's just the way that things are done now, so you better get used to it and just accept it.
But to make a modern web app, you're going to need some additional frameworks on top of the HTML, JavaScript and CSS. So you've got jQuery and BootStrap and whatever else on top of whatever is assembling pages on the server side of things, MVC, or whatever else. So you've just got to dive in head first and fully commit yourself to doing things the new way or you're going to get left behind. I've seen old programmers who made the change, and I've seen guys cling to what they're comfortable with and slowly become obsolete. And that's why I'm using the Slashdot beta.
Look, I get that we're all getting older and that there's traditionally been something of an age bias in IT but can we please stop having a "hey am I too old do be doing programming?" story every fucking week?
No you're not too old. Yes you might have a harder time finding work at your age (whatever age it is) but there's so many other factors (choice of technologies, state of local technology scene where you're at, whether or not you have people/hygiene skills) that no one can really say what it is. Yes you have commitments and debt and maybe a wife and kids and the fresh kids out of college just have those to look forward to. But come the fuck on.
There's basically two things people worry about - is your age causing you to lose job opportunities and is your age making your mind slower/worse/etc. If you're asking for an absolute answer to either then it's no. We've established this over and over and over. There are just as many jobs out there looking for fresh faced kids as there are looking for seasoned professionals. The reason that the game industry, with its cutting edge technology, is mostly young people is not because young people's minds are more amenable to cutting edge technologies, but because the game industry overworks, under pays, and generally churns through most of its non-Carmack-level talent and causes people to switch to mundane business rules programming for 2x the salary and 100x the stability.
Now can we please move on to something important like whether or not Bitcoins cause Libertarians to commit suicide?
Schnapple
We have about dozen in my city on Java, html5, mobile apps, etc. Sometimes its people demonstrating work projects with the approval of their management. other times its personal projects, often open source. We have several professional teachers inthe area who write the OReilley books and give company in house courses. I dont use much of what I hear about myself due to lack of time. But I try to keep informed about trends in technology.
A side effect is due to extreme recruiter demand we have free pizza, beer, books, etc. at these user meetings. There are often ten times as many open jobs and peole looking during the job session.
My first user group was the Homebrew Computer Club meeting at the Stanford Linear Accelerator in the mid 1970s. I learned a lot there and still learning things 40 years later. I've been to other groups on Amiga, UNIX, Mac, NeXT, SIGGRAPH, etc over the decades.
You're problem isn't that you're too old to learn, but rather that (per your own description) you were never that good to begin with. Any fool can do simple programming.
Did you forget how to read and learn?
Every good engineer I know, software or otherwise, can't resist learning how the next new shiny works
There are too many next new shiny things for any one person to figure out how they all work. A good engineer has to have either instinct or guidance so they don't invest time in doomed flash-in-the-pan technologies so they can use the time more productively. Especially since a good engineer is already spending most of their time actually working their current assignments on top of learning new things.
Someone had to do it.
I'm probably quite young, but I learned programming in C and assembler as my starting languages.
That said, I have worked on many frameworks including things like ASP.NET and Java Enterprise stuff. My first one was probably MFC.
Here's the key thing that got me for a long time.
Learning a new framework is like learning a new programming language from scratch. You have to put in the same effort into it. At least I need to as I need to understand what the framework is doing before I feel comfortable using it.
I reflect at all all the time I spent learning C/C++ and it was filled with books and trial and error and nuances.
Yet, when first presented with Frameworks, that is generally not how it is approached in companies. It took me years to get pretty good at C and C++ including STL... Frameworks are thrown around so quickly, it is almost like they just expect it to be easy to use and you just call a few methods and away you go.
So that is the first thing, you need to put in the time to learn it properly. There is also a certain amount of trust that occurs. I've found myself learning to trust frameworks more. I can't really explain it, but I trusted MFC when I used it. For all the weirdness it used and preprocessor crap, Microsoft provided a pretty good IDE that made it easy enough to use and get started. Boy was there a lot of mysterious boiler plate code.
And yes, MFC is technically C++ I guess, but you really needed to learn MFC to actually do and understand anything.
It's the same with say Java. You might learn Java, but you need to learn Spring or Hibernate or Maven or whatever.
A lot of modern frameworks don't really come with that nice custom tailored IDE. Some do integrate nicely with say Eclipse or whatever, but it still generally leaves you in a state of uncertainty.
That is one area I've always appreciate MS in. For their frameworks, they tend to provide the custom tailored tools to actually let you use it.
But lesson. The lesson is, it's going to take you a while to learn the framework. It's going to take you even longer if you plan on being an expert and knowing how it works underneath.
or do you just think you are? It's easy to minimize the amount of work it took to get to where you are. When you first learned to program, you likely took it day-by-day, just being involved with the process itself and enjoying the it without worrying about how fast you were learning. You may actually be learning faster now, it paradoxically just feels slower because you're comparing it to all the things you already know.
"The wisdom of the Patriarchs was that they *knew* they were fools." --Master Foo
There is a problem in the industry.
Good coders are expensive. Medicore ones are a dime a dozen. Management thinks it is smarter to hire 10 medicore programmers for less money than 1-2 good ones.
Thus you get failed projects and exactly what they paid for.
Do not look at laser with remaining good eye.
This comes from the race to the bottom where companies prefer programmers who are cheap to those who are good. All those H1B's coming over here because there are no good software engineers? What they really mean is there are no good software engineers who will work for peanuts. Now those good programmers just work as high dollar contractors who come and clean up the mess after all of the cheap programmers make a hash of things.
...you've been writing shitty code for 18 years and now you still don't realize it's shitty code. Before you can move forward you have to understand why what you've been doing all this time is bad.
> I never learned to ... write modular, DRY code
Don't worry about frameworks right now. This is your problem right here.
The book that helped me best in learning to write modular code was "Analysis Patterns", by Martin Fowler. (http://martinfowler.com/books/ap.html) It's ancient now (from 1996), and you can find used copies on Amazon for under 10 bucks. I came across it back around when it came out (yikes, that's 18 years ago!) while I was buying up every book I could find on OO, and this is the one that really made plain to me how to approach object design.
With book in hand, I might recommend also trying to write a text-oriented version of a card game. Crazy 8's or go fish where the number of players can vary and the "AI" is simple.
And if you really want to focus on modularity, I'd say write this game from scratch in Java. It's a language that definitely prods you towards modularity. Everything is in a class. One class per file. With that constraint, most developers learn to think carefully about how to organize code, and the lessons learned can be used in any language.
There are 0x40000000 types of people: those who understand 32-bit IEEE 754 floating point, and those who don't.
I just read thru a lot of these noobs ranting about old programmers learning new tricks to get a job.
First of all it appears you have no formal training just the abiltiy to hack.
In my estimation in contemporary software dev trends this is an advantage (especially in the eyes of HR or the employers).
Where I WAS working the 25 year old English degree M$ admin guy completed the first installment of the lynda.com beginners tutorial for Java and the next day was promoted to Java dev.
It works! Right now the kid is being spoon-fed brain-dead easy issues so the management believes he really can code (the project narcisist does an OTS pointing to which buttons to push).
If I asked this kid questions about machine arithmetic vs human arithmetic (3 questions or so...) he would not get past the first machine question: Can computers divide? It would just be eyes-in-the-headlights!
So, yes, go ahead and hit the online or brick-and-mortar for training.
I recommend Java for one because of all the JVM based frameworks out there right now (see devrates.com).
And, because the employers want a rediculous stack of techno including Java.
I wrote a popular book for learning C#, and I routinely get emails from people who started programming in the 80s and 90s who felt their skills were going stale and were able to pick up C# without any difficulty.
I do not believe there is an expiration date on our ability to learn new programming skills. This applies for any language, whether or not you use a book... as long as you remember that most (only?) effective way to learn a new language is doing lots of projects (that's something I focus on for my readers).
Building Better Software
I've used Qt and while bloated, it was useful. I now use JUCE, it is a C++ framework that works on most platforms, android, iOS, OSx, windows, Linux. It is written by ONE guy, so it fits in one brain and is consistent and compact, pretty complete. While focused on being a support framework for music software such as Traction and music synth plug-ins, it is perfectly reasonable for a wide variety of apps. JUCE does what I need, it abstracts over most OS's, providing a lasting tool I can stick with for the long term that covers the devices I need covered with the same code mostly...
I think i'm suppose to say "Beta sucks" too? http://en.wikipedia.org/wiki/B...
I 100% agree with you. Many people assume older programmers are against "libraries" & "frameworks". We are not. We understand the rapid prototyping they bring. We are leery of the compile-time and run-time overhead costs.
The one of the key differences between a novice and experience programmer:
They know when TO use and when NOT to use a framework.
The novices just want to shove more code at a problem until it "works" without really understanding the data flow. *facepalm*
If you have mastered(well no one really has 100% even 30 year old veterans) c/c++, know plenty of algorithms, then you should have no problem learning new languages like c#, perl, python, etc...
It's not a problem. That is my bread and butter.
I fix all the stuff that a team of developers totally botched.
Nothing really has changed, and the concept is still the same.
INPUT -> PROCESS -> OUTPUT
The way it is done doesn't matter.
I started programming professionally in 1969 with Fortran, followed by COBOL in 1970, Algol and IBM 360 Assembler in 1972. Since then I've coded projects in Basic, Simula, ESPOL, NDL, Databus, PL/1, PL/S, Rexx, Forth, Pascal, and half a dozen different assembler languages such as 6502, 6800, 68000, x86, Datapoint, PDP-11 and PowerPC. My current languages of choice are C, C++, C#, and JavaScript, although I can do Transact/SQL, Visual Basic, and Python if needed.
Here's my point. A computer language is just a way of expressing simple commands. The concepts are pretty much the same across most procedural languages. A DO loop is a DO loop, regardless of what you call it and the exact syntax. A much bigger issue is learning the idioms and the libraries associated with each implementation of a language. Just like human languages, the more of them you know, the easier it is to pick up the next one.
I've never had any formal computer classes. Back when I started there was no such thing as a computer science degree - most university classes in computing were done the math department. But you still have to learn. Buy books, read them, do small projects to familiarize yourself with the languages. Make yourself learn. It's your career, manage it. Make certain you have the skills that are needed, and if you think you don't have the skills you need then be proactive in getting them. Use the Tiobe index to see what's trending up.
I'm at my sixth company at present. I have never been unemployed. I don't code as much as I used to because I'm in an architectural role now, but I still can code and I enjoy it immensely. I'm still the go-to guy in my areas of expertise. I made the mistake of going the managerial route at one point and discovered I hated it. Computers are easier to handle than people - they don't lie, they do what you tell them, and they don't have hidden agendas, and they don't backstab.
18 years is less than half of your working life. Coders will be needed for long time. Application coders will needed for years to come. People will be needed to code operating systems, drivers, environmental software, IDEs, compilers, etc. for many years. Don't give up, and don't believe all you read about ageism. I interviewed for my current gig with a full head of grey hair.
For a good programmer, asking whether you can use a new language or framework is like asking someone who builds watches if he feels he could learn how to tell time. Of course you can. Anybody who knows the foundations on which the tool is built is far preferable to someone who merely knows how to use the tool.
Now, you'll never get passed HR, who is only looking for people who used that tool exclusively and recently and doesn't care whether you actually WROTE the tool.
If you are not allowed to question your government then the government has answered your question.
Before internet:
Usually one computer, one client, and zero server(because it is on one computer).
One O/S platform.
Had known libraries.
Had known software
One hardware platform.
One CPU.
Had known amounts of memory.
THIS WAS THE STANDARD.
After the internet:
Multiple computers, multiple clients, and multiple servers.
Multiple and sometimes unknown O/S platforms.
Multiple and unknown libraries.
Multiple and unknown software.
Multiple and unknown hardware platform.
Multiple CPU's.
Unknown amounts of memory.
THIS IS THE STANDARD NOW.
Before the internet you made the standard.
After the internet you have to apply the standard.
18 years of writing shitty code(which is exactly what you described) is too big of a habit to break.
Good for you, but it still makes me weep that our industry has been turned into a sweatshop of medicore messes.
Do not look at laser with remaining good eye.
https://www.youtube.com/watch?v=EtJy69cEOtQ
Lot's of suggestions here for singleton work, but maybe you should get into something new by learning in a team. This could be "extreme programming" if you're already working in a paid corporate job, or by taking a real course someplace where you can interact with similar mindsets. (The course itself may be less useful than the peer interaction, so still worth the cost.) And sometimes software conferences have workshops or "interaction sessions". Community colleges are another possibility for special topics.
I find myself disagreeing with most of the comments below, although the ones I read all have merit. As someone who's been programming since 1973, (professionally since 1975), I find learning new frameworks and methodologies not only interesting but important. When mentoring younger programmers who lack a CS background, I try and recommend the classics: Design Patterns -- see what you do and don't do based on what you read here; Prefactoring -- learning some good habits fundamental to all development; Knuth -- it's like a granite foundation in a box; Once you've gone through these, I hope it will have opened your eyes to evaluating new frameworks, languages, and methodologies. This should help you hone your discretion as you evaluate (and reject) various options you encounter. Also, think about extending your skill sets through building APIs, developing data management skills, client/server (not just REST), etc. I've had to learn 4 or 5 new systems and APIs in the last 6 months, with 6 more to come, as well as providing API and server infrastructure support. Good luck, if I can do it, you can.
Fire them.
10CHAR
When was it not? I'm only 50, I've seen/worked a few places that were exceptions for a while, but generally when has the industry not been a 'sweatshop of medicore messes'?
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Leave me to my delusions that my professors gave me!
I honestly warn a lot of youngsters away from CS, "It is the new factory work". You leave college with all that debt and utopian dilusions that it is a noble profession and discover that it will chew you up and spit you out if you are not a part of a very specialized and needed segment that cant just replace you with another fresh grad.
This is why I LOVE embedded work, CS grads cant wrap their head around only having 6-8K total for program and storage. so us old farts cant be intimidated to spend 22 hour days 8 days a week at the office to meet retarded deadlines.
Do not look at laser with remaining good eye.
Dude, you forgot to click 'post anon'.
Now everybody knows you've written Cobol!
My college prof noted 30 years ago. 'Everybody who knows Cobol, is embarrassed to admit it'.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
If you really want to change the way you code then read the following article.
http://binstock.blogspot.com/2...
Pick an old project that you think might be a good candidate for a major re-factoring and follow EVERY SINGLE ONE of the rules and rewrite it using them.
I think that some of the rules are a bit overkill but as an exercise and to force yourself to learn some new tricks follow them all and don't stop following them until they are second nature.
The secret is probably that [like many anoraky people] I enjoy the new things, I'm a neophile. Also, I'm not afraid to be mediocre at some things, I enjoy, a luxury I have because I don't use everything I know 'professionally' nowadays. But, if you don't enjoy technical stuff and do it 'just for money', it's harder to learn.
A couple of open source projects, however small, probably help as well, to 'fix' knowledge. 18 years pfui, get off my lawn...but seriously, yes, you can.
On y va, qui mal y pense!
I find your comments distasteful as I find all the other comments that disparage all frameworks. I will definitely say "Flavor of the month" frameworks are a dime a dozen and are nearly useless, however there are MANY very well accepted frameworks that increase the speed of development (and in turn the modularity and maintainability of the code). Have you tried to write a dynamic website without jQuery (or an equivalent)? If you say "I don't need it", then you're just ignorant or inefficient. Have you tried to build a large scale java application without Maven (or an equivalent)? How about create a RESTful web service without any framework (there are many options though for Java I prefer JAX-RS and reference implementation)? Have you ever had to maintain someone else's application? The more industry accepted frameworks they used, the easier it is to understand what they were trying to achieve and how they did it. If you have to read tens of thousands of lines of code to process an HTTP request, you'll never be able to manage it. There is a huge difference between a physics engine in a game and an enterprise transaction engine or a business process engine used to manage 100,000s of financial transactions. I'm really sick and tired of all the embedded systems or games developers or with old C guys who think it's the solution to everything trying to make these vast generalizations about what is viable in the world of development. Not all development is about the speed or efficiency of the code. Much of it is about maintainability and modularity and without frameworks that can be nearly impossible.
I've been working for over a decade on the server side of things. Linux kernel customization, device drivers, high-availability, fault-tolerance, etc. Mostly in C, more than a little bit of assembly, some shell scripting.
There's a lot of that stuff still being done, and it's a pretty good living since there aren't all that many people who are comfortable in that environment.
Learn the basics of a programming language (say Ruby or Python), clone a free software project and contribute to the community. When you hit an issue, people will be willing to help and your learning process will produce usefull code, not just code that will get thrown away. Coding is social these days.
The problem with this kind of thinking is that there is no real continuity any more. There used to be a time when you could take code from a couple years back and copy-paste it into your current project. Nowadays we switch technology so fast that you can hardly understand the code from 2 years back again because you got out of touch with the frameworks it worked on.
On top of that. I've seen projects being restarted over and over again trying to build the same solution using 'what's new this year' technology; and pretty much each time it fails on some new 'unforeseen' thing... It kind of works; but it isn't great. But who cares? They're convinced that when they rewrite it next year using that new framework/paradigm/whatever it will surely be perfect.
Mind you, I don't mind looking at new stuff; but in my experience it's often times the same thing packaged differently over and over again. So where is the real benefit? Using "the old methods" I know exactly where the pitfalls are and how to avoid them; using the new stuff sometimes looks quite promising and might take a lot of the grunt-work out of my hands so I can focus on the 'real fun things'; but when it obscurely fails it can be very frustrating and consume a lot more time than I assumed I had won. It's a very grey area sometimes.
If there is one thing to be learned on slashdot, it has to be sarcasm.
I mentioned Aho, Hopcroft & Ullman before. Another series of books/lectures to consume to change your brain about what you're doing when you're programming is Donald Knuth's series The Art of Computer Programming. You can start from here: http://cs.stanford.edu/~uno/ta... Go find some of his stuff on YouTube. You will undoubtedly cook your brain a bit, so give yourself plenty of rest between episodes of exposure.
JUCE has shitty licensing.
Mod this shitbag down.
am not on /. much anymore, because am in the midst of doing exactly this, only for pity sake - JUST SAY NO TO FRAMES.
Indeed. Many developers are more expensive than not having them would be. Developing code is not like sweeping floors where anybody can have some positive level of productivity.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
The issue is that mediocre developers are already around zero in productivity and may be negative. So 10 mediocre ones may be worse than one mediocre one. They certainly do not add up to anything good.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I am a CS grad, and I have embedded experience. It is not even that hard, typically you do not have to go down to assembler, but can to C with some limitations. The thing is that most CS grads are really bad these days and do not know the basics and do not care about them either.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
You are a rare one that actually cares about the craft.
Do not look at laser with remaining good eye.
Learning a framework (or any language or library) from scratch by reading documentation, or writing new applications by yourself, is doing it the hard way.
If you want to use a library of code, you have to understand the mindset/philosophy of the programmer behind it. If you don't, you're just going to be fighting it by re-writing or doing things in the most inefficient way possible.
I would recommend finding a well-regarded application that uses that framework and discover how it structures itself around it. See how it handles things like data, events and UI. Maybe it goes well with other libraries? If you still can't make heads or tails of what's going on, then maybe the example you picked is too big :-)
Try not to immediately discount a framework if you don't understand it at first. If it's popular, it must be doing something right.
If you view your "skill" as learning new trends and constantly migrating, then you don't actually need to learn any new skills! Just keep applying the skill you already have.
(Programming since the 1960s and currently fielding leading-edge personalization applications)
The difference between then and now is a few things:
When I was just starting out, the relative cost of #2 was the same for a number of topics.
Once you are an expert in one, working through feeling dumb all the time I imagine is much more frustrating.
What worked for me and the best advice I could possibly give is to identify the smartest programming writers and speakers that are doing what you want to do, read their books, watch their talks, and embody their viewpoints of code.
In the course of a few years of this you will gain a foundation whose benefits become more apparent over time.
Dealing with the perceived discomfort from #2, I'm not sure as I'm super-crabby and still young, but the most up-to-date and fresh experienced developers I've had the pleasure to work with embody a childlike curiosity.
#2 can be mitigated
#1 is a little more biological
I think #2 and related perceived tradeoffs dominate the learning equilibrium.
Find someone who already knows the language you can work with, who can tutor you, sort of like a copilot who will sit beside you and help you, someone who really knows the language well. There are many categories in languages: procedural, functional, object oriented, SQL, contract, assembler ... all these languages have elements of each other in them, and they all have their strengths and weaknesses. For example, C is extremely fast. And, there are many languages. I think the one of the fastest way to learn how to program in a language is to do it and have somebody to show you how. How to use libraries is also very important, because much of programming has already been done, and you can save yourself a lot of work. If you need to rewrite a library, you can go back and concentrate on that, but if you know how to use what is already there, that saves you a lot of time, at least initially. Programming by its nature is very lonely profession but if you can find a group of people to work within sure ideas and help each other out, then you'll be far ahead of the game. Proverbs 9:9 says: Instruct the wise and they will be wiser still; teach the righteous and they will add to their learning.
is just the old stuff with a flashy new name and a little frosting added. :) Stay off my porch!
I have a doubt that mobile displays and keyboards are anything more than a transition, although responsive design for narrow screens is valuable for accessabale designs for larger screens. The reason I think that mobile is overplayed is that the screen size limitation is probably going to go away and so desktop designs will gain importance on small form-factor devices when they are used on a hub with standard displays or when mobile devices make use of projection devices to create the keyboard and full-sized display with images painted on a table top or wall. So either a tablet or a projected full desktop will become the norm as the mobile devices become as powerful as current low-end desktop machines. This is already happening, projected keyboards already exist and projectors drawing full desktops on any desired surface can't be far off. The only value of the small cell phone keyboard is for use of the telephone. Maybe future mobile devices that aren't tablets will not even ship with a keyboard or OLED display. They will have projected displays and function exactly like today's desktops or laptops. If your mobile device is a powerful as your desktop, you may find it easier to not put up with that narrow display and keyboard at all.
The more things change the more they stay the same. The failure rate of software projects has always been about that same and the number of good developers has been low. More than 70% of projects eventually get abandoned and maybe 10% of developers are competent. I have written code and managed systems and I do not consider myself to be among the 10% of competent, I am a relative hack having written FORTRAN in my early days, C later on and dabbled in OOD in retirement. Lately I have been interested in Python but dislike Java and see that the impediments to writing good clean code are about the same now as they were 50 years ago. Then it was abuse of GOTO and duplicating code that should have been put in functions, now it is bad design hidden away in class libraries. I balked at being asked to support java applications after legacy compiler experience because of that. I felt that strong typing and poor library design made the learning curve for java applications too steep and that the language was and is too wordy. I am someone with poor vision and I regarded the environment one gets with java to be far too busy and hard to read.
When you look at the number of frameworks coming out, particularly the number written in javascript, presumably writem to avoid the awful mistakes of that language's design, beginning with the ease to create global variables, one is tempted to avoid both strongly typed languages and those with lots of class libraries, and functional languages do really need sideeffects, even though they can be abused. What is needed is abstraction and delayed typing or weak typing so that all of the complexity that relates to typing can be deferred to runtime. That is what I like about Python. But even python doesn't get around the human failing of most developers to not be able to write clean objects and to write decent documentation. Writing good documentation is almost more of a premium that writing clean code, because if the only thing you have to go on is crappy open source, and OOD tends to produce layers of boilerplate that makes it hard to get to the working code, then not having a good statement of what the software does makes it not worth the effort to use it. Many open source projects do not succeed because their authors either cannot write documentation or lose interest when it comes to that task. If I am a programming hack, I might do better as a technical writer and regard the effort to write good documentation of at least as important than coding itself.
By the way, if you go and look at the Java in a Nutshell book, any edition, you get more than 500 pages. That is is tough nut to crack. The reason is that the complexity of the libraries as authored by Sun, especially, is too much. There have been a couple of successful alternatives, acm.jar, comes to mind, but the sheer size of what is in java leads me to believe that it has been deliberately obfascated as a form of security as it was adopted by security conscious firms with the intent that the sheer size of it, the bolus of class libraries, would make for a steep learning curve and a deterent for many and job security for the rest. That is abuse of technology in my opinion and no better than a FORTRAN programmer from the 1970's hiding what his code does in spaghetti code. The Nutshell book was more than 500 pages, it is was good documentation, the problem is that the complexity came out of abuse of OOD, not in spite of it.
You did it before. You can do it again.. and again... and again...
Just enjoy what you do. It means, if you decide to learn something new, you have to pick something that you will enjoy. The magic is there... just look for the right technology.
Firstly - I've worked with (indeed I used to be) a programmer that learned through doing. As such, I've categorised such people into two groups: - those that give a shit about getting better, and those that don't. You appear to be in the first category, which is by far the better and much less dangerous of the two. About ten years ago now, I decided that I'd had enough of meetings in which I'd have to muddle through and make answers up as I went along, so I went back to University and got a Masters in Computing; my undergrad degree was in English - then I got sucked into programming via HTML, then JavaScript, then "classic" ASP etc - as I say - it all kind of snowballed as it went along. The Computing Masters was fun to do and resulted in the following major improvements: firstly, nowadays when I'm in a meeting and I don't know what people are talking about, I'm confident enough to admit it. Secondly, I have the research skills to go and find out more about the thing I don't know about. I'm pretty sure I could have gained these skills without doing a Masters, too - but (as several others have mentioned here) it's the confidence that makes the difference, however you get it. Since then, I've been a team lead at a Finance Company and (just about) managed to hold that down. I also came to the conclusion that the brash, "confident" (i.e. egotistical) developers were the dangerous ones, who always seemed to be followed around by a cloud of disaster - their "confidence" was usually utter BS. Also, fundamentally, whether you know "Framework X" or "Foundation Y" should always be secondary to whether you know how to code well in a team - to which end, I recommend that you read both Clean Code and The Clean Coder by "Uncle" Bob Martin. And learn how to write good tests. As I say - the fact that you're being conscientious about this is a good indicator that you'll be OK. Best of luck.
Got you beat by a long shot. I have over 35-years experience starting with BASIC as an actual business programming language. Also started online with PERL, CGI scripting languages,et al. Javascript and the whole OOP concept threw me for a loop initially. I *could* do some debugging, but not basic coding without frustratingly near-endless errors and bombs. I still don't call it a language I can program in. However, by cussedly returning to the subject and trying new approaches and projects, I finally had the "Ah-hah!" moment and the concept clicked... just in time for the next concept in coding. :-) Oddly enough, I've found doing a bunch of personal Wordpress development extremely useful for keeping up with the new approaches and concepts in code development, both because of what's integrated in the updates and what's not but discussed integrating or integrated by individuals in their modules. You may find something else easier for you to grok. The key is to accept that you're going to have to drop your old habits and mindsets. It helped enormously when I was able to stop looking at the programming as an entirety and instead considered it in modules or "Lego blocks" of functions that interacted. So instead of thinking in terms of having to do it all myself — write the code to collect the data, store the data, retrieve the data, parse the data, manipulate the data, and respond based upon the data — I was able to start saying "Hmmm, pretty much everyone's going to need to do X, so there's probably a function already included for that, so I just need to read the codex and find what it is and see how I can manipulate the results."
FYI, I've got a friend a little older than me who spent the last 15 years of her tech work life helping small clients maintain old sites. In retirement she's getting around to the concept of responsive web design — but I still can't get her to grasp CMS and database-driven sites. We all have our blind spots.
Best of luck and keep working. The best part of tech is that there's always something new to learn so we don't end up one of the "walking dead" retirees just waiting to die and grumbling about the "good ol' days."
> JUCE has shitty licensing.
Huh? JUCE is dual licensed under GPL and proprietary commercial terms.
If you want to share your code, use the GPL'd version. If not, buy a license. What's your beef, "it's not BSD licensed" ? Get over it. You don't get to dictate to other people how you want to use their code.