13

I need to know how to handle panic and anxiety when it comes to code writing. It's my first time when i am working as a programmer, just graduated and got my first job, but I really get nervous when I need to write code. I'm looking for some of your experience and how you got over this, how can I concentrate.

It's like I'm afraid to write code or even to speak, and I get real stressed about the though that I may get fired. I'm quite sure that maybe I'm not the first and only one having this problem so I'm looking for some advice and pointers.

OK, maybe anxiety is not the best word, nervous and not confident are maybe best to describe the feeling.

And yes I'm afraid that the code which I will write it will not going to be good enough, the project on which I'll be working it's quite old I think 5 years maybe and I can't get how thinks are binding to each other, the logic seems on some places very complicated especially in jquery and javascript which I have not come in contact until know.

I feel like the rest of the team is in a whole different league and I'm like "what the hell am I doing here? I cannot breath like that guy writes code"

  • 7
    October, it might be good if you explained what your anxieties associated with writing code are? Are you anxious that you'll spend development time and it won't compile? Are you anxious about writing in a language you're not familiar with? Do you have trouble following the logical flow? Also, this may get moved to programmers or another more code oriented site. – Sidney Nov 11 '15 at 19:34
  • hello, consider editing the question to make it better fit site topics laid out in help center. In particular, this guidance may help to learn what is expected of questions here. Good luck! – gnat Nov 11 '15 at 20:39
  • October, I presume you're new at code (if you went to school for it, you probably were only taught C/++, and Java I'm guessing). If you're in a coding profession, and you think you'll enjoy it, it might be worth spend some time playing with Javascript, PHP, MySQL, SQL, PL/SQL, C#, Ruby... Really, the more structured languages you know, the easier it will be to learn new ones. One of the things I like to do when I'm bored and want to flex my noodle is go over to codegolf.stackexchange.com and try and wrap my head around some of the answers (but not the esolangs, those are terrible!). – Sidney Nov 11 '15 at 22:20
  • @october: thats because you don't know it but that's ok. This is learning curve anxiety mixed with a feeling of a time crunch. Start slow, start small, TAKE YOUR TIME you don't need to understand the whole application (even though it feels like you do). Obviously you are new to the job and language, so you are going to be learning on the job and producing at the same time, just not at the same rate as the people who have been doing it a lot -that is why they are getting paid much more than you. There is also an illusion that you are looking at "perfect code" - you are not. GO SLOW. – Greg McNulty Nov 12 '15 at 2:00
  • "The project on which I'll be working it's quite old I think 5 years maybe and I can't get how thinks are binding to each other, the logic seems in some places very complicated especially in jquery and javascript which I have not come in contact until know." Sounds like a typical ball of mud. Don't be intimidated. Your coworkers aren't gods (although some people mistakenly think they are). – jpmc26 Nov 12 '15 at 2:31
9

That sort of anxiety sounds rather unusual, and possibly unhealthy.

Why do you feel so afraid? Have you not written applications before? Have you not gotten any praise from your instructors?

You KNOW (I assume) what you're doing. Take it easy. Breathe.

Write your ideas down and keep track of them. If you're unsure of yourself, ask someone to review your approach. Don't be afraid to say "I don't know how to do this, but I can research it and find out".

Every time I've started a new job (5, counting all my co-ops) I've been "the noob". As the new guy you're not familiar with their code base, their projects, architecture, etc. Diving into a 6000+ lines of code application and trying to figure it out for scratch is daunting. I find it takes me something along the lines of 5 - 6 months until I start feeling comfortable in a new position - that I'm familiar enough with the projects, etc.

Take it slow, and don't clamp up. The key is to communicate your ideas and concerns.


Edit: I have only been working for 3 years - graduated in 2012. Maybe I was just a little bit arrogant, but I thought I was pretty good when I started my first job. Boy, was I wrong. I quickly figured out that I had a LOT to learn, and put my nose to the grindstone. I didn't panic and just studied the new techniques I was being exposed to until I knew what I was talking about. Now I just accept that I'm always going to go through a "omg, wtf is this" moment when I look at a new project, and just internalize that fear and dive in.

  • 10
    Funny how school and real world differ so much. – Dan Shaffer Nov 11 '15 at 20:00
  • I think the biggest advantage that school gives you is that it a) gives you a foundation on which to build your skills/knowledge and b) teaches you how to "conquer the unknown". No schooling can 100% prepare you for the real world - you need to go out an experience it. But I'd rather do so after getting some solid training, than completely clueless. Co-ops are INVALUABLE in this regard. – AndreiROM Nov 11 '15 at 20:03
  • A biostatistics instructor turned to my class unprompted in the middle of an example and said to us "We give you these really very nice equations that can be solved with some effort. Back when I started in my field, my first project they gave me some data and told me to model it. It was really a nightmare." And then he went back to writing. The result, some years later: he's terrifyingly good at what he does. – CKM Nov 11 '15 at 20:07
  • 2
    The thing I have found with higher education is that there is no way they can give you everything but what they can do is give you the basics and teach you how to learn on your own. I was never taught any frameworks in school but went and learned: bootstrap, rails, codeigniter, jquery and angularjs on my own. Always continue to learn! – Resistance Nov 11 '15 at 20:42
  • @TStauff - that's the way to go, brother. I have been lucky at my latest job. I'm working with some senior devs who are very knowledgeable, as well as friendly and helpful. They have happily pointed me to the most useful technologies that I should study for this job, as well as spending time explaining it all to me. Some days I don't even feel like I'm "at work", but more like I'm back in college. At my old job the senior dev didn't even learn my name for a year, and on the rare occasions he spoke to me called me "FNG" - f***ing new guy. Big difference. – AndreiROM Nov 11 '15 at 21:00
6

Like others who have answered before, I remember my first job and assignment and feeling waaay over my head at first. The code was doing complex things that I hadn't been exposed to in school. I was also early on in my career thrown into a team of senior devs with lots of experience which at times is intimidating.

Do your homework

As others have mentioned, the first thing to do it become familiar with the technology stack by doing tutorials, reading documentation, and personal projects. One big difference between college and work, is in college you write everything yourself. Need to sort a list in college? Write a quicksort algorithm. Need to sort at work? Find a library or built in language method to do the work. JavaScript codebases in the workplace will be using many small libraries together. I recommend looking up each and at a high level understand the role each library places. For example, you don't need to know every JQuery method to understand that $(...) means the DOM is probably being manipulated somehow.

Seeking support from your team

Once you feel like you can ask intelligent questions, here are some suggestions:

  • Ask a teammate for a design review. Nothing formal, whiteboard and wavy hands are fine here. But describe to them what you think needs to be done to solve a task, and listen for their input. If you are going off in a bad direction, this gives them a chance to correct course early on and gives them a chance to mentor you. As you become more confident, this can show off your design chops.
  • Ask a teammate to code review. If there is not a formal review process, ask a teammate to go through your code. Again, approach this from a mentor/mentee perspective. They should look for obvious errors and edge cases, but you should also seek feedback on style and best practices. This can be a chance for them to give tips and tricks of the trade.
  • Ask to pair program with a teammate. This may get some resistance depending on your work culture, and a junior developer instigating this may make this awkward if the senior is not accustomed to pair programming. The idea is to be sitting next to the senior and learning right next to them. This helps learning the parts of the code base in a focused manner.
  • Know that impostor's syndrome is real. You mention fearing being fired from bad code, and that screams of impostors syndrome. Take a deep breath. This is JavaScript. Mistakes happen, just learn from them.
  • You might want to read my book Programming Without Anxiety about giving and taking review comments. Covers lots of stress sources with mitigations as well, hope it helps. – ron Aug 10 '19 at 7:47
4

As a new programmer in the workplace (started in May) I believe I can answer this. I had the same fears when I first started. I would get nervous submitting my code for review and generally second guessed myself.

I got over this by writing personal projects at home and getting confident in my code itself. I believed I didn't know much (look up impostor syndrome) and it caused me a great deal of stress. However after delivering multiple working projects and having some that have been sold to customers and made the company money, my fear started to go away.

I still get nervous but not to the same extent because I know I do provide some value. Do your best to find a personal project or two to work on and build up your skill and self confidence. Nobody knows everything in coding so learn how to learn and grow my friend.

Good Luck.

4

It sounds like your experiencing general anxiety in the workplace about being the new guy and not being up to par with (I assume) seasoned coders. This is pretty normal, and can be generalized to any workplace. As far as not being on the same level as your more senior coworkers, to boil it down quite simply, you're not; the problem comes when you don't recognize and fail to do something about that.

First and foremost, take some time to review the technologies you're unfamiliar with; while it may be irksome it won't hurt to take some time out of work to do that. SO can be a great place to answer any specific questions you have, and by answering specific questions, you will get a more general understanding.

It also sounds like you're afraid to ask you coworkers questions for fear of being considered foolish. If the logic is too hard to follow, don't be afraid to ask about it. I'm not saying you should be asking about each for-loop or function, but it'd be good to ask if you're not sure how something's being accomplished; your coworkers will find out you don't know one way or another (and will prefer being asked directly instead of having to debug a bug you may have inadvertently introduced)

3

And yes I'm afraid that the code which I will write it will not going to be good enough

It definitely, certainly, for sure will not be good enough.

It won't be good enough until:

  1. After you've finished writing it
  2. After you've reviewed it
  3. After you've tested it
  4. After someone else has reviewed it
  5. After someone else has tested it

Don't expect the code to work i.e. to run before you've finished it.

Nevertheless learn how to test it often so that you can develop it incrementally.

I'm looking for some of your experience and how you got over this

It helps to know what the acceptance criteria are.

In my first job, they had complete automated system tests for the software. My changes had to pass regression testing, and pass new tests (which were written by someone else) which tested that I'd fixed whatever bug or implemented whatever new feature I was supposed to.

In a later job as team-lead I knew I had vast advantage over new hires (more experience in general and more experience with 'this'/'our' software) and didn't expect them to be my equal. I wanted them to learn to work well, e.g. to finish and test their changes before submitting it; and to learn the right balance between reading the code to figure it out for themselves, versus asking questions about the code and about the requirements and about the process.

After six months or a year (after being hired and of being mentored on demand), the best ones among the new hires would be relatively independent (i.e. no more dependent on their team-mates than the other more senior programmers).

And yes I'm afraid that the code which I will write it will not going to be good enough, the project on which I'll be working it's quite old I think 5 years maybe and I can't get how thinks are binding to each other, the logic seems on some places very complicated especially in jquery and javascript which I have not come in contact until know.

If you're lucky, someone (e.g. whoever wrote it) is available and can tell you how to implement what you're supposed to, i.e. walk through the source with you and tell you (orally) what you need to change and where. That can save you a lot of time.

javascript can be weird-and-wonderful. A colleague/mentor at a previous job recommended I read JavaScript: The Good Parts because they used and expected those techniques in their code-base.

I cannot breath like that guy writes code

It probably took him a while (to write it and to learn to write it). To catch up, you have to start.

If you're working full-time that's abut 2000 hours/year, so...

How to overcome anxiety when writing code

Some famous advice from 1975 was, "build a system to throw away, for even the best planning is not so omniscient as to get it right the first time".

Then, "throw one away" meant "write a whole system, throw it way, write another".

The modern way is to "refactor" which means "write a whole system, and then change/evolve it to make it better".

Another adage (this one is much less famous, I read it in Systemantics) is "A complex system that works is invariably found to have evolved from a simple system that works. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system."

It's like, imagine your software is a human being: how do you write a fully-capable adult human? How do you even start? An answer is, you start by writing a baby.

1

This is fairly normal, you might feel a bit lost and outclassed for a while. But just be realistic and pragmatic about things and don't let anything get to you.

The others there look like supermen because they know that code inside out, but so will you if you hang in there for a few months. Throw those supermen in the deep end somewhere else and you're nearly the same as them. It's all about experience, and you don't get that unless you take the time and focus.

Once you have settled into your work you will start producing and gaining confidence and it's all uphill from there on.

-2

Your code will be as good as the requirements that you are given. If you have any questions about the business requirements, escalate them. Make sure you review your work to ensure your product meets those requirements as provided. Document your work so if there's a break-fix at a later date, someone will understand what you did.

The best coder I worked with on my last project was a co-op student. He really listened to what my pain points were, and turned out a great product. I feel for coders because very often they don't fully understand the business need, and business is not always great about how they explain things. Thank goodness for Test environments before things move to Prod.

  • 1
    This answer doesn't address anything that others don't already. – Michael Nov 16 '15 at 0:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.