Ask HN: What is the hardest part of programming for you?
An open Ask HN community consultation from 2022 where @duceum convened hundreds of developers and bootstrappers to share real experiences, hard numbers, and tactics.
Core Principles for Independent Builders:
Participants share raw revenue figures, churn rates, and stack decisions that corporate PR never publishes.
Recurring answers reveal that distribution, not coding skill, is almost universally the rate-limiting step in developer businesses.
Practical recommendations on bookkeeping, payment gateways (Stripe vs Paddle), and freelance-to-product transitions.
Community Debate Themes:
Hundreds of active indie hackers contributed case studies, pricing heuristics, and pitfalls to avoid when moonlighting on side projects.
CATEGORY Ask HN Roundtables →
HISTORICAL ERA Pandemic Bubble (2020–2022)
COMMUNITY SCORE 9 points
TOTAL DISCUSSIONS 16 comments
Math. More than anything, math limits what jobs I can get. Math and driving a car seem to be the main skills needed for a comfortable life.
Everything else you can mostly do by googling and doing what the glowing rectangle says.
Math and driving require real understanding of nontrivial things with multiple parts that all interact in different ways.
Math is what makes CS hard, because CS is just math, and CS or EE is what seems to really open doors for a lot of people.
I mostly work jobs where programming is only a small part, and I'll even have to do things like hand crimping hundreds of harnesses.
Everyone is saying interpersonal stuff, but I mostly only work with small companies, where things are a bit different, and there isn't that much stress from that.
When there is, it's almost always from various factors that can cause you to be the only one who knows a certain technology, and the effort needed to prevent that and avoid being on call for everything at all times with no help.
It's not like programmers are any harder to deal with than other people, although talking to some of them can feel really isolating, since so many of them are constantly talking about obscure personal tinkering stuff that I can't relate to, and sometimes it's literally the majority of their life outside of work, and it kind of puts up a bit of a barrier between them and those of us who aren't part of that culture.
Most devs seem to have a very different way of thinking, very first principles focused, always going down rabbit holes, always thinking on multiple levels of abstraction, always looking for a chance to explore. It's actually pretty amazing to watch.
Sometimes it can result in some actual conflicts because the other devs will always want to try something simple and hackable, and I'll always just want to slap a proven framework on it and move on to functionally, but other programmers seem to have a "If you didn't learn a new technology, the project wasn't worth doing" mindset.
I might be the outlier but the hardest part for me is the lack of contact with people. I like solving a tough problem or the challenge of grokking a new library/skill but then doing it over and over and over... not so much.
Sometimes I wonder if I'm good enough at the technical side (I have never outright failed at it) that I was never pushed/suggested to look at roles that are more human-facing. I have done -- and greatly enjoy! -- public speaking at user groups and even conferences on technical topics and the number one comment I have gotten both from programmers and non-technical people is how I can communicate concepts that were previously opaque in an easy to approach and understand manner. I definitely like people more than machines, even though I know the machine side well enough to hold my own with the most advanced architects and lead devs.
What would be the ideal role for someone like me? I don't think "software developer" is it.
Legacy code. Language, ecosystem, frameworks, libraries, from 5~10 years ago that people should have moved on from, but due to their lingering popularity we cannot get rid of. It sucks signficant communal/company effort to maintain and friction to develop - so much so that there's not enough energy left to actually migrate to newer and better solutions. The only way out is a multi-year vision of gradual migration, replacing part by part, keeping backward compatibility as much as possible. Fortunately, some smaller projects or green-field ones can be started on a new foundation. But it can be discouraging to see how slow the progress is, and feels like it's dragging down the devs' own career progress too.
It's probably to know which implementation will be the best one. I can have two different ideas about how something can be implemented in mind. I will think about it for a long time trying to figure out which one is the best. I know that if I choose the wrong one and later try to change to the other implementation, that will be a waste of time. That's why it feels like I have to figure out which one is best before I start. Sometimes it might be a better idea to just do something instead of thinking too much though but it's pretty hard to do that.
Everything but the technical stuff. Programming comes easily once I know what software I'm trying to write and everyone has clear expectations about the outcome and timeline. Getting to agreement on that, muddling through agile planning processes, micro-managed ticket boards, story points discussed in endless meetings, endless bikeshedding on side details, ridiculous procedural red-tape, and shifting priorities from clueless management ... it all sucks the joy out of programming and made it hard for me to even open an editor some days.