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.<p>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....
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.<p>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.<p>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.<p>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.
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’.<p>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.
1. Hype driven development: NoSQL, microservices, serverless. Used in places where they do not fit. Same with CV driven development.<p>2. Risk-averse traditionalists/architects. Instead of choosing right modern tools they keep pushing for Oracle/PHP/Java whatever they know.<p>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.<p>3. Not enough room for personal growth. I have family and I have less time to learn new stuff.
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.
Honestly none. Not when I compare what I do to anyone I know.<p>Pay is excellent. Hours are standard, work environment is comfortable. Jobs are plentiful. (Again compared to other professions)<p>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.<p>I'm very lucky to be one of them.
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:<p>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.<p>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.
Having skills go stale every 3 years.<p>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.<p>Also anxiety, and distractedness.
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.
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?<p>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.<p>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<p>I'm working myself on a start-up to solve this problem (broad idea is to find companies that sponsor learning)
- Lack of communication between design and development at the conceptual stage.<p>- Designers spending hours on particular pages with no consideration on how it affects other areas of the site.<p>- Need some tools but the process of justifying and convincing management that we need them leads to just buying them myself.<p>- Sharing common code snippets between team members<p>- Forced to stay online and be receptive on Slack while attempting to focus on code<p>- Open plan offices and the constant deluge of inspirational talks/events (I work in an "innovation space")<p>- No time between projects. One's done then it's another, and another.<p>- Crappy Jira tickets with little information.<p>- Jira<p>Apologies, this may have been mostly a rant. It's been that kinda morning.
The inevitable Schema vs Code mismatch that creeps in.<p>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).<p>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.<p>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.
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.
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.<p>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!
Petty, charted off 'areas of responsibility' that hamper natural collaboration.<p>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 <i>really</i> tell if/when my skills will be truly dated (I work in front-end web/UI)<p>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)<p>- False commitment to up-front design decisions, even in the face of absurdities and architectural violations<p>- Inability to throw away code<p>- Overengineering<p>- Underengineering
Open plan offices. They're fantastic for managers / saving space, but just awful for trying to focus.<p>I recently read a good medium article[1] about why they are a terrible idea.<p>[1]: <a href="https://m.signalvnoise.com/the-open-plan-office-is-a-terrible-horrible-no-good-very-bad-idea-42bd9cd294e3" rel="nofollow">https://m.signalvnoise.com/the-open-plan-office-is-a-terribl...</a>