Slashdot Mirror
How Can an Old-School Coder Regain His Chops?
DonLab writes "I was a proficient software engineer in the 1980s, writing hundreds of thousands of lines of ALGOL, FORTRAN, COBOL, and Pascal programs, as well as working in 370 and 8080 assembly language & pre-relational DBMS systems. My hands-on programming career ended when I became a freelance analyst and designer, ultimately retiring young in the early '90s. Now I'd like to reenter the field, but I'm finding that I know nothing about today's post-C languages, programming tools, and computing environments. I wouldn't know where to start learning C++, PHP, Java, HTML5, or PERL, much less how to choose one over the other for a particular application. Can I be the only pre-GUI software designer or hobbyist searching for a way to update his skills for Windows, iOS, or Android?"
Submitter - not trolling, but you should include C# in your list if you want to be relevant today.
Don't hate the players, hate the game.
If you want to develop for the iPhone/iOS, then learn Objective C. Just figure out what you want to do, keep your focus narrow for now, and work backward from the requirements.
Slashdot: Everything in Moderation, including Moderation itself.
Here's a few tips that I try and use when learning new languages:
1) This one may seem obvious, but just start using it. Write "Hello World!" programs, and then an address program, stupid stuff until you get used to syntax. Eventually you'll start to pick up on the strengths of the particular language and come up with ideas on how to write stuff to further enhance your knowledge and proficiency.
2) What worked for me usually was to subscribe to a mailing list. Not necessarily even the 'official' *-users mailing list, but just one that talks about problems. By reading through other people's common problems, not-so-common problems, and more importantly, the community's solutions will help get a perspective of the language and how other people are using it.
3) Start looking at well written code in that language. Go on GitHub, Bitbucket, sourceforge, or whatever, and start looking through the code.
Pet project.
First, start by giving up on that "I don't know where to start" attitude. Just dive in. That's how you learned code "back in the day" and very little has changed. You just need to start absorbing information and trusting that after awhile, it'll turn into useful knowledge.
#fuckbeta #iamslashdot #dicemustdie
Really, did the crash hit you that hard or are you bored? I don't know if you understand the employment situation for programmers these days. You're going to be old in an industry noted for it's ageism, behind the curve technologically, and depending on where you do find a job, you're likely to be paid terribly for long hours and work under a clueless asshole boss.
I really hope you have other options, it's ugly out there these days.
I wouldn't discount languages like C just yet. They're still hugely important in the kernel world, for example.
As far as newer languages go, there are a lot of F/OSS projects that could use another hand. Have a look at the Bugzilla for various projects and grab the latest source from svn/git/mercurial/whatever. Your skills as a programmer should transfer over to a new language relatively easily, and you'll have done a good deed.
"Every vision is a joke until the first man accomplishes it; once realized, it becomes commonplace." -Robert H. Goddard
Proficiency in ALGOL, FORTRAN, COBOL, and Pascal makes you stand out from the crowd. Market yourself as a specialist.
Facts do not cease to exist because they are ignored. -Aldous Huxley
If already know those programming languages, you should be able to pick-up the newer ones easily. Maybe look at some Open Source code to familiarize yourself with the new words and structure, but that's all your really need.
The biggest challenge will not be learning these new languages, but convincing the HR dopes (i.e. liberal arts majors), that just because you've never programmed in C++ or C#, doesn't mean you don't know to do it. That's been the biggest challenge for me: "But we need someone who knows System Verilog, and you only know Verilog. You're not qualified."
Idiots.
Also you may find yourself working against ageism, even if you did have the required skillset. Slashdot just recently ran an article about how hiring managers in tech firms assume anyone over 40 is not suitable for working on new technologies. They want young blood, preferably those with no family, no life, willing to work lots of hours and/or fresh out of school.
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
Postpone learning the other languages and focus on Python. It has almost as many modules as PERL but us much more readable. It supports object oriented design and is easier to use for small projects than C++.
http://python.org/
Religion is poison to rationality, and we lose sight of that at our own peril. -- Lurker2288
I have never read an introductory O'Reilly or "...for Dummies" book that was better than the multitude of online tutorials out there. Introductory books are, in my opinion, wastes of money.
No books necessary, just hit the net for more control over finding something that caters to your skill level. One dosen't have to go to Sourceforge to find snippets and application code.
Stick with what you know. You're trying to enter an overpopulated market with no experience in the new languages.
"Hi I'm here for the French teaching job. "
"Experience?"
"I'm fluent in latin, amazing at it in fact"
"You're here for the wrong job"
There are still plenty of FORTRAN shops out there, or at least legacy FORTRAN applications.
There is a ton of COBOL apps that need maintaining
If you are going to learn anything, it should be stuff that makes you more interesting as a FORTRAN and COBOL coder. For example, get comfortable making HTML/CSS pages. A lot of shops are trying to connect COBOL to the web and SOAP.
Find a web site or book to learn what relational databases are. Everything is relational these days. The NoSQL crowd think they're post-relational, but they still talk in the relational language.
That's the other thing you should learn: Oracle PL/SQL and Service Oriented Architecture (SOA). SOA these days means SOAP and message busses. At my place of work, we have a legacy COBOL application that needs to connect to the enterprise's Enterprise Service Bus (ESB). We are struggling to find anyone who can do it inside our company.
Your future is being the bridge between the past and the future. Learn how to make those old apps do new tricks, and you'll make lots of money.
Learn Perl. Because Perl is like the swiss-army knife for programmers. You may not write an application with it, but you might use it to make bulk changes to a hundred COBOL or FORTRAN source files.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
Pick a language and dive right in. If you are proficient in as many languages as you state, then learning "modern" languages will be no problem. Especially if you are familiar with Pascal, which structurally is very similar to the languages you want to learn.
C++, PHP, Java, C# and Javascript are all related structured programming languages, and primarily differ in minor syntax, class definition, data types and strictness.
For example, the C code:
if (++i > 10) {
j+=5;
i=0;
}
will execute as-is in all 5 of the languages I mentioned (PHP would have $ signs in front of variable names). So if you are familiar with C, or even Pascal, then you already understand a good portion of modern languages.
"HTML5" - HTML, CSS and Javascript (and throw in PHP for server-side), would represent the largest departure from what you have done in the past, due to the tremendous amount of segregation between what runs on the server versus what happens in the browser. To some extent the entire thing will seem like a big hack, and to a large extent that's what it is.
Still, my point is that if you were able to become proficient over such a wide variety of languages in the past, then you will not have any problem today, especially since many of the modern languages are quite similar.
Better known as 318230.
There are build managers, release managers, configuration managers, QA managers, etc. All who need high technical skills, but no need to do heavy duty programming skills. What they need is a technological eye and the ability to solve problems on the fly.
These positions get paid as much as developers, and are quite technical. And, they tend to be the place where older individuals can really make their mark. You can't out code 20 to 30 year old developers. They grew up in college with this stuff and know it forwards and backwards. However, most of them are pretty lost when it comes to the overall design of a software development life cycle.
As for programming, my recommendation is to forget about compiled languages.
Learn Linux and BASH shell scripting. Should take you a couple of weeks to get the hang of it. Then, try Python, and after that JavaScript/AJAX. These are the languages that glue everything together and can be used in either Windows or non-Windows environments.
Your main concern is getting a hang of object oriented programming. That was the most difficult thing for me to get my mind around.
Comment removed based on user account deletion
Java isn't that tough. If he were to find a local college willing to let him audit or, if necessary, pay for just a Java class then it would probably be a worthwhile investment. If he has experience with procedural languages and programming then a good Java course would let him catch up with OOP design.
I think Java still makes a good poster child for OOP design and is more portable and accessible than C# or any other .NET language.
My God! It's full of eval()'s.
Get hired for the skills you currently have, in a company that's small enough that it doesn't have a huge number of software engineers, and one that's a good company to work for and therefore doesn't have too much turnover.
Do good work and collaborate well with your colleagues. Be constantly on the lookout for any vaguely software-related task that turns up that's sort of a nuisance for them, that nobody has specific expertise in, but is too small to justify a full-time hire.. Don't worry if it's a marketable skill as long as it's a _new_ skill. Companies prefer the devil they know to the devil they don't know, and once they have confidence that you can do the tasks you say you can do, when you say "let me take care of it for you," they'll let you take care of it for them. If you keep acquiring new skills, sooner or later some of those new skills will be marketable skills.
When you're trying to get a job, it's very hard to get away with saying "Well, I don't know C++ but I'm sure I can pick it up because I know Smalltalk, which is another object-oriented language." When you're inside the company and they trust you, it is much easier to get assignments for which you can make the case that you may not be a perfect fit, but you're close enough.
"How to Do Nothing," kids activities, back in print!
The problem with books is that most people learn by doing, and toy problems don't teach you what a real application is like.
I'd suggest picking an open-source project and doing something with it. Depending upon the type of programming you want to do, add something to Linux, OpenOffice, or any of the number of Java-based things. (I'm currently working with the Sakai course management system. There are plenty of things that need doing there.)
The languages aren't any worse than what you're used to. The problem is that real programming these days tends to involve lots of complex libraries and frameworks. Those are hard to learn in the abstract, which is the reason for my advice.
Whether it make sense for someone to (re)enter programming as a job I can't say. That's a decision for you. There are a lot of problems with the profession. But there's also lots of important things that need to be done, and a lot of the people who think they're programmers aren't up to it. Programming approaches are changing often enough that skills go out of date in a few years. That's both good news and bad news for people like you. Since people have to learn new techniques all the time anyway, it's not like you have to relive the whole last 30 years.
The language depends upon what you want to do. Systems software and desktop applications typically use C-based stuff (C++ is probably the best place to start, although Objective C and other things have advantages.) Web applications use Java or .NET. I'd probably start with Java. You can find real and interesting applications in just about any language, so you can argue for Python, Ruby, and all sorts of other stuff. But C++ and Java are probably the place to start. I keep hoping that there will be some major new programming technology to use multiple processors / cores well. But there are lots of nice demos, but so far I haven't seen an approach that looks like it's going to really take off. That's really pretty discouraging. I wish things were more different from when you were programming. C++ and Java are only slight improvements on what you're used to. It's really the libraries and frameworks that are new.
If you're thinking of web-based work, I strongly suggest learning Javascript and at least one major Javascript programming environment (e.g. jquery or one of its competitors). UIs are increasingly moving into Javascript.
Typically the older coders grew up in a much more structured environment - we were expected to know the theories of programming much more than today's coders. Not a put down for anyone; times have changed.
The only place I know of for old coders with old skills is in embedded linux. It's much the same attitude - squeeze a lot of performance from a limited box. And GUI skills don't really matter.
So start with busybox. Tear it apart, put it together, submit some patches. You'll find you're not so rusty.
Then find an embedded project you want to work on and contribute. Forget about working for someone else; most companies these days don't want anyone over 35.
Set yourself up as a specialist consultant. Embedded systems, old systems, IBM stuff that's still out there. COBOL is still in demand and coders, good ones, are getting consulting jobs. Not permanent jobs, mind you, consulting jobs.
Do what you know and build on it.
Java gets a lot of criticism for its sandbox attitude, but that lets it enter the realm of idealism more than other languages. In my opinion, that's exactly what's needed for a programmer new to OOP. As I said above as an AC (damned checkbox), learn how to use and think with objects first, then apply the old knowledge of algorithms to get the most out of your abilities.
You do not have a moral or legal right to do absolutely anything you want.
Why update at all? There are still legacy systems using FORTRAN and probably COBOL as well. While there are C#, Java, PHP developers all over the place I imagine that finding a developer to maintain a legacy system is extremely hard. Of course that means there will not be many jobs out there for you but the pool of qualified applicants will be extremely small.
Plenty of money in COBOL but there is a need to suit up (physically and mentally) - not for everyone.
I have found a small but significant niche in embedded *nix programming. Small yet powerful systems requiring every scintilla of juice tempered with a familiar API - C Systems programming work is common enough (yet not common enough!). This is where I hope to spend the next while.
An "old school" approach to knowing the architecture inside-out and attention to detail is clouded by the bizarre abstractions of C# and Java. PHP isn't even an abstraction, it's a distraction (I grew tired of the inconsistency so no longer practise).
Perl is unfashionable in some circles and has a reputation for having magic constants (or whatever it is the detractors call "I don't want to learn this language") but I recommend it if you want dynamically typed "chops".
I find these "chops" are overrated. I enjoy low-level thinking so don't need to bloat up with virtual machines[1] (the real ones work fine for me), OO[2] (I know how to pass a pointer to my data to a lib) or design patterns[3] ("ways to do things" - if you learn one way as "the way" you may be unlikely to think there may be a better way)
[1] I use virtual machines but it's perverse running the dozens of MB JVM (and waiting around for it) for a browser bound animation or trivial desktop app. There may be a better case for this messing on the application server, but I don't care.
[2] OK, I will make an argument for OO in GUI programming - a large and complex library of heterogeneous components is difficult to arrange sensibly in a procedural manner. gtk_status_icon_set_from_file(foo_icon, "bar.png") or fooIcon.fileSet("bar.png")? There may be a similar argument to be made for other systems but for the most part I find the OO model a needless abstraction.
[3] Right... most programmers aren't brilliant - I know I'm fucking terrible for the most part - so having established methods for common situations is no bad thing... just don't get too attached.
I don't mean to insult the author of this comment, but I think he is very wrong.
If by "old style coding", he means procedural programming, with a column of hundreds of lines of code then that isn't Java. Java is Object Orientated language. Every hear of encapsulation with that? Everything is separated into modules.
I have seen old school programmers put hundreds of lines, procedural style, into a JSP or one monolithic function, but that just means they are ignorant of OO and using the language wrong.
Sheeesh.
If you develop apps for the new iPhone, can I put in a request for an app that uses GPS to direct you towards the nearest public phone box.
Thanks.
You'll find getting back into the field, to program in high level languages with all of your previous experience outdated, to be very difficult. Companies will not want to pay you the salary your years of experience would warrant, and it would be like starting over.
Instead, the method back in that I've found for those of us who started in the "old days" is to go for embedded systems development. The embedded world uses 10+ year old technologies, so your experience with assembly language programming and writing software for systems with limited amounts of RAM and storage space is a big plus for embedded systems development. There are plenty of companies still creating software for processors that run at between 4 and 20 MHz with anywhere from 256 bytes of RAM on up to a handful of kilobytes of RAM. I've found this sort of development work is much more interesting, anyway, and people with old school knowledge are considered more valuable, rather than a dinosaur, for such work.
There's something a little odd about this question. Mentions the volume of code output from his past life, but not the application domain. Seems to have weak Google skills. Not sure how he managed to post this query to an electronic discussion board. Did he dictate to his grand-nephew?
Having expertise in an application domain would be a good place to start. Then figure out what languages have remained relevant. But I get the feeling his former application domain is in the same state of decline as his programming skills.
With that list of former languages, the guy *ought* to have a fairly strong skillset for maintaining write-only Perl scripts (write-only code was a major industry back in the day), and I figure there's some demand for that. It would be a good transition language: old school mindset, old school syntax (uglier than most), but with a post-Algol dynamic execution environment.
If he can get over the hurdle of the moderately complex program that use to run in 50k now requiring 50M, he'll do OK. If not, he should try his hand at embedded. I've never written a line of code for an AVR that I couldn't have written (conceptually) with a C compiler from 1983. Those early microcomputer C compilers were riddled with trivial bugs. I recall a fairly simple C static variable initialization (more than one nesting level) the compile mis-generated. That wasn't uncommon. It's been a long time since I've had to report a major code generation error in a C compiler. It's the same skill, minus much of the grief.
The other thing that changed is that I no longer schedule lunch around a global recompile. Certain of the old-school time management skills have gone by the wayside. These days, it's your computer that goes to lunch. Between keystrokes.
Hey there old guy, while you were cranking out 100,000 lines of code, did you acquire any documentation skills? Those older code bases he's equipped to maintain often go along with old school formal management processes.
The biggest change from then to now is that you simply don't know what you're doing in most modern development environments, not the way one used to. Competence is a bubble of lantern light you carry on your person as you trudge into dark places, with one screen tethered to the internet. It's humanly impossible to learn PHP without constant recourse to a memory aid, if your memory is filtered on sanity. New kids won't even know what "filtered on sanity" means. It's been way out of style since Microsoft introduced us to the glories of central planning. In the 1980s, I knew *every function* of my favorite program editor. Often I knew every command line switch on the compiler I was using. And every function in the API I was programming against. These days, I don't even know every line in the context menu that comes up on a simple right click in Eclipse.
The other sea change one has to master is letting your tools do more of the work, whether it's unit testing, make scripts, or an IDE.
A fairly debilitating liability at the outset is not having a good sense of what is supposed to be painful, and what isn't. The rules on how productivity is gated have changed substantially. Long ago it was possible to put in a super productive week banging out a top notch utility library suited to the compiler and application domain. You'd be hung in the modern workplace for losing a week on an HIH detour.
If he's a bit more adventuresome, despite not mentioning Forth on his list of skills, he could do a lot worse than buying himself a Lego Mindstorms NXT and a copy of WoW and investing some quality time into Lua. The C side of Lua is anchored in the old-school skills he seems to have in abundance. He won't have a job at the end of play time, but he'd manage to bridge about half his generation gap in the process, and he mig
While you are trying to figure out how to wipe your but, I will give you a heads up on why your post is sort of irrelevant.
You see, he isn't looking for an intro to programing, he already knows how to program. He is looking for ways to use his knowledge of the past to make learning a new language easier today. Now 10 years ago, there might have been all sorts of resources on how to transfer your knowledge of assembly or cobal into something more relevant today. In fact, 10 years ago with the Y2K BS, there was probably a sleuth of resources on transferring your present day knowledge to yesterday's coding languages.
However, this point of reference has diminished to the point that he needs to ask present day coders, perhaps people who went through the transition years ago, what they found, what worked, and what was a waste of time. This will let him compile a book list and seek out the probably out of print books and other resources (even if using the way back machine which doesn't have a search like Google) that you recommend without mentioning the name or title of.
This isn't a typicle example of how do I do something everyone else is doing, it's an example of how do I do something that hasn't needed to be done in 15-20 years. And yes, if you look at something that hasn't been done for 20 years, you will find that the resources available simple arne't- at least not like they were 20 years ago or are for today's challenges.
As I mentioned earlier, C# is just a knock off of Java.
It's extremely similar if you're familiar with both, 98% of a port can be done with search and replace... s/using/import/g, etc.
Somebody else who needs to update their knowledge, evidently.
Quidnam Latine loqui modo coepi?
Really, did the crash hit you that hard or are you bored? I don't know if you understand the employment situation for programmers these days.
Depends on the programmer. Seriously. Not to make up shit, but I'm getting an average of 2 calls every week from headhunters I know for well-paid positions, calling me if I'm interested or if I know people that might fit the bill. I'm happily employed, and the only people I'd trust enough to recommend are employed. People I know that I wouldn't even trust to code a "hello world", those are the ones that are continuously having a hard time getting a job. Maybe for other people, who are truly qualified, they have a harder reality, but from where I'm sitting, if you have the chops, you get the job.
And I'm not even in a place that is known for its plethora of IT/software jobs. And yet, 1) I know people who are continuously getting the gigs, and 2) I know that a lot of positions are being unfilled.
And it's not as if companies aren't willing to pay. It's just that there isn't enough qualified software engineers. There is a shitload of cookie cutter programmers out there, you know, the type who never gets the basics, like why he needs to close a database connection or avoid Java string concatenation. For them, obviously, there aren't enough jobs. But there are jobs out there, companies are willing to pay good for filling them... and they have a hard time filling them in with qualified people.
That there is a problem with the economy is one thing. That there aren't enough jobs for the cookie-cutter programming masses, that's another. You have the skills and you have been intelligent enough to cultivate your professional network, you get the job. Period.
You're going to be old in an industry noted for it's ageism
Cliche. I work with developers who have been working with software for 25 years if not more, people well into their late 50's. I'm not making that up.
behind the curve technologically,
This you might have a point, and the person in question might have to start in an entry level position, but that's his call. But consider this.
Most people that are working with software NOW are already behind the curve. You see people out there that have been doing, say, Java for 10 years and still don't understand why fine-granularity web services are a bad idea. Since the dot-com (and thanks to it) our software industry is inundated with people who can't program for shit, and who expect to get paid $70K out of school just because they know how to code a JSP/ASP page.
I'd rather have a veteran programmer starting up with Java and C# in a junior position over the junior developers we have know. And I know for a fact of employers who think that way as well.
and depending on where you do find a job, you're likely to be paid terribly for long hours and work under a clueless asshole boss.
Isn't that how it for most us anyways? This is how it was 30 years ago, it is what it is now, and that's how it is going to be? The people who work 9-5 are those who work on an assembly line connecting piece A with piece B non-stop. You want to work with software, with finance, with medicine, with law, expect to work long hours.
As for having an asshole boss, you'll get one now matter where you work or what you do. It's life. It's a 50/50.
I mean, fucking seriously, are we really to believe that it likely to get an asshole boss, with likely meaning the majority of times? Are we really that cliche and gullible? One thing I know is that the more people focus (and believe) that this is the case, the more that it is simply a matter of projection, of projecting their own assholery.
Yes, sometimes we get an asshole boss. But other times it is not. It's called LIFE!!! And when you repeatedly hear someone always complaining about asshole bosses, they are actually saying "I'm an arrogant, pr
As a child of the personal computer revolution I too grew up with procedural programing sinclar basic, apple integer basic, Pascal and Fortran. although I've worked with Java, C+, Obj C Visualbasic and real basic I've allways felt a little uncomfortable because I never had any formal training in any of them. The Stanford CS classes on iTunes U have really helped me fill in the missing pieces. 80% was review for me but the last 20% helped make the first 80% make more sense. Don't be afraid to start right back at the beginning it will really help.
Timothy, Hopefully you read Slashdot from the bottom up like I do. A lot better signal to noise ratio that way!
Consider getting hands on with hardware and robotics and do the programming as well. The robotics field is only going to continue grow. Simple single-purpose robots are common. Think in terms of 3-D printers, Automated labs in a box, Beer brewing machines, CAM robots, etc. All of these are can be controlled by microcontrollers. A microcontroller (mcu) is a true computer on a chip. Even the memory is contained on the single chip CPU. What would be neat about going into this industry is the programming will start out pretty simply--pretty much where you left off in the 80's. This is because the mcu's are still pretty simple (cheap too--you can buy 5 Arduino mcu kits for $50). You can start by building simple robots and go to more complex ones and relearn/transition into the trade as you go. Also as far as programming languages go, you can use BASIC for PIC, C for Arduino and Java is available for some mcu's as well.
BTM
That was the turning point of my life--I went from negative zero to positive zero.
I write system software mainly, basically unixy bits for network appliances, enterprise servers and consumer electronics. I tend to read assembly a few times a month. and my idea of graphical programming is how to access the memory mapped registers to program the graphics controller. I also use zero C++, because Linux and the other OSes I work on are very C heavy. For an old school developer I think C is probably going to feel very familiar to things like Pascal and the various system programming languages of the 70s and 80s.
Picking up Objective-C and writing some iOS apps is pretty straight forward really, and not that hard to pick up. You have to have some talent and artistic flare to be good at it, but it's not that hard to throw up some widgets or draw some OpenGL ES graphics.
“Common sense is not so common.” — Voltaire
No Shit, Sherlock.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I wonder what kind of job requires you to practice music, horticulture and computer science at the same time. And can keep you occupied for nearly 25 years.
Tech guy for The Wurzels.
Leverage your old school skills, and learn mainframe assembler, too.
Many of the people who knew how to do this are retiring, but the systems and software they built is still running, and requires maintenance. There is going to be a huge skill gap when the rest retire.
there are 3 kinds of people:
* those who can count
* those who can't
This is a plea for anyone who thinks object-orientation won't do anything for them to stop and back away from that view for a second. Give me a minute to explain.
Read this great article called Why are you still using C?. I think it explains very well what OO can do for it.
Did you know that the Linux kernel, despite NOT using C++, is actually doing bonafide object-oriented programming?
Just one example is the Linux VFS. A filesystem passes in a struct with function pointers to read, write inodes, etc. The I/O kernel code only knows about each VFS in the generic terms, but ends up calling specific implementations via the function pointers. This is called polymorphism.
That's right, the Linux kernel is doing real, meaningful object-oriented programming. In contrast, if you put a few functions together under a class (like many people do that "have to" write OO), then you ain't doing jack shit worth of object oriented programming. However, because the kernel is using C, it has to do a lot of messy things with pointers. C++ helps take care of that mess (polymorphism is supported in the compiler), so you don't have to write it by hand.
Problem is, object-oriented programming is useful when it is applied on an as-needed basis.
Design patterns? Same thing. People got a design patterns boner when the book came out (I know I did). The academic/enterprise/fancypants software architect approach was: "What if? What if?! Why not use a pattern here, just in case you ever need to do it this other way?" So, you end up seeing patterns and flexibility and layers of abstraction (variations on a theme) built everywhere, where you end up not using them.
So you end up with a ton of code that never really does you any good. Worse, when you suddenly realize that you need some kind of flexibility, you already probably sliced the code the wrong way, so now it's actually *harder* to make things flexible. All because you made them flexible ahead before you knew what you actually needed.
There's a concept of emergent design, which basically says: don't come up with any frameworks, let frameworks emerge from the code. That is, if you find yourself needing to copy/paste the code or find yourself repeating something that's awful similar to this other thing, well, *now* -- only now is the time to use a technique to eliminate the duplication. Maybe you make a little framework. Maybe you just make a class or two to help you out. Maybe you use a bit of a larger design pattern, well, 'cause you don't need to use the whole thing. And that's great! You've taken care of the duplication, so now all the code you have has purpose, has a real need.
WE have been made to feel stupid, by all these academic and UML software architect wankers that are removed from real-world coding and proclaim the need for design patterns everywhere and "careful architecture" beforehand. Turns out that we weren't stupid, we were just being practical.
The first thing you should know about Windows programs (and most if not all GUI programming) is that the programs generally run in a loop (even if your programming language of choice hides this from you) and act upon receipt of "messages" from the OS. You have to program, among other things, what happens when you receive the message that says "the user pressed this button you've made" or "the timer you've set up has ticked" or "the user pressed the close window button", etc... Understanding this basic model will help you no matter which language you choose.
I had to re-enter the market as an a aging programmer, had a hell of a time. You have to have recent, relevant product to show. Worked with PHP for a year on my own, learning web and web services tech. PHP was a good environment for that learning, easy free tools, and very easy to understand, everything is very transparent. Gave me some 'product' to show others also. But now I'm in iOS/objective-C, have a few apps in the store. Objective-C is a little strange, would prefer C#, but no problems once you get going. You can develop for free for mac, or for $100 on the iPhone/iPad. You have an instant distribution mechanism if you want to sell on your own, and the skill base is very hot if you want to work for someone.
I transformed my skills into project management. It is certainly not for every old ptogrammer, but I found the transition easier than keeping up with the new development tools/languages.
I took a 1 week class (actually 4 days M-T) followed by the PMI Cert Test on the Friday. If you have spent decades developing, you will have a good shot at passing the first time around. You may find it interesting and close enough to your experience for it to be useful. Being PMP coupled with experience and an interview suit should land you in a good spot.
Slowly waving my hand - "This is not the sig you are looking for."