Training Preparation -- What 100 Attendees Dislike About Software Development
| Least favorite thing about dev | |
|---|---|
| - Having to go back and fix issues in code that was written by myself or someone else after a long period. |
Show |
| not figuring out the solution of something, and debugging. |
Show |
| errors |
Show |
| Picking up someone elses poorly written/structured code in order to fix a bug. |
Show |
| I do not like the fact that sometimes programming involves spending incredibly large amounts of time debugging code. |
Show |
| Trying to remember one thousand details that are only needed for this one little bit of code that will be forgotten as soon as I can get it to work right. |
Show |
| Re-working many times on the same code (for big changes). This often break the code (now developed without TDD) and the bugs can appear in the worst moments. |
Show |
| n/a |
Show |
| I don't like to convince people about TDD. |
Show |
| I don't like the opaqueness of testing, where it can become increasingly difficult to accurately determine where things are going wrong. |
Show |
| 1. Hectic schedule/Long hours of work
2. Unrealistic requirement
3. Stress |
Show |
| As project size increases, new requirements are brought in - things can start becoming quite complex due to the hidden dependencies they have on each other. |
Show |
| When code doesn't work, debugging |
Show |
| Having to deal with old legacy systems that I do not fully understand. |
Show |
| - Legacy code and maintenance
- When new to a complex system in place it is difficult to balance between requirements and efficiency and understand big picture (however it feels good to overcome these and understand the system)
- Effort estimation |
Show |
| - |
Show |
| - |
Show |
| Trying to figure out the root cause of a software bug that is intermittent can be frustrating. |
Show |
| . |
Show |
| sitting in front of the computer all day :) |
Show |
| too much context switching |
Show |
| Gumption traps are acutely painful. |
Show |
| Feeling there is not enough time / resourcing. |
Show |
| Documentation/Commenting. Setting up an environment. |
Show |
| Working with legacy code. |
Show |
| It's open-ended, and the number of techniques, design patterns etc can be overwhelming!
It's hard to estimate time.
It's hard to estimate how powerful the target CPU needs to be! |
Show |
| Not knowing how to approach something or wrestling with errors once I've written code and can sometimes spend hours trying to fix it. |
Show |
| there's too much variety and churn in development systems, languages, tools and methods |
Show |
| When requirements are unclear. Dealing with finicky hardware. |
Show |
| If you're not proficient with pointers, you're in for some headaches.
My last job, the software was large, it took up to 30 minutes to build from scratch. Once built, changes normally took 30 seconds to a minute. |
Show |
| Sometimes (often), work takes more time than anticipated. |
Show |
| Many devices have poor documentation. |
Show |
| lack of social interaction |
Show |
| Flaky tools and dependencies |
Show |
| The number of hoops it seems we have to jump through just to develop code. It could be compilers or debugging software there are just too many additional things needed to even run basic code (outside of Linux) |
Show |
| paperwork, schedule crunches, sometimes poor communication |
Show |
| The contant tool changing |
Show |
| People's opinions that they way they did it 20 years ago is the only way to do it or that their experience is automatically more valuable and more correct than a younger developer. Also the C/C++ development ecosystem w/r/t dependency management |
Show |
| Developing software can be stressful, if you don't how implement a function or method, or if you don't know what the cause of a particular error is. |
Show |
| In day job the work is bogged down by organizational red tape, but that not specific to software in general. |
Show |
| Working around hardware issues |
Show |
| Time consuming and rigid procedures and processes. |
Show |
| Time consuming and rigid procedures and processes. |
Show |
| Time consuming and rigid procedures and processes. |
Show |
| I dislike dealing with confusing/broken development tools that slow down actual development. |
Show |
| When I spend a lot of time fixing bugs on production environment, which could be avoided with proper tests |
Show |
| To much adhoc techniques involved and guesswork as per how long things take. Testing can be tedious ! |
Show |
| - |
Show |
| Can be frustrating sometimes when you don't have all the knowledge about certain tool, system, library, etc. |
Show |
| Testing can be tedious and maintainablity of tests is sometimes difficult. |
Show |
| The development enviroment may not always be ideal(particularly for c) which can result in a lot of complexity and difficutly to acheive a very simple task. |
Show |
| writing tests unfortunately |
Show |
| idk :| |
Show |
| learning curve |
Show |
| Debugging someone else's code |
Show |
| Constant feature creep. |
Show |
| no value software |
Show |
| Finding hidden bugs and edge cases. |
Show |
| Being stuck with legacy code with a bug I can't find. |
Show |
| When I have to fight the development environment, debugger, etc. I also don't like when I have a vague requirement on what I'm being told to do and have to guess at what the customer or product owner want |
Show |
| The errors I inject. Some embedded debugging tools can be a pain to get actually working - but they are also needed due to errors I inject. |
Show |
| Pointers and having to debug. lol |
Show |
| Setting up development environments. |
Show |
| debugging intermittent/hard-to-reproduce problems that only show up after firmware runs for days on target platform |
Show |
| documenting it. |
Show |
| I wish customers always knew exactly what they wanted and what is within reason. Changing requirements/priorities and the entire area of customer management is the worst. |
Show |
| when it never does work at first |
Show |
| tough question, pass! |
Show |
| It's time consuming and can be somewhat tedious. |
Show |
| Hunting down really obscure (rare) memory corruption bugs. |
Show |
| Tight schedules / rush resulting in product with questionable quality / reliability |
Show |
| I work in science and engineering software, so I don't have anything to complain about. If I had to work on web sites, then that would be another story. |
Show |
| Tool issues, differing coding style (beyond just what standards cover), dealing with legacy code |
Show |
| NA |
Show |
| Changing requirements. Creating documentation. Most meetings. Poorly written code. Diagnosing bugs, especially in unfamiliar and poorly written code. |
Show |
| long cycles for small change |
Show |
| testing |
Show |
| Debugging semi-reproducible (or not reproducible) bugs. If I can consistently reproduce the bug, I'm 90% of the way to fixing it. |
Show |
| Doing same functions for many products without reusing it over and over again so that reduce test/debug time |
Show |
| I always seem to struggle with getting third party libraries and tools to work. I'm also not crazy about bad code. |
Show |
| Invisible problems. Hard faults. Memory allocation. Test (sometimes). Communication protocols. |
Show |
| Having to re-write code |
Show |
| GDB debugging (in c it was fine but in c++ it's tedious) |
Show |
| Debbuging hard to reproduce event which are reported with only few information by tester / customer. |
Show |
| Working with remote teams can make communication challenging. Maintaining legacy code can be challenging when there are no automated tests set up.
|
Show |
| debugging close to a deadline. |
Show |
| The manual testing process and vague bug reports that are hard to track down to root causes. |
Show |
| The time required to debug nested issues. |
Show |
| Managing changing API for releases in public open source software/firmware |
Show |
| Debugging. |
Show |
| When things get non-deterministic. I don't mind a good challenge, I hate looking at the same line of code until I realize that the previous programmer forgot to use one more set of parenthesis. |
Show |
| Setting up tool chains, build environments, etc. |
Show |
| Hard to reproduce bugs. |
Show |
| I dislike working overtime trying to finish multiple projects with the same deadline. Especially when there is never time to consolidate/refactor an old codebase, but always time patch systems that have not been properly maintained. |
Show |
| Finding bugs, repeating coding erros, finding errors made by others |
Show |
| It takes to much to debug the code. Especially when there is no hardware available to test on. |
Show |
| When the code is too long and not optimized |
Show |
| wrangling side effects from tough-to-completely-understand APIs |
Show |
| Debugging and Maintaining documentation |
Show |
| Sometimes you are forced to create solutions that you are not proud of. |
Show |
Make this into a word cloud
Select text below (triple click), copy, then try one of these tag cloud generatorsjasondavies word cloud generator - colorful
tagcrowd - lets you show counts