
Ask HN: As a developer, what are your biggest pain points? - johnnyRose
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.
======
pmiller2
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....

~~~
anacleto
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](https://type12.com)

------
vga805
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.

~~~
corysama
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.

~~~
vga805
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

------
AlexanderNull
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.

------
WheelsAtLarge
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.

------
sgt
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.

~~~
johnnyRose
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.

~~~
noir_lord
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.

~~~
tluyben2
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.

~~~
noir_lord
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.

~~~
tluyben2
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.

------
sh87
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.

------
tluyben2
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.

~~~
cimmanom
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.

------
laughingpine
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.

------
troysandal
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.

~~~
zmmmmm
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.

------
treespace8
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.

~~~
segmondy
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.

------
Chyzwar
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.

~~~
garunski
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.

------
Ygor
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.

------
alain_gilbert
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.

------
Raphmedia
Not being disturbed. Being able to stay focused.

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

[https://www.amazon.co.uk/Peltor-Optime-Earmuffs-Headband-
Bla...](https://www.amazon.co.uk/Peltor-Optime-Earmuffs-Headband-
Black/dp/B000VDX18E/)

North American equivalent appears to be:

[https://www.amazon.com/3M-Earmuff-Protectors-Hearing-
Protect...](https://www.amazon.com/3M-Earmuff-Protectors-Hearing-
Protection/dp/B00009LI4K/)

[https://www.amazon.ca/3M-Peltor-Optime-
Earmuffs-H10A/dp/B000...](https://www.amazon.ca/3M-Peltor-Optime-
Earmuffs-H10A/dp/B00009LI4K/)

~~~
WheelsAtLarge
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.

~~~
petecooper
>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.

------
hnruss
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.

------
zmmmmm
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.

------
vertline3
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.

~~~
tcmb
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.

~~~
vertline3
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.

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

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

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

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

------
Zelphyr
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.

------
amorphous
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)

------
navs
\- 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.

------
chad_strategic
Working with other Developers.

~~~
brink
Working with egotistic devs.

------
noir_lord
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.

~~~
tluyben2
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.

------
dave333
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.

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

------
Dannymetconan
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!

------
abainbridge
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.

------
zoomablemind
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.

------
bobosha
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.

------
acconrad
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.

------
cbanek
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.

------
ojhughes
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!

------
serichsen
\- 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

------
lowmagnet
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.

------
pouta
Having a truly shared and portable dev environment

------
velebak
Users. :)

~~~
slipwalker
second that....

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

Requirements that are extremely unclear.

------
jackdh
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...](https://m.signalvnoise.com/the-open-plan-office-is-a-terrible-
horrible-no-good-very-bad-idea-42bd9cd294e3)

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

------
laylomo2
Writing bash scripts.

~~~
laylomo2
Related: Reading bash scripts.

~~~
TruffleMuffin
Related: Running bash scripts? :)

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

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

------
ithilglin909
Managers who call meetings for the sake of meetings.

------
sh87
Us devs got so much to complain about !

