25
64 Comments

What is the hardest part about coding?

I'm particularly a fan of programming. but when the question arises about being a programmer It makes me hard to think.

What'd you think about the hardest part of programming and why?

  1. 13

    Programming as a Founder - The hardest part is to resist the urge to add that extra feature and do a little bit of marketing instead.

    Just as a programmer - Hooking up security, DevOps, Setting up DR startegies, building replicable environments, unit testing etc are harder to achieve especially when you are just starting.

    1. 2

      Totally! In fact, when you're a multi-tasker at the same time you're gearing up could be one of them.

  2. 8

    Understanding that coding itself is the easiest part.

    1. 3

      You're right. It's pretty too hard to make yourself realize in my opinion.

  3. 6

    As a solo founder, for me the most challenging thing is to stop worrying about scale at the initial days of a product. Not everything has to be optimized for scalability when your product doesn't even have enough users!

    Trying to change this mindset with my new product Pigmnts where I'm building core features first before worrying about scalability.

    1. 1

      Interesting concept! I was a bit skeptical when the extension asked to read and change my data across the browser. Why though?

      1. 1

        Pigmnts embeds itself on the webpages where you enable to extension(to point-and-click on image to generate a palette). This requires permission which gives am extension the ability to append code to other webpages. That's why the webstore conveys it with the above message.

    2. 1

      Well, you asked about Solo Founder? I'd probably say yes to that. I had a new product few years back and It was going very well. You know what the best part was The users were satisfied. users was not enough but whoever, was willing to give a feedback about it. It was making my core product needful and worthy.

      1. 2

        I think as programmers we tend to over-optimize things sometimes just to be prepared for the "long-term". Probably should stay away from this when you are the sole founder(also the programmer) of your product.

  4. 5

    Coding is easy. Building an end-to-end solution for a problem by deciphering requirements, coordinating with your colleagues, answering questions you don't really know answers to, interpersonal skills, etc - they are the hard parts of a dev job.

    1. 1

      and that time your knowledge starts testing you that how clear are you for the concepts. some of the questions we get stuck with when we start as a Founder of an app or product sort of. loyal users are the root of our core infrastructure of the product itself which makes it(product) way stronger. It makes a product which truly solves one's problem either way.
      Coordination with colleagues makes a dev's life easier with real time collaboration but sometimes it sucks when things don't go according to you.

  5. 3

    As a developer, we spend a lot of time setting up and configuring tooling instead of focusing on our product and code. We need to make sure these tools can work together. For example, for each new projects I need the following things:

    • Next JS
    • Tailwind CSS
    • Code Linter, ESLint
    • Code formatter, Prettier
    • CI/CD through GitOps
    • Code Editor, VSCode configuration
    • Deploy to production: Netlify or Vercel

    Not only this process is hard but also very annoy. We lost a lot of time doing this boring stuff instead of focusing on our project.

    Sometimes these tools aren't able to work together and we need to find some workaround.

    Finally, you also need to maintain them and updates these packages to the latest version. Unfortunately, it can also bring new issue and break your tools.

    PS: I have solve this issue for my stack. Here you can find my Next JS Boilerplate: https://github.com/ixartz/Next-js-Boilerplate

    1. 2

      I'm glad you've gone from it and more happy because you solved one. UPDATED PACKAGES comes up with new challenges which sometimes make someone bother. putting things align with focused mindset could be a challenge but not when you're ready already. just because of the devs like you who make ones life easier.

      1. 1

        When you have a really large program and don’t understand from the names of functions what they do, that is one example.

        Also naming something which has many meanings, and someone else misinterprets it later. And so on.

        1. 1

          So I personally do have some personal issues with JavaScript(LOL) but not now. you know what when you reaches at a level and you're supposed to work with somethings in only that way, it becomes your habit and you don't get bothered by anything. But when you started your career as a developer things don't go really well by time you're supposed to adjust with them. That's my story BTW. I agree!.

  6. 3

    Fighting the urge to "make things better". It's much better to build the simplest version of something and iterate it over time once it's live.

  7. 3

    Explaining code things to our non-technical cofounder

    1. 1

      LOL! It makes me sick sometimes.

  8. 3

    Architecture. Organizing the your. Learning if-then, while/for loops is relatively easy. Have a question on how to do something algorithmically? A simple Google search -> a few StackOverflow answers will usually.

    But boy, architecture is hard. Once your code reaches a certain size, knowing how to NOT get lost and organize it is...hard. I've been there several times.

    It's even trickier that there's not one agreed-upon way to do software architecture. Just like there's not one agreed-upon way to get productive.

    So software architecture def takes the first spot for me.

    1. 1

      Congrats! got tricked too. It's sometimes make me feel dumb how can I just lost at the very end?

    1. 2

      If you're using GraphQL, graphcdn is pretty darn cool.

      1. 1

        It is more for niche use cases. Such as storing ssl certs on multiple servers.

    2. 2

      And naming things!

      But in all fairness, I would say "scaling".

      1. 1

        True. Caching on one machine aint bad. When you want to scale it :(

  9. 2

    Stay focused on the one thing at a time. This still an issue if you're running a startup. No matter what happens. Just do what you do and never give up 😉

    1. 1

      Being a multi-tasker is one of the abilities a dev acquires. I totally understand the worst case scenarios at startup but when you achieves it, you beat it.
      Thanks for that. It motivates me!:)

  10. 2

    flashback to me trying to center a div horizontally

    1. 1

      I still remember those days. LOL!
      But you get angry when you got to know how easy was it.

  11. 2

    Feeling the frustration of being stuck

    To me the most hardest thing about coding is the frustration I feel when I spend times on my app and things don't work. I code for many years but it is still the most painfull part which has a great impact on my mood 😓.

    Recently I tried to change my thought about this to overcome this frustration, telling myself that the time spent is a part of a journey (and the reason why thoushands of new app won't launch every day) helps me a lot 😊.

    1. 1

      This helps me a lot! For me, when I make my mistakes my code or either way I note down about every case and when I solve it by myself, I note down that too. so, whenever I feel bad I go to my previous work that how I solved without any help "By myself". I see my creations. It helps me to boost.

      I've created my TimeLine for every single project. It really helps.

  12. 2

    Improving. I know it's a generic answer but I really struggle to find motivation to go back and upgrade or improve old code because in my mind, if it works, it works.

    1. 1

      Improving it? It's damn true!

  13. 2

    Stopping. Once I get in the groove I just don’t want to stop. But sometimes you’ve just got to use the bathroom eventually.

    1. 1

      and bro you need to stop for real at that time, eventually. because if you don't. you gone.

  14. 2

    Figuring out what to build. Prioritizing tasks that have the highest ROI (impact).

    1. 1

      Specifically, we don't sometimes know what task means to be highest bump but figuring out the stuff that really matters to you isn't that bad. if you know, you know.

  15. 2

    ⚡Working on someone else's code! ⚡

  16. 2

    The hardest part? Acquire problem solving skill

  17. 2

    A lot of the hard things have this quality that once you understand them, they then appear easy.
    I’ve been doing quite a bit of GraphQL recently, I’ve found that tricky, but it’s becoming easier and easier.

  18. 2

    IMO, the hardest part is to rather be really good at a few things than trying to cover everything (and failing to do well in all areas).

  19. 2

    Umm refactoring and testing. Every now and then I'm tempted to refactor my code for modularity, and it ends up eating my time.

    Unit testing is something I often ignore.

    1. 1

      Are you being serious? Don't tell me you're ignoring Testing Stages?

      1. 1

        I've been. I'm looking into two alternatives to it - (i) UI testing, (ii) Regression testing.

        1. 1

          Oh! Regression is way easier for functional testing to make it work even after messing up with the code which is called refactoring.

          1. 1

            Totally agree. Would you recommend some tool for that?

            1. 2

              I'm not sure what is the core objective of your product as it varies from it. some people recommend No-code automation tool in some use cases and they're even pretty popular in some regions.
              I personally mess up with selenium and RanorexStudio in some cases.
              I'm sharing "some" that I think could be best in the most general cases. I hope it could help:

              KatalonStudio - https://www.katalon.com/
              SahiPro - https://sahipro.com
              RanorexStudio - https://www.ranorex.com/regression-testing-tool/
              Selenium - https://selenium.dev

  20. 2

    The hardest part for me when I was building https://retroteam.app was designing and architecting the database since I used Firebase which came with it's own challenge coming from the SQL world.

    1. 1

      So, that's interesting. well, I personally use Redis or mySQL sometimes. But what was the reason behind choosing Firebase.

      1. 1

        The database is fast and I could do real time updates which is needed for RetroTeam - Firebase SDK would allow me to do that easily

        1. 1

          Interesting! I think I should give it a try.

  21. 1

    As a hobbiest coder who knows just about enough to get code running, my biggest weakness is in writing tests. This has a number of negative downstream effects like with CI/CD etc and it will no doubt cause instability in my product as I gain customers and scale.

    But, I know my limits and I know where I'll need help. For me, it was more important to build the right thing rather building it right.

  22. 1

    I remember this one quote from my early programming days - "all decisions before code is written are made by the mind, all decisions during programming are made by the heart". This is really true, and maintaining objectivity and focus on the product when you realize you need to re-write 100 lines of dumb javascript config code is hard.

  23. 1

    It's the attention to detail that gets me. I'm more of a backend developer, but I have to do frontend all of the time. And it's annoying how hard it is because everyone has their opinions about how a design should look. For me, as long as it works, that's fine. haha

  24. 1
    • The hardest part is to resist the urge to add that extra feature and do a little bit of marketing instead.
  25. 1

    For an experienced programmer this is a hard question to answer. This is because an experienced developer understands all the nuance of what is involved in coding. As many have pointed out, in the broadest context, it may be hard to find out if what you are programming is really useful for your users. If not, no amount of clever engineering will make spending your time coding worth it. This is all too common in many an engineering departments where you are supposed to put your head down and just do the work assigned to you, even when you know in your heart that what you are making has questionable utility at best.

    Assuming that you have proved the utility of your product, the act of making the product has its own pitfalls. First, you have to get the architecture right. For if you don't, you might find yourself making great progress initially only to find the codebase become harder and harder as your product matures. On the other hand, you can't spend too much of your time thinking of the perfect architecture. Analysis paralysis has killed many projects. Don't architect for 10 million users when you have yet to find your first.

    Then you have to take into account team dynamics and morale. Coding, as anything else, is a human endeavour. If people are not happy and motivated, it will show in the quality of the code. This is as true for a solo developer as for a team of ten. Intrinsic motivators work best here than extrinsic motivators. This is again a mistake I see made again and again by many companies. Great pay or incentives are not enough. Your engineers need autonomy, mastery and purpose to really deliver to their full potential.

    And last comes the actual act of coding. There are a million things here that you have to keep in mind. Novices focus only on the functional aspects of a program. They think they are done when the program does what it was supposed to do. Wrong. The functional and non-functional parts of a program have the same ratio as the tip of an iceberg to the iceberg under water. Expert developers understand that non-functional requirements are rarely communicated explicitly. Performance, robustness, stability and ease of change are taken for granted.

    All these variables mean only one thing -- there is no perfect program. There are only trade-offs. Coding is an art; and science. Only through years of practice you start to appreciate all the complexity and develop a taste for good programming style. There is no single part that is hard about coding. The whole of coding is hard.

  26. 1

    Solving an actual real-world problem and producing something that actually helps the end-user.

  27. 1

    Depends on what your building relative to your skill level. Generally though - systems with a lot of moving parts are challenging. While any one piece may not be particularly hard, managing the interaction of a lot moving parts can be quite hard. This requires strong understanding of architecture and being able to "foresee" potential issues with race conditions, latency, etc. Requires a lot of experience.

    Also, getting existing libraries and open source software to do what you want them to do can be quite hard. The library almost looks like the right fit for your project; you start using it and realize that it doesn't quite fit. You start reading documentation, figuring out work arounds, maybe even start digging into the internals to modify it. Very time consuming and requires lots of "grinding" and patience.

  28. 1

    Writing good code on the first iteration.

Trending on Indie Hackers
Gave up 300K/yr as a blockchain dev to make a pomodoro timer 🤔 AMA! 65 comments Want to sell 💸 your SAAS/side-project? 22 comments What is your secret growth strategy? 12 comments ⚡ How we’ve marketed our SaaS on a tight budget 11 comments Post a "Show IH" and appear on the Indie Hackers podcast 5 comments My first build in public post (feels good man) 2 comments