Become a project manager

From reading your question it seems the major cause of your concern is that when faced with a "blank slate" you just can't get started.

Surely you realize that this is the hardest part of any creative process! The fact that you find this difficult is completely normal and healthy.

I have had this problem in the past and the solution was incredibly easy. I just start programming something, anything, related to the problem, no matter how seemingly stupid.

The simple act of bringing something into existence then allows me to objectively criticize and improve it. This "something" is only a small part of the overall objective and might only take an hour or two.

You also sound a bit "hung up" on job titles and reputations such as being the "Guru". In other words, once you have attained the Guru status in a company you know all and see all. But in software development this is a recipe for being made to look very stupid (believe me) when you get caught out by the rate of change. Of course it also just adds to the pressure that you seem to be feeling.

Saying that you "choke" suggests that you are putting way too much emphasis on writing top quality code, first time, every time. If you know that your first few attempts are simply to start fleshing out a real design, you have no pressure to make them perfect.

Your problem isn't incompetence or laziness. It's more like a lack of confidence due to becoming a bit rusty after not exercising these skills for a few years, combined with placing undue pressure on yourself to perform.

There are plenty of jobs out there for testers and debuggers. That may be a very good position for you. If you can identify, isolate, and clearly report issues and solutions you would probably make a pretty good software tester.

But if you ask me to sit down and code up a new application from scratch I will spend ten times longer than programmers who are much more junior than me.

Being quicker is not always the best way, and subsquently taking too long without justification is also bad. There is a fine balance to be had between doing something effectively and within a reasonable time limit.

Although these Junior Programmers are doing it quicker, are they doing it better?

1. Is their code maintainable?
2. Is their code extensible?
3. Are they following patterns and practices?

There is also a case where something is not good enough and you consistenly look at the work you do, and think "WELL THIS CAN BE BETTER!" On this scale I would take a pragmatic view and say "Do not let perfection get in the way of good enough!"

Something I like to practise is always to start out simple and extends where ever possible. So even if you have the smallest idea for a core application. Break it down into smaller parts and repeat until what was once large, becomes modular and may allow you to get a better perspective of things!

OMO

Cheers,

Andrew :-)

p.s. Keep programming, it sounds like you would begrudge having to give it up, i would be the same, absolutely!!!!

You have four options as I see it.

1. Continue to be a programmer - read books/blogs and for goodness sake, write some code on your own time. Contribute to an OS project, join a user group, whatever. If you want to be a better programmer, then you have to act like it.
2. Get a different technical job - if you like the tech field, there are plenty of jobs that don't require programming know-how. You could be a server administrator, Network cable monkey, software tester, etc... That's not to say that these jobs require no programming, but it will be much more watered down if you actually need to code something.
3. Quit and become a manager of programmers - this might make some sense because you already have some technical experience and might be adept at knowing what your programmers need. This isn't quitting by any means, but if you don't want to learn more about programming then I suggest you get out.
4. Change professions completely - just because you have programming experience does not mean you have to stay in the field. There are plenty of other fields where having some above-layman computer knowledge will actually make you a commodity.

I am not the sharpest tool in the shed, but let me share my impression:

1. Nothing 'wrong' with you.
2. I was a top tier consultant for the database folks in Redwood Shores for about 6 years in high performance MPP/SMP platforms. I’d previously had 5 years porting of the core code to a variety of platforms. Subsequently I’ve worked for most of the big names in the business and consulting world. At Redwood Shores when I was in town one week, I was told by my boss to go for an “interview” with the resident “database” expert. No explanation about why or what was up. Turns our he was half my age and a new dba. He asked me three questions regarding syntax, “How to create a database”, adding a tablespace and backing up. On the third question I asked him what platform or OS he was wanting the answer for. He turned red and said it didn’t make any difference. I explained that Unix, Linux, Windows and a couple others are indeed different. I was dismissed. Next day I was fired for being incompetent. Turns out a female co-worker sabotage me successfully. She arranged with our boss to have me “interviewed” by an “expert”.
3. I’ve hired and managed as many as 35 programmers, designers on a single project. Anyone in the business with any experience would understand that asking someone to code something or provide a solution on the spot is rediculous. In fields of narrow, well defined clusters of knowledge it is a different story perhaps. But in the IT industry, just tell me what they guy is good at and I’ll ask a question he cannot answer.
4. I know it is popular to give “tests” to measure skill, proficiency, seniority, etc. But the mindless wonders that put this crap together, stand by it, believe it and promote it are just folks like you and I who need the job and need to be able to send kids to collerge.
5. In the past 8 years when I have been asked to sit down and take a test or write code, I just say “Thank you” and walk out.
6. You have three choices: Working for the man, not working at all, working for yourself.
7. With the level of experience you have, I suspect that age is more of a factor in you not getting a job than any percieved lack of skill.
8. When you are the age of or older than the hireing party, your chances approach zero. No one wants to hire someone more experienced or who may know more. They need to preserve their place in the corporate sun.
9. I have both an MBA and MS in CS. “over qualified” is what I hear most. (In reality it’s the money and the age that are the problem).
10. I don’t view you as a problem. Nor anything about you. The inbreeding, incestuous, toxic corporate environments are part of the problem. You are going to have to work with them or you’re going to have to go our on your own, learn consulting skills, and sell yourself as a unique and wonderful solution to problems that some companies have.
11. You’re not alone.

“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”

—John Gall

Once I read that quote, the last 5 years of my life suddenly made sense. All the times I've struggled to create programs.. REAL programs, and failed- It's due to this simplicity principle.

Your problem, is a problem of confidence. I am beginning to suspect that everyone has your problem, in all careers, from business, to art, to writing, to programming. If they don't have this problem, they're either lying, or stupid. I don't ever want to have to work with someone that never doubts their own abilities. I've done it before. Those people scare the fuck out of me.

Recognizing an incompetance in yourself is the first step towards improvement. People who are incapable of recognizing their own incompetance are pretty much doomed to be incompetant forever. I'd say don't worry about it, but that's kind of the point isn't it? :)

A business analyst is another good avenue. You can help defined the business problem and with testing, but do not need to figure out the actual code to do it.

  Those who can do - are doing.
  Those who can't do - are teaching. 
  Those who can't teach - are managing.

(a saying, rough translation)

PS. Don't take it personally. I'm well aware there is people out there who can both do, teach and manage.

It sounds to me like you've primarily worked on code developed by others. Very easy practice to fall in as it's a comfort zone. The other coders you talk about probably worked more with software design. It takes time to find your own 'brand' when designing software and you just need to find yours.

My suggestions:

1. LEARN to design software. Ideally, learning to design would be the best, first step, then learn a language to fit the design. However, many of us learn the language first THEN come up with the solution. This presents the PROBLEM of 'when all you have is a hammer' mentality, which shuns creativity and language independance.

2. Buy a copy of CODE COMPLETE ^[1] and/or Head First Design Patterns ^[2] if you haven't already to get your creative juices going. Chances are, you learned a language(s) without learning to design. It's a common theme. Don't be discouraged. It's a hurdle you'll have to eventually jump over. We all have/had the same hurdle.

3. Go home, spend some time and design a piece of software you need, for fun. Put the keyboard aside and design it. Take some time and lay the whole thing out. Enjoy it!

4. If you still feel you just can't do it, as others have said, sounds like you have an excellent opportunity for tester or software support, which are both very challenging fields and you're already one foot up on them.

Two words: training montage

I've seen questions like this here before, and always find them interesting. A common piece of advice, which I believe, is that the very fact that you're here and asking indicates you're neither lazy nor incompetent.

Can I ask: do you enjoy coding?

I think if the answer is "no, not really", then maybe it would be worth looking at taking another avenue, and going more for the project manager / business analyst route. I think in a job interview situation you could come to the table and say that your coding days are pretty much behind you (if indeed you would be happy they were), but don't feel or show shame in that admission.

If the answer is "yes, I love coding", then perhaps it's a question of continuing to plug away at it, maybe going at coding with a different approach, set yourself some different challenges. I too find sometimes that it's hard to write up a whole application from scratch, perhaps partly due to a constant feeling of needing to look up Google for what the "right way" of doing things is; so perhaps to build confidence, set yourself a simple programming task and try to do it with the internet turned off. I think you'd be surprised at what you can achieve. It may not be perfect. But then look at it a week later, and you'll be able to see the problems in it just as you can with other people's code.

You could test yourself for symptoms of ADD/ADHD. I almost always get hung up on layout and design because I can fiddle with it for hours like a game and never get anything "done".

Everybody's given helpful and useful answers, but one thing to remember is that the scariest thing for anyone in a creative endeavor is a blank canvas/sheet of paper/etc.

Programming tasks don't begin with writing code--they begin with organizing an understanding of the problem at hand. Some people organize better in the limited world of a programming language, others organize with pictures of boxes on a screen or piece of paper (UML), some people organize better on whiteboards or napkins in an ad-hoc fashion. It all depends. Ultimately, of course, as a programmer you need to eventually get to the point where you're churning out code, but that has to come after the organizational understanding.

It could be that you've just lost your "mojo" after doing what you've been doing for so long. Similar things have happened to me over the years because the job has pushed aside the creative aspect of programming in favor of the logical, methodical side. My solution has been to find a technology that intrigues me and dig into that on my own, learning about it in my own ways, and re-discovering the "play" that drew me into this hobby/profession/passion in the first place. If you once had that same playfulness, then you can probably rediscover it if you find something that tickles your fancy.

Be honest when you're interviewing, and be sure to point out the myriad ways in which you bring immediate value to an organization even if that's not programming from scratch. Also, remember that rarely do places have the luxury of starting from a blank canvas on any project and, if they do, it's likely that they'll have a team of people rather than just you. That means that a savvy hiring manager can assemble a group of people with complementary skills in order to accomplish the task at hand, i.e., there will likely be a person on the team for whom the blank canvas is the best thing since sliced bread and can help jumpstart your creative juices.

Good luck!

I discovered when my wife took a CS course that she's very much like you. She got A's on all her tests, but couldn't create a program de novo if her life depended on it. She's just not a creative person. Most people aren't. There's nothing wrong with that. She's so much better than me at organizing things and remembering things that it isn't funny.

I'm with Max on this one. Go ahead and be good at what you are good at. I am a good creative person, but I've spent most of my time in the last 10 years porting or debugging code someone else wrote. Some of the time I've floundered, because that isn't really my forte'. Pretty much any job we ever take here is "just like" some other job we did before, with perhaps a few changes.

We also have an entire group where I work who's only job is maintaining software at various customer sites. It would be a wonderful job for someone like you who enjoys travelling. We have large numbers of other software folk at permanent sites charged with maintaining code. There's plenty of work out there for someone like you.

Man.

I'm disappointed to see so many people so confident with their conclusions that "you're a typical project manager" or "it sounds like you should teach instead."

There's nothing here to say that you'd be good (or bad) at either of those jobs. Same with programming. The only concrete thing here is that you're doubting yourself which is something that happens to everyone at some point.

So, here's my two cents which are just as tainted by my own experiences as any of these other opinions.

You struggle to develop solutions from scratch but you are great at debugging existing code. Which have you practised more?

If the answer is "debugging," then you have pretty solid case right there to put some time into practising analysis/design (read: coding from scratch) before you throw in the towel, assuming programming is what you actually want to do.

If teaching or management are truly for you, then great. I'm just saying don't give too much weight to the general consensus here as we do not know you and we do not have enough information to do anything more than speculate and spout opinions.

Hope this helps you in some way and good luck!

Programming is creativity.

Creativity comes by learning, copying and adapting.

Learning comes by doing. copying and adapting comes from studying.

Just do and study.

Also, don't pretend to code a new application from scratch, ground up. Do it progressively. It will get much easier.

If you are in the wrong career path? could be. Maybe you are a great tester and maintainer. Maybe you are a great manager. who knows ? You don't have to be a good coder to produce (indirectly) good code.

If you want to code, pair programming might be a good way to build other skills. Or the others have good suggestions about related tech careers.

The question has hit a nerve...

I think a lot of us doubt our abilities, especially when put on the spot in an interview situation. I often feel very intimidated being expected to write a solution in front of a group of strangers on a whiteboard in 10 minutes -- that's not really what I do in my job, and I have my doubts as to how helpful this type of test really is in judging people.

The truth is a lot of us look for code samples to start things off, and there's nothing wrong with that. Why start from scratch and spend 3 hours creating something you could poach from someone else, might as well leverage the code and re-use.

Also--interviewing is, from my recent experience, much worse than it was 2-3 years ago and before, meaning--it used to take me 24-48 hrs to land a new position, now it seems to take 1-2 months. The questions are harder, expectations are higher, and I think they are interviewing way more people, pushing down rates, and hiring very slowly...

It is easy for anyone in this market to start to lose confidence.

One solution -- practice "drills" of coding some sample solutions on a white board at home. Practice creating quick solutions to typical algorithm questions in interviews, either in the language of your choice or pseudo-code. Think of it as like running sprints at the track. This is -not- a skill we normally learn, has, I think, little to do with the reality of our roles on the job...but it is required now to get many jobs. So practice this skill as a "survival" and "getting hired" skill. Also, realize that in these times, it is about 10x harder to land a position anywhere.

Did you ever consider that you're just not that experienced as you say you are?

You're a fine debugger, got decent coding knowledge, have lots of experience in developing software "with others", and you know in theory how the software world runs.

You got yourself a decade (or so) of extra education and took it for granted. That is one hell of a foundation to build on. However, you forgot to start building.

I'm just guessing here, based the people I've worked with but: What you probably never did, was act. Pro-actively pick up assignments or pull responsibilities towards yourself. In the years passed, you reacted. Said "yes" to the tasks that were thrown to you and did the task over and over again until your manager said it was fine. You learned to mimic the behavior of an experienced software developer and are gifted with a rapid tongue. That's got you this far.

But you're gifted with another thing, one that you should use more often and that is self-reflection. Your question here shows that you analyze yourself and have a pretty good idea how your mind works internally. To me that looks like you'll probably understand what I'm going to say next.

You are probably not as good as you pretend to be. So stop pretenting, and become good.

Or, as Morpheus said:

Stop trying to hit me, and hit me!

Modify your CV so it does not imply the things you don't want it to. In interviews, do not pretend to be the hotshot developer, but be honest. Quotes like:

"I know in theory how a software design is built up, but have no hands-on experience"

are even more powerful than stating that you know it all. Take a step back and apply for a job that seems below your standard. If you are as experienced as you say you are, and you can show it, you'll be promoted quickly and your competence will grow along the way. But the most important part is that you try and do things for yourself. Build up that experience using the theory you already know. Find your shortcomings, see what motivates you, find out what sort of IT you like most (office automation, embedded, audiovisual, web, realtime etc), because the only way to get motivated to actually put the theory into practice and to excel in what you are doing, is to work with the matter you love.

I can tell you that that attitude has given me much more pleasure in my work and brought me to places I wasn't before. Your network will grow, and so will your pay check ;)

Good luck!

You are the typical Project Manager.

You know enough jargon to go around and know the overall stuff. You say you can't do specific code/problem solving but you understand stuff at a high level.

That's a typical project manager. If you have enough people skills, you're on your way to becoming a PM.

If you enjoy the technology and code, consider finding a position in support. You admit you can read and understand code, as well as grasp the technology. Combine that with troubleshooting skills (methodical testing) and you probably have your dream job.

Sounds like a great candidate for maintenance projects. Maybe atleast for time being. And like someone pointed out, you may be a perfect fit for a tester.

Thrilled with your honesty. And good to see people not ripping you apart as is what usually happens these days!

I'm in the same boat actually, so I understand where you are coming from. This is an excellent question that I'm afraid doesn't have a cut and dry answer to.

Your experience as a programmer seems well enough to come up with a solution to any problem, but the answer isn't obvious right away. I believe you would find the answer if you actually relaxed, took a deep breath, and broke the problem down yourself. I know in this business things have to be done relatively fast, so any solution to a problem that already exists without having to come up with will make any job easier. Reinventing the wheel is a waste of time. Researching the problem before attacking it is effective and shouldn't be looked down upon.

Problem solving or using your brain is a muscle like anything else in your body, it does take practice. The programmers you mention that have this problem solving ability probably practice a lot (maybe with their own projects), focus on the problem at hand, and yeah there is some innate ability too, but I don't think you would have gotten this far without a shred of it. I wouldn't say it's laziness, but motivation and focus and both of those can be worked on.

The answer is something you have to find yourself since it's impossible for anyone on here to know you. Get a therapist or confide in someone that knows you to discuss the problem. You will find that as you are discussing it you'll understand yourself better. If it's a focus problem, there are many techniques to get you in that mindset, if it's motivation, maybe it's the work you are doing now is not interesting to you and it could be you love programming just not working on certain things that lose your interest. If you kept your day job and just worked on something that interests you the most that might help you understand what it's like to work on something you chose to do and try and tackle it without looking up the answer. That will take some self discipline and will challenge you, but it will be in a non stressful environment.

I like your question, because I feel many people may have the same issue. I don't think I can tell you the good answer, but only give you some piece of reflexion on that question.

Well every time in my experience I found I was slow or unable to begin my work, I've realized lately that it was only a question of motivation.

I don't know what are the projects you've worked on. But for me every time I've worket on graphical interface, I realized I was very bad at it. Too much bugs, taking too much time to deliver, and not pretty at all. I know by now that I like pretty graphical interface, I can even have good ideas at it. I may be critic about other's GUI. But it is really not the part that I like in the programming world.

Take some time and think of it. Did you ever found a project that you made yours? Working on a part that motivates you? So much that you really want it to be a sucess?

For instance, how much time I dreamt of my ideallistic IPhone killer app. As far as I remember, I've only created the XCode project, drag and drop an Image view on the window. Then no more .. I will need big efforts to finish it, or help from someone who like to do that... :-)

If you can logically think things through like this, then surely you'd be right for some sort of "consultancy" role? You get asked questions, you get to ask for more info, and you hash out a solution together :D

You have a similar problem to me. Technically I know quite a bit, and I'm a top-notch problem solver. Bugs don't survive when I'm around, I'll dig down into the assembly emitted by the JVM if I have to.

But if I have to start a project from scratch, I spend so much time doing up-front work, that a hack and slasher usually has something workable in about 1/10th the time. I think it's a big indicator that my job tasks need to be small and focused.

A job as a maintenance programmer is my ideal. I bring value to a team, I don't hold back the team by missing deadlines on my projects, and I unbruden them by fixing bugs they otherwise wouldn't be able to.

Since no one hires maintenance programmers, I maintain skill in current technologies so I can pass those interviews, and hopefully settle into a nice slice of a job fixing other people's bugs.

When that fails, technical support for development products where I get to fire up the debugger every other day pretty much keeps me sated.

"I can identify the source of a bug quicker than anyone I work with"

Identifying bugs in code quickly - particularly code that is not your own - is a fantastic skill in it's own right, and worth it's weight in gold. That skill alone would make you eminently employable!

I'm in the same boat.... been working for 10 years as a developer and never really knew how to design because I never really had my own project.

They finally said "We are gonna give you your own project", and I had to come up with a design and meet with the lead programmer until I got it right. Maaaaaan, that was difficult and frustrating. To have to walk in with a design and then have the lead programmer drill you on what could go wrong with your design and have you do it over again, will humble you with the quickness.

Well, I have finally finished the project. It was a small project but they wanted to get my feet wet with actually designing of an app.

Luckily, they are willing to give me a chance and tell me what I need to improve on. I think after a couple of more designs, I should be good to go.

The way they had me do it, was write everything down I knew about the project and figure out the best solution for each part.... they had to smack the heck out of me a couple of times because I wanted to start coding, which is bad.... they were constantly like "MORE DESIGN!!!! NO CODING!!!", but I think it's working out.... like I said, I just need to do some more designs to get my mind in the right state.

Those who can't do, teach!

My company is one that does ask programming questions in interviews, and for us, it's not important that you get a "perfect" solution off the bat. Often times, it's perfectly OK with us if we give you some assistance during the problem if you get stuck. We want to see that you're thinking through the problem, though, and that you're able to refine your answer once you've got something up.

Many times, it's the tangents you think about during the problem that are the most interesting to us, as they give us great ways to talk about specific skills and knowledge that you bring to the table.

Most of our problems center around basic data structures, algorithms, and OO classes. I believe people well-trained in data structures and their tradeoffs will usually do well with us.

Communication is a key skill to have in interviews with us, since it helps the interviewer and the interviewee put each other at ease (yes, it does go both ways!), and like I mentioned above, gives us opportunities to explore specific strengths you have. That's not to say that you need to babble stream of consciousness throughout the interview, but explaining what you're trying, assumptions you're making, and questions you may have, is great stuff. Be prepared to listen as well and respond to the interviewer if they lead you in a different direction.

I've interviewed CS PhD's that have surprisingly choked on basic problems, and fresh-out-of-college students that could breeze through our questions. I do think fear, and analysis paralysis (which often derives from fear), are two key differentiating factors. The good news is: master these, and you may handily outperform PhD's. :-)

So my advice is:

• Forget about being a "guru" when you're in an interview, and simply become a "problem solver".
• Give yourself permission to fail. Time permitting, with us, you can hit a dead end, start over, and still knock it out of the park.
• Start with simple, potentially inefficient solutions, and refine them after you've sketched them out.
• Practice makes perfect. Interviewing is a skill that can be learned and improved just like troubleshooting, software design, etc.

Suggestions for practice:

• Memorize your favorite data structures in your favorite language, so that when it comes time to use them in an interview, you can use them fluently and confidently, leaving more brainpower to focus on the problem itself.
• Practice implementing basic data structures yourself to make sure your lower-level programming chops are there.
• Practice the starts of problems. Go find interesting programming problems, and see how far you can get on them in fifteen minutes, or half an hour. For this, I wouldn't recommend heavy brain teasers, but simple problems that capture your attention.
• Write sample code. This is a terrific way to build up speed and fluency with code. The disadvantage is that, with sample code, you're often not worrying about corner cases, so it's good to stop after you've written a snippet and make sure you can identify corner cases you skipped and how you'd fix them.
• Stack Overflow is a great place to practice. Even if your favorite question is already answered, ignore the answer and decide for yourself how you'd go about solving it. You might even try writing some sample code to solve it (see above). Then you can compare your answer to whatever someone else came up with – or even post it as an answer yourself!
• Practice talking through problems as you go through them to build up communication skills. Work with a friend or colleague on this if the opportunity presents itself.

Finally, one book I recommend to musicians who have difficulty with performance is "The Inner Game of Music" by Barry Green, which I read many years ago, based on "The Inner Game of Tennis" by Tim Gallwey. There's a lot of great wisdom in there about preparing oneself mentally for performance, and much of the advice there ought to be directly applicable to interview situations as well.

Good luck!

The question is: do you want to continue programming or find a new track?

• If you want to continue programming, you need to focus on your creativity and problem solving ability. I recommend a personal project to make an application from the start to end.
• If you want to get out of programming, I recommend becoming a Project Manager. You should start managing projects instead of working on them. You programming background will be an asset to you as a manager or programming projects, even if you don't write code.

Unfortunately probably not. I used to be a programming tutor in college and found some people just have a knack for programming, while others don't. It's not related to intelligence, diligence, or computer aptitude. But it's not all doom and gloom. So you're not an A+ programmer from the ground up, maybe you'd be happier as a tester - or in a pair programming environment. You at least can admit the fact you have a deficiency, most people can't do that - you have somewhere to start from. I would look at other positions in the company, see if you can do 4-6 month rotations and maybe find something more to your skill set.

I was surprised to learn from someone that, at IBM, the position of "Sr. Programmer" does not involve any actual programming. I think its just a natural progression on one's career. Programming isn't a profession you can age into like medicine for example. You don't see many 70 year old code-monkeys.

I appreciate your honesty. This takes a lot of guts. But because of that I expect you're doing yourself short. Many people underperform without ever having the guts to admit it. Hey, there's even taxi drivers who can't drive... ;-)

Please take some time to evaluate yourself and focus on the strong points; to find your core values. I'm quite sure you've made a lot of good contributions to projects and people around you. Possibly you're 'ok' according to other people's standards. Or you may have enabled other people and/or teams to succeed. If projects preform well because of what you did, it may have been the right thing. After all, it's the team success which really matters.

Depending on your values you can make choices to alter course. If you're unhappy in software engineering: is it because of your role, or because of other things? If you're happy, you may find a different role which better fits your qualities. Years of experience count for something too. Whether it is as a PM, or as QA or as a people manager is something for you to decide.

You ask just one question: "Does anyone have any ideas about what I might be dealing with - are there books or exercises that could help me with this basic problem?"

Yes: build something. Take an idea you have, pick a technology you enjoy, and start. Speed is a question of practice, concentration, inspiration, and the same with creativity. Make some software yourself following an idea you have. You'll see how you resolve problems, dance, or sink. You suspect you'll sink, I suspect that you'll see how fast you really are.

Many companies have people whose role it is to be current with advancing technologies, research them and suggest plans for purchasing or integrating technologies to improve the business.

I have a friend who did this for HP, and he earned top dollar as well.

This even applies to roles such as CTO's etc.

There is a certain knack that good programmers seem to have. However, if you actually want to be a programmer (decide this first), the best way to learn is by practice. There are hundreds of sites on the Internet that have problems for you to try to figure out, with solutions.

At the same time, as you said yourself, you may not want to be a programmer. Nothing wrong with that. You said you could find bugs quickly - there are companies who would love a good V&V ^[1] guy. Or, if you understand the technology, and not just specific implementations, look into becoming an architect. And, if you like the business side of things more, go down that path.

Sounds to me like you're selling yourself short.
I manage teams of programmers and skills like yours are very important for actually getting code out of the door so don't underestimate your experience.
In my experience ( especially in my industry which is games development ) software is created by teams not by some superstar uber-coder. Teams are made up of different skills and trust me, no-one ( especially me ) has all the answers.
I have guys on my team who are amazing at code design and coming up with great ideas to get the project off the ground but then some of these people aren't so great at 'dragging it across the finish line' i.e once they hit the bug-fixing phase they lose interest.
Then again, I have guys who come into their own at this point and without them, we'd never get anything released.

So, I'm not saying ignore it but it sounds to me like a case of 'the grass is always greener', you may find that there are coders who'd kill to have the knowledge you have.

It also sounds to me, and please forgive me if I've got this wrong. that your main problem here is fear of being judged by your peers i.e they expect you to be some uber-coder and so expect your coding skills to be as good if not better.
How about doing a little side-project or contributing to an open source project where you can make these mistakes outside the nasty glare of your co-workers? It all sounds to me that what you need is the space to play, make mistakes, learn and hone your skills

Hope that helps

I don't know enough about you but in my experience your problem is one of the below:

• You are good at programming, but you haven't done something in such a long time that you start to doubt yourself. It is time to take a break, think of an interesting problem, turn off your computer and think through the solution to the problem. Once you have the architecture and design, implement atleast one use case to get your creative juices flowing.

• You are good at grasping ideas and technology, but can't stay focused for long enough to think through or create anything of consequence. Maybe it is good to get professional help.

• You are not made for programming and you better start looking for something else. But since you are good at finding bugs in other people's code, I don't think this is the case.

Anyways, there are tons of other careers in the tech sector. Have you thought of freelancing?

Cheers and good luck!

sounds like you'd be good for QA or bugfix work. There are plenty of creative types around that suck at QA and fixing bugs.

People are good at what they do, and bad at what they don't do. Your problem may just be that you haven't done enough actual programming from scratch.

One problem people have when getting started is the blank page syndrome. You could put anything there! There are so many possibilities that it's scary. And because you are used to dealing with fully fleshed out things, no matter what you put first looks dumb.

If that sounds familiar, I'd suggest you learn test-driven development, which I use with novices very successfully. This is the basic loop:

1. Spend a few minutes writing a small amount of test code.
2. Run the tests. Make sure the new test fails.
3. Write just enough code to make it pass.
4. Run the tests. Make sure everything now passes.
5. Refactor the code until you think it's clean.
6. Run the tests. They should still be green.
7. Repeat.

This solves most of the blank page problem, because it reduces the fear. You just have to get one tiny thing working. Then you get positive feedback when your test goes green. Each short cycle lets you take one small step forward. As a bonus, you get a complete unit test suite for your product, and -- if your tests are reasonably good -- clear developer documentation that can be automatically verified.

If that sounds appealing to you, check out one of the many books on test-driven development.

You are not alone. I have had kind of same problem for long but finally I Think I’ve figured out the core. What I am talking about is not your problems at interviews but 'thinking' of not having what I call 'Genes for a programmer'.

First I am at the start of my career but have spent hell a lot of time learning computer sciences', about 6 years and now hold a Masters degree from one of the top Uni in the world. I am good at so many other things such as I am the best presenter at my work place and on top of discussions mostly but the programming jobs I undertake; only I know how I have been doing them.

I-e spending overtime at home unpaid, at nights on the modules been undertaken as other could finish them during 9-5 hours.

So where lies the problem?

It was just the lack of confidence. When ever I started with a problem I couldn’t think of where to start, spent lot of time on books and help instead of thinking my self. The problem started at college days when I tried to work around the assignments and course project by using a lot of existing projects, samples available online and modifying them perfectly with no traces.

It helped me with grades and earned me good name but my approach left me with weaker programming skills. Now I try to get into the task as much as I could on my own and put aside all the external help (forums, samples books etc excluding documentations) and only go for it as last resort not the first. And it has started to work for me.

and do read this post from joel, an older one but fugures out sort of problem you have

The Perils of JavaSchool ^[1]

Hope it helps

I hate such people.

I worked with such people.They only know to assign tasks to people and get its result.But when time comes to do same task by himself, then he cant do anything.

Such people always take the credit of developers working under him.

Such people are really dangerous for any organization.

I hate them!!!!!!

I think Michael Feathers might be on to something:

I once read that people who end up as developers usually have one of two different temperaments: scientist or engineer. You either get a deep thrill out of learning things or a deep thrill out of creating things. The best developers are a mix. They are continually on the prowl for new ways of doing things and they reflect on their practice, but they also know that they have to ship and they get a great deal of satisfaction out of that. If you're at either extreme, you end up as an "architecture astronaut" or a hack who ships cruddy code day in and day out.

I know that I lean more toward the scientist of end of things. I love working with teams and shipping code, but at the end of the day, I measure myself in what I've learned about software development. What I've seen that works, and what I've been able to discover. One of the secrets of the software industry is that many people who end up as high-end consultants really are more at the scientist end of the spectrum. They amass a lot of knowledge by experimenting and thinking critically about what they do. In an age where pragmatism and the credential of shipping code is nearly deified, it's a sore spot for some of us. We know that we have to reflect, that we're good at it, but also that we are sometimes a little bit out of the cultural value stream.

Blockquote

(From here ^[1]. The rest of the text is not really relevant to this theme)

You might be a scientist.

I ceartainly feel this applies to me. I always thought I loved programming, but it turns out I love to read and learn about programming, much more than actually do it. I also love to spread the knowledge once I aquire it. (I do love the creative aspect of programming, but when you work as a consultant in a large company, creativity is not really present.)

A good tip might be to take a personality test. It worked wonders for me. I find the Myers-Briggs Type Indicator ^[2] very useful. Read a bit about your type, and see if your job fits your natural preferences. I am an ENFP, working alone in an office, with lots of details, so naturally, I have resigned.

(For those of you familiar with the mbti, I also have a little theory. It seems to me to be a connection between the Sensing/Intuition function and the Engineer/Scientist difference? In that scientist --> N and Enginners --> S?)

I feel as if I could have written some parts of your question. In retrospect, I'd probably make a great QA person. Instead, I'm a project manager. It comes in handy, understanding how the code works, being able to recognize good code, being able to suggest possible root causes for bugs. I know I wouldn't be a bad programmer, but I know enough to know what excellence looks like, and I'd rather leave that to the people who are excellent at it, and do what I'm excellent at. It sounds to me like you would be a good business analyst, QA person or maybe even a development manager.

I guess it depends on whether you really enjoy coding.

I enjoyed the act itself, but I also enjoy everything else that I do. I didn't enjoy being a mediocre programmer.

To help with this problem, I will give the best advice I've ever gotten. It is precisely related to this problem you have.

Write the piece of code you wish you had.

Only then, you start actually coding it.

That is, suppose you want to write a program that checks your balance with your bank. Your first lines would be:

balance = get_balance()
if balance < low_level()
   warn_user("YOU ARE LOW ON CASH BRO!")
else if balance < 0
   alert_user("OMG!!! U ON RED!")

Notice that you do not have any of these functions. But this gives you the goals you need to complete the code. The rest is just filling in the details.

On a side note, one of my best math professors used prove analysis statements backwards if he just wanted to check if it was true. He would write the conclusion, and then literally go backwards assuming the conclusion was true until he would get to the initial assumption.

This is the same thing, but with code.

Sounds like you haven't made enough mistakes. So make more and enjoy.

I tackle a problem with Functional Decomposition. Start with the end solution i.e. what it's supposed to do and then iteratively break that down into subsystems. Keep the principles of YAGNI in mind. The idea is to solve a problem not produce a masterpiece.

So long as the cost of solving the problem is less than the benefit of solving the problem you've generally added value. Then it becomes a matter of optimising that return either by refactoring the design in order to support the future or otherwise improving performance bottlenecks.

Sounds like you get stuck in analysis paralysis. 65% of what Ive learnt about application architecture, which what you seem to be talking about not coding, i learnt by doing it the wrong way first.

Put some business logic into a user interface, try and test it then you'll understand why things like MVP and MVC are so valuable. Call one object from another directly for a given scenario and then find yourself in a place where you get caught because the caller has to be aware of the callee - how to fix that...Observer>> Observable / Delegates perhaps. Decoupling it's a beautiful thing..... especially when you can smile smuggly to yourself when you know the future pain you're avoiding. And you only know that pain by having made mistakes. So make some.

I wouldn't get caught up on coming up with creative solutions of your own. Just copy the practises and principles of all those who have gone before you. Ive never come up with anything original as far as coding practises and architectures go and yet my customers are happy.

At the end of the day no one cares who you are, just solve the problem. It's not art. It's business. If you're getting caught up on being the smartest/best then you're going to choke. Solve the problem and price accordingly.

Seriously man, with respect, get over yourself, make mistakes. The pain of that will teach you how to code better. This whole coding thing is a continuous stream of new understanding. Do what you know then do different when you know different. Be judged. Be wrong. Learn.

Five options that come to mind:

1. Maintenance programming, where you're working on someone else's code base. A lot of programmers can do this without viewing themselves as particularly 'creative'.

2. Systems integration - plumbing. Generally these projects require a wide range of technical knowledge and the programming required tends to be more in the nature of smaller bits of glue code.

3. Enterprise architecture. If you can understand solutions proposed by other programmers and come to a sensible opinion on their merits you may be able to do well in this role.

4. Consultancy or management. If you are a good communicator and technically literate you may do well in a technical management or consultancy position.

5. Specialist. What are you really good at? Find something that you do really well and concentrate on that. For example, quite a lot of database administrators start out life in development jobs.

Put in context, I'd view myself as a passably good but not really great programmer - certainly not in the same league as (say) John Carmack. ^[1] The work I do (designing and building data warehouse systems) covers a whole gamut of activities, of which actual development is just one facet. Within a single job I might do a variety of work from technical architecture, requirements and specification, development or data modelling through to managing other stakeholders in wider data architecture initiatives driven by the data warehouse.

I have good communication skills and core skills around data architecture, database design and programming. At other skills I am 'good enough.' This is sufficient to be regarded as a guru, although there is still plenty that I don't know.

My advice is to find what you are good at and focus on that. Works for me.

Actually I think most of the developer working on product actually does not have enough chance to write new project from scratch. Most of them start with a module in a big product, and then after done with it, he has to maintain the code until the product get stable.

For many big company, this problem is extremely obvious, you may more easily to be a good debugger since you have to maintain an old project and has no opportunity to rewrite it. So you may learn a lot of knowledge with little coding skill comparing with your knowledge.

Working on projects is different, you may keep on working on projects, so you have many chances to write new code. But also you may have to write similar code again and again...

How about head hunting for the IT business?

You say you get choked up when writing new code - do you get anxious and worry about it to the point where it clouds your thinking?

I ask because I find your story similar to mine. I have self-esteem and anxiety issues. When I open up my IDE and stare at a blank screen, I find myself in a panic and unable to perform at my best.

Perhaps you believing you are not a good coder has turned in to a self-fulfilling prophecy? How well do you do when working on personal projects, free of deadlines and expectations?

If you think at this in a more psychological aspect, it looks like it's procrastination. I'm a bit like this too. One of the major cause is that, as you're highly considered, you always want to do the best at the first attempt. You are afraid of being underappreciated, afraid to make mistakes, afraid to do the wrong choice.
Maybe you should digg in this direction to overcome your problem.

Hey, I like your narration skill, it is awesome and to the point. You can be a good Project Manager or what n8wrl says could be a right thing to do ... don't just give up. Improvement is a practice, practice it.

I would make the assumption you read lots of technical books on your spare time. You may feel like you understand the concepts pretty well and can carry on a technical discussion about several technologies and concepts.

I can also assume that you haven't programmed heavily applying those concepts in a real coding effort. Maybe you have been involved in the discussions, design and debates, but in the actual coding you may have not had the chance. It may also be possible that at one point in your career you did code heavily but in the recent past or for a long time you have not.

Are these assumptions correct?

If so, the path to getting past your issue is to just start coding. Get hands on. Be involved in the heavy details and the specifics of development. Take the responsibility to code and don't leave it to junior developers; struggle through the issues.

Software development is a lot like sports. Your concerns would be a lot like saying "I know all the rules of basketball, I watch lots of games, I know all the players, I love the sport, I can have lots of conversations and I know where to buy basketball gear. But when I shoot baskets once in a while, like once a month, they never go in. What do I do?" What would be the answer to this! Practice, Practice, Practice.

I hope this analogy helps. I would assert that there is nothing wrong with your intellectual capacity or ability to program. What is lacking is hands on practice, and you must summon the will to acquire this.

Just be a project manager.Developer and Manager should be diffirent.You canot build software on one man show.Developer hard to find and also SA or Project Manager.Ability tounderstand and ask the customer requriement and changes takes a lot of patient.Coder is for yougster or to whom which have objective.Coder also got two type.One type just follow order.Another type just wanted to reinvent the wheel to .....

Not that this is necessarily worth a whole lot but I think your problem is more fear than anything else. If think to yourself, "how do I make the best possible design, like a great designer would" that is going to really hurt your ability to let your mind relax and be able to be creative.

I have been programming for 14 years and don't have a problem doing so, but if I was faced with that task I would have a hard time being able to think of anything too. I think your best bet is to: A) First recognize that you don't have to make it perfect B) Just practice small programming projects and just write the code for it. If it sucks so what? Once you get habit the solutions will naturally appear when you see a problem. C) Once you feel comfortable with B then start learning more about proper designs and what not.

I can't say this is the same problem but I have a lot of CS students I talk to who have learned all these algos in class, but when faced with programming the simplest things they have a hard time. Mostly because they haven't really learned to think and tackle the problems, their mind just hasn't acquired those skills through programming. So they say "I've been through 3 years of intense CS but I feel like I'm not cut out for it".... That is sad I think.

So if this rings a bell, just keep working on small projects, it'll come with a little time.

If you really want to stay with programming job, try to refresh your programming skill. Creating small tools or pet projects can be a good exercise for you. Building app from scratch is not as simple as modifying codes. You will need experience on it.

Don't give up.

You will be very good if you stay in System Support / Maintenance team.

There are 2 types of programming job - 1. Design , and 2. Support

The requirement for these 2 groups are different. If you go into Design group, you will need to think solution out of nothing :D If you go into Support group, you can read the existing code and do bug fixing.

Just find the job which fit your talent.

I think you should just sit down and start a personal project. You could use Python, C++, Java, C# or anything that meets your fancy. You could even try Ruby - it's a very, very expressive language. Seems like you just need to write some code - whatever it maybe. And maybe read up on design patterns and best practices. Just don't give up on coding!

As you said you can debug the code and fixed code. And S/W engendering theory said that every S/W need 25 % bug fixing time in its cycle. I think you have lot's to do here in development.

There is scope for you and it could be one option for you. I think.

Programming, in my experience falls under 2 general categories:

Scientific Computing

This is the programming that requires algorithm design and a strong analytic background. To become better at this type of programming, ironically you shouldn't program at all, but instead read about different algorithms (usually in pseudo code) out there and analysis of those algorithms (this part requires the analytic skills.)

Software Engineering/Development

This is the type of programming that requires you to understand the OS you are working on, memory management, how a CPU works, etc. It includes development of applications. Ironically, you can get much better at this by actually reading about known software patterns then actually reinventing them yourself. However, in this type of programming you will benefit far more than the other type from experience. The more you actually develop the more familiar you will become with your main tool: the computer.

Usually, the line between these two general categories is pretty thin. When you program you will find yourself usually involved far more into one or the other. I recommend identifying which one you need to become far more familiar with and take the appropriate action.

If you actually like programming and want to get better at it, here are two books that will help you:

• David Gries's Science of Programming will teach you how to be precise and exact about programming with assignment, loops, and arrays, and it will help you develop systematic methods for specifying problems and finding code to solve them.

• Udi Manber's book on algorithms will help you practice creative thinking and the invention of new algorithms.

If in a year from now, these books changed your life, please let me know!

Wow, I can really identify with you. I feel like i'm in a similar boat, but in the end i decided as angst-driven as i feel about my weak programming skills i can't imagine doing anything else. I have great work ethic, my managers love me, i get my tasks done quickly, and i haven't really heard anyone cry because they had to work on my code.

I don't work with other programmers often, and usually i'm working on the code of very talented people. What sort of help me stop moping so much was to work with a TERRIBLE programmer, who had no idea WTF they were doing. I might not be the 'guru' programmer supergirl who can whip out that never-before-see use of technology but i was better than that guy. ;)

You have to decide if you like what you do, could see yourself doing anything else, and if what you do write is going to cause anyone any grief.

Maybe look more for a junior position where you can grow in different kinds of programming. My problem was i worked for the same company for 7 years but their needs were very specific. Resume wise i have all this experience, but so very limited. When i moved to .NET at another company i really felt out of my element, but each new project i learn SO much more.

Take a look at my "Building Skills" books -- you're part of my target audience.

http://homepage.mac.com/s_lott/books/index.html should work

I can identify the source of a bug quicker than anyone I work with.

That's great, and very useful. So if you want to play to your strengths, find a job fixing other people's code. So long as there are programmers, there will be no shortage of bad code.

Do you want to code? Then figure out how to get better at it. But if you don't, then own up to the fact, and look for jobs that don't have you doing what you don't want to do.

Some things that could help:

• Write a program for yourself, something you want, so you've got the motivation to get past the tricky bits;
• Pair with someone who doesn't have your problem getting started, and learn how s/he does it - ideally by having your pair help you through it, rather than simply watching him/her do it.

I suppose the word 'guru' in your title refers to yourself.

It's hard for me to understand how anyone who does not have the talent to write a new program from scratch, can possibly be labeled a 'programming guru'.

Furthermore, you say that your qualities are, and I quote, :

"I generally communicate well, present myself well, know the 'jargon' and know a lot about technology at a high level".

Well, let me tell you how I would react to that if I were taken to task to interview and select a "good programmer" :

"Communicating well" has nothing to do with (the basic skills involved in) programming. Except maybe in paired programming, but I personally don't believe that effectively putting two programmers in front of one computer pays off.

"Presenting oneself well" has nothing to do with (the basic skills involved in) programming.

"Knowing the jargon" has nothing to do with (the basic skills involved in) programming.

"Knowing technology at a high level" (and I take that to mean "at a high level exclusively") is exactly the opposite of (the basic skills involved in) programming.

If it were my task to recruit "a good programmer", your resume would go directly to the bin with me.

From personal experience (and I too have a similar problem when it comes to starting to write code or embarking on a project) is to first identify things you can do that are related to the problem. If the problem is, for example, writing an algorithm for graph traversal or similar then perhaps read up on graph algorithms, code some of the examples and then think about how you can adapt what you know or have learnt from that to apply it to the problem at hand.

Finding a good (and efficient) solution will inevitably take a lot of researching, thought, time, effort and probably quite a few cycles of implementation. It's not about getting it right first time - more about building on a basic (possibly even bad) solution and improving it step by step whilst moulding it to solve your specific problem.

Are you trying to come up with too good of a solution?

It's easy to get yourself in the trap of not wanting to do something wrong early on in a project. You can get locked in analysis paralysis and question every decision. After a certain amount of consideration regarding the best practices of the day, you just have to take the plunge and start writing code.

While it's not something we usually get much time to do, it's good to remember that we can always refactor later if a bad early decision causes us to create some messy code. I usually try to sneak that stuff in when I finish something ahead of the estimated delivery date.

You know too much. Analysis paralysis. Over-analyze. This is my take anyway, as I probably am the same way.

Reminds me of one of the Star Trek episodes when there was a robot or something that simply couldn't make a decision. It's like a computer stuck with an unsolvable problem, whirring away.

This is partly the result of the software world today - we are expected to know 6 or 7 languages, front-end, database, network, OS, hardware, commercial apps, your resume is probably littered with the clutter of hundreds of technologies (CORBA, SOAP. REST, Java, Spring) that are useless in your next job, yet when coding, you must sort through all that knowledge before arriving at the solution.

So I've got an idea on the issue, and the possible solution is to churn out solutions faster. As you start to go down the path of writing something, and then your mind starts to think, wait, what if I employ the observer pattern here, would that work? Or should I use an EJB? Throw it away! Trim you indexes. Shorten your retention span. Still the mind through Yoga. Focus on the current problem, not the perfect solution. That's how we got to stuff like EJB and Spring in the first place. "Oh yes, we'll put all the logic in XML and it will be great!"

Surely it's not so important how quickly you produce actual code as it is the manner with which you go about thinking up a number of solutions, choosing the best 'before' you write a single line of code.

I had a similar problem. I do understand very well all aspects of software technology. I can learn very quickly how things work. but when I have to create something it becomes very difficult. Not because I don't know how, but I don't like all the details that I should handle. I suffered the same thing for some time untill I understood what was the real problem. I am not lazy and I enjoy software developement very much. But I don't have patience and I am eager to see the efinal result. So what I did is work on the solution on a high level and then give instructions on how others could continue. I am happy with this even though sometimes I find it difficult to explain something that in my understanding is so obvious but not in the others heads.

I would love to work with a guy that immediately sees what is wrong in my code and/or how could be improved! Some people are good at starting projects, others are good at polishing it.

It may even vary between different fields: as a photographer I feel the other way around, as I am good at improving other's photos, but I might lack some creativity for my own work (this is why as an artist I usually focus on rendering the emotion and being pretty good at that, rather than trying to be creative and fall short - but that's another story).

Anyway, a team has to have both skills to be performant, so don't be ashamed, you have a precious (and, I'd say) rare skill for any software project. And if you can't find an employer that understands that, then don't hesitate: become a consultant and add in your expertise to other's projects.

• Life long learning

Get a book on ruby on rails and an interesting hobby project.

Instead of talking down about yourself, retrain, your experience will be valuable and all software developers need to constantly learn and adapt.

That said:

if self.love != self.profession {   
  self.profession = self.love.profession // you only live once 
}

I'm a programmer and a song writer. It's not possible to imagine either an application or a song into existence from a completely blank slate. Luckily, you don't ever have a blank slate when programming. When writing a song, it's far easier when you have a seed of an idea to start with and some constraints. The more constrained you are, the more artistic you'll find your creation is.

In programming, define the constraints of the system better and you'll soon figure out the best way to deliver a solution that works. Personally I worry more about performance and maintenance over elegance.

It's a shame that the most simple, maintainable, and working solutions get the least reward in the corporate environment. If you make something look easy, managers think it was easy to develop. If you make something overly complex that breaks in exotic ways during production, you become a hero for being the only person capable of understanding and fixing it!

Unlike playing a musical instrument, in programming nobody will ever remark "Wow he makes that look easy" because they'll never have to write that same piece of software and they can't see or hear your though process, and hindsight is always 20/20.

I meet people like you, that is good to maintenance, but not so good to create things. It's normal.

I prefer to create things, and I feel happy and comfortable doing that.

My Project Manager became a Program Manager because of the same concerns which you seem to have. But fortunately or unfortunately for him, while being a Program Manager he had to sit and put some quality hours with the development and testing team [P.S: Small companies aren't so tacky with resources, i mean there aren't huge number of people writing a small piece of code everyday monotonously.]

But now after getting his hands 'greased' again, he has sort of reinvented his technical acumen, quit his job , and went for an out and out Architect's role.

Impossible is Nothing. Just TRY .. you ONLY need to prove to yourself, rest all settles down by itself.

Regards..

I think you want to improve yourself more and more. You can be a really good project manager(i wrote as a junior:)

Try out a few different languages and see if any work for you. Programming is a pretty diverse art, which could probably accomodate most people who are interested enough to frequent sites such as this. Personally I know there'd be situations in which I'd struggle (basically whenever I can't get the IDE/compiler to do all the heavy lifting for me)

If you did so many projects and you see everything faster and making it better as other programmers you need to be very creative man, but I think that your problem is you yourself. You can't do something under pressure, then losing your mind. You will never ever be a good developer, because you can't change yourself anymore.

I would like to add to this that Test Driven Design (TDD), Behaviour Driven Development (BDD) and arguably Domain Driven Design (DDD) are all frameworks to solve this very problem. Your problem is green field projects, arguably IMO some of the more interesting projects. The first step in designing anything is to obviously figure out the very first thing you want to do, it doesn't have to be the right first thing, heck you could pick anything almost, just not the UI. You should always leave the UI for last, now with that said and following TDD. All you want to to do is write a test, the test will test a problem, you will solve this problem, your test will pass. Voila, you have a starting point, extend upon that test, when that problem is adequately solved for the time being move on to another problem.

By problem I simply mean a business problem, thats what software is for, to solve business problems so defining your baseline like this kind of makes sense. As you get better you will be able to move quickly in this manner.

Big up front design is no longer needed, in fact at first you don't necessarily need to put any thought into up front design. Once you have a bunch of tests written and a decent baseline the solutions typically just occur to you as you go along. If they do not, you at least know what problems you are going to have or might have, if you don't just keep going till you do, if you need to refactor your code you can do so easily because you have unit tests to rely on as a safety net.

I am sure you have heard this a million times, but it does actually work I assure you..

Leave the industry. Godknows there are aleady too many pretenders who cant or shouldnt be coding because they cause more chaos and headaches than they solve.

If you need help in preparing for the programming interview, try reading Joel Spolsky's blog site Joel on Software. He's awesome, and this article in particular is helpful:

http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html

It's The Guerrilla Guide to Interviewing, and it is really helpful!

Learn a musical instrument. Playing music is an enjoyable activity which has the property of 'tempo'. A big part of it is consistent, forward progress, and you can't go back and fix mistakes.

Try a few small projects in a low-level language that are a challenge for you technically. Maybe some kind of gray-hat hacking if you aren't already familiar with that discipline. Specifically though, work on stuff with very little UI or large project organization.

Develop the ability to throw away all the things that you'd wished you'd done differently over the years in order to approach it with a new mind. Imitate those who don't know any better.

Being a good programmer is hard work. You need to spend a lot of time on it. But there are actually structured ways of doing things. This is not magic, follow these steps and you will be on your way.

Understand Your requirements. Why: You cant develop a solution if you are not clear what is required.

Read up on archetecture books and Look up modelling techniques, orm diagrams, sequence diagrams, component diagrams. Why: Creativity can be an ad hoc process, this is a structured why of understanding problems and coming up with concrete solutions.

Study your language. Why: so that you know what is possible and what isnt.

Study your environment/platform: Why: So you know what the technology can do, such as servers and networks, browsers, operating systems etc

Look at other peoples code, and design patterns. Why: Nothing is ever entirely new, you may have come across this problem in a different context.Making it easier/quicker to come up with a solution.

Maybe you need to turn the whole thing around. Instead of beeing the stadard type of programmer your every teams dream! Someone who can write code like an maniak. Lots of programmers start and get a job because of there programming 'instinct'. And they write code to. Well if those guys can leave the code writing to you, the code become less issue for them with means you'll save a hack of time for the team making it effient and fast. Your one-of-a-kind developer. Use it in your advantage!

Have you think about reading some books about programming architectur? Just to see how they come they come up with a generic structure of the program?

Or you could try (if the lazyness isn't too big) learning some of the patterns beacaus your problem is all about that! You have already seen alot of problem i supose but you cant deals with them.

It could be a good way to gain some agility when you start a project from scratch and the biggest part it could be a good way to gain back your youngster willingness to program the world :D

If you can cut it, then it's probably easier to stick with what you do moderately than switching to something in which you really wouldn't have any applicable job history.

I don't think you should choose another career. There's a lot more than coding to software engineering. There are plenty of developers with deficiencies in various areas. If you can get a job where programming ability isn't at a premium, that should give you a chance to be useful on a team and work on your problem-solving skills.

To me it sounds like you need to find the right type of job. From what you've told us startups and younger projects are not the place for you. If you are to take any of these types of jobs you'll find yourself overwhelmed.

You would probably do very well to be maintainer of a legacy system. The patterns are already laid down and adding anything new would just be a replication of those patterns.

Also I would suggest looking for a company where you will have strong management above you to help manage your time and tasks. This will prevent the "I just can't start" attitude.

Next to help you solve the real problem.

Start reading about design patterns and give yourself some sort of mini-project. Work on it for a few hours every night. Treat it like you would (or should) have treated a homework assignment. Once you start being able to recognize the patterns you'll find starting from scratch isn't really that hard.

Next I suggest reading code. Find smaller open source software projects and just read through the source code. You hint at being good at being able to track down bugs so this shouldn't be too hard. But instead of looking for a bug, look for the architecture. Depending on the size of the project it shouldn't take too long for you to come with an overview of the entire codebase.

If you can't build applications from scratch you have deep lack of knowledge with regards to Software Development Methodologies (UDD - TDD - WTFDD). Read a few god books about that if you're interested in overcoming your limitations. If not - as someone else said ... get a Master in management and pursue that kind of career.

Well, the big question is, what do you want to do? Do you want to program, or is being a PM/tester an option?

If you do want to choose programming career, you can do two things.

Number one, you can specialize. Programmers very rarely need to start from scratch. If you are joining the existing team, and if it's not your job to build a team, you'll probably have similar aplications you can start from. My team even has "application template project" which gets copied to new project and tweaked to create a new app of the same type (and with type I mean web app/deamon-windows service/GUI). Especially in big corporations, you'll rarely be in position to start from scratch. Actually, you're in better position that most programmers - average programmer is not happy in typical corporate environment because he has that irrational itch to "create something from scratch." You just have one less itch to stratch, and it can be a good thing. :) Seriously, you don't have to be great at all things. I suck at math, and thus mostly avoid math, and I don't feel lesser programmer because of it.

And number two, if a think it's a problem worth solving, look into your problem and solve it. Analyze your thinking and dissect your problem until you get to concrete things you can improve. So you have a writer's block - but what's that made of? Are you afraid you won't do good enough or don't know enough? Do you have problems with decomposing problems into smaller problems you can code through? Can you remember solution to similar problem you've seen? Have you encountered anything like it before? Can you pick a teammate's brain on the similar problem and watch how he solves it (pair programming)?

I'd guess that your "problem" is twofold; first part is fear which blocks you from solving it, and second part is simply no experience in solving specific set of problems. First part can be analyzed and decomposed into small problems with easy answers, and second part can be learned. It's usually not simple, but it can be done.

Unfortunately there are no programming psychologists around.

Actually there are.

Google 'Gerald Weinberg' (but call him Jerry). His current site motto is 'Dedicated to Helping Smart People be Happy', but it's been a career-long obsession for him, and he's part of a community of like-minded people.

For a little investment, google and read his blogs.

For a larger investment, look at his books, perhaps starting with 'More Secrets of Consulting' as it's focused on helping technical people/consultants be positive when mood and circumstances threaten, and 'The Psychology of Computer Programming' to help see that there is not a single personailty type suitable to programming. Also consider 'Becoming a Technical Leader', which gives great practicals on how to get better at something you're already doing, and how to choose new things to learn, among many other things.

For an even larger investment, consider the annual 'Amplfying Your Effectiveness' conference, hosted by Jerry and a number of his like-minded compatriots (you may have heard of Esther Derby and Johanna Rothman, but Don Gray and Steve Smith are also tremendous people). It's a small (99 person) conference, and you'd meet a great many amazing people who have reinvented their jobs and careers (or decided to stay put) based on the principles and practices the conference offers.

Very roughly speaking, it turns out that technical people are humans too, and need to be treated as such, something that doesn't get covered in CS courses or HR departments :)

I wish you well, as I sometimes feel like I stand in your shoes.

While I can offer no advice, I just have to say that I'm almost exactly in the same boat as you!

I've been a software developer for more than 15 years. I've been on the core team working on very successful products. For the past 5-6 years, I've been standing on the sidelines correcting other people's work. In hopes of gaining some respect among fellow developers, I failed at the last big project I "owned" at my previous company. Most of my time has been fixing other people's code. Many times over I've thought about getting out of the business and still haven't ruled it out.

I feel I'm competent at what I do. My approach may not be considered textbook compsci, however I can usually get the job done, sometimes admittedly not in the most efficient way possible.

I'm watching this discussion to see if it offers any advice for myself...

I highly appreciate your honesty. You could be a good trainer to guide the people. If you are a productivity geek then you can jump into Management.

You should pursue ur passion. It seems u have been working on large scale projects this is the reason y u haven't gained confidence in writing ur own code. So u better set a simple project for urself and program it urself. I hope u'll gain confidence after completing 2 or 3 projects.

I'm a little confused. You've said you have worked on tons of big projects at your company at the past? Were you actually programming or involved in some other way? Either you programmed or you didn't

There are two questions being addressed here: Can you program (write lines of code that produce a workable product - not come up with the idea or implementation, but just write the lines of code)? If you can, then to some degree technically you are a programmer. You can write a program.

However, the other issue is: If handed a problem, could you come up with the answer that you actually write the lines of code for? If you have programmed in the past, I don't see how you could of not done this. Yes, maybe you didn't come up with the whole idea for the software program or web app, but given the sub-problem of X you come up with the answer and coded it.

If this is the issue, then you can program and I don't see why you think you can't. Yes, maybe you shouldn't be the idea guy, but why not a team player. Besides, it takes time to become a good programmer (the guy who seems so good his pours ooze goodness). You have to learn about things like design patterns, best practices, etc.

My suggestion would be to consider one of two routes:

1. Change your job description - In this case you'd become a project manager, tester, group manager, or business analyst to give a few examples. While there may be some creativity to these positions, there are a lot of best practices that can reduce how often you are working from scratch.

2. Find work within your strengths - In this case you are looking for work where you'd be given a specification that details what code has to be written so that you aren't writing something from scratch. Rather you are given detailed instructions of what the application/web service/whatever is supposed to do which merely means you are translating requirements into code, possibly using a given architecture and components that you are connecting and just providing plumbing.

I'd likely consider what you want to do as well as where you have skills as while you may not be great at creating solutions out of thin air, there is a lot more to development than just that piece of the pie.

It takes practice to code/think up brand new solutions. How long have you been programming? Maybe you need to quit letting yourself get in the way of yourself!

But if you've been at this for 10+ years then yes, perhaps you should only be in the testing/maintaining gig or get out of the industry.

I think opting for a different career is a big decision and it might be NOT the right one for you. You know what, nobody is born with a creative mind. People observe, learn and then implement their observations and learning to find answers for their questions. We all create something (big or small) on day to day basis, but we don't realize it. For example, people smartly fix things at their home. How do they do it? They analyze the problem, think about possible solutions and then implement the smartest one which will save time and money. Quite similarly we do things while programming. It's all about thinking.You already have the biggest asset with you- "Knowledge". You just need to think freely.And believe in yourself. Erich Fromm once said- "Conditions for creativity are to be puzzled; to concentrate; to accept conflict and tension; to be born everyday; to feel a sense of self."

So..start thinking and you will see the light!! :)

Think of this differently,

you are not a "creator", you are a "Copy and paster" and you do that better than most. I'm kinda in the same boat.

I am headed in the Project Management direction.

I think you should learn system administration, maintenance. This indeed also has a learning curve to it, but here you can be in the IT field without coding and have also have a good job.