Process
|
Show
|
NA
|
Show
|
-
|
Show
|
Repetitive tasks
|
Show
|
process
|
Show
|
Time taken for compilation and sometime load on target
|
Show
|
Preparing documents( HLD, DLD)
|
Show
|
Nothing much.
|
Show
|
Long compilation cycles
|
Show
|
Coding without having a proper Design. Not taking care of impacts of software.
|
Show
|
Preparing the exact simulation environment to avoid testing on hardware is difficult.
|
Show
|
nothing
|
Show
|
Complexity as and when features increase, managing is difficult. Need to make sure no regression
|
Show
|
how to test software
|
Show
|
how to test software
|
Show
|
NA
|
Show
|
I don't know to be honest, sometimes it's just boring when I have to re-implement something existing
|
Show
|
Develop feature, which had incorrect prepared tests.
|
Show
|
Extensive testing
|
Show
|
Everything, especially the constant humiliation
|
Show
|
Documentation.
|
Show
|
Engineers don't talk much and lack the pleasure of communication.
|
Show
|
debugging, incomplete requirements, undefined behavior of code
|
Show
|
Finding bugs.
|
Show
|
Fighting legacy code
|
Show
|
Being deep in the debugging process and not knowing what to do resolve it.
|
Show
|
The overhead - documentation, design meetings, etc
|
Show
|
Setting up infrastructure for development, debugging the tools instead of the code
|
Show
|
Debugging hard to reproduce problems. Spending time trying to hit weird edge cases.
|
Show
|
Without understand system
|
Show
|
Getting into something over my head.
|
Show
|
Getting into something over my head.
|
Show
|
Using someone else's API or tools that are poorly documented
|
Show
|
Bugs
|
Show
|
dealing with buggy tools, dealing with legacy code...
|
Show
|
schedules
|
Show
|
When you can't figure out why the computer won't do what you want!
|
Show
|
pressure
|
Show
|
Debugging (mainly, not knowing how to debug).
|
Show
|
Distractions
|
Show
|
Dealing with changing requirements
|
Show
|
Finding causes of bugs and fixing them.
|
Show
|
When algorithm that seemed good in my head does not work in code as expected
|
Show
|
- Wasting tons of time drudging through legacy code
- Breaking brittle code
- Poor architecture
|
Show
|
- When debugging takes too long
- When there is too much code to wrap my head around
|
Show
|
Esoteric/time wasting bugs
|
Show
|
Analysis Paralysis. It's easy for me to spend too much time trying to find the best architecture.
|
Show
|
The short schedules to achieve unreasonable accomplishments
|
Show
|
Bugs and defects. The challenge and communicating the challenges to others.
|
Show
|
Debugging. Hurriedly trying to learn necessary new things. Setting up complex toolchains before making simple progress.
|
Show
|
documentation
|
Show
|
The misconception by other groups in multifunctional teams that developing software is quick and easy.
It is quite easy to walk down the wrong path and write software quickly and haphazardly to produce code that functions for only "right now".
|
Show
|
I'm not convinced documentation is as important as everyone says it is. When there's too much, there's a sense of ease but you often miss the important parts. When there's not enough, there's a sense of panic but you can always elaborate more.
|
Show
|
no universal rules and good practices
|
Show
|
Remembering syntax for languages I don't use very often. Fighting with different IDEs and Debuggers.
|
Show
|
When feature creeping gets out of hand
|
Show
|
How long it can take to find bugs sometimes
|
Show
|
That one renounces quality for reasons of cost.
|
Show
|
Limitations by advice / tools.
|
Show
|
If time or money are wasted for any reason.
|
Show
|
?
|
Show
|
It could be paid better.
|
Show
|
so many bad code, so many new hypes.
|
Show
|
-
|
Show
|
I don't like when coding is performed without a plan for the overall architecture and code reuse.
|
Show
|
It isn't all exciting- keeping up on new standards and methodologies can be hard to do.
|
Show
|
running out of time and deliver unfinished (incomplete and buggy) SW to the customer
|
Show
|
running out of time and deliver unfinished (incomplete and buggy) SW to the customer
|
Show
|
Nothing comes to my mind now.
|
Show
|
reverse engineering spagetti code; long feedback loops for (test) results
|
Show
|
Debugging. Sure, I might be the same as the majority (as stated in the intro video), but, yeah, the abyss of debugging can sometimes be a little deep.
|
Show
|
bugs - best tester in world taught me to call them mistakes
|
Show
|
repetition of implementation and bugs/errors
|
Show
|
debugging ;).
badly formatted code (different styles from different authors in single file), actually non-tool-formatted code.
writing documentation.
project managers that trade (initial) development time for quality.
|
Show
|
Finding errors/bugs
|
Show
|
Feeling on not fully understanding things. Risk of small mistakes having big consequences. The common perception that programmers are already doing the best they can using limited approaches.
|
Show
|
|
Show
|
Sometimes hunting bugs can be tedious
|
Show
|
Sometimes simple things take a lot longer than they should
|
Show
|
Documentation
|
Show
|
Because you can dramatically change the behaviour of a whole system with very few effort, everybody thinks everything can be fixed by changing the FW
|
Show
|
Finding errors/bugs
|
Show
|
Packaging, setting up environments, and troubleshooting something to later realize the problem was somewhere else.
|
Show
|
the lack of documentation
|
Show
|
The search for the cause of an annoying bug that is almost impossible to find out about.
|
Show
|
Due to the fact that a lot of people belive that software can always and at any time be changed easily there are most of the time a lot of changes during development. I do not like to fight with a fragmented software that grows and grows.
|
Show
|
It is hard to tell if a the way we choose to do things will be considered as a good decision in the future.
SW modules always seem to be fine in the beginning as long as they are small and the person who created is available.
|
Show
|
Maintaining poorly-written software. Throwing documents over the wall. Doing anything that doesn't add value.
|
Show
|
Depending on how the project is lead, it can go wild very easily and the "anything" of above can be changed to "crap".
|
Show
|
too many configuration options and unique rules
|
Show
|
Lacking of documents. Bad software design.
|
Show
|
Writing documentation.
|
Show
|
Often solutions are not properly developed because of time constraints
|
Show
|
pressing deadline, issues happen last minute require staying late solving it
|
Show
|
It's hard to clean up and 'pay' (via code rework) for messes by quick-fixes made in the past. I try to look at it as more of an opportunity to look for ways to not predict the shape of the code beforehand, but make it easy to work with when needed.
|
Show
|
Knowledge gets outdated too soon
|
Show
|
there is no teammate to review my written software to improve my skills
|
Show
|
there is no teammate to review my written software to improve my skills
|
Show
|
Long debugging sessions.
|
Show
|
Hunting for bugs in poorly written code
Weighing up the pros and cons of tidying up poorly written code
Making the same points over and over again in code reviews
|
Show
|