Developer

10 tips to go from a beginner to an intermediate developer

Having trouble finding tips for beginner developers who want to take their career to the next level? Justin James aims to fill this information gap with his suggestions about how to make that leap.

During an e-mail exchange with a TechRepublic member, he mentioned that blogs, articles, and magazines aimed at developers seem to fall into two categories: items for beginners ("Hello World" type tutorials) and items for experts (MSDN Magazine). It's a really good point; there's very little information out there to help a developer make the leap from beginner to intermediate. Here are 10 things you need to do to make that transition.

#1: Learn another language

It doesn't matter which language you learn, but learning another language (regardless of how many you already know) will make you a better developer. Even better is to learn one that is significantly different from what you already use on a regular basis. In other words, if you are a C# developer, learning VB.NET or Java will not help you as much as learning Ruby or Groovy.

And when I say "learn another language," I mean really learn it. Learning a language consists of three realms of knowledge: the syntax, the built-in operators and libraries, and "how to use it." The first two are easy; I think that an experienced developer can pick up enough of a language's syntax to maintain code in 30 minutes to a few hours depending upon the language. The operators and libraries are just a matter of slowly accumulating knowledge and being willing to check reference materials until you memorize what you need to know. But it's the third item -- "how to use it" -- that can only be learned over months of working with a language and that's where the real magic happens. I suggest doing a project that is well suited for that language and doing it in that language's style.

Truly learn another language, and I promise that your abilities as a developer will start to blossom.

#2: Learn advanced search techniques, tactics, and strategies

More and more, being a good developer is not just about your skill, but your skill at finding information. Simply put, modern languages and development frameworks are too large for most people to remember much of them. As a result, your ability to get work done is often dependent upon your ability to perform research. Unfortunately, knowing how to find accurate, high-quality information is more than just heading to TechRepublic for the answer or typing a few words into your search engine of choice.

"Techniques," "tactics," and "strategies" may sound like synonyms, but they are not. The techniques you need to learn are the advanced search systems of your favorite search engine; you need to learn things such as the Boolean operators, how to filter results (negative keywords, domain restrictions, etc.), what role word order plays, and more. So essentially, RTFM.

You should learn tactics such as knowing how to approach any particular search and knowing what you should you actually look for. Errors are easy -- just look for the error code -- but keyword selection on many searches is much more difficult.

With regard to strategies, you need to learn things such as what search engines to use (hint: general purpose search engines are not always the right answer), which sites to visit before going to a general purpose search engine, and even which message boards to post to for help.

#3: Help others

Teaching others is invariably one of the best ways to learn anything. It is understandable to think that you don't have much to offer because you are relatively new to the development field. That's nonsense. Remember, everything you know you learned from someone or somewhere; so try being the someone that another person learns from. Spend a few minutes a day trying to answer the questions on TechRepublic or another site as best you can. You can also learn a lot by reading other members' answers.

#4: Be patient and keep practicing

Research shows that it takes "about ten years, or ten to twenty thousand hours of deliberate practice" to become an "expert." That's a lot of time. Furthermore, becoming an expert does not always mean doing the same task for 10 years; it often means doing a wide variety of tasks within a particular domain for 10 years. It will take a lot of time and energy to become an "expert"; working as a developer for a few years is not enough. Want to become a senior developer in your early 30s? Either start your education/training sooner or be willing to do a lot of work, reading, and practicing in your spare time. I started programming in high school, and I devoted a lot of off-hours to keeping up with the industry, learning new skills, and so on. As a result, I hit the intermediate and senior level developer positions significantly earlier in my career than most of my peers, which translates to an awful lot of money over time.

#5: Leave your dogmas at the door

Time for some brutal honesty: Beginner developers probably don't know enough to state that there is One Best Way of doing something. It's fine to respect the opinion of a friend or an authority figure, but until you are more experienced, don't claim their opinions as your own. The simple fact is, if you don't know enough to figure these things out on your own, what makes you think that you know which "expert" is right? I know this sounds really harsh, but please believe me; I have met far too many budding developers who had their careers or their growth set back years because they got hung up on some foolish piece of advice or followed some "expert" who really didn't know what they were talking about. A great example of this is the abuse of object-oriented architecture. For example, many beginners read some information about OO, and suddenly the class diagrams to their simple applications look like the Eiffel Tower.

#6: Learn a few advanced ideas in-depth

Much of what goes into being an intermediate developer is having a few concepts that you are really good at working with in code. For me, it is multithreading/parallelism, regular expressions, and how to leverage dynamic languages (and the last two are fading as I get farther away from my Perl history). How did this happen? Multithreading and parallel processing came about because I read articles on it, thought it sounded interesting, and figured it out on my own; I keep writing apps that use those techniques. I had a job that used a ton of regular expressions in Perl. Also, I ended up writing my own e-commerce engine with a template processing engine and built-in database system; then I spent nearly two years working on it.

Find something that has you really hooked. It might be image manipulation or maybe database design or whatever. Even if you're an entry-level developer over all, try to become an expert in at least one area of focus. This will get you into that intermediate level quite quickly, and once there, you will be halfway to expert.

#7: Learn the basic theories underlying your field

It's one thing to write "Hello World," but it's another to understand how the words appear on the screen. By learning the "groundwork" that supports the work you do, you will become much better at it. Why? Because you will understand why things work the way they do, what might be wrong when things are broken, and so on. You will become better by learning what happens at a lower level than your work.

If you are a Web developer, read the HTTP RFC and the HTML spec. If you use a code generator, really look at the code it generates; if you use database tools, take a look at the underlying SQL it generates; and so on.

#8: Look at senior developers' code

At your job, take a look at the code the senior developers are writing and ask how and why things were done a particular way. If you can, check out open source projects as well. Even if other developers don't have the best coding habits, you'll learn a lot about how code is written. Be careful not to pick up bad habits along the way. The idea here isn't to just blindly imitate what other developers are doing; it's to get an idea of what works and what makes sense and try to imitate it.

#9: Learn good habits

Nothing marks an inexperienced coder like stupid variable names, poor indentation habits, and other signs of being sloppy. All too often, a developer learned how to program without being taught the less interesting details such as code formatting -- and it shows. Even though learning these things will not always make your code better or you a better developer, it will ensure that you are not viewed as an entry-level developer by your peers. Even if someone is a senior developer, when variables are named after their 97 cats or their functions are called "doSomething()," they look like they do not know what they are doing, and it makes their code harder to maintain in the process.

#10: Have fun

Want to be stuck on the career treadmill? Hate your job. What it takes to move up in this business is not merely dogged determination to bring home an ever growing paycheck but an actual enjoyment of your work. If you do not like your work and you are a junior developer, what makes you think that being an intermediate or senior developer will be any better? Change jobs or change careers. On the other hand, if you love the work you are doing, great! I guarantee that you can become a better developer if you keep at it.

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.

---------------------------------------------------------------------------------------

Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!

About

Justin James is the Lead Architect for Conigent.

67 comments
Arag1989
Arag1989

I'm actually a beginner developer in the industry, and I think that your article it's very nice and motivational.

Because, in my personal experience, sometimes it looks impossible to step over to intermediate developer from beginner, I means all the developers of your team in much of the cases they usually have the double expertise than you, so it's very difficult to offer some advice about some topic.

But the point it's that I liked a lot your post and I loved the last point, have fun! I sometimes forget to have fun because I'm worried about some topic that I don't know.

Regards!

DavidHiltz
DavidHiltz

Number 3 is a great comment. Not only does that help you teach the code so you know it better yourself, it gives you some good references to use in a resume or contact later. Networking is huge when it comes to learning and growing and basically surviving in business. I would love to advance my language skills as I'm just starting out on Java, but when I learn more I'll be sure to pass it on.

http://www.altsrc.net 

Hozycat
Hozycat

Well, tick tick tick, all correct. :) Just check my reply to Timothy for some comments about it… feel free to add your own comments if you want as I'm not infallible myself and could make a mistake or forget to mention something :)

http://www.teachandlearn.ca

bigtechideas4
bigtechideas4

I all want to add some things in this great list..


“Right” is Not Always Right

Never Stop Learning

Be Prepared to Give Up Sleep

Find a Routine

Exercise Your Mind and Your Body

parastoooo
parastoooo

Hi

Thanks for the nice article.I graduated 2001 and always working as junior developer in academic projects with no money, 3 years ago I worked so hard to learn java and found a job after a year working in a charity project ,I found myself  again in a crappy project in a office with me  and none technical guy and had to use c# ,I decided at least  to use my training budget to learn business analyst skills, my contract will finish in 10 days ,I am looking for Business analyst job but no success ,I do not want to start a junior programmer job again,any advice?what kind of job I can go for?

yoginder bagga
yoginder bagga

Hi I was just looking for some information/things i am missing to being creative in the programming I've started. And i got your article. Some tips are good Thanks

jimiwa
jimiwa

I agree with most of what you're saying. I do feel it is ideal to have a job that one enjoys, as I do, because I went into programming at an early age and like to program. But not everyone is lucky enough to be able to find a job, what to speak of finding a job that they like. Therefore, when you imply that someone who doesn't like to program should change jobs, I think you are missing the point that many people have a hard time getting a job in the first place, and even among those who have jobs, most people don't "enjoy" their job. So I think it is unrealistic to say that if someone doesn't enjoy their job (especially in a field like computer programming) they should find another career. A lot of people who decide to get a degree in a field that they enjoy learn the hard reality after they graduate that there are not enough jobs in that field, even if they were decent students, and some of them know there aren't many jobs in that field, but go after it anyways. It's great to pursue one's dreams, but sometimes the hard reality is that most people can't make money off of their dreams. I figure if a person doesn't enjoy programming, but actually can do well enough at it to hold down a job, such a person is fortunate to be in a field where there is a lot of employment and good salary and should keep that job unless a better employment opportunity comes up, which is usually unlikely. I'm not saying that money is the most important thing, but there has to be a practical balance between enjoyment, salary, and job stability - and one should choose the career that they are able to get that strikes the best balance with these 3, depending on which of those 3 factors matter or are the most important to the individual. Some people would rather make more money at a job they don't enjoy, some would rather have a job that they like and make less, probably almost everyone wants a job that they immensely enjoy and make a lot of money at, but that's rare. Most people are not fortunate to get a job that's great in every way. But aside from that, I agree with what you are saying.

yordan.georgiev
yordan.georgiev

The number 10 should be number 1. Development is about creativity and invention. Without motivation one could expect only poor results ...

jck
jck

Justin, Here's a dilemma: What I like: I love programming. I love making a language do what it's supposed to, make it do what it should but doesn't, and make it do what it was never supposed to do but can be made to do. What I don't like: The technically ignorant beancounters and suit-wearing egotists thinking a number in a spreadsheet or a deadline they didn't plan for is when a software project can be done by. For instance, I was handed a project to do on an existing platform at my job less than a month ago. I haven't programmed in the language in 8+ years, never programmed on the deployment platform or using any of their libraries. Yet, they wanted a fully functional app within 2-3 weeks. And, they didn't want to hear "no". You think my best route to success in the field that I love is to go independent and consult and write my own software systems I can peddle or sell-off to a bigger software house to reach the successes that I want? I don't hate working with tech or doing tech work. Just the arenas in which I've had to apply my trade and the politicos that often come along with it.

oldbaritone
oldbaritone

Nothing SCREAMS "Newbie" like Spaghetti Code. When you try to "do something" before you understand the real goal, and the steps to reach it, it always shows up in the code. "Oh yeah - we needed to do x before we started y." Sorry OOP folks - so the translation in OOP might be "Oh yeah - we have a 'wrench' but we need a 'metric wrench' so we'll have to create a 'wrench-to-metric wrench adapter'" Overloads on top of Overloads, hidden-hidden-hidden attributes in a convoluted mess. If you'll spend 10%-20% of your time planning, defining, and creating reasonable expectations, you'll end up spending 50% less time coding (or more) and 50% less time debugging. (or more) End result: More productive, less effort, fewer bugs. Planning pays off. Noobs don't plan. (or not enough) It always shows.

sleepybrown2003
sleepybrown2003

i think i like this article........is kind of motivating.............thanx james

sergini
sergini

Thank's for your Tips! Nice, it's gave more confidence to the person who reads them

marco_faustinelli
marco_faustinelli

Some time ago you asked a question about intentions for the new year. My reply was: "I am going to learn Javascript". I am now at step 3 in your ladder (HOW to use it). I am studying code from some open source project and planning to contribute; indeed these projects are mostly of awesome complexity! My 5-cents is: Writing real code that proves to be useful to someone else should be the indicator that level 3 is reached, but that's harder than what it may seem at the begin of the process :-) A nice day to all of you, Marco

blcat
blcat

understand what are you coding for =)

shakespear.joy
shakespear.joy

i think your views are right but when still in the starting years can somebody tell me how to pass written exams ? !!!!!!!!! acquiring knowledge is one thing but passing exams and obtaining some degree by some univ. is a different story altogether!

Kinetixx
Kinetixx

What would you recommend as the more marketable Web development languages and/or frameworks with the shortest learning curves? Clearly there is no one "correct" answer, however I seek this advice after a 13+ year career in systems administration (particularly Microsoft file, web, SQL and Exchange servers, and some Linux) that i must transition from after a handicapping injury. I'm already quite good with HTML, CSS, design layout, PhotoShop, mathematics and logic. I have some familiarity with JavaScript and ASP, and love the puzzles that programming offers. Again, my goal is to become the most marketable in the shortest amount of time. All advice is much appreciated.

fewiii
fewiii

Whatever language you're learning (or know), read, practice and experiment. Then do it some more. Modify the relatively simple code printed in books or included on Cd's to make it more functional (or even change the functionality). And don't be afraid to try advanced things -- that's the only way you'll "get there". Also, I've found that learning the "internals" of the platform you are developing on or for can be invaluable.

bern.ruelas
bern.ruelas

Good stuff Justin, thanks for the help. As a real newbie I found that making a cheat sheet of commands for my "new language" certainly speeds up the coding process.

doug
doug

Justin, THANK YOU for this list - 100% inspiring. It seems that there is TONS of information out there for the very beginner OR the big time expert, but not much for those needing advise help them scratch and claw their way up out of the "newbie pit". Having a good attitude is also a plus, you are more apt to be mentored from those that offer their time.

milesgibson
milesgibson

"You are who you hang around with" -- associate online or otherwise with others who have more experience than you do. Ask lots of questions. Makes notes and a responsitory for code snippets etc.

Osiyo53
Osiyo53

Looks like a good list to me. Not that I'm any great shakes as a programmer. I do program for a living, but in a highly specialized field which has its own unique requirements and expectations. I program DDC devices (dedicated computers in a "Black Box") which in turn control real, physical mechanical and electrical equipment. Originally done in a programming style called "ladder logic"; these days the programming languages (mostly proprietary) look more like Basic, Visual Basic, C and it's cousins, or Java. Throw in regular Java, HTML, SQL, etc which are used on front end display and control consoles (which are regular PCs). None of which make me a programming guru by any means. In my field it is important to be an "adequate" programmer, but MORE important that you have a mechanical or electrical engineering background and have an excellent grasp of the science and technology of the equipment that you'll be controlling. The actual apps we develop are normally neither long nor complex (from a programming point of view). The general practice in my field is to go for shorter, simpler apps, that accomplish a few functions. And if more is needed, to create multiple, discreet and independent apps, each of which will run independently of the others (altho they might share information) within their own memory spaces. In any event, I'd hope that any young developers out there would pay heed to your advice. Its good. The learning of alternate programming languages is important. For a number of reasons. Not the least of which is that I've experienced numerous occasions where some technique or method I learned in an alternate programming language could be advantageously used in some other. Besides, one doesn't ever really know when or if that knowledge of another language might come in handy. For instance, years ago I learned (just as a hobby) VB. At the time my bread and butter programming languages were QB and Clipper. But then at the place where I was working we started using a certain proprietary and specialized programming language which was so similar to VB, that learning it, for me, was a snap. Likewise, some years ago I learned to be proficient (but not expert) in Java. But then let it drop as at the time I wasn't into Web apps at all. But here recently where I work we started working with platforms which have what is essentially an embedded Java framework, and all programming for these devices is in Java. Not just for web apps, although these devices besides their other functions are also web servers, but ALL programming of ALL functions is done in Java. An attempt by the manufacturer to make these devices OS independent while using a common programming language that is free and open source. In fact, one can buy these control devices in the form of a "black box" with microprocessors, I/O controllers, memory, etc ... which have an embedded form of Unix as the underlying OS. Or one can buy a software version of same written to run on a standard Windows based PC. And control programs you've developed run on either, unmodified. Because said programs are in standards compliant Java. Add, its always a good practice to be exposed to new ideas, techniques, and so forth. It keeps one's mind fresh and agile. The learning of basic theories is something I couldn't agree with more. The only guaranteed constant in life ... is that things change. But if you know not only the "How" and "What" to do, but also the "Why" of it ... adapting to change, or being able to figure out what a problem is will only be that much easier. Learning from senior programmers is also a good one. We have one such where I work whom I'm always asking questions of. Often, I'll look at some original code he generated, and wonder why he did something this way as versus that (some other way that looks to me to be a better method). All too often, often enough to keep me from ever getting a fat head, I find out that he's got a darn good reason for doing what he did, the way he did it. Often, it's some aspect or consideration I never even thought of. Something he learned or figured out via the old "school of hard knocks". His answers as to why are not always insights into some new, fancy algorithm, or advanced line of thought or methodology. Chuckle, sometimes its as simple as, "It's less obfuscated code. Plainer, simpler. Done this other way you are suggesting, there is more likelihood that another programmer using that function in his application is gonna make an error or screw it up. My way is more immediately understandable and more easily re-usable by others." On another occasion he explained that for a certain function he went about coding it a certain way simply because the way the resulting info was presented to the user was more intuitively understandable to them than any other way he'd seen. In this instance, I THOUGHT I had the better idea. And did it differently. I was wrong. My way looked better to me, and seemed to be perfectly understandable to me. But in field experience showed that my way resulted in more complaints and misunderstandings than his way. In other cases, his reasons were more obscure and technical. A case in point. A certain routine he wrote which had a built in time delay in it (a Wait). I saw that and thought about it and thought about it. Could not figure out why he had that wait statement there. Finally asked. He explained that the main microprocessor in the target device was so fast that if one did not slow down the program execution, it COULD outpace the board's I/O bus and their independent processors in certain situations. Old data was overwritten by new data before action was ever taken on the old data. Occasionally, at unpredictable intervals. And sometimes registers or other memory locations went into overflow conditions. System might work for an hour, or days. But sooner or later you got a crash, abort, or other adverse result. Usually in the middle of the night or some other most disadvantageous time. Wasn't an unrecoverable error. System would just reboot the app. But this tended to irritate customers. That kind of thing is NOT something you learn in books or in a classroom. It's not that this fellow always has the better answer and method. I've managed to teach him a thing or two. But nothing as compared to what I've managed to learn from him.

kishorekoney
kishorekoney

Pretty good ... Selecting the right mentor early in your career helps a lot in Successful Career growth. Find your Mr.Dependable right now.

jslarochelle
jslarochelle

My quick list: Code Complete Design Patterns: Elements of Reusable Object-Oriented Software If you want to program in Java you must read Effective Java (2nd Edition) If you want o program in C++ make sure you read Scott Meyer's Effective C++ serie. Start with: Effective C++ A good book on algorithm, compilers, ... Books give you a break from the PC screen and the keyboard and are really great to carry around on the bus. JS

Tony Hopkinson
Tony Hopkinson

disagree with there. Develop and develop and then develop some more. Each successive task, learn fom what you did right and what you did wrong last time. The more you do it, the quicker you catch your mistakes. Have no doubt there will be many, some only discernible in hindsight. Code that seemed 'ideal' six months ago now looks like the deluded scribblings of a moron. If it still looks good, change careers, or at least find a new role, switch languages or environments, work on a different sort of application. In our job, change is a given, if you don't, can't or won't change along with it, do something else, you will always be a junior.

Justin James
Justin James

If you knew someone trying to make the leap from junior developer to intermediate, what would you suggest that they do? J.Ja

Editor's Picks