Some examples - server management, deployment, choosing the right framework, hiring the best talent, designing database, etc. Would love to hear some extended answers too.
Honestly management, and I work in a place that probably gives me more freedom and autonomy then any other software shop I'll ever work in.<p>It's just the usual gripes, the CEO, Product Manager/Dev Manager don't understand the technology as-well as they should. (And I interact with both of them on an almost-daily basis). The CEO is some-what understandable for his lack-of-technical knowledge except that he is a technical founder (of an admittedly 20-year old company), so you would just expect more. Same with our Dev Manager who doesn't code anymore, and spends most of her time getting requirements and working on the data-models...but again, using extremely out-dated techniques.<p>Oh and I also want to add, the feeling that I could legitimately produce a better product then what I am working on now, if I was just in a position to take that risk and open a company. (Can't work on similar work for a year after I leave due to Contractual Obligations). It's pretty obvious when you are re-writing EVERYTHING, that the entire product could just be...better. And that it's also obvious when you enjoy re-writing everything and going to work, that this is a business-area you have a passion-for improving. Sadly, I'm no salesman and never will be, and I also lack sufficient capital at my (young) age to get started on my own.<p>Those are my gripes anyway :)
Management. Front line dev managers I find all share common characteristics: 1. They are tech illiterate and are afraid of being found out. They use aggressive anger to avoid getting into a technical discussion. 2. Are actually trying to hinder and slow down development. Being in charge is all that matters, and fast progress does not contribute to that goal. 3. They enforce common denominator 20 year old technology not so they can hire more easily, but because they have no basis for judging modern technology and can't politically handle making a wrong decision. 4. They will make a project crawl because they and the three levels of management above them are simply there to collect money for as long as possible before they rotate themselves around to "new" projects.<p>Projects are slowed down by these tactics:<p>- Heavyweight code review process with very large teams and lots of conflict<p>- Unscheduled meetings if things start happening too quickly.<p>- Using methodology to limit the scope of developer work.<p>- If things get too out of control, rotate and reassign developers every few months.
Almost everybody should agree on bugs as the major annoyance to developers :)
But do we have data to support any claim about bugs? Are developers to blame? lousy requirements? aging software? inappropriate tech? process?
Maybe we need more data to make informed choices in the future when developing software, to decide where to put our efforts?
Do we need a startup/project postmortem website with data analysis?
Not 'problems', but my dislikes.<p>I dislike that my IDE (sublimeText, but I don't think others are any better). has stuff all over the place, that I've got separate terminal windows for my grunt tasks (linting, tests, etc), git status, a separate browser window to view changes.<p>That's why I'm building my own :)
"transfer of knowledge" being extremely hard when the requirements and projects have no structured documentation. Faster in short-term, but obviously creates technical debt in the long-term...