Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

We Need a Steady Flow of Software Engineers with Performance Skills, but All We're Getting Is Drip, Drip, Drip

DZone's Guide to

We Need a Steady Flow of Software Engineers with Performance Skills, but All We're Getting Is Drip, Drip, Drip

The question of the shortage of performance engineers seems to go mostly unanswered. It's time to change the priority we place on performance-centric education.

· Performance Zone ·
Free Resource

xMatters delivers integration-driven collaboration that relays data between systems, while engaging the right people to proactively resolve issues. Read the Monitoring in a Connected Enterprise whitepaper and learn about 3 tools for resolving incidents quickly.

We need a steady flow of software engineers with performance skills, but all we're getting is drip, drip drip. This blog post is my take on a few things we can do to fix that.

Kids will says the funniest things, sometimes, and ask the most uncomfortable questions. Often, the best response is, "Ask your father," or, "Stop watching YouTube." But what if at bedtime, your 5-year-old corners you with a tough question like this: "Where do Java performance engineers come from?" That's a really tough question, right? How do Java developers pick up performance skills in 2018?

If instead you ask where structural engineers come from—that is easy to answer. Their skills come from a college curriculum designed for structural engineers. In fact, this one school says structural engineering is about the design of "load bearing systems." That sounds a little like a Java application deployed on Tomcat or JBoss, doesn't it?

In the animated gif at the top of page (stolen from here), note that every one of the students in that college class were learning how to load test. To contrast, in software, only a magic few engineers— the performance engineers—are tasked with the "load bearing" part of the discipline. The rest of the developers stay at home, coding barefoot and in their pajamas with little concern for performance. That's exaggerating a bit, but what percentage of developers check their code's performance before checking it into source code control? 5% ? 3%? Who checks all that code for memory leaks, problematic sync blocks, and torrents of slow, and chatty calls to the database?

But, I digress. Back to the point, where do performance skills come from in 2018?

Here is my take, let me know if I've missed anything:

  • Experience. Do performance skills come from having been around the block a few times and having seen lots of systems in production? I've been doing performance engineering for 10 years straight, and some do and some don't. Kirk Pepperdine (performance guru) thinks he has hard data that shows that experience doesn't necessarily translate to performance skills, and I tend to agree with him.
  • $2000 short courses. Performance skills sometimes come from performance short courses, where great experts like Kirk PepperdineCharlie Hunt, and others can get you up to speed. These are great ways to learn, but from my experience, very few developers ever make it to these classes. What company pays $2k to send their entire team to this kind of course? That rarely happens.
  • Self taught and from books and blogs. Many performance skills come from some 400-page Java performance book and some elbow grease. This is how I learned performance, and actually, it took a few 400-page books. But frankly I'm not sure how much I've retained from 400-page books. How about you? Can you name 10 things from the last 400-page tech book you read? How about from the last three 400-page books you've read?
  • Perhaps a few four-year college Computer Science programs have a class or two in performance, but rarely do they venture beyond, "What is a profiler?"

Looking at this list, it's not surprising that we've got so few performance-savvy developers. My point is that we need a steady flow of software engineers with more performance skills, but all we're getting is drip, drip drip.

So how can we get more developers trained up in the ways? I've got two main suggestions.

First, 4 year CS programs need to treat software for what it really is—a discipline that designs/builds load bearing structures, just like structural engineering. Ok, performance experts, what do you think should be in this curriculum? If we inserted new classes into the curriculum, wouldn't some classes have to go? Which ones would you remove? And to repeat, these classes must go beyond, "Here's how to use a profiler."

Second, I think the current format of Java performance books is doing very little to help.

I tried a new format with my recently published Java performance book , hoping that it can provide a repeatable process that will stick with developers.

The list below is what I was shooting for when it comes to "format" for the book. I would love to know whether or not you think I've achieved it.

  • Shorter: 200 pages, not 400. Why? To reach a larger audience.
  • Easy to remember. Like a scaffolding, helping out when you get started. For example, in my book, I used a completely cheesy acronym to help people remember the main places to look for performance defects. It's called the P.A.t.h. Checklist, and it covers Persistence, Alien systems (ones you connect to over a network), threads, and heap. Its cheesy, but it works. 
  • Comes with running examples of commonly found performance defects, and this should include load gen scripts....all downloadable from Github.
  • Cover most common performance problems for a particular app type. Embedded apps, desktop, server-side code. My book is focused on Java server-side code.
  • Acknowledges that "learn to use a profiler" is not enough. What about load generator skills? Building test environment and test data? What about scalability?
  • We need a common denominator for tool selections, to facilitate more universal metric comparisons. If you and I both use JStat to compare garbage collection metrics, we've got something to talk about. When we all use different metrics and different tools, it's tough to say whether we have comparable situations.
  • Clear instructions to avoid wasting time over-tuning. There is plenty of angst over what it means to avoid premature optimization. Let's clearly state how to decide what's enough.
  • Repeatable and methodical. Less of an art. More of a discipline.

So that's my story on a few things we can do to provide a more steady flow of software engineers with performance skills. Would love to hear your ideas on how to improve on this. Thanks for reading, I hope to be blogging a lot more in 2018!

3 Steps to Monitoring in a Connected Enterprise. Check out xMatters.

Topics:
java ,performance

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}