Discussion on:

We're entering the decade of the developer

Original post:
http://blogs.techrepublic.com.com/hiner/?p=6020

More and more applications are being built with tools that significantly reduce the need for developers. US Bureau of Labor Statistics estimates a 3% *DECLINE* in "programmers" between 2008 and 2018, and I am inclined to agree. *Programmers* are an increasing commodity. As systems follow standard patterns more and more closely and better frameworks exist to implement those patterns, demand for developers drops on a per-project basis. Add to that the competition from offshore, and being a *programmer* is a losing proposition.

The real opportunity for the foreseeable future is in software engineering and business analysis. You have to have hands-on with end users and add value to the process. Being the person who translates that vision into reality is a bad career choice.

J.Ja

I've worked in smaller IT shops where the software engineer was the business analyst who was also the developer who (in my case) was also the DBA.

If your software engineer/business analyst is also the person writing the code, I think there are huge benefits. You simply don't lose as much in translation.

I believe that that combined type of developer job will, in fact, be a big deal over the next decade. That type of person makes a huge difference.

-mark

I'm with you on the blended developer. I'm one myself, and I take it a step further by also doing sys admin and networking. Being a programmer helps me run the systems better (I know how to track down problems and understand error messages) and knowing the systems helps me write better code. I also agree that few understand the distinction between a "programmer" and a "software engineer" but it is a critical distinction when you talk about the job market's future. People who don't know better are going to end up as "programmers" and end up on the short end of the stick when they should be focused on being a "software engineer".

J.Ja

The biggest problem with "doing it all" is that this only works in relatively small companies. As companies get larger and larger they start segregating the work. IT (i.e. maintenance, installation/etc of the company network and computers) is seen as being totally separate from development and it is this "IT" that gets outsourced. HR, Benefits, all gets outsourced.

The REAL problem is that companies simply do NOT realize that there are substantial benefits to be had from having the people who DESIGN the software to be the same OR VERY CLOSE TO the people who WRITE it. Writing specs that are interpreted by people in India is a recipe for disaster. I have personally seen this fail multiple times, however, the "manager" who started the project had since been promoted for "saving" so much money and the fact that the project went over budget (even over the budget we had when all development was still in the US) gets buried so no one sees it.

This is the reality of business - it's screw everyone else before they can screw you. Pure capitalism at it's finest...

Where it fails is in meeting corporate management desire to have their own little empire.

Aided and abetted by us as well. You don't have to be a genius to realise if your manager's niche goes, so do you....

Ever heard a QA Manager argue against writing better code, because it's too expensive.....

Substitute the word capitalism with the word humanity and I think you will be closer to the mark.

BobP64 - It's even less recognized by those who have influence in companies, that writing software is designing.

> I also agree that few understand the
> distinction between a "programmer" and a
> "software engineer"

Maybe the reason why so few understand the difference is because there really is no difference. The distinction between terms such as "software developer", or "programmer", or "software engineer" are made only in your own head. If all three terms are used to describe someone who inputs code to produce applications, then it makes no difference what you call them. A rose by any other name, and such.

This is no different from the "title wars" of the last decade, where everyone in the I.T. business tried as hard as they could to outdo each other and make themselves sound more important and more relevant than they actually were. "Chief Technology Officer", my ass. It's a glorified way of saying "Systems Administrator".

When you walk into a Subway to get a sandwich, do you think of the person behind the counter as a "Sandwich Artist"? That's their actual job title, in case you didn't know. But now that you know, does it impress you? Does it make any difference to the quality of your sandwich if the person is known as a "sandwich artist" or simply a "cashier"?

When I was in grade school, the janitor used to be called a "janitor". Today, the exact same guy doing the exact same job is called a "Custodial Engineer".

In hotels, remember when they used to be called "cleaning ladies" or "maids"? Today, the same person doing the exact same job is called an "Environmental Services Aide".

Remember when the guy driving the truck once a week to collect garbage was called the "garbage man"? Today, the same guy doing the same job is called a "Waste Management and Disposal Technician".

Remember when your accountant used to be called an "accountant"? Today, that same accountant is a "Financial Asset Analyst".

I could continue with a list of bogus job titles long enough to fill a book, but you get the idea. So if you want to make yourself feel more important by calling yourself a "Software Engineer" instead of a "programmer", knock yourself out, but don't expect everyone out there to fall for the B.S. you're dishing out.

You clearly did NOT read what I wrote. There is a VERY important distinction, both in the industry and as I am using them here (their definitions as the US Bureau of Labor Statistics uses them). One just writes code. The does things like writes specifications, designs overall systems, interacts with other people in the business to determine their needs, and so on. In many smaller companies or departments this is the same person, but in a large company or development team they are VERY different people. For example, those offshore shops have a very small number of "software engineers", but they have piles of "programmers".

J.Ja

One might call it software engineers vs programmers. Another one might just say good programmers vs. bad programmers.

You're not right about offshore shops, at least not about those in Eastern Europe. Usually, all employees have five years of study and at least a bachelor's degree in computer science or information technology. More recently, most go on studying until they get a master's degree.

before it becomes the decade of the developer, this sort of misguided drivel has to corrected.

A better analogy wuld have been sandwich artist and chef.....

> A better analogy wuld have been sandwich artist and chef.....

It wasn't supposed to be an analogy. I was making the point that the person who makes your sandwich (the so-called "sandwich artist") is also the same person who takes your money and gives you your change (the cashier). Hence, it makes absolutely no difference what fancy title you put on a person, because underneath it all, they're doing the exact same job.

with role.

You coul call the guys in subway sandwich chefs as well.

You aren't going to see them doing seven course meals in a five star restaurant though.

Though I must thank you for proving my point that the near total ignorance of the discipline will be the biggest factor against some rise to eminence....

Back in the old days, when programmers were kings, there seemed to be plenty who were software engineers - guys who could flowchart your business process and write the COBOL or whatever. There were also programmers, probably much closer to driver developers today, who could write code that made a piece of hardware do back flips, but would probably have a negative impact if asked to turn a business process into code.

Further, there were guys who could lay out a process for programmers to develop as code, but who could not write any code themselves.

I knew people like this, and I'm rather certain the same circumstance has applied from the days of mainframes, through the micro vs. mini wars, up through today.

I think you will find the software engineer who also writes excellent code (or at least doesn't abuse code or coding frameworks) is a rarer bird than your average dude who can program.

i very much appreciate you terms and it also happens to us.. i for myself has a title of I.T. Manager,but hey our company now has 300 employee and im not managing just the IT Dept. we evolve from being an EDP to be Information Management Service, and then BI comes now not all programmer are ready be a BI Developer, so while having that title is very much not related to the job "WHO CARES " because in our company in terms of ICT that is my TERRITORY! no one will deny it!

I have to say, I'm inclined to agree with alot of what is being said here, but you're making an awfully big generalisation over a whole diverse range of industries. I think there IS a definate distinction between 'programmer' and 'software engineer'. Programmers, in my opinion, are code monkeys (like myself at present). We're given a task, and we bash the keyboard until it works, and usually we don't even get to choose the platform - and do you know what - I'm very happy to be a code monkey, I love it. The Software Engineer on the other hand will take customer needs, design and develop a system and a strategy to write the system to meet those needs - on an appropriate platform, using whatever tools are necessary to do the job (see the definition of engineering). That's two completely different roles - although that's not to say someone couldn't wear both hats.

Your description of "software engineer" would more accurately describe a "system engineer".

I agree Mark (btw, good name), I also work in a small shop where I wear all hats as either primary or backup, since there are only two people in IT. There is a huge need for people like us that are willing to diversify and maintain web sites, fix PC problems, support business apps and databases, while also picking up networking, smart phones, etc.
Personally, I love this kind of variety in my work, but it isn't for everyone. You can't really become an IT pro at anything; wide knowledge and personable, that's what my boss looks for when he hires now.

i think it will help if your company tends to grow... i myself been a programmer .... ad sometimes tinkering and tweaking hardware up to network. It helps me a lot in changing hats in case you have to

mbrown:

A hit more square upon the proverbial head is a task potentially slotted for things more difficult than one may actually accomplish.

To add one additional item...stating 'generally' and 'most of the time', I would take such an individual within my organization even under circumstances whereby IT has been eradicated altogether. My experience has demonstrated such individuals tend to get things done. In this case, "things" may be defined as, well....things.

- Chris B

I agree that's going away and morphing into much more of a business analyst role.

However, there's a lot more app work arising from the desire of brands large and small to have apps (the way they used to want websites). This is going to accelerate.

With Web sites, there was the huge rush for the "business card" sites... the five - ten page site with a minimum amount of backend programming (say, a "Contact Us" form or maybe a simple store), and that work fed zillions of Web designers/developers from 1998 or so to 2005 (that market has substantially died, I may add). That opportunity just is not there for mobile apps. It makes sense that my local hardware store or restaurant or dentist is going to have a small site to tell me their location, specialty, and sales. It does not make sense to have a mobile app for the same. Furthermore, the splintered mobile market and the HTML 5 revolution is going to make it much more likely that folks are just going to overhaul existing Web sites to be mobile-friendly than to write apps. Why write 1 iOS app, 1 Android app, and 1 - 3 apps for the second tier mobile OS' when you can just write 1 Web site? Especially since the Web site is much more discoverable than the apps?

J.Ja

HTML5 certainly can and will be part of the "app" equation, as long as it's not just a mobile skin for a current site.

As for the splintered environment - that's where developers and small teams of developers will thrive by making an app experience that translates between three different screens (PC, mobile, and eventually TV) and across different platforms. That will be the premium work.

HTML5 could be an enabler, but that's backend sausage-making stuff. What really matters will be the developers that can deliver this three-screen unified experience.

No matter what, HTML5 will definitely play a role in making Web sites themselves more app-like.