Discussion on:

10 tips to go from a beginner to intermediate developer

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

J.Ja

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.

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.

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

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.

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

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.

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.)

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

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.

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.

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.

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

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.

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.

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.

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.

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....

"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.

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.

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

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

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

Pretty good ...

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

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.

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.

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.

good article

"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.

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.

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.

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.

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.

... 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

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!

understand what are you coding for =)

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

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.

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

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

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