That’s because as much as choosing who will design the critical code that powers your business depends on their raw technical talent, that talent can’t be brought to bear if you’re not comfortable being around them.

In fact, it’s no exaggeration to suggest that the most successful software engineers are just as gifted with soft skills as they are with coding ability – and that these often-overlooked non-technical abilities are as crucial to the final outcome as anything else.

Because no matter how brilliant an individual or team of developers may be, that brilliance can only come alive when the business relationship that surrounds it is a healthy one.

With this in mind, whether you’re hiring software developers in on a contract or full-time basis, here are a few questions to consider:  

1 – What are your preferred languages and methodologies. Why?

Ideally, software developers will have had experience in the same technologies and platforms that are in use within your organization. But this doesn’t need to be a showstopper if they don’t. It could, in fact, be helpful to dig a bit deeper and ask why they’ve chosen to support certain tools or approaches. You can learn a lot about a software engineer by chatting about what motivates them.

2 – What experience do you have in our company’s sector?

It isn’t enough to be an experienced developer. Fundamental knowledge of – and experience in – a potential client’s particular line of business goes a long way toward ensuring a strong partnership. Ask about the kinds of business problems they encountered along the way, and how they worked with their clients, business partners, colleagues, and other stakeholders to ensure their code helped address them.

3 – What are current and past clients saying about you?

The client testimonial remains one of the best ways to measure the bottom line capability of a developer to deliver the goods. While most software developers and development shops maintain a project portfolio, ideally, they’ll also be able to share contact information for references. Consider it a red flag if they’re reluctant to do so – and don’t hesitate to review online and social media profiles in either case.

4 – Why does quality assurance matter? What does effective QA look like to you?

Truly great software engineers understand the role that QA plays in the overall success of any project. Their code is just the start, and a thorough discussion that highlights their overall approach toward QA can help separate the mature professionals from the rest of the pack.

5 – Can you take me through a standup (or Scrum) meeting?

Spontaneous role-playing can give you a greater sense of how effectively a prospective developer will work with you and your team – and how well they can communicate. In addition to the obvious ability to identify technical opportunities and solutions, look for signs of strong listening skills, collaboration, and empathy.

6 – Tell us what makes you an effective communicator

Communication is a crucial factor in any successful software project, and is often what separates the good from the great. How they answer this question can shed considerable light on how effectively they’ll work with stakeholders and the project team. It can also uncover red flags.

7 – What was your biggest disaster as a developer? How did you overcome it?

It’s easy for developers to boast about their biggest successes, but a lot more difficult to talk about engagements that didn’t necessarily go their way. Answers to these questions can help you gain insight into a developer’s critical problem-solving skills, as well as their abilities in coaching, project management, business analysis, and other areas of expertise. Few questions, in fact, are as effective at helping paint a well-rounded picture of what makes a developer tick.

8 – How do you know you’ve delivered to the client’s satisfaction?

This question speaks to the ability of a developer to not only create solid, stable code that functions as planned, but also their ability to measure the outcomes against stated business goals. In many respects it is the penultimate question because it challenges them to measure their output against organizational needs, and to speak to the value they bring to any given engagement.

THE BOTTOM LINE

Hiring the right software developers can easily be one of the most important resourcing initiatives at any organization – and this is particularly challenging given the historic shortages of talent in the broader technology landscape.

But the journey need not be difficult, and you need not be alone. Here at STEP Software, this is what we do, and we’re always happy to answer any questions you may have.

The post Hiring software developers for your team? Ask these 8 questions first first appeared on STEP Software.

Anyone who has worked in the industry and knows what it takes to become a developer will appreciate how unfair this kind of reaction is. Because it fails to account for the years of education, training, and experience that fully qualified developers must go through.

It fails to recognize the massive investment developers must make to become top-performing professionals. Developers aren’t just born, and they don’t just materialize out of thin air. They need education (and lifelong learning), real in-the-trenches experience, and unbridled passion for writing great code if they are to become capable of turning, often obscure business requirements into elegant code that does what it needs to do, no matter what an end user throws at it. 

This kind of reaction also fails to accommodate the myriad of gates any complex software development project must go through – including initial client interviews, scoping, technology selection, development, quality assurance, integration, rollout, training, and maintenance, among others.

Developers – well, the good ones, anyway – don’t just scribble some quick code on the back of a napkin and call it done. And anyone who thinks that’s the key to a successful outcome may want to toggle their expectations a bit.

LISTEN TO THE FIREFIGHTER’S WISDOM

All of this brings to mind the late Paul Neal “Red” Adair, who achieved fame by putting out oil well fires that anyone else might have deemed impossible to extinguish.

He used innovations in technology and process to take on some of the most intense petroleum industry disasters in history, including the Piper Alpha explosion and the oil field fires deliberately set by retreating Iraqi forces toward the end of the first Gulf War.

He’s a well-deserved legend in the energy industry, but he’s perhaps best known for a quote that resonates in the tech industry to this day:

“You can have it done fast, you have it done cheap, and you can have it done well – pick any two.”

I’ve lost count of how many developers, project managers, CIOs, and other professionals have this very quote framed in their offices. If you’re going to put one thing on your wall, this should be it.

CAN YOU REALLY HAVE IT ALL?

Adair’s words reflect a stark truth that applies to all projects, but especially technology-based ones. It is that the level of training, expertise, preparation, and background simply to get to the position where a developer is qualified to bid on a project are far more profound than the casual observer might appreciate.

To a certain extent, it’s similar to someone who refuses to bring their car to a qualified mechanic because they perceive them as being too expensive. The cheaper mechanic who services cars in a shadowy driveway may indeed have a lower hourly rate, but there’s probably a good reason for that – and for why the qualified mechanic can justify a higher rate.

Many of us learned from our parents that you get what you pay for, but for some reason we often forget that simple lesson when we first lay eyes on a quote and realize the number is bigger than we’d like.

What that number represents is multifaceted. Qualified developers, just like qualified professionals in any industry, bring so much value to their roles, including:

• Longer, higher-quality education and/or training, industry certification, exposure to crucial coaching and mentoring opportunities, time spent with community resources, and practice, practice, and still more practice.
• The ability to get the job done in fewer hours, at a higher level of quality and robustness.
• Access to tools and processes that are off-limits to lesser-trained professionals.
• Confidence that the client can get back to the business of running their business, or leading their life, whatever, without worrying that the software will fail – or the car will leave them at the side of the road.
• Deeper business experience that allows them to ask the hard questions and fully explore the resulting options instead of taking on projects at face value and failing to align their solutions to specific business needs.

Barely-qualified developers, just like shade tree mechanics, don’t stand behind their work as much as those more qualified. The mythical high-school-coder-nephew may eventually learn how to be a fully qualified business partner who anticipates critical issues, confidently suggests solutions, then crafts artful, elegant code. But not now, and not at any price. 

All of this reinforces a simple truth when we ask for quotes on certain services: we ultimately get what we pay for. And if we fail to appreciate what the professionals who provide these services are bringing to the table, we shouldn’t be surprised when our corner-cutting strategy ends up costing more in the long run.

Red Adair was right then, and his words remain right today.

Want to learn more? Reach out to us anytime.

The post Here’s why it takes so long to write great code first appeared on STEP Software.

While the cancellation rate for most other major U.S. airlines – American, United, Delta, and JetBlue – ranged between 0 and 2% on the Tuesday before Christmas, Southwest had grounded 70% of its flights on Monday, and 60% on Tuesday. By Tuesday morning, Southwest’s schedule accounted for fully 2,522 of the 2,890 flight cancellations reported across the U.S.

The airline that has cultivated a scrappy, humorous brand since its founding in 1967 suddenly found itself tripped up by a crew scheduling system that couldn’t keep up. 

The root cause for Southwest’s inability to keep its planes in the sky wasn’t weather after all. It was outdated software.

In a damning interview published by NBC and the Associated Press, Michael Santoro, a Southwest Captain and Vice President of the Southwest Airlines Pilot Association, said while the severe weather touched off the crisis, it was the airline’s “vastly outdated” IT infrastructure and scheduling system that ultimately led to the full-on meltdown.

“We fly a point-to-point network which can put our crews in the wrong places, without airplanes, mismatched. Our software can’t keep track of it,” Santoro said. He added the pilot’s union has been bringing this issue to Southwest’s attention on an annual basis, but the airline has failed to respond.

“They never update it. They never invest the money and resources they need to. So, we continue to have these issues.”

A DISASTER WAITING TO HAPPEN

Southwest’s employee scheduling system dates back to the 1990s, when Southwest was a much smaller operation than it is today. In 1990, the airline carried 19.8 million revenue passengers. In 202, the airline carried 123.2 million passengers. What was once a regional player based in Texas had long since expanded to a continent-wide footprint.

Southwest now carries over six times the passenger load, over a substantially wider geography, using a software system that hasn’t fundamentally changed since George Bush Sr. lived in the White House.

While the airline experienced a number of outages over the years, their impact was mitigated by the organization’s ability to fall back to largely manual processes – namely employees calling in from wherever they were, so the airline could rebuild its situational awareness and get them and their planes back in the sky.

Unfortunately for Southwest, by the time the lousy weather rolled in, just before Christmas 2022, the organization was far too large and complex for those old, manual processes to hold up. The phone-it-in Plan B simply couldn’t scale, and there was no fallback or failover.

LESSONS FOR THE REST OF US

Think about your own organization for a moment: can the software that supported your business decades ago – when you were likely a lot smaller and simpler – continue to get the job done today?

We all know the answer to that. The sad truth for most organizations is their software often remains static while the operational landscape continues to evolve. Organizations often develop applications and install systems within the context of monolithic, high-profile projects, then turn their attention to other things.

That’s a frightening reality. You wouldn’t buy a car or a house and forget to maintain it, would you?. So why does this backwards logic seem even mildly appropriate when running a business?

The stark truth is, there’s no way for infrastructure, tools, and processes to fluidly evolve in near-real-time, to perfectly reflect the challenges posed by a constantly changing business environment. But that’s still no excuse to walk away once the initial switch has been turned on.

To ensure the gap between infrastructure and environment doesn’t grow wide enough to swallow your business, start the new year by asking yourself the following critical questions:

1. When is the last time you conducted a software inventory? Knowing what you have is the first – and most important – step toward improving the health of your software estate.
2. Are you soliciting regular feedback from end-users? Software must align closely to evolving business needs and internal/external market conditions. Your people are your best resource to help you determine if you’re hitting that mark.
3. Are you measuring software effectiveness against business outcomes? Code drives modern organizations. So, make sure your metrics reflect this.
4. Does software development and maintenance have its own budget? Make sure code is uniquely visible within the overall IT operations spending and resourcing plan. Benjamin Franklin said it best, “If you fail to plan, you are planning to fail.”
5. Are you benchmarking against your competitors? While you don’t ever want to be a me-too kind of organization, it can certainly help to ensure you’re at least in the ballpark. You can then innovate and differentiate from there.

THE BOTTOM LINE

It is important to recognize that what happened at Southwest Airlines is hardly unique to the airline industry, nor was it solely attributable to the weather. The roots of this brand-threatening event first took hold years earlier, as fiscally-driven leadership trimmed the wrong budget line items and allowed the code base to lag behind. No organization in any sector can afford for its software to flatline the business, because as Southwest learned – the hard way – you can’t compete if your software hasn’t been properly maintained.

If you’ve got questions about the health of your own investments in software, we’d love to hear from you.

The post Southwest Airlines meltdown: a reminder why software maintenance matters first appeared on STEP Software.

Hidden in the rapid-fire series of headlines, tweets, kitchen sinks, and aborted verification checkmark introductions was a tiny tidbit of information around programming languages. When Mr. Musk first settled into Twitter’s San Francisco headquarters, CNBC reported he brought along a core team of software engineers and other staff from Tesla’s Autopilot autonomous vehicle team.

According to CNBC, Musk has tasked this team to review Twitter’s source code and begin planning for a revamp of the entire platform. It is this decision that deserves to be studied more closely by developers no matter who employs them or what kind of dev work they do.

Because unfortunately for Twitter, Twitter’s software environment is nothing like Tesla’s. The code that turns Tesla’s electric vehicles into supercomputers on wheels is radically different than the code that powers Twitter. Vehicles don’t need to support large-scale publicly facing search and platform services for millions of users concurrently. Tesla’s code also doesn’t have to accommodate regulatory requirements across multiple countries. Likewise, Twitter isn’t hooked up to a network of sensors measuring and responding to the surrounding environment at speed and in real-time.

Similarly, the two companies take a different approach to scripting, with Tesla using Python, and Twitter selecting Scala. Which means the tiger team from the car company entrusted with the high-priority social media code review may not have deep enough experience or environmental exposure to pull it off.

THE TAKEAWAY FOR DEVELOPERS

So, here’s some advice, offered with humility, for a Musk-owned Twitter that easily applies to any other development environment: bring in developers with domain knowledge. At the same time, take the time to assess what language or languages are being used – or should be used – for a given project. Then make sure the developers tasked with delivering the project are either trained up in the target environment, or have access to training and mentorship resources to raise their skills to an appropriate level. Finally, give them a starting point and vision to build toward – otherwise they’ll fail to understand how their work fits into the overall mission.

After job cuts that decimated every corner of the company, talent retention has become Twitter’s biggest challenge. Finding the right devs, for the right language, for the right functionality, is crucial if future-Twitter is going to realize some of the ideals Mr. Musk has recently shared via his feed. The very survival of Twitter depends on having the right developers with the right skillset and the right organizational support in place to fuel the transformation.

KEEP STAFF AUGMENTATION ON THE RADAR

The answer may not necessarily lie exclusively in Twitter’s internal complement, as the company’s need to adapt and scale, quickly, may exceed the capacity of the existing corps of developers. Despite Twitter’s latest round of large-scale content moderation contractor layoffs, staff augmentation could be a crucial opportunity for Mr. Musk to quickly build capabilities under the guidance of his core dev team.

By leveraging his carefully deployed contractor resources underneath their leadership, he could ramp up the pace of both innovation and delivery. This will be key to Twitter leaving the current market uncertainty behind and rebuilding for a very different, and lucrative future.

Given Mr. Musk’s outsized reputation and the white-hot coverage this story has generated, it’s easy to conclude none of this is relatable to any other company, or any other developer. But ultimately, the Twitter takeover is little different than any other corporate buyout. And no matter the organization, it’ll be the right developers with the right skills using the right tools working on the right projects who in the end hold the true power in any corporate transformation.

The post Twitter, Elon Musk, and a critical lesson for developers first appeared on STEP Software.