Software Development

Why it's impossible to become a programming expert

Justin James discusses how the pace of change in the technology industry has made it nearly impossible to specialize in much or become an expert in anything.

The pace of change in the technology industry has made it nearly impossible to specialize in much or become an expert in anything. I started cluing in on this a few years ago when I was reading a lot about Lisp, but I simply didn't have time to try it out. Learning Lisp, and learning it well, requires a lot of reading, practice, trial and error, and so on. This would have been fine and dandy, but I wasn't doing this during my 9-5 job; this was just a "wouldn't it be neat to learn this?" type of project. A few months ago, my father and I were discussing the topic of expertise, and some of the things he said really clicked in my head.

Compare the amount of knowledge needed to really know C, Pascal, or maybe COBOL to their modern business programming analogues of J2EE and .NET. There are a few commands, a few primitive types, and a few operators. Let's look at the libraries in 1991 as an example (1991 is the year I learned to program). Windows was just starting to penetrate the enterprise. A lot of programming was happening on mainframes. By and large, UIs were completely text based without a mouse. Input validation was a cinch; you simply looped over a "wait for input" statement until the user pressed one of the three valid buttons for that point in the program. Events? Nope. Object-oriented programming? Nope. Declarative UI definitions (HTML, XAML, etc.)? Nope. N-tiered architecture? Accessing resources over a network? Globalization? Nope, nope, and nope. Life was pretty darned simple.

It was a really nice transition from that world to the Perl/CGI world. At the end of the day, writing Perl in a CGI environment is conceptually very similar to writing a COBOL program: You take a batch of input, do your processing, and dump your output as a batch. It took roughly 50 printed pages to have enough Perl documentation, examples, "cookbook recipes," and so on to do the job at a decent level of competency. The experts were the folks who had been around long enough to understand issues such as SQL injection, and the need to properly escape encoded entities. At the time, I specialized in regular expressions. A few months of working with regular expressions (which are arguably a micro-language of their own), and I could read a regex like English. Over the next few years, I worked some real magic with them, from writing my own PHP-like system that fit my needs to working on screen scraping.

In 2001, I transitioned to Java. All of a sudden, I had some monolithic 1,000 page tome on my desk and 200 MB of HTML with minimal formatting on my hard drive -- and these were just as reference sources. I ended up reading 500-700 pages of a "teach yourself Java" type of book. (In comparison, I read C in Plain English in three days -- it was only a few hundred pages -- without access to a C compiler, and I definitely qualified as "knowing" C.) The Java language has grown quite a bit since then; C# and VB.NET are comparable in size and scope. I would guess that it would take at least 500 pages to adequately document (with examples and a thorough explanation of the techniques, usage scenarios for them, etc.) VB.NET, C#, or Java. PHP is much less complex, thanks to its Perlish roots. We still haven't looked at the massive libraries that these systems carry with them; J2EE and the .NET Framework are both quite extensive. If anyone tells me that they are an expert in these systems, I know they are lying.

I have been working with the .NET Framework since 2003, and I am not an expert in the Framework. I am highly experienced with a few namespaces: System.Drawing, System.Threading, System.Net.Web, and System.Text.RegularExpressions. The rest of my time working with .NET has been so insanely spread out that I can't remember much of it. Thank goodness for Visual Studio's IntelliSense; at least with that, I can muddle through namespaces until I find what I need. If anyone were to watch me write code, they would assume that I am an idiot, since it would definitely look like I was grasping at straws 50% of the time. To be honest, that is what it feels like. Unfortunately, my "grasping at straws 50% of the time" still beats the industry average of 70% (I'm just making up numbers).

An expert programmer is no longer someone who is really knowledgeable or experienced. All too often, an expert programmer is the person who is adept at using a variety of reference tools and documentation to find out how to achieve their goals. This is my secret sauce. I am really good at looking at a problem, figuring out approximately what is wrong, and being able to quickly find the solution. To the uninitiated, it looks like sheer magic. To others, they say, "wow, Justin figured that out in only 30 minutes!" when they had been struggling with it all day. My real talent is knowing how to rapidly research and turn my findings into usable information. I suspect that I would be just as good at being a forensic accountant or a question writer for Jeopardy!.

Most of the really good programmers I have met are the same way -- they know a little of everything. They have tons of experiences that inform their "guiding light" when they look for answers. They have a natural talent, but overall, if you were to grill them on anything outside a narrow area (say, the System.Threading namespace), there is a really good chance that they will know where to get the answer from but not actually know the answer. Mark Cuban recently called this the "Open Book" World, and I tend to agree. Although for those of us in the IT industry, this happened 10 years ago; programmers (unlike network engineers and system administrators) have been able to touch radically new concepts with a simple download since about 1995. The eruption in new programming models, languages, frameworks, libraries, etc. closely tracks the adoption of the Internet. Between vendors and open source projects, it seems like another new "this will revolutionize how you program!" system is announced once a week or so. They all look worthy, but they take six months to learn really well, and I just can't devote my time to working with more than one at a time. So my choice is to either become barely familiar with a lot of things, or to commit myself to something that may not pan out.

For now, the "sampler platter approach" has been working well for me at the professional level, although I find it quite frustrating at the personal level. I miss learning things in depth. I miss the sense of satisfaction from attaining a level of expertise. I miss getting to explore obtuse and obscure areas of knowledge. But it simply does not match the reality of my work or that of most other programmers.

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine.

About

Justin James is the Lead Architect for Conigent.

57 comments
danpaz
danpaz

Higher level abstractions certainly change a lot, but the lower level concepts and operations driving them remain largely static. A solid knowledge of them, along with an arsenal of ways to use and apply them, mark the difference between expert and average. An average programmer knows C the C way. He knows what is in the book, and he may have picked up a few clever tricks over the years he has spent with the language. An expert knows how to write mind-blowing C that takes advantage of concepts from multiple paradigms, in such a way that his code may be far more stable, flexible, readable, and efficient than average--even if he is on working on day 3 with his reference manual. Do not underestimate the power of new ideas. Dig into a few radically different programming paradigms, or work at solving some interesting-but-irrelevant problems. You will see permanent improvements in whatever technology or language you use or may someday use.

cmhatte
cmhatte

Thanks. I've been unemployed for about 6 months now and getting frustrated with my daily job searches. There's a few things in there with languages close to what I know, but nothing specifically for my field. I started introducing myself to multiple languages to understand the basics so I could at least try to get in at ground level. Your insight to this practice of knowing a bit of everything makes me feel a bit more confident about the next 6 months of searching.

ramthatsmyname
ramthatsmyname

You would be amazed at how well you have captured my angst. I belong to the same, unfortunate timeline (1991...95) and I vibe when you say you miss the expertise, the satisfaction of "knowing" a language. And lucky for you, you seem to have overcome this hangover and moved on. I am still trying (unsuccessfully and desparately) to achieve the same expertise in this exploding universe :( Ram

trefre
trefre

Why do you think knowing or not knowing trivialities about this or that library is the most relevant criterion to define who is an expert at programming? This is ridiculous. This is the kind of thing that is actually _hurting_ our field, because it tends to make less experienced people want to just learn blindly about this or that library when the real useful knowledge is abstract (always have been and always will stay). From my experience, people at this stage of their programming development tends to make shitty architecture... (and some of them stay at this stage of their programming development :/ ) Experts are not afraid to RTFM. The good news is: you are probably an expert. You just didn't know it.

apotheon
apotheon

You're on Hacker News, Justin. I just figured you might want to know.

Peleg
Peleg

I don't agree. I consider myself a programming expert without qualifications. My job is fundamentally NOT knowing about any particular language -- it is all about knowing how to use any particular language (given it is suitable for the task -- I wouldn't think of writing a device driver in Perl) to solve the problem. This first means that I know how to design a solution and, to me, the highest level design doesn't depend on the language. It's figuring out what the program has to do, the steps to getting it done. This means I need to know about a bunch of general techniques, like linked lists, hashes, objects, database table design, etc. Then, I look at the languages I've got available and solve the problem using a suitable language. If, as recently happened, I found that I didn't know the language well enough to get the job done, I simply clocked-out for a few days (I'm an independent consultant, and I think I'm paid to know how, not to learn how on the client's dime) and studied the language some more. Now I got to solve a problem with a web site being hack so I'm about to do it again looking into how sites get hacked and what to about it. So, an expert is someone who has the fundamental knowledge to solve a large set of problems, the honesty to admit when he's out of his league "A man's got to know his limitations" -- Dirty Harry, and the willingness to learn what is necessary to get the job done. A language is like paint and canvas to an artist. An artist needs to know how to use different colors, different types of paint, and different brushes but the art all comes out of his talent and experience. The paint and canvas are just the medium of expression.

Vincent_Salomon
Vincent_Salomon

"So my choice is to either become barely familiar with a lot of things, or to commit myself to something that may not pan out." The third option is to be a late adopter. Wait to see if something pans out, then jump on if it does. You'll always stay a step behind but moving forward. They used to say, "leading edge, not bleeding edge".

rgavila
rgavila

This is so true. Now I know why the field always feels like a horse race that never ends!

chatterjee.pratap
chatterjee.pratap

Exactly what I feel. I have been programming since 1984 and followed similar path to Justin. Assembler, C, Pascal, VB, Java, PHP, JSP, Servlets, Patterns and still not an expert. There are too many so called experts out there but .....

brian.kiser
brian.kiser

I agree with this. When I was in FoxPro, I thought I was hot stuff because I knew a tremendous amount of the language. The last few years, I have struggled to learn C# and the .NET Framework. I doubt I will ever have the command over it that I had in FoxPro.

jmerrill
jmerrill

It would be nice to see broader recognition of the need to be a "constant learner" and of the value of having experience with, and understanding of, a number of different technologies. Every once in a while I look for a different job. Without an explicit statement in the job description that the people doing the hiring are looking for someone who knows how to develop software and can learn to do anything isn't already known, and that they value smart people with lots of experience doing software development (in my case, more than 30 years) -- it just doesn't seem as though my skills would be appreciated. Too many people expect that all software is going to be like the Microsoft sample programs, and they don't want to be challenged to do anything that isn't like one of those samples. Those people are not going to build anything of great value.

alekro
alekro

This what I think about current state of development (learn-on-the-fly-apply). I see I had similar way :) (Basic->Pascal->C->Perl/CGI->Oracle->Java-J2EE/.Net->BPMS). I recalled magic in perl's regexps. I developed small DB engine as part of my diploma..that was good time.. -AlexK

james.rector
james.rector

Almost 35 years ago I was in a community college to learn aircraft maintenance. One of my instructors told us that it was not important to remember everything he said, however your success would rely on how good you were at finding and applying the correct answer....I have applied that bit of knowledge to all things in my life as well as the last 25 years as a computer expert?????

obFuscAted
obFuscAted

Awesome - I used this article during my recent review. My boss not only gave me a significant raise but he also hugged me and confirmed that he, too, does not know everything. He further stated that, between the two of us, we still don't know everything but, if we kept it cool, no one would find out since it would seem that (together) we knew more. I also showed this article to my wife who soon after told me that she's having an affair with a man who states that he does in fact know everything. You win some and you lose some, I guess.

nedzanfjnut
nedzanfjnut

That's probably why some of us who teach the fundamentals of programming to kids are stuck in a time warp with stuff like VB because now it all gets too complex too quickly. They want to see results of their endeavours now and make "stuff" that works. Since it's only a small part of my job I got left behind 7 or 8 years ago. I'm still struggling to migrate to .NET because, as you say, there's just too much to learn and too much documentation to come to grips with.

jmartinez7709
jmartinez7709

I am a recent master level graduate in computer science (2008). I been told is not what you know but how you solved it by someone who been in the IT field forever. Justin your comment was right on target. I have been employed in the Mental Health field for fifteen plus years as a license mental health counselor. Solving OPP (Other People Problem) is what I do best. I been creating DB application since 1990 for helping the mental health professionals do their jobs better without the paper work stress. I do read a lot on differ program languages ( jack of all trades but master of none) Thank you for your insight until then peace.

sywillia
sywillia

I'm a technical writer (12 years experience mostly in the telecom industry) with an engineering degree (3 years experience). What I'm finding as a technical writer is I'm expected to know as much about programming, networks and engineering development as the "experts" in those areas along with the tools used in technical documentation. It's impossible to know it all. But I'm also a good problem solver, because I've had to document hardware and software products when the experts weren't available to tell me anything or when a product was still just a concept. Been asked if I know Java, Perl, .NET, C#, C++, HTML, XML, Sharepoint, Visual Basic, FrontPage, Dreamweaver, Flash, FrameMaker, etc. etc. Makes my head swim sometimes.

michaelnelson
michaelnelson

In the 1990s there were scads of programming and scripting languages, all with there own focus. If you wanted to harness the power of any one particular language, you had to learn a whole new language. Now, all of those focuses (math, text or file manipulation, graphic editing, etc.) are converging into one ginormous structure called .NET. Suddenly, there is a common syntax to harness all of your PC's powers. Learn that common syntax THEN you are a 'programming expert'. If you want to switch from database programming to graphics editing, it's simply a matter of spending several hours with the help file instead of spending weeks learning a new language. So even though you may only harness 15% of what .NET can do, that doesn't make you any less of a 'programming expert' than someone who mastered 15% of the available programming languages available before.

julieferguson
julieferguson

As a college professor, I always tell my students that they cannot expect to know everything about programming; however, they need to know how to find a solution to a problem quickly. In addition to good searching skills and good reference materials, I also tell them to build their social network of IT people. Over the years, I have found many other IT people who are willing to point me in the right direction when I have a problem that they have already encountered.

paul
paul

I would agree with you wholeheartedly. I can still manage a VB6 application, for the most part, without working through the help - but when working with PHP, Coldfusion, MySQL, MSSQL et al - it is becoming a complicated plate of spaghetti that I can't keep in my head all the time. Thank god for online help and forums!

Jamesb
Jamesb

I agree with the sentiment of your article, but I would differentiate between specific API knowledge and an understanding of how to design and write good software, and of the programming 'memes' over the last 20 years. I would argue that the real pace of innovation is not that fast, if you have sufficient expertise & experience to distinguish between a new concept, and merely a new implementation of one. AJAX was around for 5 years before the term became widely used, and is actually a simple use of DHTML, HTTP and XML, though some of the abstraction frameworks around it are great for productivity. SOA is an attempt to describe ideas 10 years older in a more cohesive, and more standardised way. An expert programmer sees Ruby and thinks 'cool implementation', not 'OMG I need to go buy a book'. The .NET / J2EE APIs are very different (e.g. swing vs. WinForms) and you certainly can't hold all of their details at the forefront of your mind. However, the principles of being able to code well in either, and make good decisions about approach and API selection, are almost identical - not surprising because both are OO imperative languages with a JIT compilation, GC'd runtime. People I know who are expert in one learn the other very, very quickly - and that's down to their programming expertise and experience. I don't think the problem is so new either, I think it's just that the bar has been raised significantly in the last 10 years with more competition to be productive, and hence to use higher level languages with rich, abstracted and large APIs. You used to be able to get away in the early 90s with writing everything from scratch and still be perceived as competitive - now you can't. An expert programmer nowadays is someone with experience of multiple programming paradigms in a mixture of contexts. e.g. imperative (C++/C#/Java), functional (ML/Scheme), who has worked at a systems level and business application level. I know quite a few people like that. They still pick up APIs and frameworks as you describe, but they have the knowledge and experience that gives them a deeper understanding of why and how an approach should be taken. If you're stuck with a complex technical problem, or a load of bugs, then someone like will solve it for quickly regardless of whether they know the API you're using or not. They know the relationship between a semaphore and a mutex, they know that the network is expensive and they should go for coarser grained messaging, they know the pros and cons of ATL vs. MFC, and are comfortable with regular expressions, SQL injection, transaction isolation levels and probably wrote their own equivalents of AJAX back before everyone called it that. By my definition of expert programmer, there's still just as many as there ever were out there.

jean-simon.s.larochelle
jean-simon.s.larochelle

Most of the really important stuff that you learn in one environment are still valid in another. This is particularly true with languages. Once you have mastered one language it is much more easy to learn (and retain) another language. I guess this is the same phenomena as in learning foreign language. Reading on C# recently I was able to breeze through many sections of the books. Once you understand concepts like static members, instance members, virtual methods, ... multithreading, etc... It is much easier going. Even so call new concepts are easier to grasp (closure is somewhat like anonymous class, mixin is somewhat like multiple inheritance with some additional safegards, etc... What I found however is that switching from static languages to dynamic ones is less obvious in practice. This is where I feel you really hit a good learning (practicing) curve. All of this is nice though because I dread the days when I will grow bored and start to believe I know enough. JS

don
don

Justin Well said indeed. Having worked in the IT field for over 40 years now I am constantly learning new technology. Four years ago I started learning J2SE Java and it was very painful for the first 6 months buried in the docs learning the basic working-set of class methods required to do useful work. Now 4 years later it is second nature and I have the z390 Portatble Mainframe Assembler open source java project to show for it at z390.sourceforge.net. One of the limitations of my z390 assembler has been that it did not offer an easy way to be integrated with other mainframe high level languages. But this month I learned that Micro Focus COBOL now has support aavailable for the IBM standard EZASOKET callable interface to TCP/IP sockets. Amazing in a matter of days the following EZASOKET SOA generation capability was added to z390 so high level languages including COBOL that have EZASOCKET support on their platform operating system can now call z390 assembler SOA services running on any platform supporting J2SE connected to the same TCP/IP network. Not other framework or other languages such as XML, C, or native platform assembler are required. Amazing new technology! For demo source code and screen capture visit: http://z390.sourceforge.net/z390_SOA_Support_for_COBOL_and_Assembler.htm As soon as you guit learning, you become a dying breed. Don Higgins don@higgins.net don.higgins.net

Tony Hopkinson
Tony Hopkinson

I've stopped enjoying learning about it though, maybe if something really new and exciting came up, but programming wise, while there's been an explosion of tools and methods, there hasn't been a new concept for a long time. Wrote my first program in 1976, I personally don't give a toss about picking up the latest fad from an intellectual point of view, (job wise is a different story). I learnt more from the .net framework books than I did from programming in C#. The biggest problem I find in .Net or any other large 'library', is generally you end up reinventing wheels and or spending hours trying to make octagons round. Useful knowledge, but to me not the level of complexity I genuinely enjoy working at.

mcnwilliams
mcnwilliams

I understand the frustration as well. I think this article hits the nail on the head. However, it reinforces a long lasting concern that there are hiring types that are looking at prospective employees the wrong way. I see many ads with a long list of skills that you must be an expert in and very little mention about problem solving skills. The hiring people need to be converted and we must also push and promote our problem solviong experience in our cover letters and resumes. I have worked with many people with a long list of credentials (i.e. Microsoft) who could not keep the good ship lollipop sailing. Good luck on your job search. I am unemployed as well and I have been solving problems for 20 years. Getting a job is the hardest one always.

Justin James
Justin James

... but it is impossible to be efficient or effective without it. Otherwise, you find yourself either constantly reinventing the wheel (because you didn't know that the functionality already existed), or doing research to find the functionality you need, how it is used in context, etc. A great example of this is kicking off a process to run in the background while leaving the UI responsive for things like a "Cancel" button. It's a fairly common chore, but uncommon enough so that most of the .NET developers I've met have never done it (it helps that most of them are ASP.NET people, and I tend to do desktop/command line apps in .NET). To make sense of the documentation on this takes forever. I know, because I did it a while back. It's a few hours of back-and-forth with the documentation and experimentation to get a handle on it, I'd say. Now, I can do it with a lot less effort because I'm familiar with it. So yeah, I "learned a library" and can save two hours. That's not bad. Multiply that by many of the tasks that can come up on a project, and you are looking at shaving a week off of a 1 month project, because you "know the libraries". I'd say that makes someone a lot more "expert" than someone without that knowledge. Of course, being an "expert" involves so much more than library knowledge. You need to know the fundamentals of logic, decision making, understand architecture concepts ("is this kind of loop truly useful here?") and more. And languages are getting HUGE. In the last few months, I've learned a lot about extension methods, lambdas (which I knew in other languages, but not .NET), LINQ, and other C# 3 functions. Let me tell you, I am coding MUCH faster now that I invested the time to read about these technologies and then do a demo project to myself to see how they get used. Again, it's knowledge of concrete items which is the difference maker here. It's just a shame that the knowledge base is so broad now! J.Ja

Justin James
Justin James

Always interesting when an older item gets picked up somewhere. :) J.Ja

Tony Hopkinson
Tony Hopkinson

is expertise with tools, not the discipline so you are not an expert in teh terms described. Nothing wrong with that of course, after all an expert is someone who knows nothing about anything else..... Generally of limited utility in our trade.

Justin James
Justin James

Alex - That reminds me of the time when I write a full (except for the lack of an admin tool) Web shopping cart with zero libraries or external dependencies in Perl... in about 1,400 lines of code. Including a templating engine, a module system, and a built-in flat file DB system. Was the DB system full featured? Heck no, it was a delimited file system with no concept of types, relationships, etc. And regex's were at the heart of the whole project. That's the biggest Perl-ism I miss, that regex was a language operator level construct, instead of having to wade through some tower of objects like you do in the current crop of mainstream languages. J.Ja

Tony Hopkinson
Tony Hopkinson

I didn't realise the fundamentals were still being taught. :p It's always been my contention that any language / environment stops the teaching of programming fundmanentals and starts you on language fundmanentals. Teach them programming in the kitchen, it's a twofer. Anyone who can program can learn VB, C#, F# 6502 Assembler..... The same cannot be said of anyone who simply knows a particular language. Course you'd have a real problem selling your students as qualified to HR types if you went down that route. :(

Justin James
Justin James

I learned the fundamentals from people much like you... BASIC and COBOL on mainframes, Scheme, Pascal on a PC, C on a UNIX box. They had me focusing on the ideas (linked lists, recursion, modularization, etc.), not the tools (languages, libraries). As a result, I have a great basis for the work. I am grateful I didn't come of age after everyone started learning in Java, too much work to focus on the Java itself and not the ideas. BTW, I highly recommend "EdScheme" for teaching the fundamentals, to this day, I attribute most of my fundamental knowledge to working with it and its learning program for half of a school year in high school. J.Ja

Justin James
Justin James

... you need to know as much about the tech as the developer, but be able to communicate accurately & effectively (in writing, no less) the precise details of a system, while often not being privy to the nitty-gritty details of the internals. Definitely not a path for the faint of heart! I can't imagine how touch it must be to have to know all of that tech, but not use it at the level of the developer. I have only learned by doing. J.Ja

The Ref
The Ref

I thought the job of a tech writer is to take non English* jargon which only engineers can read and turn it into semi-technical English which no-one can read ;-) * [replace if needed with the choice of your own language]

Tony Hopkinson
Tony Hopkinson

But I see this select * from Table followed by a While Reader.Read(){...} way too often....... I saw an Onpaint routine for a component with a query inside it once, I sh1t you not. Unfortunately once of the things that has come out of big frameworks, is "Those who can't, do anyway" Language is small part of programming, in fact it's a trivial one in my opinion, except in terms of the constraints the choice of language / environment impose on a design. The sort of screwball who does the above wouldn't understand that anyway.

Justin James
Justin James

You make a bunch of good points here. I too remember when, if you wanted to work with a database, you *couldn't* easily do it from a general purpose language like Pascal or BASIC, you found yourself writing an application in FoxPro or Powerbuilder. The only alternative was to use C++ (not always the "best" choice as a language, but often the only one with the needed libraries) as a "glue" language to hold a bunch of APIs together. Aside from that, though, the languages *are* becoming significantly more complex. C#, VB.Net, and Java, for example, have been adding a lot of advanced functionality; LINQ is based on closures (not a trivial concept to "get" and leverage), there are anonymous functions, closures in generable, portial inheritance, etc. Luckily, knowledge of these is not "basic requirement" to "know" the language. But it is certainly true that general purpose programming languages encompass a LOT more functionality than they used to! J.Ja

Peleg
Peleg

This young fellow was bright, well-versed in the subject, and eager. At the time, I had close to 20 years experience and he had about two years. He often came to me for questions and I answered him best I could. One time, after I had answered his question, he started to lather all kinds of praise on me for knowing so much, call me so smart, and such a great programmer. I responded, "Roger, you are bright and aggressive. The only difference between me and you is that I got born first."

Tony Hopkinson
Tony Hopkinson

stand on the shoulders of dwarves, lots of 'em though. :D If they are going into business programming, I personally would emphasise recognising a bad solution quicker, not many of the ones we end up with can actually be described as good, they are hopefully better. Oh and could you please knock a few marks off for using single character names, global variables and side effects.

Justin James
Justin James

If I were designing a course of study for prospective IT workers, I would definitely have a semiar (maybe 1 credit) on "Information and knowledge discovery, retreival, and leveraging". So many people I encounter don't know how to find information, or determine if what they find is credible/useful, or do not know how to successfully use what they have found. It's really wasted time if someone keeps paging through search results instead of narrowing the results, for example, or if they keep beating their head against the same problem because they keep following bad advice instead of figuring out a solution based on a thorough analysis. Great example: a problem that I worked on for about 20 hours turns out to have been caused by me typing in the wrong IP address into the firewall's permissions list. Instead of checking my fundamentals, I buried my head in a search engine and blindly tried to fix non-existent problems. J.Ja

Justin James
Justin James

"I agree with the sentiment of your article, but I would differentiate between specific API knowledge and an understanding of how to design and write good software, and of the programming 'memes' over the last 20 years." You are absolutely correct, and I should have stated just the same in my article much more explicitly. The fundamentals *have* changed a bit, and *have* gotten more complex (OOP adds a lot of concepts that don't exist in procedural code, but still uses all of the procedural guidelines too), and many modern languages (particularly Ruby, Perl, and increasingly [and surprisingly] C#) are blending multiple paradigms into the mix. But overall, "getting" the amount of functional programming in order to use, say, LINQ effectively, is not nearly akin to "getting" enough of the .Net Framework to not need the F1 button. :) J.Ja

Justin James
Justin James

Yes, it is good news that the fundamentals are always the key to actually being good, even if it is hard to convey on a resume. In terms of what you've been learning... anonymous *functions* are indeed a subset of closures, and a "mixin" (Ruby term) is similar to a "partial class" in VB.Net/C#. :) For me, I learned on static languages (BASIC, then COBOL) and immediately went to functional languages (Scheme), then to static again (Pascal/Delphi), and then to dynamic languages (Perl) for a long time. Perl, combined with Scheme, changed me forever. Once you've experienced the Ultimate Power of eval.() (and it's Perl-specific cohort, ///e [the "e" flag on a regex says, "eval.()" whatever you are doing!]), it is extraordinarily difficult to look at static languages the same way again. I hear old Smalltalk folks say the same about working in C++, Java, .Net, etc. People who learn Ruby also talk about a similar permanent perspective alteration. J.Ja

reshea
reshea

I see that Don is still enthusiastic--and after 40 years. Yes, Micro Focus COBOL is indeed a great product. I saw it in action over 10 years ago---I can only imagine there have been many 'extensions' over that time. I approached the 'computer thing' some 20+ years ago as a 'hobbiest'(enthusiast). I do remember well that one could handle C quite well in not too long a time. Ah! Those were the days. I am 58 now and work as a programmer/analyst/information specialist. I must say, that the libraries and frameworks and other things are such now that even an 'enthusiast' (I am still one) cannot hope to get real deep knowledge. One can 'flit' over things. I will agree with Justin 100% that becoming an 'expert' in the sense that it meant in days of yore is quite humanly impossible. It took (takes) many good minds to put together these very large frameworks (.NET for example) to have things work as well as they do. For the 'lone wolf' to become 'well versed' in of the aspects of a large framework (.NET for example), it just too much. However, like Don, I too am still enthusiastic!!! But, I harbor no illusion that I can 'know' in a deep way 'virtually' all of the aspects of the frameworks/libraries that are built today (Ah! - .NET for example [ha!]).

Justin James
Justin James

Yeah, I'm in a similar boat myself a lot of the time. It's why I went off and forced myself to get into multithreading and to explore functional languages. Typical "business use" scenarios simply are boring to me. I feel like I've been writing the same application (with different DB fields in the backend) for the last 10 years or so. :) J.Ja

Justin James
Justin James

Yeah, I'm in a similar boat myself a lot of the time. It's why I went off and forced myself to get into multithreading and to explore functional languages. Typical "business use" scenarios simply are boring to me. I feel like I've been writing the same application (with different DB fields in the backend) for the last 10 years or so. :) J.Ja

jean-simon.s.larochelle
jean-simon.s.larochelle

Recently I had to start learning C# and the .NET framework. This had the something like the effect (I suppose) of a massive dose of antidepressant. Maybe that was just because I had to learn the basic quickly and I just got high from the adrenaline. I hope someone will come up with something to grab your interest. JS

Locrian_Lyric
Locrian_Lyric

I have a fondness for 'C' because if you can master that, anything else is a snap. When it comes to the more complex languages, someone with a knowledge of the basics will at first find themselves daunted by the enormity of one of the high-level languages. That person should be able to do just fine with a book, google, and the help files. (Though if you're using an early release of anything by MS, a book, bell and candle wouldn't hurt either)

michaelnelson
michaelnelson

The OnPaint method is part of .NET basic syntax, not part of an obscure namespace. In your example, the programmer is displaying a lack of understanding of the common syntax and therefore is NOT an "programming expert"!

Locrian_Lyric
Locrian_Lyric

global variables, however drive me batty. Hey, let's ask him to take off points for 'clever stuff' like: a = (b/c * foo(x,z) + foo2(l,m,n)

Justin James
Justin James

I enjoyed learning it too, because it was also my intoduction to proper OOP; before that, I had used a lot of other languages (FoxPro, Delphi, Pascal, Perl, COBOL, C, JavaScript, Java, Scheme) but I had never used OOP beyond the very basics, I kept trying to fit OOP languages into a produral model. So it was enjoyable to learn OOP and do it in a language without C++'s "overhead". I was also unemployed when I learned it, which helped. But today I think I would have a very tough time getting excited about it. I recently transitioned from VB.Net to C#, and it was very ho-hum (not helped by the fact that I already *knew* C# fromr eading so many code samples, just never actually write any of it of my own). I keep finiding myself wanting an excuse to try working with Ruby and/or Lisp, but I can't justify it either at the moment in terms of time. I finally starting cutting into the 1/2 bookshelf of books that I bought but haven't read yet. J.Ja

Tony Hopkinson
Tony Hopkinson

A few interesting bits, but nothing eye catching. SSDLanguage. It's the second S I need to work on.

Tony Hopkinson
Tony Hopkinson

It's got nothing to do with syntax, or semantics for that matter, the code is valid as far as those go, it's just stupid or ignorant. My point was in the old days the concepts and the language would go hand in hand....