10 steps to becoming the developer everyone wants

You're a crack coder and people depend on you to solve their issues. Still not enough? Here's how to hit that next level

You thought it was all about programming skills. But you were wrong!

Great code is fine, yet commanding better work and a higher salary depends on ensuring more people know who you are. In other words, you need to market yourself. Here's what seems to succeed.

[ Epic codefest: 7 programming languages in 7 days | Learn how to work smarter, not harder with InfoWorld's roundup of all the tips and trends programmers need to know in the Developers' Survival Guide. Download the PDF today! | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]

Developer tip No. 1: Blog

Set up a blog, and post more than once a month. Do real research and make sure you don't sound stupid. Seriously, learn to write. Do the stuff your grade-school English teacher taught you: Create an outline, draw a narrative, check the grammar and spelling. Then, with great sadness, simplify it and shorten it to the point enough where someone scanning it will have an idea of what it's about. The Internet does not tolerate nuance (nor does my editor).

Developer tip No. 2: Go open source

Don't believe the lies about open source. The younger among you may not remember the days where a developer could actually be unemployed, but even during the darkest stretches of the dot-bomb recession, all of the developers of the open source project I started were quickly back at work. Just make sure the open source code you produce reflects the kind of job you want. I wanted to solve hard problems with the simplest solutions possible, but I've interviewed developers who, as was clear from their open source code, wanted to complicate simple problems. Believe it or not, there's a market for that, but make sure your code reflects the market you're in.

Developer tip No. 3: Not six months, not 10 years

Don't switch jobs every six months. Seriously, the end of 100 percent developer employment will come again. When that time arrives, nothing will haunt you more than job-hopping. On the other hand, don't stay at the same place doing the same thing for 10 years. You'll become insulated and institutionalized. To stay valuable, you have to be familiar with more than how to code IBM's stack while at IBM in the IBM way. I haven't hired anyone who was at IBM or a similar organization for more than a year or two. They usually impress me in the interview but fail the programming test.

Developer tip No. 4: Eye on the new stuff, hands on the practical

Exceptionally young developers have a tendency to work on the shiny. Ruby is probably my favorite programming language, but it doesn't pay (on average) as much as Java, and the market is smaller. This may not always be true. Scala looks like it's coming on strong, but don't kid yourself about the market size -- it isn't here yet. On the other hand, don't stay still so long that you are the future equivalent of a COBOL or PowerBuilder developer either.

Developer tip No. 5: Write your own documentation

I can't tell you how many times I've worked on a project, only to be pulled into an executive meeting because I wrote a document or presentation they saw and understood. I always begin with an executive overview -- that is, the page you really have to read -- while the rest boils down to details in case you don't believe me. The question is: What does a very busy person have to know about the topic if it's not the only thing they're working on? What most managers want to know: Who can drive this to completion and won't BS me about how it's going? Write that way.

Developer tip No. 6: Brevity is the soul

One thing you learn about management right away is that the people who know what they're talking about tend to give shorter, more concise answers. When the responses grow long and complicated, it often means they don't know or won't commit. You also learn that tone is often inversely proportional to the importance of the topic. When really bad news hits, someone comes in the office, shuts the door, and whispers. When something is not inherently important but bothers someone anyhow, they will try and raise its prominence with an inflammatory tone.

Don't be that guy. Know what you're talking about, figure out how to summarize it, and have the details, but don't load every sentence with minutiae and don't build up the hype -- the sky probably isn't falling (but maybe someone should take a look at Jenkins because we haven't had a good build in a while). When all else fails, lead with the money. Make sure your numbers are well thought out, plug them into charts, and clearly demonstrate that one point is superior to another in dollars and cents.

1 2 Page 1
Page 1 of 2
How to choose a low-code development platform