Apps

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.

64 comments
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

Justin James
Justin James

This is an ancient problem. I can tell you this much up front (I'll go more in-depth in an article in a few weeks, I think!): * Being a consultant inflicts you with the same problems of expectation vs. reality, but the dynamics are different. You get paid a lot more, so the clients expect you to be able to work miracles where their ordinary employees fall flat. It's also a lot easier to terminate your contract. With an employee, they might mentor you, wait until your review to let you know they aren't happy and you need to improve, etc. It typically takes 1 - 3 years to lose a job for incompetance, so long as management isn't asking departments to cut headcount. A contractor/consultant, on the other hand, is gone within weeks or months if the performance doesn't match expectations, *regardless of how dumb the expectations are*. On the other hand, you have the freedom to pick and choose your projects, clients, etc., so long as you have a wide enough client base. * Being an ISV is not a walk in the park either. Sure, you're working for yourself. But being a successul ISV takes more than development skill. Do you know how to market and sell a product? Manage a team of people? What kind of software will you write? Remember, it will probably need to be supported. If it is "mission critical" or "enterprise class" software, are you willing and able to be 24 x 7 tech support until you can hire a support team? I've been involved in small consultancies and small ISVs, and while there is potential for great profit, you need to work your butt off. It's great to not worry about the management breahting down your neck, but you have a bigger challenge, which is keeping the customer happy. J.Ja

Tony Hopkinson
Tony Hopkinson

that when the wrist is too tired to wave the wand to get that last tiny bit of magic dust out of it, and make all management's problems go away, a right good belly laugh helps... Trust me, consulting will make no real difference, they'll just lie their arses off until you sign the contract and then blame you. I've even been employed to take the blame... There's nothing you can do except document and refer to the no, then cross your fingers and hope the muppet who set you up has some powerful enemies.

Sterling chip Camden
Sterling chip Camden

It's really a pretty amazing language, and mastering it (which I'm still working on, BTW) leads to a deeper understanding of inheritance, arrays, and objects. These insights apply even to other languages that don't provide those facilities in the same way.

programmer07
programmer07

I taught VB/C#/Intro. to Programming classes at a community college for 3 years. On the first night of class, I made it a point to inform my students that there would be no "traditional written exams". FWIW, I don't believe that selecting True/False, A, B, C, D or None of the above will help programming students write a nested looping structure. I truly believe, the best way to learn to code, is by examing code written by others, and writing code yourself.

Justin James
Justin James

... but your local job listings do. My best suggestion (this quesiton had come up a number of times in this space) is to take a look at the job listings for your local area, find the jobs that sound like they are ones that you would like, and find the common denominators. In general, PHP, J2EE (Java), and ASP.Net all have their advantages and disadvantages. PHP is probably the least complex of the three. There are free tools and development environments for all three that you can use to work with, and tons of online resources to help you learn as well. J.Ja

Tony Hopkinson
Tony Hopkinson

I can (well could) sight read and follow it through. Didn't actually do it though, as you needed the electrical training to avoid blowing up expensive kit, or killing some one. I did a lot of interfacing to Allen Bradley PLCs, I was the odd one out as the 'software' guy. It was interesting to see a different abstraction, and if you want to learn fault finding, you have got to talk to a competent experienced 'tricians, they do it better than anybody. I'd recomend the environment to any main stream programmer, you can learn a lot.

Sterling chip Camden
Sterling chip Camden

I'm surprised I didn't think of that one. A good mentor is probably the most important factor in maturing as a programmer. Often, though, you eventually outgrow your mentor. Then you need to find another one.

Justin James
Justin James

Great one, I completely missed it! I also hear that "The Art of Programming" is good, but I must admit that I haven't read it, despite my best intentions. J.Ja

programmer07
programmer07

"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." I agree completely. Also, if you're a "good junior programmer", accept (if not request) more challenging assignments. Depending on your current environment, there will hopefully be intermediate/senior developers there to assist you when you get stuck. I recall that being mentioned on my first review as a junior programmer...the fact that I always accepted/requested more complex assignments...and succeeded. I think you learn a great deal more when you're forced to do research to complete a task, rather than always completing projects that require no more knowledge than that of a junior programmer.

Vladas Saulis
Vladas Saulis

Additionally: Keep any dogmas behind the door. Be flexible. Learn only from your mistakes. Do not try to learn from others' mistakes - these might not be really mistakes, unless you prove that by yourself :) Read Nietzsche - this will help you to think controversely. Be optimistic - in all aspects. Today you stuck with some chunck of the code - tomorrow you'll find another solution, never mind you've even changed the programming language. Please DON'T read senior's code. It'll really be anything but stylish - just a pure idea... It'll look like senior's being newbe. But that's it. Don't try to be stylish in code. The code doesn't need to have a style. CPUs are indifferent to style. The code must be working. Concentrate on idea. Only idea is worth for code, not theory, nor acronyms. Don't let too deep into three-letter acronyms space - these all are not worth a penny, comparing to Idea. I'm practicing for around 30 years nearby programming area, but sometimes I feel still being newbe. This is somehow better, than pretending to know everything. Encyclopedic knowledge is nothing. Idea is everything.

SObaldrick
SObaldrick

If you have not done any, you will learn a lot about computer hardware and programming best practices (and worst) by programming in assembler. That's how I learnt to program (30 years ago), the hardware has barely changed, and the experience still helps me do my job as a business analyst today. Les.

AhmedAba
AhmedAba

Experience is knowledge. The more knowledge you have the more experience you are. And in order to be an expert you need to improve your learning system, so that when others know one thing from a task you know 10 and keep it and know when to use it. Ahmed.

The Terminated
The Terminated

Work on a certification. I have 3 years of experience in VB.NET and SQL Server, so I'm a beginner. I'm currently unemployed, so I'm working on getting an MCPD: ASP.NET Developer 3.5. I'm almost done with the first Self-Paced Training Kit, the one for the 70-536 exam. Out of the 16 chapters there was only one where I could say, "Yeah, I already know this stuff." There are a few where I said "When will I ever need this?" The rest of the chapters filled in a lot of blanks that I didn't know I had. All of them gave me the vocabulary I need to search for answers. A certification will not make you an expert, but it will show you the gaps in your knowledge. It is especially good for me because I didn't really have senior developers' code to look at. (At my last job, we were all dumped off a mainframe into .NET. I survived the first cut because I had taken VB.NET and ASP.NET at the local community college.)

mattohare
mattohare

I think a difference between novice and advanced developers is the ability to have every action be towards successful completion of the project. Be careful not to add 'cool features' that don't meet the project's end goal. Or worse, put off delivery of the project in time. Document things clearly so all involved (including yourself) can work well with the project later. I'm not saying write books of padding. If you had to work really hard on a particular algorithm, take a few minutes to say what you discovered so it makes sense later.

jreddy
jreddy

No language, technical trick, or methodology will make your life as a developer more pleasant then conquering what is truly the hardest thing about software development: other people. You?re communication and get-along-ness with stakeholders, users, and the ?next guy? will take you much further.

Sterling chip Camden
Sterling chip Camden

1. Create some useful widget or utility and publish the source code online. The public review (or the dread thereof) will make you a much better programmer. 2. Read software development blogs.

jck
jck

I understand the dynamics. Been doing part-time consulting for a while. Just seems like being able to pick and choose my "battles" is the biggest thing. Where I'm at, I don't get project choice. I get told "do it" and that's that, whether I have the skill set or I have to learn it in 2-3 weeks. As for being an ISV, I have no desire to produce enterprise-class software. I'm thinking more of inexpensive, fully-loaded office software. I see office packages out there going for $3k-5k that have crap functionality. I've worked in enough industry and have enough contacts that I could produce something multi-practice (that I already have pretty much designed) and multi-functional that I could market for $1k and then do setups of servers, networks, etc., and make even more. Plus, the business end of doing software for practices like law, medical, accounting, etc., generally means 7am-7pm hours. Not a big deal, since I do about 6:30am-5:30pm as it is now (with the commute). As for keeping a customer happy, I think that it is easier when you go in, get full details of what they want, and can decide whether it's something you can or can not do within the framework they want (cost and schedule). I'm not afraid to say no to a client. That's my strong point. I'm not going to make grand, false promises. But when it comes to working for "the man", seems as though saying "no" will (eventually) get you a "goodbye".

SObaldrick
SObaldrick

Yet, they wanted a fully functional app within 2-3 weeks. And, they didn't want to hear "no". Draw up a realistic schedule. Mail it to the muppets and their bosses. Explain the consequences of working to a non-realistic schedule, and cover you arse in every way possible, so that when the project fails you have plenty of shielding. Do this up front and don't whine during the project, because it will make it look like you are failing on purpose in order to prove your estimates correct. Make sure that you are working to the muppet's schedules and document why every task slipped. Les.

jck
jck

I just want to write my own applicationss suite , and do PC build and repairs. I am not in it to go out, find companies looking for custom apps, and be their software Jesus. Well, not unless I know it would be an easy project and I can make a mint doing it...say...$250k for 6 months work? lol Then, I'd put on some robes and go "Yes. I have come. Bring me your systems." :^0

Justin James
Justin James

When I first encountered it ages ago, I thought it was blah. That's because I was trying to do rinky dink tasks within the browser, and the browser's DOM was the *real* problem. Now that I've been exposed to it a bit more, I like it a *lot*. It reminds me in many ways of Ruby, albeit with a different syntax. It is a shame that it has been relegated to the role of client side browser work. I would not mind seeing a system that uses it on the backend as well (well, technically you *could* use it in classic ASP, if I recall) and make it one unified system. J.Ja

Sterling chip Camden
Sterling chip Camden

... that the three you mentioned are the ones specifically designed to make you into a bad programmer. But you're right that the demand is there.

hoggerlrf
hoggerlrf

become a better programmer. The one skill that I developed as a technician was strength in was fault diagnostics. This now allows me to easily debug my programming errors. My career morphed from a technical background into IT and then into programming. However I am still a junior programmer as I have to balance my time in my current job between a technical role and programming. My boss loves the fact that he has one employee that can do both and not have to employ a seperate programmer. I love programming as it feeds my analytical brain (the reason I so love fault finding).

jslarochelle
jslarochelle

Certainly a classic. A couple of years ago I decided that I needed to update my reference on algorithm. The one I had was not very complete and a bit out of date (missing Red-Black-Tree and some other more "modern" algo). I looked at TAP but the cost and the strange pseudocode used in it stopped me. I went for Introduction to algorithm. It is not perfect but I'm pleased with it. You can even get audio transcript of a course based on it from MIT. I will probably buy TAP one day because it is very good and approaches the subject from a slightly different angle. Of course there are other books that we could recommend but those few certainly are a good start. JS

Tony Hopkinson
Tony Hopkinson

Whether it's a methodology, a language, environment or whatever, asdie from being more interesting and exercising the cranial muscles, at some point the rut you are confortably in, will end. Seven years as a VB6 cookie cutter, or 15 years as the COBOL guy, it doesn't matter. To your next potential employer you could will look like a junior, and possibly one with now bad habits. I had the opposite problem as a junior, management had to restrain me from quests for perfection, and implementing things differently because I could. I still have a major need for one last twiddle or tweak, I sit on myself now though.

Tony Hopkinson
Tony Hopkinson

It's the major benefit of experience, knowing that at some point you are not going to be. Theoretically this could be dealt with, but we'd all still be working on Hello World. I do read other's code a lot, especially my own....

oldbaritone
oldbaritone

we used to write inline-assembler code to optimize the oft-repeated code. Nobody does it any more, except maybe in embedded controllers. Everyone else just keeps throwing faster hardware at the problems. And it's really amazing to see the difference in latency with just a few lines of ASM.

Sterling chip Camden
Sterling chip Camden

It matters not how much you know if you can find it out quickly enough. Become a master googler. But also build a deep enough understanding of programming principles that what you find immediately makes sense.

Tony Hopkinson
Tony Hopkinson

will help a devloper, if nothing else it stops you reinventing wheels, or on occasion lets you choose to invent one that's round and such. In terms of the discipline of programming itself as opposed to learning a language or IDE or some such, never seen one worth the effort of taking on a technical basis. I did the .net one, and the muppet told me I didn't need to manage my memory anymore. I can read marketing BS by myself, no need to cough up a few k for some dimwit to do it for me. For the HR muppets, a different story, if they are looking for it, and not you, then it's a worthwhile investment on that basis alone.

Justin James
Justin James

Working on the MCSE ages ago, while I never completed it, was quite helpful to me, because of the "Networking Essentials" portion of it. As a result, I learned TCP/IP inside and out, and that did wonders for me down the road. When other developers struggle to find out why a networked system is going wrong, I know how to troubleshoot at a lower level, for example. In addition, it opened up new career avenues for me; for example, I spent a good bit of time doing network analyst/engineer work, which was enabled by that learning. J.Ja

Justin James
Justin James

Along the same lines, it's important to know if you have "just a few too any notes" in there (to rip off "Amadeus"). In other words, are you making things needlessly complex? I've seen some junior developers put in some wild, unneeded error handling into systems, for example, because in a more complex system it might be needed. People who use a design pattern for every little scrap of code are like that too. :) J.Ja

Justin James
Justin James

Absolutely right... in addition, these kinds of soft skills are what get you moving in different directions on the career ladder if you choose as well. J.Ja

jck
jck

If it was something I knew I could crank out by not having any social life or spare time in 3 months? Hell yes, I'd do that. Heck, I've done it before. Cranked out over 10,000 lines of code in 4 months including doing regression testing and design mods in the process (after the drop-dead change date had passed that management set). It almost drove me nuts, but I ended up getting that task done. Of course, that was working for a company. I got no bonus. The Program Manager got a $10,000 one. Way to show appreciation for sacrifice, huh? :^0

Tony Hopkinson
Tony Hopkinson

six months work for 125k and due in three months. Cthulu help you if you pull that rabbit out of the hat as well. The penalty for success in IT, is a forthcoming failure.

Sterling chip Camden
Sterling chip Camden

Here's an interesting post on server-side JavaScript: http://www.sitepoint.com/blogs/2009/03/10/server-side-javascript-will-be-as-common-as-php/ The way that JavaScript naturally combines the functional and object-oriented models is what reminds me of Ruby -- although they do that in slightly different ways. What is profound (for me) about JavaScript is the way that there's no difference between object members and array elements. An array index is really just an identifier for a member of that array object, and an object is really just an array of members (including member functions).

Justin James
Justin James

I agree, the price of TAP is a bit... high. Unfortunately, neither Safari or Book247 (I get a limited membership to both via my ACM membership) has them, at least not at my membership level. My boss has a copy on his shelf. I wonder if that is sufficient justification to buy them on the company credit card? :) J.Ja

Sterling chip Camden
Sterling chip Camden

You have to continue to stretch yourself, even if it's only on your own time. if you're not progressing, you're falling behind.

mattohare
mattohare

was learning how to learn. That's what my dad (on vashon) always said when I was growing up. With all the oddities of my disfunctional family, I ended up in eight schools in four school districts across Washington state. It really did teach me to be flexible in how I learn. Great preparation for dealing with the likes of Microsoft and Novell.

Justin James
Justin James

That's why I made it #2. It seems like I spend more time looking stuff up than actually working in many cases, especially when applying myself to a new problem or domain. Fact is, just sticking in a couple of keywords into a search engine is often not the best way of doing things... learning the various filters and Boolean choices can make your search much more accurate and fast! J.Ja

mattohare
mattohare

It was a VB application that started in version three. I got there when it was in version six. It had two problems, one of which is the one you mentioned. The other problem was they'd used all these odd ActiveX controls to 'ease' date entry and provide help with those stupid little hover messages. VB6 had hover messages native, but I got rid of most of them as getting in the way instead of helping. The remaining four, I used vb6's native method. The date picker i removed altogether. The users did better entering a short date (with out the year when it was the same) and me formatting it when they left the text box into a full date w/four digit year. The worst was the error handler. Not only was it massive bloat, but it would provide a 'dialog box' that covered the users screen with enough details to scare the a seasoned programmer. (I remember when I felt my heart skip a beat when I first saw it.) replaced the whole error facility (half a page of code PER procedure/function) with one line of code. It was for a message box that displayed error number and description. Oh, this brought the executable size from 12 megs down to 3 megs. And the application had fewer errors popping up.