Hacker News new | comments | ask | show | jobs | submit login
Ask HN: As a developer, what are your biggest pain points?
32 points by johnnyRose 4 months ago | hide | past | web | favorite | 78 comments
As a developer, what are some of the most impactful problems you or your peers face? These could be technical or non-technical, work-related or not.

The fact that interviewing for software engineering jobs tests skills that are mostly unrelated to software engineering. Related: interviews that are SE relevant, but in no way apply to the job at hand.

Example: I was asked by a 50 person company to “design the Twitter home page/feed for the world.” Relevant to SE, sort of... I mean, who designs massive distributed systems themselves without being able to consult colleagues or the internet? Relevant to a 50 person company? I suppose they wish it was....

Might be worse? Yes, whiteboard coding questions.

Unbiased opinion, but this is a problem I really care and I'm trying to solve with https://type12.com

The need to be stationary for 8 hours a day. standing desks help, but not enough. I plan to start doing yoga, which I think will help with this.

Not perfect, but... get up and walk around! You have more than enough to think over for a short walk on a regular basis. If it doesn’t seem like it, maybe it should. In practice I only spend a few minutes a day actually typing code. Most of my time is spent trying to figure out WTF I should do.

good point. i used to walk and think a lot when i was in academia. the act of walking always added a different dimension to my thought processes, though it's hard to describe in exactly what way.

I'll try to make an effort to do that more often now! thanks

This is one of my biggest complaints about the job.

Unfortunately, standing desks, under-desk cycles, and I would guess (though have not tried) treadmill desks, are not complete solutions.

I am certainly not as focussed while I'm using my under-desk cycle than I am when I am sitting still in a chair. It's great for certain types of dev work, but not great for when I need to learn something new or tackle a really critical situation. I wish this work was more physical, but alas, it's just not.

I started a yoga practice at the beginning of the year and it’s been amazing. I wasn’t inactive before — being in NYC I always walk and I used to run a good amount — but yoga has opened my body up further than I really realized was possible. All those years sitting at a desk coding and studying all day really took its toll.

I’d suggest trying a few yoga schools out until you find the teachers you connect with who teach a style you like (I’ve found Ashtanga to work for me). Then just commit yourself to struggle through it for the first couple months until your body starts opening up.

A note on this, my doctor tells me that sitting for a long time will ruin your lower back and will cause problems in the future if you are not proactive and minimize it. This is an absolute fact so keep that in mind. He sees it constantly in his older patients.

Technical debt. Some places let this stuff mount up under constant pressure from product or management to always deliver features as quickly as possible. This makes it more difficult to track down bugs or add new features as this mounts. Most often it severely impedes on the ability for low-mid level engineers to write good quality code as the complexity of refactoring the existing issues surpasses their skill level.

I guess the big pain point then is actually having management that doesn't support tech debt cleanup at any appropriate level. Without support, budgeting you'll end up at a point where even as a skilled developer your choices are to a) say to hell with your managers guidance and blow the whole iteration refactoring just so you can even start on the right footing with a new module, or b) write code that isn't as reusable, maintainable, or performant.

As a web developer, my biggest pain point was the never-ending pressure to get a project done by tomorrow with perfect no bug code.

Another was designers designing because it's "cool" and everyone else is doing it as opposed to designing for app function and helping the user get around the app easily. Some designers love eye candy that weighs the app down with useless features that are cool once but get in the way over time.

One that really comes to mind is bad SCRUM project management. The longer projects will always get spaghetti code when badly managed that will be a bear to maintain. It's not too bad for smaller projects but longer project the manager needs to be a master to divide the project into manageable parts that will deliver good code.

Thinking you are finished with a project, then taking on another project that's suddenly taking all of your time - while fixing bugs or making improvements to the previous one. Now you're suddenly under a lot of pressure.

I hear that. I was once employed as the sole full time internal webapp developer for a local company with 600-ish employees to serve. Over time, more applications == more code == more bugs == more features/improvements == more "customers" to interact with... Being able to move that quickly was a lot of fun, but managing everything was challenging.

That's basically my job now.

Absolute technical freedom with absolute responsibility.

It's made me very cautious about adopting any 'new'/'shiny' technology, I'm sticking to things that already have mass market adoption and a proven track record because I simply don't have the time to disappear down rabbit holes.

I keep a scratch list of "this looks interesting, check back in a year" and sometimes even then it goes back on the "check back in a year" list.

Besides for research projects or your own company, in my opinion this should always be the case. I see people literally screwing their employers by introducing ‘shiny X’ (usually seen in a frontpage post on HN...) saying it will be faster. It never is in the greater scheme of things and it always costs more because it will have issues.

Couldn't agree more.

Outside of work on my own time I play with things I think might be useful or worth using a year or two from now, if they are fantastic, if not I learnt something and had fun.

At work it's PHP (I inherited that project sadly), C# and Java, On my radar in the next year are Kotlin and F# (Kotlin particularly since we have java applications in production on industrial handhelds and the codebase previous dev left on those is...worrying).

As for people screwing their employers by picking unproven new shiny, I think in the main part that's because of mismatched goals, Employer wants reliable software but doesn't understand what dev is doing and Employee wants a resume that will get them hired so skates to where the puck will be on the ooh shiny.

I've been programming since I was a kid in the 80's and the one thing I've learnt (often the hard way) that no language/framework/library is a substitute for thinking things out, that and everything is a trade off in some direction.

A 5mm square A4 pad and a pack of decent coloured pens has saved me thousands of hours over the years.

Also been programming since the early 80s and I do by far most programming in my head and on paper (I ‘just have to type it in’; that is mostly bullshit because of the real world vs my abstractions but it does save me a lot of wasted time behind a computer).

Screwing the employer is a tad harsh but I am the employer often and I see people coming up with these things, so I give them some room to play. Usually they just go back to the old ways when they see it is not that silver bullet the Medium article claimed. I just can imagine when someone does this with more power or less supervision within a company as an employee and actually costing the company money for some unproven and resume driven thing which does not necessarily bring any business value.

Interviews. They are so disconnected from the day to day work that causes devs to 'prepare' for weeks/months to clear the interview only to get back to doing what they were doing before or something like that in the new job.

As most clients only appreciate things when they see them; a better enviroment to mock up applications which look and feel like the real thing but take less time than actually implementing the real thing. I used many tools meant for that but usually the endclient (internal or external) says ‘yes thats great’ or ‘come back when its done’, which are basically the same remark in reality. In the first case when you deliver, they feed back things 80% of which could have been caught when you showed the mockup/clickthrough but they really thought at that time ‘yeah looks ok, but come back when its done’.

Besides just spending far too much time on actually doing a chunk of the actual work (which might not yet be commissioned for), I have not found effective ways of fixing this issue.

The problem with mocks that feel like the real thing is that the client then interprets that as the project being nearly done and doesn’t understand why you still need another $N months to build it.

This is good. Customers don’t know what they want. It’s not their job. They only know what they don’t want after they see it. Anything that helps customers understand the implications of their own requests cheaper is a huge win for everyone.

Incomplete or missing requirements. When it isn't clear what you are trying to deliver, you introduce a whole host of problems to the project.

End to End Testing Flakiness - at my last company we spent a large amount of engineering time automating end-to-end tests. In the end we found them flaky, maintenance heavy and couldn’t get to 100% browser coverage. E2E tests are of huge value but their costs are still too high.

Yep. We were just getting a handle on it and then the new wave of frameworks have largely broken it again due to browser DOM's not being stable. Basically gave up automating testing of our last VueJS project after 5 years of successfully automating traditional web stacks.

This so hard. You'd think we'd have it figured out by now.

+1 to this. Huge pain point at several startups I have been at.

Honestly none. Not when I compare what I do to anyone I know.

Pay is excellent. Hours are standard, work environment is comfortable. Jobs are plentiful. (Again compared to other professions)

I know my programing skills here are nothing. But after 20+ years of doing this professionally it's clear there are not many people who can do this type of work.

I'm very lucky to be one of them.

I know right? I would be bored out of my mind in an environment that doesn't have problems. I'm hired to fix problems, I don't care if it's technical, people, process, whatever. The more problems there are to solve, the more I'm challenged to fix it. When all problems are solved, then it's time to move on to a new challenge.

1. Hype driven development: NoSQL, microservices, serverless. Used in places where they do not fit. Same with CV driven development.

2. Risk-averse traditionalists/architects. Instead of choosing right modern tools they keep pushing for Oracle/PHP/Java whatever they know.

2. They pay me a small fortune but I always get slow Windows box. VirtualBox helps but it is complex and slow. My three years laptop is a few times faster than new company laptop.

3. Not enough room for personal growth. I have family and I have less time to learn new stuff.

Absolutely agree. The amount of technologies that one has to be familiar with just to get an interview is ridiculous. And then once you are hired you are still doing maintenance on the 10 year old ASP website. Also: 3. off by 1 errors.

Most of the pain points raised here are a day to day reality, fair enough, but I would like to also bring up another point not often surfaced here:

Fellow developers not aware of the business requirements, or fellow developers not being able to see things from the business perspective and where the money comes from. I know, our code is not monadic enough, but we do really need to solve that problem affecting customer X before end of September, or there won't be enough money in the bank to pay for that fresh avocado on Monday morning.

Not necessarily a developer problem exclusively, but I always have to fight with the AC.

I'm freezing all day long, while some of my coworkers are apparently sweating. I think it has to do with the fact that the AC outside of the conference rooms is much more "efficient", and these coworkers use the conference rooms way more than I do.

This isn't specific to development, but feeling burnt out at the end of the day, every day. I also struggle with getting enough sleep, getting enough physical activity, and finding time to just get other things done. If I could, I'd only work 25 hours/week. Maybe someday.

Not being disturbed. Being able to stay focused.

This. I've found a pair of 3M Peltor Optime III do a pretty good job at keeping people away while I'm working.


North American equivalent appears to be:



Yes, but co-workers don't like it and then you become the antisocial hermit in their mind.

You have to let them know why you are doing it.

>You have to let them know why you are doing it.

Absolutely, yes. When I managed a tech support team in an open plan office, the indicator for "do not disturb" was either standard headphones or ear defenders. That was part of the new starter initiation, so everyone knows from day 1.

This is one that managers don't get. They don't take into account how important it is to focus on writing code to be productive. They assign seats on some random process with no regard to keeping developers undisturbed.

I suspect that open offices cost more on productivity than they save.

It greatly helped me to buy noise-cancellation headphones. The newer Sony 1000mx3 are great...a bit pricey but have helped me so much in an open office environment.

Having skills go stale every 3 years.

It seems impossible to really ever get really good at anything because everything you learn is trashed within a few years. It induces a feeling of constant mediocrity.

Writing tests first. Sometimes it's hard cause I am more flowy and designing interfaces and I'm just needing work here.

Also anxiety, and distractedness.

Your comment is a day old already, but I'll reply anyway.

Can you elaborate what you mean with anxiety and distractedness?

I've switched from developer to product owner, and then back to developer after two years. The problems I'm having with my role came back instantly.

I'm anxious that I'm not good enough, taking too long for everything, not smart enough to understand complex existing code that I have to modify.

This anxiety alone keeps me from properly focusing on the job at hand. And the more time pressure there is, the worse my focus becomes, because I feel I have no time to understand everything properly and have to hurry, which only leads to a worse solution and more problems in the end.

Add to this the 'normal' distractions of working in an open plan office.

Listening to other people's experiences sometimes helps. Yesterday I watched Sandi Metz' talk "All the little things", and also reading about Clean Code in general, and about imposter syndrome sometimes help me think that it's not really my fault and that I'm at least an average developer.

Then again, I'm also prone to asking too much of myself and being overly ambitious, also with sports, nutrition, life in general, so I'm not really content with being an average developer.

But being 40 already, I feel like it's already too late to become really good at anything, when I have 20-year-old colleagues who are already presumably better than me, despite me having 10 years experience in various roles and companies.

And then there's so many things that I could improve in, systems architecture, frameworks, backend, frontend, databases, OOP principles, learning new languages etc, that I don't even know where to start and the whole endeavour seems futile already.

That's when I ponder quitting the dev role again and switching into something else, but how often can I do that before my CV looks like patchwork and nobody will hire me because they don't really know what role I'm actually qualified for?

That's my struggle, anyway. Having worked as a developer for quite some time, but not really feeling like one.

I think it's a running dialogue in the mind that I need to quiet. I have specific problems, but if I solved them a new set of things would arrive to my mind.

I appreciate reading your thoughts, I think there are a lot of universal problems there. With so many things to learn, I just remind myself of the Joel Spoelsky essay, fire and motion.

Thank you for your post, it really helps me a lot.

Those times when you're not adding business value when developing features

The 5-day work week. If I could have a 3-day weekend every weekend, my quality of life would be so much better.

BaseCamp supposedly has a 4-day work week policy for the summers. Does anyone know of any other companies like that?

Finding enough time for coding (which is great fun).

As a freelance engineer, not knowing how to efficiently invest my time in learning something new. In other words: how do I keep staying relevant in the market?

Unlike other professions, having more experience does not relate to being more valued, often the opposite (image a medical doctor being dismissed for having too much experience). A software engineer (that wants to stay a developer) needs to re-invent herself multiple times during a career.

How do I pick what to learn? Just going by what interests me or what is hyped doesn't seem to be a good strategy

I'm working myself on a start-up to solve this problem (broad idea is to find companies that sponsor learning)

Untrained or poorly trained managers. The lack of solid leadership that exists in organizations of every size is stunning to me. The jobs I've had where I was my most productive was when I had quality managers leading the department.

- Lack of communication between design and development at the conceptual stage.

- Designers spending hours on particular pages with no consideration on how it affects other areas of the site.

- Need some tools but the process of justifying and convincing management that we need them leads to just buying them myself.

- Sharing common code snippets between team members

- Forced to stay online and be receptive on Slack while attempting to focus on code

- Open plan offices and the constant deluge of inspirational talks/events (I work in an "innovation space")

- No time between projects. One's done then it's another, and another.

- Crappy Jira tickets with little information.

- Jira

Apologies, this may have been mostly a rant. It's been that kinda morning.

Working with other Developers.

Working with egotistic devs.

This is a function of having to work with different people with different personalities. Developer or not you have to deal with this if you want a job.

The inevitable Schema vs Code mismatch that creeps in.

I've yet to see a belts and braces solution that works when introducing it on an existing database (rather than from the start with something like Flyaway).

I mostly like SQL but I kind of wish someone would do a clean slate design of a relational data store and unfuck the last 40 odd years of cruft.

I work in an environment where our data is eminently relational and generally mapping to a relational db type structure is quite simple but actually dealing with the minutiae of the various RDBMS's is just painful.

I was wondering about this a few days ago when I was, again, stuffing a square peg in a round hole by doing work you would hope a db or orm should be able to handle.

Is there any research going on to solve this in a non OO environment? I worked with (expensive) OO databaes in the past and that was crap, nosql is not helping much either, although the idea (I say the idea as I hate the implementation) to have the language married with the datastore like Mongo is something. I have seen non OO environments where the company just extended sql to be a full generic programming language which also works but it all feels... Not quite there. Q/k on kdb+ I find pleasant as I find Mnesia with Erlang. That feels far more natural than the other choices, but I feel it can be better with research and more FP oriented.

The rate of change of javascript frameworks and tooling. Need to learn a new one every year roughly. And dump all the working code and knowledge gained next year.

compare with Unix shell commands I learned in 1980, that I still use every day

Being told I was getting hired a backend Java developer for a first job and then working in a JavaScript, Java and DevOps full stack role for the last two years.

The frustration that comes from being required to be competent on a large range of technologies because of this and feeling just as I start to invest enough time in one I have to switch to doing something else. Most recently was working with Jenkins and Groovy!

Having to spend most of my time learning how vast piles of other people's code works and very little time getting to write any of my own.

Petty, charted off 'areas of responsibility' that hamper natural collaboration.

These may be cozy to some middle-managers to protect their domain, but ultimately this slows down the project flow via scrolls of email, request tickets, kowtows and 'bribes' just to have some matching project pieces fit. I guess, it's all down to team interactions.

As an interpreted lang developer (Python), hate the small things that can cause major delays, for example, "permissions missing on folder", or "filename_1 not found" (it was actually filename1). Little things that could be automated could make life a lot easy.

1. The industry changes so much I can't really tell if/when my skills will be truly dated (I work in front-end web/UI)

2. Sales/marketing. I'm a consultant and I just want to code and have work, but all of this stuff is just such a constant drag on my time.

Users/PMs/Management either don't know what they want, or worse, they think they know what they want, but can't articulate it or tell you something else. Then after you do it, they tell you it should have been some other way.

Bad habits of coworkers - the worst of all is loud throat clearing or summoning snot. Eating smelly foods noisily at desks when there is a break out area available! Loud talking on conference calls!

- Technical decisions from non-technical people (especially management and politics)

- False commitment to up-front design decisions, even in the face of absurdities and architectural violations

- Inability to throw away code

- Overengineering

- Underengineering

Working on user pain and trying to serve their needs while someone is pressuring you to work on something that a number of people can do.

Having a truly shared and portable dev environment

The pressure to deliver code that isn't of high quality and tested.

Requirements that are extremely unclear.

Open plan offices. They're fantastic for managers / saving space, but just awful for trying to focus.

I recently read a good medium article[1] about why they are a terrible idea.

[1]: https://m.signalvnoise.com/the-open-plan-office-is-a-terribl...

Having to explain technical things/difficulties to non-technical people.

Users. :)

second that....

Writing bash scripts.

Related: Reading bash scripts.

Related: Running bash scripts? :)

Related : Rewriting bash scripts to windows batch scripts because they can't get cygwin installed on that one client machine. Ughh!

Related: Rewriting the batch script to be PowerShell because reasons.

Managers who call meetings for the sake of meetings.

Us devs got so much to complain about !

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact