Ask HN: As a developer, what are your biggest pain points?
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.
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....
Unbiased opinion, but this is a problem I really care and I'm trying to solve with https://type12.com
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'll try to make an effort to do that more often now! thanks
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
https://www.amazon.co.uk/Peltor-Optime-Earmuffs-Headband-Bla...
North American equivalent appears to be:
https://www.amazon.com/3M-Earmuff-Protectors-Hearing-Protect...
https://www.amazon.ca/3M-Peltor-Optime-Earmuffs-H10A/dp/B000...
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.
I suspect that open offices cost more on productivity than they save.
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.
Also anxiety, and distractedness.
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 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.
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)
- 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.
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.
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 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!
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.
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.
- False commitment to up-front design decisions, even in the face of absurdities and architectural violations
- Inability to throw away code
- Overengineering
- Underengineering
Requirements that are extremely unclear.
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...