4 Hard Questions For Enterprise Developers Who Want To Get Ahead

Guest author Adam Seligman is vice president of developer relations at Salesforce.com.

The tech industry is once again at a turning point. We've moved from a world of big monolithic applications to lightweight, contextual social and mobile apps. Apps, not applications. Apps in your pocket, connected to back-end services and data, with user context, and integrated into the social social graph.

Java and .NET developers represent the biggest pool of developers, but enterprise application-development practices too often have them stuck in the '90s. You wouldn't use a phone from that era, yet enterprise developers are constantly asked to keep pace with today's business using antiquated processes and technology.

Here are four tough questions enterprise developers should ask themselves when evaluating their IT culture, their own path to innovation and their own value in the field:

Question 1. What Am I Working With?

The Java stack is a huge collection of standards and class libraries, and then there are practical sets of tools Java developers use, like Eclipse, ANT and Maven. Visual Studio is the center of the .NET universe, but there are a huge set of classes, frameworks and SDKs to choose from.

But development practices have moved on. Being lightweight and agile is most important. You can't innovate any other way. There's a huge productivity boon with the shift to modern frameworks like Rails, Django and Play, but most enterprise developers don't get to use them.

Sit back and look at the code you write over a week. Is it business logic? Does it add to the success of the business, and your career? Or are many, many lines of code simply going into boilerplate and plumbing? If you were going to write your own personal app, would you want your code to look like this?

1a. What You Should Be Doing

If the answer is that you would do something different for your own app, look for opportunities to introduce new frameworks into your organization. Start with a project that isn't mission-critical. Demonstrate success and be the champion of change.

Question 2. How Often Do I Put Code Into Production?

The development world has moved from a planet of 12-month waterfall releases and deployment cycles to a galaxy of continuous delivery.

There is a bigger principle at work than just continuous integration and automated testing. It's rapidly and flexibly building apps that fit client needs and that deliver business results. Startups know smaller and less tightly coupled generally is better, and that lesson is important for enterprises, too..

2a. What You Should Be Doing

There are several takeaways here.

Read The Lean Startup by Eric Ries. Don't dismiss this as just a book about startups. It's about running projects with a relentless focus on testing for success or failure. You've got a browser open. Order it now.

In the meantime. analyze where you are as a professional in this evolution. Don't be caught back with the old school.

If it's in your power to choose, make sure your projects are leveraging small, agile teams of developers, designers and analysts. Don't stop there, though. Bring in any department that can contribute.

Can you, for instance, push out small feature changes for rapid feedback? It's better to err on nimbleness than on deliberate and top-down. Navigate to a point where you can craft a new feature in a matter of hours, then listen to the audience, revise and go live on the run.

Granted, you can't upend the status quo singlehandedly. Ries offers some great pragmatic advice on how to accomplish change one project at a time. With your help, as soon as your company experiences the benefits of early and regular feedback on IT projects, it will begin to think of rapid development as an opportunity rather than a risk.

Question 3. Is My Organization A Laggard?

Your customer is the business' end customer. Don't forget that. Customers expect to be able to use the latest appropriate technology in dealing with the business, which means you need enough elbowroom to deliver that experience.

Give thought to the hoops you need to jump through to deliver innovation. Needlessly long processes and stultifying standards are the enemies of a healthy development culture. Legacy policies weren't intended to limit innovation, but some do exactly that. Most policies were written before mobile apps, for example, existed. Challenge the conventional wisdom.

3a. What You Should Be Doing

Just to take that example, are you working on mobile apps? Are they social? Do they serve all of the major mobile operating systems? Enlist designers and user-experience experts to avoid developing to a detached, early-stage mission document.

Again, take small steps that meet organizational goals and market needs. Remember that you'll have to do battle again, so back up successes. Show adoption. Show improvement. And most of all, show what changing your organization from a laggard to a leader can mean for your customer and the business.

Question 4. Do I Have A 2002 Or A 2012 Resume?

For the sake of argument, let's say you work for a company that sees these ideas as heretical. You want to be first to realize that you don't belong there.

Here's an experiment: Picture your resume in your mind. Do you see a finely printed document in a serif font on bone-colored, textured paper? Yes? That's a problem.

Your resume is a browser search. It's your LinkedIn page. It's probably your Facebook page (which should give a lot of people cold sweats).

Of course, you need the best paper resume money can buy, but that's a formality. Your image begins forming with what you attach to your email or an employer's careers tool, You can't control every instance of when you pop up online, but where you can, you should. LinkedIn profiles (as should all resumes) tell the reader where you're going, as well as where you've been. So tell that story.

4a. What You Should Be Doing

Make sure you are communicating your capabilities, such as using open-source tools, frameworks and libraries. Contributing to these projects.

Don't hire technical staff without some sort of footprint on Github. It signals that they are paying attention to the changes in the industry and keeping their skills sharp. It shows they work well with others, have great self-direction, and can rally around a shared purpose.

Github projects don't have meetings. They just do. I want to hire developers who do things, not those who sit in meetings.

Go beyond code confabs by getting involved in user groups. This says you passionately believe in something. As Fred Brooks, in The Mythical Man Month, relates, there's a huge productivity difference among developers. Those with great skills, who collaborate well with others, produce so many more quality features than those who don't.

Hire for passion. Passion makes game-changing apps.

Do you like what you see when you search your name? If yes, fantastic! Connect with me on LinkedIn, I'm always looking for developers like you.

If you don't like what you see, find a project to get involved in. Pick up a new language like Ruby, or Node.js, or a new framework build using your current language skills. Contribute code. Connect with a local user group. Network, and just do. That's what makes a great developer.

Summary

So that nets it out. I challenge you to sit back and think about these four questions. 

The biggest complaint from developers looking for opportunities to elevate their career is, 'My company would never allow that.' More often than not, experience has shown me that the reason companies say "no" to change is because they don't fully understand alternatives to status quo.

It's up to you to present these alternatives, and do it in an intelligent way. What are you waiting for?

 

Image courtesy of Shutterstock.