Help, I just graduated but I don’t feel like I know how to program!

There was a great question on Programmers about graduating with a programming degree, but not knowing how to program. I see this kind of question a lot, and I felt the same way when I first got my degree, so I thought I’d write about my experiences and what I learned when first started programming.

This was originally an article I wrote for the Programmers.SE blog, however the blog doesn’t appear to be happening at this time so I am posting it on my own blog instead.

Start with baby steps

First off, don’t expect to be able to code enterprise-level applications or the next Facebook right away. You really can’t become a good programmer without a lot of practice, so practice any way you can. This can include hobby projects, reading books or source code, or even answering questions on Stack Overflow.

The book Outliers: The Story of Success frequently states that to become a master in any field you need to practice it for a total of 10,000 hours. In case you don’t want to do the math, that’s about 3.5 years of programming 8 hours every single day. If you only program during business hours at work, that’s almost 5 years.

Don’t discount your education

Rachel - Graduation Picture
When I first started working, I felt my education was worthless; that it just taught me stuff that was never used in the workplace. I soon realized it provided me with something better than syntax: it provided me with a good foundation for programming. For example, it didn’t teach me design patterns, but it did teach me what design patterns were and how / when to use them. And I might not have built a data access layer in my class projects, but I knew what they were for and when to use them.

It also provided me with resources such as books, an online library, and networking contacts in the industry. In addition, it gave me a fancy piece of paper which can be very useful for getting your foot in the door when you don’t have experience.

Of course, it didn’t teach me everything. Looking back I wish I had been taught about things like Version Control and Unit Testing. But they did their best to provide me with a solid foundation to build upon in the short time I was there, providing I was willing to go out there and keep learning.

Always be learning

One of the first things I got taught in college was that to be an IT professional, you really need to be a life-long learner. You can’t just graduate and expect you’ll have everything you need to get a high-paying job for the rest of your life. You’ll need to be willing to spend the rest of your life learning new technologies and languages.

Whenever I come across something new, something I don’t understand, or something I’m not sure of how to do, I Google it. Most of the time I can find a simple definition or samples, and I can start from there. If I do start from samples, I hate just blindly copying/pasting. I always take the time to understand what the code does. It might be slower to start with, however once understood it makes me that much better of a programmer.

Remember, N years of experience means nothing if it was simply 1 year repeated N times. There are plenty of jobs out there that are that will let you accumulate years of experience without you ever needing to learn anything new, however I feel you simply cannot be a great programmer without continuing to learn.

Steps to success in programming projects

Here is a list of steps to success in any project as a new programmer:

  • Be positive when asked if you can do something.

    If someone asks you if you can do something, be positive in your response. Answering negatively, or even indecisively, will often result in a lost opportunity to learn and grow, so avoid that unless the task is truly outside the realm of possibility.

    I usually use terms like “I don’t see why not” or “shouldn’t be too hard”. You may not know how to do it right away, but you should have the tools (Google!) and intelligence needed to figure out how to get it done. I like to avoid actually saying “yes” unless I know I can actually do what is being asked.

  • Determine requirements.

    Sit down with your client (boss, customer, etc) and figure out what they want. I’m not going to go into details of gathering requirements here, but do take the time to draw out the screens they expect to see, and to determine the expected input / output. My favorite tool for screen mock-ups is Balsamiq (its free!).

  • Figure out how to build it.

    This is one of the most important steps. A huge part of programming (especially early on) is figuring out what your client wants, and then learning how to do that. Don’t just stick with your own knowledge base!

    For new programmers, I would suggest just focusing on just getting the desired results. Don’t get bogged down trying to learn design patterns, architecture, test-driven development, etc. Learn the basics of how to program first, then expand on that knowledge. And remember, keep it simple! You don’t need an enterprise-level solution for the FizzBuzz problem.

    At this point, if you determine that the project is completely out of your scope, say so. Even if you determine the project is far too large or complex for you to build, you will have at least increased your own knowledge, so I always see it as a win-win situation.

  • Build it.

    You might think this is the hardest step of all, but in reality it will eventually become one of the easiest ones. Gathering the requirements and figuring out how you’re going to build the application are much more important, and if done right, it will make this step a breeze.

    Of course, early on in your career this step will be the most time-consuming and frustrating one. It will likely consist of a lot of trial and error, but don’t be disheartened because this means you are learning! We learn much more from our mistakes than from our successes, and the more you learn, the better your programming skills will become.


So to summarize, don’t worry too much about not being able to build / understand enterprise-level applications straight out of college. Start small, and keep an always be willing to learn. Work on programming for results first, and worry about best-practices later on. Hobby projects are a great way to gain experience. And remember, don’t ever stop learning!

12 Responses to Help, I just graduated but I don’t feel like I know how to program!

  1. Erik says:

    This same problem applies to old programmers whose skillset has been deprecated by the market. I have 25 years of coding experience, but it has been primarily with PowerBuilder…which just is not viable in many places anymore because there is no one to maintain the code. It’s still a fine platform…but you have to be in a location where it is used.

    In any case, I am in a new job working with C#. I am way behind where I want to be, though I am gaining ground thanks to GOOD people like you who share your knowledge with the community. THANK YOU. You write in a clear manner that is easy to grasp…even on complex topics.


  2. Karthik says:

    I am really happy to post my response, because I am come to this field form non-IT background especially for Coding. Mostly Non IT guys choose testing or non-coding / development criteria of job in IT.

    Once I read heading, I remember the talk from my friends and smile. And read more and more I realize that “It is common for all. It is not only for me. Everyone in IT, have a same problem. It is not because of my graduation background”. While I am starting as a new programmer, I created almost 10 to 15 sample project, most of them are not correct. And then start exploring the design patterns and programming methodology. Now a days, I am confident enough that “what is inside my knowledge base” and I want to increase same by learning new things.

    Thanks for remembering those days once again. Really nice article to build self-confidence.

  3. Adolfo says:

    One thing I would add is, don’t be afraid of redoing work. start again form scratch, constantly take steps backwards and follow your gut feeling. Whenever I dislike something I code or I feel uncomfortable with then I re-do it until I feel good about it. In software development you have to learn to be brave and bold. Always aiming for a better, faster, flexible and more organized code. Refactor, refactor, refactor. Will make you nimble and more adaptable to changes..

  4. Stan says:

    What happens when you learn things in school and then you get an entry level job. You are given bugs to fix, not implement design patterns or optimizations. This was the problem with me is that I forgot everything I learned in school.

    Then when you become more respected in your field, you start to realize how truly important those Data Structures are and how every Algorithm can be solved with a proper data structure.

    When you begin to review and re-learn those Data Structure it becomes much easier, because not only is it something you learned in school, but now you have enough real world experience and have seen these Data Structures in real life and understand when and how to use them. This makes re-learning them much easier and a lot more interesting.

    I always go back and learn bottom-up and re-learn if I have to, the key is not memorization, but understanding the concept well enough that you can you quickly assess what a certain data-structure is, its running time complexity and it’s pro’s and con’s.

  5. Adrian Facio says:


  6. eshementov says:

    Thanks, awesome.
    I just realized that “Be positive when asked if you can do something” was the key tip for me some time ago. Maybe it relies on self-confidence, sometimes we have good knowledge but it’s not enough to get things done.

  7. Bong says:

    If you say yes when you don’t know how to do it how do you determine how much time it takes? What if you think it takes a day and finally it takes a week? Do you write a script repeating: Not yet!? 🙂

    BTW nice reading.

    • Rachel says:

      I’m still terrible at estimates – that’s the kind of thing that only comes with experience. I’d recommend making your best guess though, then tripling it. Also, if I’m working on something new I always make it clear that I haven’t done it before and that I will probably need extra time for research. Most of the time the company doesn’t mind, and if they do mind they can decide to cancel or find someone else 🙂

      • creamcode says:

        Estimates are always tough to deal with. What my experience taught me is: (keeping it simple)

        1. Give estimates after having a good understanding of what is to be developed, else first clarify properly, COMMUNICATE don’t assume instead verify and identify the GREY areas, communicating a lot initially when the project starts will save you from hidden EVIL SURPRISING SCENARIOS that might prevent you from 3 am coding situation(s) later in the sprint.
        2. Make the breakdown as detail (technically drilling down the task) and keep the estimates till yourself.
        3. If possible, consult someone who is junior and ask the colleague 15 minutes of his time to what he might think about doing the same task.
        4. If possible, consult a senior and ask the colleague 15 minutes of his time to what he might think about doing the same task.
        5. Look for any good practices and hints that the senior/junior states, (only if they are kind enough to mention) and in parallel look for the areas that you think might be tricky to handle.
        6. Once the tricky areas are identified, make solutions simple and good enough just to pass .
        7. Estimates for the areas that are clearly understood, take the average of the estimates made in point 3 and 4 and if working on a new stack of technology , keep an extra buffer and try to accomplish things in a simple manner.
        8. Register yourself to different technology forums and use it for posting any situation /scenarios that gets complex , many times the hints and directions are so useful that you would be personally inviting the contributor for a cup of tea.
        9. Don’t be scared from managers, they will always push it’s their job and you have to do you’re job. Say NO when NO is required and YES when YES is required, Uncle Bob (The Clean Coder, taught me this a must read ).
        10. Don’t get demotivated, always look for solutions, there can be mistakes but look forward for solutions , always with the will to learn(maybe every day , it’s not that bad).

        Hope it helps…

  8. nischayn22 says:

    Reblogged this on nischayn22 and commented:
    Really “don’t discount your education”

  9. SLC says:

    Excellent post! Balsamiq is a great suggestion too, I swear by it.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: