The Technologies Changing What It Means To Be a Programmer

snydeq writes Modern programming bears little resemblance to the days of assembly code and toggles. Worse, or perhaps better, it markedly differs from what it meant to be a programmer just five years ago. While the technologies and tools underlying this transformation can make development work more powerful and efficient, they also make developers increasingly responsible for facets of computing beyond their traditional domain, thereby concentrating a wider range of roles and responsibilities into leaner, more overworked staff.

Comments

Re:Some of us do still assemble, even now

[asmkm22]

Just because you can doesn't mean you should. 30 years ago, applications were built with long life-spans in mind, so dropping into very low-level code could make financial sense. Today, programs are generally designed for adaptability and compatibility. The target is constantly moving for the vast majority of applications out there. Dropping into assembly rarely makes sense anymore, because the mantra is "good enough" rather than "best" because even the "best" won't stay that way for long.

Of course, different industries will have different mileage. If you do most of your work for embedded devices or industry-niche things like robotics or satellites, then by all means dive into the 1's and 0's.

Re:Not changed much

[digsbo]

I'm not sure I agree 100%.

As a senior engineer today, I'm responsible not only for knowing the primary back end language (C#) for my web application, but also HTML5, CSS3, JavaScript, and the UI toolkit library. I'm also expected to understand database design, including being able to have an intelligent conversation about the physical schema, and I'm expected to be able to design tables, indexes, and optimize queries. I also have to know security, build tools, the automation scripting language for my platform (now PowerShell), and the deployment system (WiX to create MSIs). I'm also the source control administrator (Subversion).

I also have to read requirements that are maybe 5% of the value of those I got 15 years ago, and be a business analyst to figure out the rest.

Now fifteen years ago, I could probably have gotten away with knowing C/C++, a little scripting in Perl/Bash, and be decent at a CLI. I can probably write a multithreaded TCP/IP server in C without need for Google, which I haven't done in at least 12 years, but have to constantly Google things for what I now do daily.

I don't think things have changed fundamentally, but they haven't stayed the same. We're getting shallower, broader, and less efficient for it.

Somebody is projecting their delusions...

[gweihir]

Quite frankly, I just finished a larger project for a customer and what I did strongly resembles what I would have done 30 years ago: Define what the solution must do, do an architecture, a design, define interfaces, and then code the thing. The only thing that is different is that the C code was a web-server module and that the in-memory database may go up to 10G instead of the 100k or so it would have 30 years ago.

Really, nothing has changed much, unless you are at the very-low skill end of things, where you can now produce bad code in ways you could never before.

Re:what a load of utter bullshit

[Tablizer]

The hardest part is trying to get a web browser to act like a desktop GUI, which is what customers want. We have to glue together a jillion frameworks and libraries, creating a big fat-client Frankenstein with versioning snakes ready to bite your tush. Great job security, perhaps, but also an Excedrin magnet. What use is lining your pockets if you die too early to spend it?

It's time for a new browser standard that is desktop-GUI-like friendly. The HTML/DOM stack is not up to the job.

Dynamic languages (JavaScript) are fine as glue languages and small event handling, but to try to make them into or use them for a full-fledged virtual OS or GUI engines is pushing dynamic languages beyond their comfort zone. Static typing is better for base platform tools/libraries. You don't write operating systems in dynamic languages.

Somebody please stab and kill the HTML/DOM stack so we can move on to a better GUI fit.

Not that simple

[fyngyrz]

While the technologies and tools underlying this transformation can make development work more powerful and efficient

...and they can also bury them in irrelevancy. It can make them depend on debuggers instead of good coding practices and skills and self-checking that tend to make the debugger an uncommon go-to. It can isolate them further from the hardware so that the difference between what is efficient and what can only be said to work becomes a mystery to the new-style programmer. It can turn what should really be a one-programmer project into a team effort, where "team" should carry the same negative connotations as "committee." It can move critical portions of projects into the black boxes of libraries and objects sourced from outside the primary development effort, and in so doing, reduce both the maintainability and the transparency of the overall result. Languages with garbage collection can create much looser coupling between performance and system capacity, reducing the range of what can actually be done with them. Worst of all, with all the wheel spinning and checking code in and out and the testing methodology of the month, it can make them feel like they're really doing something worthwhile in terms of time spent and results obtained, when what it really boils down to is something far less efficient and effective overall.

There's another factor, too; the industry really wants young programmers. The costs are less for remuneration, insurance, and vacation; the families are smaller or non-existent, and these people will work much longer hours based on nothing more than back patting and (often empty) promises. One of the consequences here is that some of the deeper skill sets are being lost because they simply aren't around the workplace any longer.

I think there is no question that all of this has changed the face of coding. An interesting exercise is to ask yourself: When was the last time you saw a huge project hit the market. Now ask yourself how many little does-a-couple-of-things projects you've seen hit the market in the same time frame. My contention is that there are very few of the larger projects being undertaken at this point, or at least, being finished.

Just one (retired) guy's opinion. :)