Repair-It

If you asked someone what defined a ‘good’ car 30 years ago, what would that person say? Size of the engine displacement? Horsepower? Number of cylinders?

Now ask someone today. Some aspects of the answer might remain the same, but only the most diehard fanatics would say that a V8 engine is superior to a twin-turbo 6-cylinder. The latter would trump it both in terms of performance and efficiency. Many consumers would say it’s fuel economy. Or crash test rating. Or reliability.

You get the point.

So has the bar gone up? No, it’s changed. Drastically. it has shifted from depth to breadth. 20 years ago, ability was measured by a significantly different rubric than we do today. A good example is how irrelevant the “coding interview” as an inductive barometer for success. That’s not to say that deep subject-matter expertise about compiler optimizations, OS memory management, or AVL trees isn’t important. But the industry demand has shifted to breadth. We now need developers that can adapt to a multitude of languages and platforms, from web and moblie client UX frameworks to back-end server, cloud, and storage technologies.

By the way, that doesn’t even include the fact that developers today need to be able to think about all the unit and functional tests as they build, as well as the development and scalability model. Writing a microservice that will deploy at scale to millions of users? Better think about the TPS rate hitting your S3 or Azure storage buckets.

The game has changed. The set of horizontal concerns a developer has to think about is now at a much higher level of abstraction. And rightfully so. Don’t get me wrong, I will give infinite props to someone who can at write a compiler (we still have to implement those in upper year engineering classes in college), but that doesn’t mean anything about how ‘good’ that person will be in real-world industrial applications.

Not that I can see. The bar I've seen people measured against has always been "gets stuff done without disrupting the team," or thereabouts. Ideally, "good" also generally implies that you don't soil your pants if you need to learn new things, but that's debatable in a surprising number of circles.

The major differences I've seen over the last twentyish years probably include:

•Mythology: Big companies (like Google) have tried to re-mystify programming by claiming that some engineers are just way better than anybody else, and programmers take the bait, hook, line, and sinker, and want to prove themselves. I call it "D&Dification," because of all the questions I see about programmers wanting to know what their "level" is, like there's some linear measurement of skill or experience.

•Availability: A lot of days, jobs get done more efficiently by not doing work. Open source licenses, frameworks, Q&A sites, and the web in general have all become huge levers that good programmers can use to accomplish far bigger and better things with less effort.

•Business: Since companies have cut expenses and staff to the bone, a good hire can't usually get away with just being a good programmer. Even the junior people need to be able to understand the company's direction and take that into account when making decisions, as opposed to trying to do what's easy or fun.

Those aren't really big deals, in the grand scheme, just shifts in attention. It used to be that developers could get some sort of respect by implementing some specific things that--honestly--didn't say a whole lot about their skills. Today, nobody cares about the person who wrote an operating system kernel unless that kernel happens to be Linux, and that's more because Torvalds seems like a good guy than his specific code...

I think John Colagioia has a superb answer here, and I can’t add that much to it, but I will anyway.

I think the bar of what makes a “good” software developer has probably dropped significantly in recent years.

When I was growing up, I looked up to the developers at Commodore (for the Amiga), Apple of course, for the Mac, and Acorn for RISC OS and the ARM processor. In later years I learned of Bell Labs, Silicon Graphics, Sun Microsystems, and Be Inc.

The teams that built the exciting things at Commodore, Apple, Acorn, SGI, Bell Labs at the rest were quite small, ranging from barely more than one person (Sophie Wilson, for the ARM processor), to a few dozen or maybe a hundred or so at Bell Labs or Commodore.

With those small numbers of people, Commodore, Apple, Acorn, Sun, SGI, Bell Labs completely defined the computing landscape we are in now.

Compare that to some famous companies now, and with their thousands, even tens of thousands of developers, they essentially have managed to make a few web sites.

The above is deliberately dismissive of the difficulties in making a scalable website, it is difficult, I don’t deny that. I do think however, what we considered “good” 20 years ago or so is quite different to what we consider “good” now.

“Good” 20 years ago was writing a DTP package on your own in assembler.

I don’t think we expect any programmer to be able to do that now, we don’t really even expect them to know what assembler is.

I think John Colagioia is exactly right about the mythology around big companies like Google. I think young developers want so much to believe in something, believe that what Google does is special, that they just buy it, no questions asked.

So now we’re at the point that if you can put ads on a web page you’re a genius, and nobody can even remember the names of all the people who did all the work to make it so easy.

It’s like looking at a Hollywood star on TV, but nobody gives a toss about all the technology which makes it possible, they just want to look at the pretty people.

I think that most of the previous answers have covered the basics of what it means to 'reach the bar' and a couple have touched on the fact, that not all employers make their recruitment choices based on current in-depth knowledge of a subject alone.

I would like to add to this chain by saying, sometimes a person that is articulate, communicative and engaging, can stand out amongst the rest during the interview process. Its not always the best option to choose the quiet guys who knows every keyword in a particular language, sometimes, it is more important that the SE or develeper is able to capture, interpret and implement requirements and busines processes.

I'm not saying that some level of knowledge is not important, but in my experience in toadays workplace, the typical tasks asked of an engineer are different to those asked of the 'code-monkey' type of role. It is more beneficial if the candidate is able to understand the requirements of the customer, interpret them into a language that the dev team can understand, and then also deliver and explain the solution to the customer.

I thnk the distinction to make here is that the role of a developer is different to a software engineer. The former being more hands on implementation, the latter being more conceptual, communicative. Know the basics, and the more indepth knowledge can be learned.

I hope this adds to the answers given already. If you found it useful, share the love and upvote.

Regards, Robin.

Of course, both are required but if you had to pick a single person, you might do better with someone who understands the bigger picture even if he doesn't have absolute mastery of the programming language or whatever.

Its not always the best option to choose the quiet guys who knows every keyword in a particular language, sometimes, it is more important that the SE or developer is able to capture, interpret and implement requirements and business processes.

I'm not saying that some level of knowledge is not important, but in my experience in today's workplace, the typical tasks asked of an engineer are different to those asked of the 'code-monkey' type of role. It is more beneficial if the candidate is able to understand the requirements of the customer, interpret them into a language that the dev team can understand, and then also deliver and explain the solution to the customer.