November 29, 2017

10 things you wish you'd known when you started programming?

Hey all,

I have recently committed to learning how to code (I've been playing about with Ruby and I'm currently exploring Rails). I know there are some seasoned pros here and beginners too, so I thought it might be a good idea to ask:

What 10 things do you wish you had known when you started programming?

...I think there are a number of us in here who could benefit form this, so I'd appreciate your thoughts (funny stories too).



  1. 27
    1. Don't learn to code. Decide what you want to build and learn to build it. Having an end goal in mind will guide you and the progress towards your goal will motivate you. You will encounter unexpected challenges which will frustrate and surprise you, but that is how you will learn. This is what I call depth-first learning. Not topic by topic, but feature by feature. You will learn just enough of each topic to build what you are working on. You can go into the details of how it really works later, by which point you will have a practical context from your own experience to apply the theory to.

    2. Some bugs are best solved the next day. I've spent countless nights trying to figure out why my code is not working only to come back the next day and spot an out of place comma or brace. Going away for a while, reseting your mind works wonders for finding those tricky bugs.

    3. Learn to get in The Zone or The Flow. The Zone or The Flow is that state of mind where you are only aware of your code and nothing else. This how some of the best software is written. You can't have any interuptions to pull you out of it. Oddly, this is why so many hackers like working at night. When you can load the problem into your head and solve it in your brain, programming becomes just writing down the answer.

    4. Make sure your function and variable names are consistent and descriptive. It should be obvious from a function and variable name what it does and how it relates to other parts of your code. If you decide to call your list of customers 'customerList' then use the same name to refer to it everywhere else. Don't call things 'process' or 'data'. Generic names will not provide help when you go back to your code after a few months away.

    5. Don't work alone. Working with other people will help you understand your own work better as a result of describing it to others. Also, you will pick up lessons and ideas from your peers. For example, check out Codebar. I mentor there most weeks. If you don't fancy that, then find some folks who are working on similar stuff and organise regular chats or meetups with them.

    6. Enjoy it. I like programming because it's like playing with Lego, except the pieces are free or very cheap. You can build anything you want and have everyone in the world use.

    7. Don't be too harsh on yourself when things are not working. You are learning a new skill and sadly getting stuck is part of the experience. When stuck, just go back to the last place where your code was working and try solving it again. Commit to git each time you have added some more functionality. That way you will always have that secure place to go back to from which to try a slightly different approach

    1. 4

      +1! "Decide what you want to build and learn to build it." This is gold.

      1. 1

        Found the perfect advice, thank you! Learning to code feature by feature is genius because many apps use the same features.

      2. 1
  2. 9

    Building projects is the best way to learn. When I was young, I would buy programming books in an attempt to read them and learn. I never got very far. But in college I learned to code pretty quickly once I had some interesting projects in mind. Whenever I got to a roadblock, I just Googled what I needed to learn, figured it out, and moved on to the next step of the project. It's hard to learn in the abstract, but easy to learn as a side-effect of some project you're trying to complete.

    Writing "good" code is simpler than you think. Essentially, it means code that both gets the job done efficiently and is easy for someone else (or yourself) to understand later on. That means descriptive variable and function names, consistent patterns, and not being lazy. You may not appreciate this at first, but once you've spent enough time having to read your own messy code, you will.

    Don't plateau. Your first year or two of learning will be at a breakneck pace. But once you start to get comfortable with things, it's easy to slow down and stop learning. Don't. Continue to find things that are hard, that are scary, that are above your head, and learn them. You'll blow past people who've been coding for way longer than you but who stopped learning when they were only a few years in.

    Nobody is a "real" programmer. Programming as a discipline has hundreds of variations, topics, skills, etc. You can be a mobile dev, or a web dev. You can be badass at front-end interaction design, or at putting together a complex back-end system, or at setting up servers and scripts. You can be great at computer science, or algorithms, or AI programming. You can be a great systems developer, or a low-level machine code programmer, or have an amazing understanding of the hardware that computers depend on. A Windows expert, a Linux expert, or an OSX expert. But guess what? Nobody knows all of it, and nobody ever will. Don't ever let anyone tell you you're not a "real" programmer because you don't know <random thing X>. All you need to know is what gets your specific job done well.

    Googling is legit. An important part of being a good programmer is being able to overcome hurdles and roadblocks quickly. Often, this requires being good at finding the right answers via Google. There is no magical level of awesomeness you can reach where you will no longer need Google.

    Code a lot. Always be building something. There's really no substitute for this. Whatever you're trying to learn, do it a lot.

    Understand your goals:

    • If you want to be a founder, then you need to have a diverse skillset. It's not all about code! It helps if you're good at design as well, if you understand servers, and of course marketing, sales, copywriting, product design etc.

    • If you want to be a badass employee, then you probably want deep knowledge of a particular skillset, as well as the business knowledge to be able to sell people on how it will make their companies millions of dollars, as well as the networking skills to meet potential clients.

    • If you want to work at AppAmaGooFaceSoft, then you're going to need some computer science knowledge and whiteboard coding skills.

    • etc.

    Try to decide on a direction and head that way, rather than learning random things will nilly. And remember, you can always change directions and you can learn any of this with practice.

    1. 1

      All great points.

      To be honest, points 4 & 7 is a bit of a reality check for me. I have only really thought about building rapid prototypes and I am the first person to explore countless tangents. Without an actual plan, I'll probably end up partly learning lots of concepts but never have shipped anything.

      I'll create some sort of framework to check myself against every now and then to make sure, I'm focused on core skills that allow be to build things users can get value from, quickly.


      1. 2

        Don't forget point #1. If your plan is to become a generalist programmer who wears a lot of hats and can get new products of the ground, then building (and ideally shipping) lots of prototypes is a solid way to get there! In fact, it's what I've done for the past 10 years or so, over and over.

  3. 5
    1. Youtube and video tutorials are your friend.

    2. Work your idea out on paper 1st!

    3. Have a definite end goal.

    4. Know how to render the client

    5. Know how to version control

    6. Know how to push to server

    7. Set a time limit on how long you will work a issue yourself before asking help.

    8. Help someone else to learn more yourself

    1. 1

      I think number 2 is great. Sometimes just writing things out step by step when learning is the greatest way. Then you just take each line and translate into code.

      1. 1

        Definitely. Think #2 is a great time saver.

    2. 1

      Really like point number 7. I could apply that to lots of things to be honest. Cheers.

      1. 1

        Yeah it something I just picked up myself. Makes things really efficient.

  4. 4
    1. Be humble, I've been programming non stop for two years now and I still feel like a total noob, there's no shame in it and the community will be much more welcoming to you if you don't act like you know everything.

    2. Eat well, sitting at a laptop all day every day is not good for your waist, don't make it even harder.

    3. Be present when you're stuck and break the problem down to its smallest steps.

    4. Buy a rubber duck and talk to it OUT LOUD when you're stuck.

    Link for more context as to what I'm talking about(

    5, 6, 7, 8 ,9 10 Get back to coding instead of reading about coding tips as I am currently about to do right now, the only way you will learn is by doing , theory only makes sense when you apply it.

    1. 1

      @5 - 10 For sure! lol

  5. 3
    1. First 4-5 years it doesn't matter if it's language A or language B, framework C or framework D. Don't think about it. Take what's good for the task you're planning on doing, stick with it and don't engage in idiotic comparisons like "But this language's map function is 0.5 seconds faster" or "Johnny from Google said language A is obsolete and switched to B". Whatever! You will be able to bunny hop from one stack to another later, when you have understanding and reasons to do so.

    2. Ask questions immediately. Don't monkey patch. Don't think of doing it differently. If you are stuck on a task which is beyond your understanding - hire an experienced $40/hour freelancer to explain it to you. Ask a question on SO. Figure it out here and now.

    3. Take care of your health. Intense coding can take away your most precious resource in no time, and you will spend years taking it back.

    4. Always add twists to your process, especially when starting new projects. Throw in a new lib, a new framework or a different db, if you can afford it.

    5. If you can't afford a mentor, at least use a linter.

    6. Read more than you write. Remove more than you add in.

    7. Make sure to know what's happening outside of your ecosystem. I've seen guru PHP programmers who have no idea how SASS works or what Node.js is. On the one hand - it's really not their field of study, but what would you say about a surgeon who has no idea where human heart is, because he only operates kidneys?

    8. Soloing is fine but you will get stuck in your own little world with self-invented best practices and opinions. Try working with someone. You'll seamlessly learn a ton of new things every day.

    Bonus point

    Always (!) upvote both the answer AND the question on StackOverflow, if you found the right answer. First, you will encourage both participants to contribute more - by both asking and answering, and second - when googling code-related questions later in your career you will immediately be able to distinguish pages that helped you when they load up, because of your Question upvote. ;)

    1. 2

      Cheers Grammakov, I'd not heard of Linter until now. Looks like it could be really useful.

      I like idea 2, just getting help in if needed. Especially since one can literally go to PPH and find someone almost as quickly as googling.

      Thanks for your input.

      1. 2

        Glad you found it useful. I've added a bonus point. ;)

        1. 2

          Great idea! - I'm all for being about to look back and see how far I've gone. I keep a journal or tweet things when I know I won't get around to adding them to my journal.

          I'll be sure to upvote both comments and questions (it' the least I could do for all the time and suffering saved!) lol

  6. 3

    The best way to learn to code is by doing.. Get out there and build stuff.

    1. 1

      This is the one thing everyone seemed to agree on so I am going to try make something by Jan 1st.

  7. 3

    Write incrementally. Write a little, test a little.

    1. 1


      One of my friends said this yesterday. One of his points was he wishes that he took test driven development more seriously when he started out.

  8. 3
    1. Never be afraid to ask another dev for help

    2. Don't assume a Sr dev has the right answer, there are many ways to tackle a problem. Just listen and absorb their perspective among others.

    3. Practice. Don't just read, apply.

    4. Don't undervalue your skills (I struggle with this one)

    5. Apply for jobs you think are out of your reach, you never know! (I got a dream job I 'wasn't qualified for)

    6. Look for up votes on stack overflow!

    7. Udemy is your friend. Video tutorials with code along emphasis are the jam.

    8. You'll never learn it all. No one will.

    9. Make time for yourself and family/friends to recharge. Are you working to live or living to work?

    10. If you don't love learning, maybe don't try to be a developer. It's going to mean a life of learning and growth, if that doesn't appeal to you and you just want a stable career look at other options.

    1. 1

      This comment was deleted a year ago.

  9. 2

    I can answer this from a developer perspective for small to medium sized projects.

    1. Don't optimize until you need to.

    2. Naming things is important. It's a pain when you name things too specific when the usage changes due to biz changes.

    3. Spend the time to setup a linter and leave your code cleaner than how you found it.

    4. Automated tests are important but not the end of the world if you don't have them.

    5. Avoid steering away from the conventions of the framework you're using. Unless you really know what you're doing, and that applies to very few people.

    6. Opt for simple understandable code instead that repeats than cleaner refactored code that is hard to understand... unless it really really makes sense to do.

    7. Build with a platform like heroku which forces you to build a scalable solution. Eg- you can't store user generated content on there.

    8. Opt for composition of code instead of inheritance.

    9. Plan out your tasks before you code. For every non trivial task I do, i break it out into baby steps so that when I'm coding I'm not having to think as much about the context. You wanr to minimize context switching, hurts the brain and slows you down.

    10. Be accountable to youe estimates. If you are off, which is the norm, assess why and keep trying to improve your forecasting. Most of my bad code is from rushing a job that I under estimated.. this code debt is rarely fixed once it's shipped.

    And if you really love programming, make sure to read some books from Kent Beck, Martin Fowler, Uncle Bob to name three i like.

    I didn't do any of these when I first started... and it took a lot of mistakes to figure out what makes a difference to the business and what practice should have little or no impact.

    1. 1

      Thanks Andre.

      Would you recommend any of their books in particular? ...if Uncle Bob's books are as funny as his videos, that might be the best place for me to start. LOL

      1. 1

        Sorry super late reply! Yes, I like Uncle Bob's books.... they have some good humour in them.

  10. 2

    My two big ones...

    1. Learn to love the challenge of solving a programming problem. By understanding that 80% of programming is trying to figure out a bug or find out how to do something, it will make it more fun.

    2. Get the code working, then refactor and make it reusable. Don't worry about making things beautiful from the start.

  11. 2

    Learn to ship. That's what counts.

  12. 2

    Hello Pete,

    These are some of the most important pieces of advice I could give to someone that is learning how to code and wants to become a developer.

    1. Be a self-starter. Meaning, skip the expensive tutorials, time consuming bootcamps, and the events on meetup that teach at a average level. You have the internet right in front of you, use it wisely. Use stackoverflow, join subreddits on reddit, and continue to be involved in great online communities like Indie Hackers!

    2. Surround yourself with developers that want to help (mostly everyone will). No matter what level they are at, if they are on the same level of learning as you, it can be an advantage because you can both go through the process of learning together. Bouncing ideas and common thoughts off of each other can really help with the learning curve of learning a new language.

    3. Ask great questions. It may seem like a small detail, once you are able to creatively think and challenge yourself and then ask questions that someone may know more than you can really be helpful. If you ask better questions you will most likely have a better answer in return.

    4. Find a problem that you face with daily. When people learn how to solve a problem, it's most likely done because they are scratching their own itch. It's important to understand what your problem is and decide how you can effectively work towards it. Brian Chesky and his roommates needed a way to pay for rent, so he created airbnb.

    5. Start with a big problem, people will tell you to stick to smaller projects and continue to do that until you can move over to a bigger project. This ideology doesn't challenge you, find something that you know that if you put yourself up against it that it will be extremely difficult. It's the only way to grow and learn at a increasingly way.

    6. Build unconventional products, to the point that people have never seen built before. It will create conversation and allow people to see unique ideas at a different perspective.

    7. Have a clear vision. Learning to fix a problem, learn a new language, and building something that people will use can be extremely difficult. Stay focused on what you are creating and do whatever it takes to make it work.

    8. Lastly, if not one of the most important things, Fail very fast, and Execute on your failures even quicker. The faster you fail, the more you will learn. I mean that entirely, don't waste time on something that is holding you back. Just break whatever it is and keep moving along.

    Hopefully this helps. The journey of becoming a developer can be long and tiring at times. If you need any other advice just let me know!



    1. 1
      1. Is quite controversial. If someone is really new, I would not advise them to take on a big project, because a huge part of the learning is seeing how users interact with what you have built/how what you have built helps you - and big projects are likely to be abandoned by a newbie before this stage is reached. Also, taking on projects that are genuinely beyond your grasp will prevent getting into a flow state, which is where programming is fun - now this is not necessarily ideal for learning, but is important for creating a long term passion. Having said that, I understand the point you are trying to make. Once a couple of small/medium projects are complete, taking on a big project can be extremely valuable as a learning experience, perhaps after say, 6-12 months of groundwork.
    2. 1

      Hey Landon, thank for your input.

      Almost everyone has stressed how important it is to just build stuff. I was thinking about building a basic CRM or Bug Tracker for my first project, however, I really like your point of view about building unconventional products (number 6). you think I should re-think my original idea, even if it's my first product? or are you talking about future projects.

  13. 2

    Basically this without #6 – I love long variable names:

    1. 1

      I'm gonna have to come back to this, looks like his CDN is playing up.

  14. 2

    I wish I had a topic like this when I started :D

    In addition to all the valuable tips that are already presented:

    • StackOverflow is your friend. If you get stuck on an issue, trying typing the exact issue in the Google box, and if you have any luck, a topic on SO will appear that contains the answer your looking for. And I really mean this in the "the php variable that I define in the class doesn't show up in function when I declare it as private" way of typing out the problem.
  15. 2

    In my early days I'd often face "insurmountable" problems that felt like I could never handle.

    Then you realise all big problems are just made up of a series of much smaller, manageable problems. And if you go through those, in the end you'll have solved your big problem.

    1. 1

      Still getting my head around Classes, Loops etc... so the idea of building an actual app, especially without a framework like Rails seems like an almost impossible task! lol

  16. 2

    Practice >>>>>> Doing tutorials / courses

    Want to be a web developer? Make websites. App dev? Make apps. That plus googling to answers will make you a way better coder than someone who does courses and tutorials all day.

    1. 2

      Thanks for your advice.

      This seems to be one of the comments made most frequently, I'm going to come up with a project to build in the next week or so and try have something live by Jan 1st.

  17. 2

    If you can find a mentor with a lot of experience, that would be the most valuable.

    Second, read some books by seasoned developers: Pragmatic Programmer, Legacy Code, Clean Code, Test Driven Development

    Always try to be learning and improving your skill set. Programming is as much an art as it is a science

    Softer skills like communication and documentation are just as important so do not neglect them.

    Create some open source projects or contribute to some. Having a side project lets you build skills you might not get an opportunity to do at the day job.

    1. 1

      Cheers, mate.

      I'm hoping to find a mentor, I agree it will make a massive difference. Not sure how to go about it at this point but luckily I live in London and you wouldn't believe how many meetups there are for learning each language. I've already started attending them and should be able to get to one a week.

      With regards to documenting, do you advise leaving comments in the code or using something like Notion to build a separate doc?

      1. 2

        If your working a day job, its also possible to find a mentor. Look for someone that is invested in life long learning.

        In regards to documentation, I mean more of the high level stuff. What does this software do? What is the public api for this package or library. Think of all the times you have looked at projects on github. Which had excellent pages and which did not?

        1. 1

          I've been working a lone in my flat for the last couple of years (made worse by living alone too), so I'm currently looking for a company/ team to join. Funnily enough people to learn from and grow with was top of the list of job criteria.

          I couldn't agree more on documentation, I've already come across a few projects on Github that hit roadblocks because it didn't say basic things.

  18. 2

    hello! I recently spent a year learning to code to make projects. honestly the fastest ramp up (if you can afford it) is a bootcamp. I did one and recorded my experience at now for the 10 things.

    1. alternate between learning and making. i disagree with the top comment here about "decide what you want to build and learn to build it". if only things were that simple. without a good map of the area you will hit a wall and you will not know how to go around it. google and stackoverflow fail you pretty fast after the beginner stage. when you feel like you've gone learning too long and its all theoretical, switch to making.

    2. focus on javascript. ruby on rails and/or Django and/or laravel has been discussed to death here and in every other forum and you can get somewhere with any one of them. pick one, learn it. if you dont like it, pick another, rinse and repeat. but you will have to learn javascript sooner or later to get shit done on the frontend. and yes there are backend javascript options so you can have it ALL in javascript. freecodecamp teaches you the fullstack javascript approach. i dont care about arguing the pros and cons of each stack. the best stack is the one you "just get" and make stuff with.

    3. get a community. you've got a good start here in the forums but we don't see you every day. you need people to harp on you every single day. no zero days. i have more thoughts on

    im only doing 3 because you're never gonna absorb all 10 anyway. in fact thats another lesson. less is more.

    1. 1

      Hello mate, thanks I'll have a listen & read.

      I've decided to focus on Ruby/ Rails at the moment. The syntax seemed much easier to digest when comparing with others.

      I agree about Stack Overflow / Google - in some situations because I often have no idea how to describe what the problem is. This is where the bootcamp will be great but I am going to try meetups and see where that gets me first.

  19. 2

    Write code. Lots of it. Practice all the time. Practice on throw-away projects. Read others' code and work to understand it. Learn and defer to best practices as much as possible (have a good reason to do the 'quick and dirty')

    1. 1

      No escaping the 10 Thousand Hours lol

  20. 1

    Some great advice here. I sincerely appreciate everyone taking the time to comment.

    Thank you.