Lost skills: What today's coders don't know and why it matters

"Today," says Rudin, there are occasionally times with you can't use the integrated debugger in your IDE (usually with some weird web application frameworks and server configurations), and younger programmers are at a loss as to what to do, and resort to hack-and-slash coding to try to randomly fix a bug, using guesswork. Me, I just calmly put in some code to display output values on the web page, find the bug, and fix it."

Oh come on. What he's describing isn't some "lost skill". If you can't figure out to use print statements for debugging you're not much of a programmer in the first place.

Most statements in that article describe really basic, common sense stuff.

> Bernard Hayes, PMP (PMI Project Mgmt Professional), CSM (certified Scrum Master), and CSPO (certified Scrum Product Owner).

makes me not want to continue reading much further.

To clarify: you become a CSM and a CSPO by taking a 2-day course each (well ok, there's an online exam, but you can look up the answers on wikipedia and pass). PMP is the only certification in that last that takes some effort, but it's totally unrelated to software and, thus, to most of this article's subject matter.

What, do they also expect us to cut, polish and etch our own silicon wafers as well?

    Ben Summers, Technical Director at ONEIS, a U.K-based
    information management platform provider, points out
    that "habits learned when writing web applications for
    14.4kbps dial-up telephone modems come in rather handy
    when dealing with modern day mobile connections. When
    you only had couple of Kbytes per second, and latencies
    of a few hundred milliseconds, you were very careful to
    minimize the size of the pages you sent, and just as
    importantly, minimize the amount of back and forth with
    the server."

    With today's mobile connections, says Summers, "the
    latency is much worse than using a telephone modem
    connection, and that's compounded by error rates in
    congested areas like city centers. The fast 'broadband'
    headline speeds are pretty irrelevant to web applications.
    It's the latency which determines how fast the response
    time will feel, and tricks learned when phone modems
    ruled the world come in awfully handy. As a bonus, when
    someone uses your app on a fixed connection, it'll feel
    as fast as desktop software!"

And by basic I mean not understanding the different performance implications of a table scan, an index scan and an index seek in an SQL query plan. And also why "it takes ages first time, but is quick after that (when everything is already in RAM)" is usually not acceptable (every time could be the first time around if the query isn't run often or RAM is limited).

Some of the stuff that article lists is just not needed at all by a code, really. Some are strictly hardware issues. Others are oddly specific: "programming tight loops" is part of the complexity theory thing: understanding how a process will behave at relevant scales and optimising accordingly.

I remember similar articles in the 80s and 90s bemoaning how "programmers these days" didn't know how to use a protocol analyzer or logic probe, or didn't know that xor made for a faster register clear operation (or moveq for 68k fans), or any other number of esoteric trivia that, while useful in context, did not usually contribute significantly towards a programmer's ability to get the job done.

My first debugger was an in-circuit-emulator for a Z80. It was the size of a small television set, had a crappy UI, and limited functionality. Today's debuggers can be hosted on the system itself, and have become so powerful that most people don't know how to use them to maximum effect (myself included). IDEs check your code as you type. No more writing something in VI, compiling, tracking down the cryptic error messages your compiler spat out and trying to figure out where the REAL error is because the compiler is dumb. You're shielded from the ugliness underneath, and for 99.9% of cases that's more than enough.

Do "kids these days" really need to know the sound of a hard drive dying? The last drive I heard going bad was in the 90s. Since then drives have become so quiet that you'd need a stethoscope to even hear the arm thrashing (which is why I use RAID). And how useful is the knowledge that you can open up a frozen drive and spin it up with your finger going to be as disks are replaced by SSDs?

We live in the future, where things have gotten a LOT better. Do the new batch of developers really need to know assembly language? After moving to "fluffy" languages, I only twice found need to use it (once to disassemble a stack dump from a JNI crash, and once to monkey patch a buggy device driver). Twice in all my years since using Java, Python, PHP, Objective-C, Scheme, COBOL, VB, and C#. Was it damn handy to have the right skill at an opportune time? Hell yeah. Does EVERYONE need this skill? Hell no.

How about bit packing? Memory has become so cheap and plentiful that even routers come with 16MB or more. Beyond low level networking and peripheral protocols, what use is there in packing up bits and coming up with clever encoding schemes that make for complicated (and potentially buggy) codec routines? Saving one byte in a packet header is hardly the triumph it once was.

All the "kids these days" need to know is their algorithms, profiling, debugging, multithreading issues, and how to write well structured, maintainable code in their paradigm of choice. The rest is usually industry specific, and can be learned as-you-go.

Don't worry about the kids. The kids are alright.

This is what I do every day at my job and there are other people who know how to do this, plenty of them. Most of them are EE's, though, and consider SW/FW development as their secondary job.

It isn't easy to hire embedded programmers, graduates with computer engineering, EE or CS degrees will have some knowledge but it's experience more than anything that will help you acquire these skills. When I look at resumes I look for experience building small circuits, Arduino or PIC. If I don't see anything like that or if the skill list starts with Java, PHP, ... it would be kind of unfair to expect detailed knowledge about how to use "volatile" in C or how to use a scope to find race conditions.

I'm totally guilty of this. I write new code on new hardware, and have very little intuitive of how fast it should go. Is 10k ops a second good? 1M? I just don't know how fast it should go. Of course, then I pull out the profiler, and think about my algorithm, but it takes a lot of second-guessing to decide how close to the limit I am.

For example, I was writing some clojure code to write to a SQL database. I'm relatively new to the JVM stack. I was writing to the DB at 1MB/s. I thought "well, that's not great, but not bad. Maybe after network traffic and DB constraints, and writing to a laptop disk drive, I suppose that's alright". No, I replace the JDBC DB thread connection pooling driver, and the same code now writes at 8 MB/s.

It'd be nice if there were a web resource for general guidelines on what it takes to max out hardware. Basically, benchmarks for real-world tasks.

I started to learn how to program in PHP. Back then there was a sentiment that PHP and similar high level scripting languages weren't real programming.

With the web so ubiquitous today, I didn't that sentiment had survived, but here it is.

I think our culture was and will always be based on exploration and innovation and this is simply moving to higher levels of abstractions today. There is nothing wrong with this.

However, I personally am not satisfied with simply being able to use an abstracted interface. I have a strong curiosity of how things work under the hood, of tinkering with something to make it do new things and even try and rewrite things in simpler forms.

I think a different kind of hacker evolves when you have a basic understanding of the entire technology stack. This breed is inevitably going to fade with the increasing complexity of this entire stack (breadth and height) paired with the current speed of innovation.

In the end, we can lament all that we are losing or work towards everything that lies ahead unexplored :)

Just like the phrase rtfm, there should be rtfs.

http://www.pbm.com/~lindahl/mel.html

And I think they left out the most basic and fundamental skill or understanding: there are no silver bullets. A lot of programmers nowadays seem to religiously follow whatever new language is being hyped and try to fit their problems and tasks to the language instead of the other way around... a bit of critical thinking and seeing a bigger picture than "thisandthat is THE SH*T (right now)!!" would work wonders.

In the real world, real coders could not care less how god-like the latest scripting languages or NO-SQL-but-relax-data-maps are because chances are very good that my customers use Java and Oracle or a few other big names and since they are paying me, who am I to push religious plugs about the latest fads on them?

Bottom line is: real coders (should) just know enough about computers, hardware, software and networks to make educated decisions and guesses and typically they don't care that much which language they are getting paid to develop in... pretty much all languages "suck" in the way that they ALL have their short-comings and it is up to the engineer to understand them and work with them.