Is it normal for a programmer with 2 years experience to take a long time to code simple programs?

Question

Hi all,

I'm a relatively new programmer (18 months on the scene), and I'm finally getting to the point where I'm comfortable accepting projects and developing solutions under minimal supervision. Unfortunately, this also means that I've become acutely aware of my performance shortfalls, the most prevalent of which is the amount of time it takes me to develop, test, and submit algorithms for review.

A great example of what I'm talking about occurred this week when I was tasked with developing a simple XML web service (asp.net 3.5) callable via client-side JavaScript, that accepts a single parameter and returns a dataset output to a modal window (please note this is the first time I've had to develop a web service and have had ZERO experience creating/consuming them...let alone calling them from JS client side).

Keeping a long story short -- I worked on it for 4 days straight, all day each day, for a grand total of 36 hours, not including the time I spent dwelling on the problem in the shower, the morning commute, and laying awake in bed at night. I learned a great deal about web services and xml/json/javascript...but was called in for a management review to discuss the length of time it took me to develop the solution.

In the meeting, I was praised for the quality of my work and was in fact told that my effort was commendable. However, they (senior leads and pm's) weren't impressed with the amount of time it took me to develop the solution and expressed that they would have liked to see the solution in roughly 1/3 of the time it took me.

I guess what concerns me the most is that I've identified this pattern as common for myself. Between online videos, book research, and trial/error coding...if its something I haven't seen before, I can spend up to two weeks on a problem that seems to only take the pros in the videos moments to code up. And of course, knowing that management isn't happy with this pattern has shaken me up a bit.

To sum up, I have some very specific questions I'd like to ask, and would greatly appreciate your objective professional feedback.

1. Is my experience as a junior programmer common among new developers? Or is it possible that I'm just not cut out for the work?

2. If you suspect that my experience is not common and that there may be an aptitude issue, do you have any suggestions/solutions that I could propose to management to help bring me up to speed?

3. Do seasoned, professional programmers ever encounter knowledge barriers that considerably delay deliverables?

4. When you started out in the industry, did you know how to "do it all"? If not, how long did it take you to be perceived as "proficient"? Was it a natural progression of trial and error, or was there a particular zen moment when you knew you had achieved super saiyen power level?

Anyways, thanks for taking the time to read my question(s). I don't know if this is the right place to ask for professional career guidance, but I greatly appreciate your willingness to help me out.

Cheers,

Daniel

Update Just to address some common concerns I'm reading in the comments -

1. PM's knew I had little/no experience with web services -- that's why they tasked me with the solution.
2. We're not using jQuery or any other 3rd party lib (has something to do with the contract...way above my pay grade).
3. My tech leads don't directly answer questions I ask them, but instead respond with questions they think will lead me to the answer. I kind of like that. :)
4. You guys are awesome. :)

Answer 1

Obviously, nobody is going to expect you to know how to do everything straight up. I think the problem here, though, is that you've tried to work on the problem on your own and never actually asked anybody for help. I assume you've got access to more senior developers where you work, and it doesn't seem unreasonable to me to expect you to ask some of them for pointers on where to get started with a new problem.

Answer 2

(please note this is the first time I've had to develop a web service and have had ZERO experience creating/consuming them...let alone calling them from JS client side

Its common in all the level. you were asked to do the work, that you have never done before. sure it ll take time than your routine work.

Make use of online (forums) and senior dev guidances when you are approaching something new. Sure it ll reduce the time.

Cheers

Answer 3

You are on the right track. The speed will come with experience, especially given your dedication and desire to improve. The fact that you are able to solve it and solve it with a good solution is excellent. I've seen plenty of junior and senior developers simply not able to come up with workable solutions on their own, given any amount of time.

Answer 4

The other thing that can help you with rapid development is breaking the problem down. Instead of looking at it as "web page that makes a web service call and displays a modal dialog," Do the individual pieces.

1. Web page (should be easy, right?)
2. Send request to web service via JS (lots of samples of that!)
3. Receive the request (and do something with it initially...)
4. Pop up a modal dialog

None of those problems are too hard in isolation. It's only when they're tied together that they start to look overwhelming.

Also, as others have said, ask for help. No experienced developer will think less of you for this - good developers know where they do and do not have knowledge, and will get that knowledge the fastest way possible. Not knowing something isn't a bad thing, it's expected - good developers know that they don't know everything.

Answer 5

If this were the fourth or fifth time you've implemented an XML web service in ASP.NET and JavaScript client lib and it is still taking you 4 days to get it done, you would have cause for concern.

Since there were many firsts for you in this assignment, you need to factor in time for learning curve, getting oriented, etc. If this is the sort of work they will be expecting of you regularly, you should put in some effort to stay ahead of the curve and invest in a few good books on the technologies you're working with. Also figure out who among the experts could be your mentor to help you avoid getting lost in the weeds.

If they throw you into a completely different lion's den each week, then they're just randomizing you. That will work against you in the building confidence and building skills departments.

Answer 6

I couldn't get from your question if you informed your bosses that you had zero experiense in that area. If you didn't, then it could be a reason for them to be worried by the slow progress.

No one can be expected to work as fast in a totally new field as in a known one. Therefor I think it's important to let people know that youv'e never worked in a certain field.

Answer 7

You did well for a first timer, but there are many levels to consider.

Sometimes, having a numerate background or genius helps your programming proficiency. That's why so many mathematicians are excellent programmers.

Keeping up with the ever evolving technologies is something even I find challenging, as they keep springing up everyday.

Dedication also helps. Programming I suppose is for the goal-oriented folks.

The time it took you is irrelevant for a first timer. See yourself as fighting the odds to become the better person that you want to be. Dedication is how people become experts and "senior developers".

Except you find the time aspect is a repetitive trend. I think that there is nothing to worry about.

Keep getting better

Answer 8

I have the same doubts. It's one of the reasons I'm a sysadmin rather than a programmer. Eventually I manage to get things working, and when I do the code quality and test coverage are usually pretty good.

But I still feel like it takes me quite a bit longer to get there then it should.

In your case it might be better if they tracked the time spent in troubleshooting, debugging and maintenance for a year after your code is put into production. Your management and peers might have considerably more respect for your skills and results if it turns out that your investment netted significant savings over the most comparable efforts of those who cranked out less robust code at a faster rate.

Meanwhile I've heard of studies in programmer productivity. I know they exist somewhere. I don't know where and I have only vague hearsay about their contents. You might review some of those and compare your productivity to their results. A search on "programmer productivity metrics" seems to provide plenty of promising hits.

Answer 9

This is a great question and the fact that you are asking yourself (and the community) how to improve yourself is mature and very appropriate. Your seniors and leads are probably very pleased to have someone with that approach and attitude in their team.

Quality is key - and they are pleased with the quality of your work. That's a major benefit to you, and to them. There's no point being fast but producing poor code. So you are an asset to the team.

You sound like you are dedicated and enthusiastic - you carry the work around in your head, you think about it in the shower, you wake at night thinking about it. You research it and you clearly want to do a good job.

The speed will come with experience, so don't worry too much about that.

My guess is that the management team recognise all these things and have put it to you in a way that will get you thinking and to see how you go about solving that problem...and what you have done is to ask other people for advice (here, on stackoverflow). And that is the answer to your question - you need to ask your peers and seniors for advice, for help, for guidance.

I think that if one of your colleagues came to ask you for help with a programming problem that you would willingly help, that you would enjoy helping. I think the same would apply to them. Ask them, talk to them, and they will respond by helping you and enjoy helping you.

You sound like you are an asset to the team.

Answer 10

Often there is a situation where you could spend hours researching and make little to no progress, since it is often quite difficult to put the idea onto paper.

On the other hand, a 30 second (seriously it often is that short, or even less) conversation with a senior guy, will give you the tools (often simple keywords) that you need to go away and research the problem efficiently.

For example for the problem above, you might have asked "how should i call the webservice from the client?" and the senior guy might say "we're using jquery, check out the ajax function", having not even needed to look away from what he is doing. You can go of and look it up with little difficulty.

Ok so it's a simple example, but just a few seconds of there time can really enable you to go the rest of the way, in a fraction of the time. With time you can figure anything out but often you can slash the time with a quick point in the right direction.

Answer 11

Out of curiosity, which part of this problem did you find most difficult?

The Javascript webservice call? The webservice syntax? The actual body of the webservice? The return value? The modal popup?

To sort of address your questions: If this problem took me four days after 18 months of ASP.Net programming, I would be very concerned -- as you seem to be.

If you have been writing Haskell for the past 18 months and then got thrown this little feature out of nowhere, it's not too bad.

The fact that you're here on SO is a good sign. But honestly, you could have posted a question asking how to call a web service from client-side code on day-one and probably have finished it in... maybe a few hours?

Answer 12

I remember being at this same point in my career a few years ago. Except I had probably more experience behind me then. So you're in a good position at the moment.

Like many have said here already: If you can be truly critical of yourself and can keep reflecting on your productivity, you'll get there. If you're an arrogant developer who thinks they know everything, you won't get far at all (there are some exceptions like Linus Torvalds).

Get yourself a copy of "The Pragmatic Programmer".

You're cut out for it, yes.

Answer 13

Is my experience as a junior programmer common among new developers? Or is it possible that I'm just not cut out for the work?

Yes (and not only in junior devs) - but most don't recognize it or care. The fact that you do both is a good sign.

If you suspect that my experience is not common and that there may be an aptitude issue, do you have any suggestions/solutions that I could propose to management to help bring me up to speed?

It's not an aptitude issue per se - ie., it's not a training or knowledge issue - it's that you're probably inefficient in learning or perhaps hesitant to put it into practice.

Do seasoned, professional programmers ever encounter knowledge barriers that considerably delay deliverables?

Sure - there's always the unexpected. If it's a pattern though, then it's a problem. And rarely is it a knowledge barrier - knowledge can be gained (or outsourced) fairly quickly in most domains. It's usually an unexpected circumstance that delays projects (flaky hardware or frameworks, the design has a fatal flaw, etc.).

When you started out in the industry, did you know how to "do it all"? If not, how long did it take you to be perceived as "proficient"? Was it a natural progression of trial and error, or was there a particular zen moment when you knew you had achieved super saiyen power level?

Of course not - and I still don't know how to "do it all". I'm confident in my ability to figure out how to "do the required thing" fairly quickly, though. Proficiency - for me, at least - is measured less by what you know how to do and more by what you can learn how to do. After all, it's pretty rare that you'll need the exact same solution twice.

Assuming you've been doing ASP.NET for 18 months, I would've liked you to be able to code up a web service with jQuery in less than 4 days, too. If you were a C or Classic ASP programmer, I'd cut you some more slack - a radical change in environment (eg., I've just started looking at Objective C for iPhone programming, after spending years as a .NET dev) can take a bit to come to terms with. I've got about 10 hours of coding in Objective C, and maybe another 15 of reading and am just starting to grok it (I blame half of that curve on OS X, though). I expect it'll be a good 6-12 months of part-time coding before I can claim proficiency or feel productive in it.

To be clear, I'm being a bit harsh (and I think your management is doing the same thing) because you seem to have the potential to be really good. You have the right attitude, you seemingly have the desire, and you write good code. There's plenty of devs that would just complain about having to do something new, or be unable to write the code ever - they're not worth spending time coaching.

You need to look at what's slowing you down, and take steps to solve it. I don't know you, but my amateur psycho-analysis tends towards perfectionism. Without hard deadlines, perfectionists tend to over-analyze the details and possibilities and be struck by analysis paralysis - fear of making the wrong choice prevents them from making any choice. If that's the case, I suggest getting/making a deadline on the next project and sticking to it. It'll force you to make compromises in your design and learning, but such is the world we live in - "good now" is better than "perfect never".

A couple of other suggestions (remembering this is all based on no knowledge of you, so you'll need to think carefully about which (if any) of these would be helpful to you):

• You mention online videos. Personally, I find online videos to be terribly inefficient. I can read (and scan) much faster than I can watch and listen. Google, blogs, and SO are 10x more useful to me than videos.
• Speaking of blogs - find a handful that you like and read them everyday. Pay attention to your niche of the field. Even if you've never called a web service via JavaScript, if you spend 15 - 30 mins/day "keeping up", you'd know about jQuery's AJAX implementation. That gives you a head start on figuring out what to do - which, for a lot of folks - takes a lot longer than the how to do it.
• It's not necessary to learn "a great deal about web services and xml/json/javascript". Learn what you need to complete the task. When the time comes, you'll learn the rest (or learn it after the task is done).
• Podcasts, while falling into the inefficient category like videos - are useful for broad overviews of a subject. Listen to them while cutting the grass, cleaning the house, on the commute, etc. so you're not hit with the inefficiency tax (it's not like you're reading blogs or coding during those times).
• Write code. Lots of it. Some that sucks, some that's awesome - most of which never sees the light of day. Don't only write code for production or a project - or treat everything like a project. It's okay to have drives full of code that's half-finished, half-broken, for a stupid idea, or otherwise crappy. It's okay to delete it, too - it's not about the code but the learning you'll go through while writing it.
• Ask Stack Overflow, the Twitterverse, your senior devs, etc. when you're floundering. There are times when you'll be stuck - don't spend half a day trying to dig yourself out without help.

Daily standups are also a good cure for this - by being accountable to your team for a day's worth of work every day, you (and your senior devs) will know when you're spending too much time on a particular problem. If your team doesn't do daily standups, ask your mgmt to implement them or give you 5 minutes a day to tell them what you did yesterday, and what you plan on doing today. That'll keep the surprises on both sides to minimum at the end of a project and allow you to course-correct quickly if you're sending too much time on an implementation detail.