As the old Faces song "Ooh La La" goes, I wish that I knew what I know now when I was younger. Back then, I simply loved to code and could have cared less about my "career" or about playing well with others. I could have saved myself a ton of trouble if I'd just followed a few simple practices.

FEATURED RESOURCE

Presented by Citrix Systems
10 essential elements for a secure enterprise mobility strategy
Best practices for protecting sensitive business information while making people productive from
LEARN MORE
1. Take names. I was really focused on computers early in my career and considered people to be minor annoyances who kept me from being one with my beloved machine. OK, I'm exaggerating a little. Despite meeting many industry luminaries and people that would have been worthwhile to befriend, I didn't keep any business cards. I didn't bother to remember their names and never checked in on them. I only went to user groups (there wasn't meetup.com when I started and it wasn't a big thing for a while after) when I needed a job.

I realize the concept of needing a job seems a little quaint to some of you younger developers. But take it from me -- there've been times when merely saying you're a developer and knowing basic syntax and how to search (there was no Google when I started) was not enough to find immediate employment. There was a time when developers actually called headhunters versus being spammed by them endlessly. This will happen again, eventually.

More important, a lot of developers who were more skilled than I am have had far less interesting careers and less success because they never put themselves out there. They never met the right people at the right moments. Hey, timing and luck are great, but you also make your own opportunities. The first nine times you go to a large gathering and no one speaks to you and you're left with all the perks of being a wallflower are practice for the 10th time when you meet someone interesting.

Also, take note of your peers. If you're an early 20-something, chances are you have no real power or influence, and neither do your peers. In five to 10 years, that will all be different and the person who you ignored because they were boring and couldn't help you will be the person who could have won you an important opportunity.

2. Problem solving. Luckily, this came pretty naturally to me after a while, but early on it was a struggle. The trick is tonever fall in love with any one theory of the problem. Pick three theories and go about proving them wrong rather than trying to prove yourself right. Also, gravitate toward alternative theories. If something says there is a port conflict and you can't find any port conflict, then maybe you're connecting to the wrong network device or an unassigned IP address, and the error is bogus.


Problem solving is essentially the same thing you learned in abstract in seventh or eighth grade or whenever you learned simple algebra. Remove all of the variables that you can, then solve for x.

3. Pick your language or other technical specialties based on the market and your career goals. Sure, you want to do what you love, but really is Scala (insert other language name here) your real love in life, to the point where you are willing to tie your success or failure to it? A better reason would be that it is a smaller talent pool and you might be able to make more money doing it and you know that the finance and scientific community near you is big enough and using it avidly. (It also might be you want to work for Typesafe.)

Either way, pick rationally rather than based on some weird zeal for a syntax. Hadoop is wicked cool, that's a fact. However, analysts are predicting the market will grow several times in the next couple of years, and there is a huge uptake. Companies are building out major infrastructure in a way I haven't seen since the '90s. I think PaaS is awesome, but I do not see tons of business opportunity for developers here. Publicly show passion and enthusiasm, but privately make this a cold, hard calculus and business decision. Your favorite technology will be dead probably before the end of your career anyhow.

4. There is relatively little real innovation in the software side of the industry compared to popular perception. Most of us who have done this for more than five years have already watched all the vendors rename everything and sell it as new at least once. Anyone working for more than 10 years has seen it a few times. When you go into a meeting with a bunch of old people, realize that they roll their eyes at many of the things you think are new. There are some innovations, but those are usually combinations of previous technologies. While Hadoop may be hot, HDFS is a distributed filesystem and distributed filesystems have existed for decades.

RECENT JAVA HOW-TOs
on target
Stability patterns applied in a RESTful architecture
ChoiceFormat: Numeric range formatting
Google Go
Fast guide to Google Go programming
5. Think in terms of a career, not a series of jobs. When I started I job-hopped for relatively dumb reasons: I didn't like that I was put in a cubicle, I could get an extra $5 per hour, and so on. This would come back to haunt me during the dot-bomb. At the same time, I usually failed to pick jobs for the best reason: What will help me progress in my career? Sometimes that means taking a job for less money but more responsibility or better opportunities. I probably still have put in my time at big companies -- then quit working for them sooner. It's relatively hard to make an impact from the inside of IT in a big company and opportunities are frequently limited.

6. Work more than 40 hours per week. I don't mean you should work in a sweatshop or run yourself to death, but make a personal investment in your career. If the only time you learn something is on your boss's dime, then prepare to have your options limited -- your boss isn't going to train you to make sure you have options.

7. Programming is not hard unless you make it hard. I disagree with Joseph Gentle. People are still messing up software development in the same dumb ways since software separated from hardware. Programming simply requires reading, concentration, and logic. Luckily, plenty of books, courses, and patterns can tell you how to do all of that (see No. 6). Coordination with other people on any scale? That's hard.

8. For Zod's sake, learn to communicate. If you are unable to write properly in English (or the appropriate language for your community), take a writing course. If you are unable to give a talk, get over your stage fright, take a course, practice in front of a mirror, and/or attend some meetups and learn. This is probably as important as writing code.

Now it's your turn. If you're more than five years in, what do you wish you'd known at the start? If you're less than five years in, what advice have you found helpful?

Link ~> http://www.javaworld.com/article/2597522/learn-java/what-i-wish-id-known-starting-out-as-a-programmer.html