Five handy tips for the newbie software developer

I've been in software development for about a dozen years, with gigs ranging from dot-com startups to Microsoft's main campus. I don't claim to be a wily veteran or industry expert, but I recognize the patterns across companies and can offer some advice. Keep in mind that while I lean on generalizations I know there are exceptions to every rule. Your mileage will vary.

Tip #1: Reject the classifications that others place upon you.

It won't take long for you to pick up on this: people in the tech industry — recruiters, developers, and managers alike — tend to make hasty assessments of your aptitude. If your portfolio includes a decent-looking web site, don't be surprised when they classify you as a "UI guy" (pardon the gender type). Conversely, if you have a knack for algorithms don't be surprised if they assume you struggle with creative tasks. On several occasions I've worn the albatross of the "UI guy" distinction. It took a while to convince my peers that, yes, I could understand their oh-so-complex C# code.

To be clear, these assumptions are not necessarily based on ignorance or malice. After all, it's pretty apparent that the general mindset of a hardcore low-level developer is quite different from that of a designer or user experience (UX) expert. But that doesn't mean you aren't capable of being a hybrid. You don't have to accept the tendency of others to box you in.

Some developers actually prefer to set those boundaries for their own sake. I can understand that, especially if their company would exploit the situation. But a good developer wants to contribute to the fullest possible extent, whether it calls for skills explicitly stated in their job description or not.

Tip #2: Get over yourself.

The biggest challenge you'll face as a developer will not be technical — it'll be the ongoing struggle to keep your ego in check. There will be times when you finally hit your stride, when you finally understand the complexities of an application or language. Your chest will swell with pride, you'll walk around with an extra bit of giddy-up. Those moments of exhilaration are important and memorable and necessary. But there comes a point when the self-congratulatory parade should end, when you should come back down to Earth and blend in with the common folk.

What fuels the insufferable ego of the typical developer is up for debate, whether it's insecurity or overcompensation or something else. What's important is this: you will encounter peers who decide you're inferior for any number of baseless, illegitimate reasons. Some will take it to the extreme, dismissing you based on which technologies, applications, or languages are in your repertoire.

Firsthand experience: a developer admitted to me that he checked with my recruiting agency a few years back to make sure his billing rate was higher than mine. His refreshing honesty doesn't excuse his smug jackassery, but it illustrates my point that many people grossly overestimate their ability to assess others.

On a related note, developers have a habit of dismissing non-technical people as thick-headed and declaring their criticisms as invalid. Here's the reality check: if people think your application falls short, it doesn't matter what technical issues you cite as an explanation. Set aside your ego and make it right.

Another reality check: 999 times out of 1000 your brilliant work is only possible because someone else provided the tools and technologies. Quite often that "someone else" is humble and accessible despite being worth millions (if not billions) to their company. Follow their example.

Tip #3: There are certain business realities we must accept.

In a perfect world, projects would follow a linear path: stakeholders meet to discuss their ideas, then Marketing shapes those ideas into a defined offering. PMs and tech leads collaborate to forge a set of requirements, from which a development strategy emerges. Once a consensus has been reached on the timeline and resources, the development can begin.

And I couldn't write that last paragraph without smirking. Nearly every company I've been involved with has asked developers to build something that hasn't even been fully defined. Sometimes it's a result of management not understanding how changes can sabotage development. Sometimes management does understand that but timelines can't slip any further. Sometimes they just want to see some sort of traction, real or perceived.

There really isn't a bad guy in this scenario, it's just something we must accept. Great ideas don't always come early in the process. Sometimes money runs out. Sometimes competitors come out with products that render our efforts obsolete. Sometimes people are just plain lazy and/or piss-poor planners. The key is to recognize which of these things you can influence. If the answer is "none" so be it.

Tip #4: Don't hope for work-life balance. Insist on it.

Developers have a tendency to over-indulge in their craft. If we're neck-deep in code it's easy to forego meals, appointments, social interaction. We're sitting most of the day and we're in a zone, and as such it's not readily apparent to others that we're taxing our bodies from the inside out.

The good news is we're starting to realize that doing our best work and maintaining our health aren't mutually exclusive concepts. Having the opportunity to "recharge the battery" is not a luxury or a perk, it is something we must insist on. A foolish employer will equate a developer's contributions with the number of hours logged per week. A smart employer knows a burned-out developer is more of a liability than an asset.

Wise is the company that sees "work-life balance" as a mutually beneficial necessity, not just lip service.

Tip #5: Speak up.

It's easy to understand why developers often struggle with the whole "communication" thing. Our minds are focused like a laser beam on implementation, and as such we have a tendency to neglect the importance of discussion. Therefore, as a newbie developer you may have moments where you feel like you're talking to yourself. You send an E-mail seeking clarification or sharing ideas and the response is... nothing. Crickets. Tumbleweed.

Believe it or not, that moment is critical for you. You can do what many others do — take the silence as a hint to put a sock in it. But if there's one thing to take away from this article it's this: don't suppress your contributions just to keep the peace. SPEAK UP.

If you sense that a solution or architecture doesn't quite cut it, say so. If you feel an application needs improvement, say so. If you don't have the silver-bullet solution, there's still value in voicing your concerns. If 8 out of every 10 issues you raise are old news, that means 2 of them weren't previously addressed. Personally, I'll gladly take a little "white noise" from a newbie if it comes with a fresh perspective now and then. Beware anyone who ever hints that your enthusiasm is somehow "rocking the boat."

Just make sure you're voicing your concerns for the right reasons. If your intent is just to make yourself look smart, people will see through that. If you're firing off questions that could just as easily be answered with research, that won't sit well either. But if your intent is to improve a product or process, and if the answers can't be found in a document or search engine, by now you know what to do: SPEAK UP.