Training Preparation -- What 1030 Attendees Dislike About Software Development

Least favorite thing about dev
Documentation (other than code comments), spending too much time testing.
Show
Can be stressful.
Show
x
Show
Variety, Creative Independence
Show
Being hurried to get it done without thorough testing, covering all use cases.
Show
Testing
Show
Bugs and debug
Show
Bureaucracy involved in some of the process steps we have at GE.
Show
Trying to schedule its development time.
Show
death marches poorly structured code
Show
having to debug and fix defects that no one can reproduce.
Show
Nothing
Show
Challenges
Show
Maintaining poorly documented or rambling patched code
Show
I don't like having to conform to old or outdated standards.
Show
debugging
Show
Waterfall model of software development
Show
At Zebra, have not been given the opportunity to design prior to coding
Show
I least enjoy API design as it can be frustrating to get the right balance of simplicity and flexibility.
Show
Too many untrained developers.
Show
Non-trivial projects are enormous and generally old. Standards change and newer developers will modify improper pieces of code.
Show
Debugging multithreaded code.
Show
Poorly defined requirements
Show
zxczc
Show
No major dislikes.
Show
Deadlines
Show
much thinking and much testing .
Show
Code Maintenance
Show
Sometimes some very small issues take up too much time trying to find out what went wrong.
Show
too much process.
Show
-
Show
When there's a bug and it's very difficult to find it out
Show
vice versa
Show
I don't like dirty
Show
Testing
Show
Computers are dumb. The only do exactly what you tell them to do. Lots of bugs to catch.
Show
build time too long
Show
Testing
Show
It's difficult to find bugs.
Show
repetition
Show
The frustration when the development process is not going as fast as expected.
Show
Debugging
Show
Process
Show
Using different tools to test and compile the code. Slow build time and lack of debugging tools
Show
when there are too many screwed up unknown dependency
Show
object oriented
Show
long build times
Show
Debugging.
Show
when build server is down, build need longer time, requirement is not clear, do not have test targget to test, too much of process.
Show
different hardware environment or different system environment between developing and running.
Show
too much process to govern the software quality, debugging software
Show
review processes
Show
Debugging non-deterministic low level embedded software issues.
Show
1
Show
bug and error
Show
Hidden bugs that only show up months later
Show
Debugging.
Show
-
Show
Waiting for code to build. It takes 2-3 minutes every time I clean my code on CCStudio.
Show
embedded software has limit resources, often we have to have some hardware ready in order to test or implement a functionality. Some problems that we see (like complete lock-up issues or driver lock up issues) are not repeatable
Show
poorly written legacy code
Show
Being dependednt on hardwar whose workings I dont know
Show
Testing the code which we know will work , but sometimes not thinking through the code where it impacts other systems.
Show
takes time to debug
Show
Hard to say, it gets to my gut sometimes
Show
Debugging other peoples code with sufficient debug messages
Show
if jobs becomes repetitive and documentation.
Show
Tight dead lines.
Show
Time spent on not doing the real thing
Show
Debugging unknown code written by the open source community with the "sparse" comment style.
Show
Bad code.
Show
Overheads and paperwork
Show
Tracking down those elusive bugs for too long.
Show
You can get stuck in the most simple bug for hours...
Show
Writing documents (SDD)
Show
NA
Show
Spending time continually debugging everyone else's code and not writing anything.
Show
Too much emphasis on process and not on effectiveness of code and results
Show
Having to come up with high confidence predictions for large pieces of complicated programming work...
Show
It doesn't happen fast enough
Show
DO-178B flight certification requirements for following a more Waterfall flow. Resistance to testing first because it hasn't always been done that way. I don't like that DO-178B requires independence (code developer can't be the test developer).
Show
Getting bogged down fixing weird bugs.
Show
The ability to effectively predict time to capability availability
Show
almost nothing
Show
Not having all the requirements when I start.
Show
Someone sitting on my shoulder
Show
debug
Show
Documentation
Show
nasty bugs (timing, memory or multithreading problems that can consume significant effort)
Show
Problems that are difficult to get to the bottom of.
Show
Wasting time debugging simple errors
Show
Facing numerical problems like the loss of significance.
Show
Have to do with inherited messy code
Show
Tricky debugging
Show
documentation
Show
the intriccies of the language
Show
Mundane but necessary tasks. Tracking down bugs. Maintaining bad code.
Show
Documentation... :)
Show
jumping through all the hoops to get code checked in
Show
nothing really
Show
Debugging others' code.
Show
-
Show
too many meetings and not spending time on development
Show
Difficult to track hardware interactions, trouble getting consistent results
Show
Fighting with the tools to get them to do what I want them to do.
Show
All the BS management stuff.
Show
Hard bugs. It's a love - hate relationship.
Show
Being patient with management.
Show
It has been 10 years since I worked on a project that has actually shipped. Seems most companies cannot tolerate the amount of time it takes to build something from scratch.
Show
Debugging, especially in embedded environments.
Show
Tedious processes.
Show
Check-in process
Show
Dealing with buggy or inadequate environments.
Show
-
Show
Yes
Show
interruptions & managers
Show
boring solutions that take a long time to test
Show
I don't particularly like debugging (most of the time)
Show
Not having the correct tools to properly test the software
Show
tool crashes
Show
The big amount of legacy code, which is badly written and not understandable.
Show
Maintenace work of old not documented code where no tests are available.
Show
repetition, ugly code, hungarian notation, tricky code without clear design and responsiblity. Non exisiting model.
Show
I don't like when you fix some bug in a part of code and create another one , or maybe more than one , in some other part.
Show
Writing the documents
Show
Trying to find those bugs that turn up in the field.
Show
Runtime errors which can't be reproduced. And that they always come up when it is no time to analyse.
Show
People that don't communicate and don't like to clarify anything. Non passionate people about programming.
Show
nothing till now
Show
Debugging code for bugs after release. In simple word post release bug.
Show
-
Show
Getting blocked by the "company"
Show
n/a
Show
finding the starting point of how and what to code.
Show
debugging
Show
Lousy tools
Show
Tedious debugging.
Show
test and documentation
Show
debug.
Show
I don't like sitting and staring at a screen of text all day.
Show
reading code with no comment, improper idents
Show
Hard to set up. Questions like this
Show
Frustrations with tools on occasions. Sharing resources when needed.
Show
Really long debug sessions, working with buggy, undocumented legacy code bases
Show
Issues caused by tool limitations that I have no control over and have to work around.
Show
Not much really other than having to sit at desk all day.
Show
Project politics, redirection from above, poorly stated and/or shifting objectives.
Show
cannot control other people's activity, for example, your product architect, your testing team, even if you do a good job, other people could still screw up the product
Show
coding
Show
creating something new
Show
Inability to use a debugger, forced to use printfs
Show
schedules, lol
Show
None.
Show
Slow environments
Show
Integrating code changes into the larger code base. Many code developers running pre-commit tests that have intermittent failures.
Show
Meeting, Meetings, Meetings - I attend all the bug reviews and do the initial triage on the bugs reported by other groups.
Show
making changes in other module code
Show
Tools that don't work
Show
Getting around hardware hard bug, dealing with unexpected and critical timing issues, specifically un-reproducible bugs.
Show
na
Show
Failing.
Show
Switching between platforms can be a painful, grueling process.
Show
Working with legacy code that is not well documented and difficult to test.
Show
Debug and test. Fixing problems after they get to the field.
Show
testing
Show
When we get a customer complaint, and I have to try to figure out what code (that I probably didn't write) is doing, while being pressured by management
Show
dealing with managers who don't understand software
Show
Too much documentation
Show
Nothing really
Show
when inconsistent errors occur
Show
It can be hard to follow another's code, particularly if they do not write organized SW.
Show
Meetings, distractions, constant pressure to under-estimate how long things will take to design correctly.
Show
Reading/debugging other people's code
Show
Undocumented APIs, excessive management overhead, pressuring schedules and last minute changes
Show
Not much really. Perhaps when 3rd party tools are crashing/buggy and/or shaky requirements.
Show
1. Weak hardware. More's law seems to stop when it comes to embedded hardware. 2. Legacy code.
Show
I do not like when things are going very slow. For example, the customer is not answering problematic questions etc.
Show
Static working position.
Show
Debugging errors others have made
Show
messing with log files and looking for errors
Show
I hate that very often I have to fix and clean up untested sloppy code written by other (often more experienced) developers.
Show
When I release SW with a bug that I wrote a unit test for... Race conditions...
Show
somethimes stressfull
Show
new specificaitons in the last minute
Show
Unclear specifications, changing opinions,
Show
Errors that show no clear pattern .. of course.
Show
Messy code from others.
Show
It always takes more time to finish than anticipated.
Show
Parts of the documentation and planning before starting
Show
deadlines :) !!
Show
efficiency for problem solving
Show
not sure
Show
Debugging
Show
Debug time and tools - especially gets harder when there are more components involved; integration is likely bound to be affected, unless the code is carefully written/implemented.
Show
requirement not clear
Show
Find tricky bugs, work on dirty code base.
Show
...
Show
I use hardware platform.
Show
NA
Show
no comments in code, no coding standard
Show
There are always bugs in the code, and some of them often bothers me for weeks.
Show
It's lonely
Show
no
Show
n/a
Show
nothing
Show
no
Show
limited test
Show
No
Show
Impossible deadlines and expectations.
Show
having to tolerate people that are not good at it
Show
I can't always use the languages I'd like to use.
Show
Waiting for computer/tools. Bugs in tools.
Show
Documentation
Show
Spending hours to find where the bug is. Spending a lot of time trying to get the environment working, rather than the business logic.
Show
Error handling, testing, documentation (reading and writing), eye strains of staring at the screens, interacting with other people
Show
pretty much everyone else's coding style; working on a poorly written code base.
Show
Dealing with shortcuts taken in the short term that negatively impact long term software quality.
Show
Mysterious bugs; hardware anomalies.
Show
na
Show
Debugging code that is not mine.
Show
Intermittent bugs
Show
some times not efficient when editing
Show
Its been a while
Show
documentation
Show
The changing of requirement that cause changes in the automated test scripts
Show
Cost! It is tough when you are bound by cost. You need a $3 CPU and you are given a $1 CPU.
Show
Not having the information to understand the goal of writing the test.
Show
Release to production process
Show
debugging other people's code
Show
don't like to be rushed, usually results in half baked solution
Show
Bugs.
Show
There is a risk with any software deployed in large quantities that a bug will cause serious problems.
Show
Meetings, pressure to fix bugs or complete features in short space of time.
Show
changing requirements
Show
multiple releases
Show
new languages
Show
Nothing really. It usually the politics of code changes near a release that make I don't like.
Show
easy to change so business can often add more and more features to releases that already have challenging schedule
Show
Bugs
Show
Documentation can be tedious.
Show
kalimba dev environment
Show
See above.
Show
Dealing with careless and untidy code
Show
Random results when testing on real hardware, working on hard to follow or rotten code.
Show
Humans.
Show
I think we spend too little time writing code, instead we seem to have to spend lots of time maintaining technical debt, and 'fire fighting' problems that arise in the most remote corner conditions.
Show
Fighting with tools and development environment.
Show
When I haven't got software to develop.
Show
Fighting toolchains
Show
Dealing with crappy existing code
Show
Struggling to fix issues in legacy code
Show
Integrating new code into old code
Show
To understand/work on legacy code which is not documented or not very well designed.
Show
Documentation, meetings.
Show
Trying to fix bugs caused by careless planning and design reviews.
Show
Building the setup for cross-compilation, and deploying
Show
Spending a long time debugging a problem and finding it is a one-line fix that should have been picked up earlier.
Show
Having time pressures
Show
-Bugs!!!
Show
Honestly, I don't like doing regression testing after writing software
Show
Debugging
Show
Manual test, especially when it have to be done more than once. Software components without source code or documentation/examples.
Show
nothing really, wouldn't be a software engineer if i didn't like doing it.
Show
Deadlines
Show
got stuck when debugging, frustrated when can't find the bug or solution
Show
Depending on other's code.
Show
Debugging
Show
Debugging.
Show
Technical friction, bugs, untested software, wasting time debugging, accumulation of technical debt, flaky tools, wasting time debating with co-workers, dealing with people who don't want to (or don't know how) to change.
Show
Dealing with immense technical debt.
Show
Being out of the zone.
Show
Less observable and debug-able than hardware
Show
Determining what a customer really needs vs what they think they want. Arguing with management about priorities, especially around tooling, refactoring etc.
Show
Debugging
Show
Painting yourself into a corner with bad design decisions.
Show
I don't like looking deadlines when there is a tough problem in my path to the finish line.
Show
Repetitive changes, fear of regression due to enhancements. One of the reasons for joining this course if it can automate UT as much as possible.
Show
the tedium still associated with the assembly and configuration part of development. It's amazing how far we've come and yet how much BS we still put up with.
Show
existing software
Show
stress
Show
Working with preexisting code
Show
learning new technology
Show
Debugging poorly written code or mysterious bugs that often appear to be problems with things like the OpenGL video drivers we are stuck with.
Show
Trying to make sense of another developer's code, especially when said code contains functions consisting of hundreds of lines of code.
Show
documentation: it is challenging to keep it up to date with the software that's constantly evolving and is time consuming
Show
Some of the politics required when making a design decision and the amount of testing required to prove the design out (with no unit testing)
Show
Lack of knowledge and understanding of software development by rest of company
Show
TBD
Show
Suppose this is optional.
Show
Fighting with tools and poorly written code. Bureaucracy. Solving the same problem over and over.
Show
changing or misleading requirements or last minute requirements.
Show
bad IDE
Show
N/A
Show
Troubleshooting other people's poorly written/designed code
Show
Flexibility / Rapid results
Show
Brainstorming initial stages
Show
I don't I the useless complications and the non commented codes
Show
Documentation
Show
nothing
Show
Nothing
Show
writing tests and debugging
Show
Documentation (Yes, I know that is necessary)
Show
Writing Documentation
Show
Inadequate requirements capture Not having target HW or FPGA platform to develop embedded code with.
Show
When bug reports come back from the field and engineers must work hard to identify and fix the problem in very short time. That is a very stressful period.
Show
Branching and merging. 'Big-bang' integration. Requirements capture is painful, requirements sign-off is almost impossible. Mentoring and teaching others...
Show
Changing requirements
Show
testing
Show
Testing corner cases
Show
that stupid random bugs that you aren't able to replicate
Show
delving into somebodies else code
Show
time pressure
Show
I don't like sitting too many hours per day in front of a PC. I don't like headaches caused by uncontrolled software.
Show
Sometimes management does not understand the software developments process and might pressure you for unrealistic results
Show
the risk of bugs
Show
Talking about what to do for too much time.
Show
manual testing
Show
Debugging, because it oftenly takes much time
Show
?
Show
Changing requirements
Show
Bugs are usually very silly .. and done by me.
Show
make sw tests
Show
bugs
Show
Complexity
Show
if software testing has hardware dependency
Show
Technical debt getting lower priority than business requirement in regular planning. But this technical debt may result into bigger problems if ignored for long.
Show
s/w that is not documented, s/w not debuggable
Show
Sometimes I get bogged down during the design phase trying to find the perfect solution, drilling down too deep.
Show
Unnecessary complex coding and untested code
Show
Documentation
Show
Dealing with bad legacy code.
Show
Documentation
Show
Alot of folks dont really know how to design or develop code
Show
That it is so malleable---thus can change easily which then brings it's associated issues.
Show
then i wouldnt be in this training.
Show
Rutine
Show
NONE
Show
NA
Show
Be tied to very complex code (hard to understand and to reuse) because the projects are already in a mature stage and big changes are not allowed
Show
We sometimes have lacks in the requirements from the client, and sometimes the requirements that are very well specified do change several times. This is normal and we live with this.
Show
The time spent investigating bugs due bad designs
Show
I don't like running tessy for my code.
Show
Testing
Show
When you find code which is not documented, is illegible, weak, and try to fix it.
Show
Surveys.
Show
spaghetti code
Show
When an issue comes up that causes long debugging times and late hours.
Show
It can be a challenge in not perfect environments
Show
Project managers and scrum masters who seem only to want to check off their boxes, not deliver actual good software to customers. Also, I dislike when software engineers design UI's - this usually results in bad usability.
Show
Debugging with less info.
Show
Maintaining and developing over something that is built by somebody else. Need to know , visualize and assume which sometimes could be wrong.
Show
unexpected crash
Show
Finding duplication. (Though removing it can be satisfying.) Working out real requirements when there aren't any that are coherent. (Again though that can be satisfying when complete.)
Show
Testing
Show
Having to rework my implementation because someone will not sign off the code review until it has been done in they way that they would prefer, not because it would make the code any less error prone or more maintainable.
Show
sitting in front of computer the whole day, no physical activity
Show
Short deadlines meaning I don't always get time to design and write in the best way
Show
Not much really. The aspects I don't enjoy are mainly organisational and political. I don't really consider those "developing software".
Show
The way in which I am forced to do things I don't think are sensible
Show
Maintaining poorly written code without supporting test cases. Repetitive manual tasks.
Show
Effort going waste
Show
Sometimes having to maintain other people's legacy code
Show
Mainly maintenance, debugging the issues which are not easily reproducible.
Show
.
Show
.
Show
Too much sitting still.
Show
Not knowing where to start when attempting to dive into a new, large subject
Show
I am yet to find that part...
Show
Usually have to move faster than I would if I didn't have to keep a client happy
Show
Hard to comprehend bugs that make you feel like you're going insane. The boring work in between writing code.
Show
Yak shaving
Show
Frequently changed the requirements and debugging.
Show
having to maintain/fix spaghetti-code in the name of business interest
Show
There is rarely time to write good code for a product. There is too much pressure to get something out the door *now*, irrespective of whether it can be maintained or extended in the future.
Show
Not much, actually except when I have to work on some one else's code or work in an area that is uninteresting to me, e.g. GUI code or data protocol analysis (L3/L4). I'm a low-level embedded software engineer.
Show
Dealing with legacy code
Show
Lack of thought put into designs
Show
Fixing problems in other people's code.
Show
hmm mostly the delays and lags preventing me from being efficient(ide, development environment, build times, testing, boot times). I also hate compromising on code quality for meeting a deadline.
Show
the minutia of cross platform issues, steep learning curves
Show
The hours of manual test and regression testing existing code for product release.
Show
Things often do not work.
Show
Working with existing code and trying to get things to "fit" cleanly. Trying to understand poor abstractions in existing code.
Show
Getting bogged down trying to fix bugs.
Show
Layers of useless process, information duplication, shoehorning.
Show
Misunderstanding of what we do from the rest of the company, though that's getting better. And of course, the odd bug that only happens once in 10,000 occurrences.
Show
Testing, but I want to learn to love it, just like I want to learn to eat my vegetables, since it seems like it is a "healthful" way to work in the long run and I might even get to like it eventually.
Show
N/A
Show
There is no 1 proper way to do anything, everything has pros and cons to it and can make things really difficult on figuring out what is the best action.
Show
Timelines are too short to properly document the process.
Show
Code tends to become untidy or obsolete too fast.
Show
Trying to figure out what somebody else did, especially when their code is arcane, poorly written, or not done the way I would do it.
Show
Deadlines.
Show
scheduling, waterfalls.
Show
Having to do all the legacy manual testing we have.
Show
When stuck debugging complex problem
Show
Support
Show
- limitations of the languages. - some clever guys that write code that only they understand (or think so). - bad code - bad tests (that take forever to run, fail intermittently and were done to make the code to pass.
Show
Can't think of anything except for providing time estimates ;-)
Show
The reluctance to sometimes change bad processes.
Show
anything that isn't pure design, coding or analysis of existing code, for example: setting up the environment to work with for the first time, reporting progress to project managers, etc.
Show
Not enough time spent actually coding!
Show
Modifying code I don't understand
Show
Taking ages to make decision
Show
Grappling with complex test setups which often don't work reliably
Show
Repetitive tasks.
Show
Nothing
Show
Coding can be mundane at times.
Show
Having to type so much to get something done (particularly a problem for c, hence the use of perl and more recently python).
Show
When I have to go through and fix bugs in legacy code which is not well commented and documented.
Show
may not be fun
Show
Difficult question. I don't think I dislike anything about developing software
Show
Bugs due to cut and paste the code
Show
Maintaining poorly documented code where the author assumes the reader will understand the intent. Maintaining 'scruffy' code that does not conform to even the most basic of formatting and indentation rules.
Show
Unstable sw and hw development platofmrs
Show
Testing.
Show
frustration of time spent compiling, loading, debugging to achieve goals. End to end time.
Show
Time pressures
Show
Other peoples code
Show
Dunno
Show
challenge!
Show
long requirement and design cycles. Somehow it stops you to try early prototypes. Or sometime end up forcing you to write which is bound to not to work!
Show
Being interrupted and context switching to other peoples problems...
Show
Bad code layout.
Show
In some cases testing is very time consuming and debugging even more.
Show
changing requirements that mean work needs to be reworked.
Show
bugs
Show
Badly written, untested, unreadable code.
Show
Can be frustrating when things don't work. Uneasy feeling of unintentionally breaking or introducing bugs with code changes.
Show
When it is hard to understand what is happening.
Show
Not much.
Show
Everybody likes to shortcut and not do things the right way or cleanly.
Show
That we don't have a lot of strong software developers at the company and I often feel as though I'm stumbling in the dark.
Show
Discussions about details.
Show
too much arbitrary convention to learn
Show
When different ideas about how writing software collide.
Show
The are too many things to mention, but you have to take the good with the bad.
Show
When I don't feel competent frequently enough. It's self-reinforcing and I have to bust out of that spiral, usually by clearing my head enough to pick something small and easy that I can competently do. When I succeed, that's self-reinforcing too.
Show
There is so many ways to solve a single task, or worse design a system. This leads to endless discussion.
Show
Meetings. Time schedules. Maintenance. Correct answer is probably testing, but I thing testing is mostly fun. Its like baking a cake (coding) and actually taste it afterwards (testing). Ok, repetitive testing is not so fun.
Show
Poorly thought out requirements that come in verbally.
Show
Paying down another vendor's technical debt.
Show
1) Writing condensed code that may run fast but is difficult to understand. 2) Manual integration of code from different teams 3) Only manual testing
Show
slow compile times, old toolchains, crappy debug-interfaces.
Show
I don't have many technical problems. Most revolve around working with people, managing my own levels of motivation, and capturing / delivering / communicating customer needs.
Show
When management is indifferent to the welfare of their employees.
Show
Other peoples code
Show
Documentation
Show
When we give up on the design and future changes / debugging is difficult.
Show
Debugging
Show
Debugging legacy software
Show
Working with team-members that don't appreciate quality code and good practices/processes.
Show
The messes that people make (including me).
Show
Reviewing others code. Debugging linking problems. MISRA-C (MISERABLE-C) picky or arcane errors. Fixing others poor code.
Show
Blind hatred or love of 'agile/scrum' while simultaneously misunderstanding it. Monolithic schedules that change all the time. Not wanting to invest to get more efficient or use new tools.
Show
issues that aren't reliably reproducible (mainly race conditions)
Show
When I don't understand why something is not working the way I expected it to.
Show
Working with legacy code, investigating customer bugs
Show
There are frustrations in any endeavour but nothing jumps to mind.
Show
Pointless paperwork
Show
I takes a long time to figure out that I didn't actually tell the hardware to do what I wanted it to do.
Show
When I have to debug code written so poorly that I have no clue what's going on. This typically leads to too much time spent on debugging leaving the feeling nothing has been achieved.
Show
Almost the same as why I love it: There is so MUCH to learn, and so much change, that it becomes VERY tough to keep up with new techniques and tools.
Show
Assembly language
Show
see above
Show
Interruptions and distractions
Show
I don't like code that people describe as tricky or where the author wants to focus on how obscure their solution is for little or no functional gain.
Show
Configuration
Show
Nothing
Show
Where to start. Like other disciplines, the blank page is the most troublesome part.
Show
Dynamic
Show
Repetitive
Show
Testing.
Show
Figuring out why things that should work don't
Show
Things sometimes don't always behave as expected.
Show
Debugging other peoples code when they do not care to make their code easily maintainable.
Show
After 20 years in the business...still haven't gotten it right.
Show
I never seem to be given enough time to develop embedded software correctly. There is always code I would love to re-factor if I was just given a little more time.
Show
Overhead.
Show
Manual testing. Using third party API's that is either undocumented, or does not work as specified leading to countless hours of trial and error and support requests.
Show
The environment it is embedded in (or I am actually embedded in. Don't know.): Price and time pressure, unreasonable expectations and demands. Manual procedures like going through test lists, release creation, ...
Show
When a colleague / tester shows me an error and I get that "Oh no, I hadn't thought about that. This is going to be a complete nightmare to fix and I will need to have a complete rethink.
Show
Spending time generating waste. Working on legacy code (even my own!), by legacy I'm using Michael Feathers definition.
Show
Any situation where I get stuck on a problem for a long period of time and can't figure out why something doesn't work as expected
Show
With developing software, we are required to deal with new last minute requirements and come up with workarounds. This leads to last minute bugs and some timing issues, which require the system to be completely retested, even for minor updates
Show
It's up to the SW developer to prove that the problem is with the HW.
Show
hard to reduce the time spent debugging because of bugs that are not catch a head of time
Show
Going round trying to get to the bottom of the requirements
Show
too much sitting
Show
syntax errors
Show
implementation
Show
Parsing input and gui development
Show
Can be tedious
Show
stuff
Show
time spent on testing
Show
writing documentation
Show
It strains my eyes when I look at the screen for too long every day.
Show
The overhead time before a single line is written (especially relevant when you are working on a simple system that uses both microprocessor and integrated FPGA fabric)
Show
Testing
Show
It's never finished, there is always something that could be better.
Show
naming is hard, code generation sucks and is used way too much in embedded, embedded tools are in the stone ages compared to web & mobile
Show
tightly coupled codes
Show
Time taken to root cause failure. Trying to understand code that is not structured well or readable.
Show
That you have to sit at a desk all day
Show
When build systems/configurations fails.
Show
It's easy to make fatal mistakes.
Show
Doing it under timepressure
Show
Writing ugly fixes due to time constraints. Working in code that should have been refactored long ago.
Show
That our instruments (target) vary between individual to individual.
Show
When you gets an unimaginable bug.
Show
na
Show
bugs, carelessness, cost of going back to fix really simple errors that should have have existed in the first place.
Show
Time and effort taken to root cause an issue (reproducing the conditions that lead to it).
Show
I like developing and nowadays I don't get much chance
Show
complexity of tools, code.
Show
Defects that appear Friday at 5pm.
Show
-
Show
- Manual testing
Show
Thinking sw is malleable and can take-up all work-around for HW team issues
Show
--
Show
Code that is hard to understand (eg legacy code that is monolithic) Debugging issues that should have been identified early in the development lifecycle.
Show
Developing software with bigger teams is difficult.
Show
- Many times we cannot predict results especially in real time environments
Show
More bugs..
Show
Documentation.
Show
too many bugs
Show
debugging, digging through documentation to understand development software tools.
Show
??
Show
My own lack of understanding. I'm sure most of my issues are solved problems.
Show
Its frustrating when people who dont understand much about embedded systems ask for changes/features that are extremely difficult to implement.
Show
Patching,debugging
Show
debugging other developer's codes
Show
Poor Documentation...
Show
take over some bad design existing code and fix bugs
Show
Figuring out how/where to make changes, resolving merges, and integrate libraries.
Show
When the code does not perform as expected , even after I've debugged it.
Show
Tracing low-level issues.
Show
Constant interruptions. Fear to change things. The overwhelming amount of bad code out there.
Show
Portability of code between different hardware types is never seamless. Takes ages to debug.
Show
Debugging really low level errors (silicon errors and interrupts)
Show
The amount of time spent on fixing bugs.
Show
Legacy code that sucks. Difficult to find spontaneously combusting bugs.
Show
involves working on code someone else might have written and you dont necessarily agree with the design approach
Show
NA
Show
Not much chance for physical exercise.
Show
The tool and system set up
Show
It is also fun to understand how each developer is unique and the thought process is different to resolve a given issue.
Show
No two programmers are the same !!!
Show
If the issue doesn't get solved or no roo cause find. Or the code is very hard to debug
Show
Sorting out issues/glitches in test environment.
Show
When working in big teams it is difficult to maintain the quality
Show
debugging
Show
Lack of clear goals. Assumption is code change are easy
Show
No comments
Show
Time munching coz of different tools and depedencies
Show
In large projects I don't like if there are too many external libraries involved over which you have almost no control. Bugs.
Show
Many hours spent because of one stupid bug
Show
- debug, fix code from other programmers. - hard to catch bugs - difficult to reproduce. - start programming from the scratch.
Show
Potential for failure, bugs that show up once released.
Show
I do not earn enough money.
Show
/
Show
Fixing legacy code or maintenance
Show
debugging
Show
waiting for builds and test runs
Show
Nothing ever works first time. Maybe TDD can help with that :-)
Show
It can get complicated at times.
Show
Technical debt building up in code or test harnesses.
Show
see above
Show
The time pressure
Show
Nothing that I can think of, except dealing with Sales/Marketing! ;-)
Show
Nothing so far
Show
Debugging it.
Show
I don't like repetitious work unless it is a one-time thing.
Show
I don't like routine coding.
Show
constantly being forced to use someone else's crappy code
Show
na
Show
debug
Show
Time constraints
Show
Other people's code.
Show
there are two many processes when you are working in a huge project and many other works other than developing.
Show
debug
Show
when it just started
Show
Writing a piece of code never gets executed. Writing throwaway codes.
Show
many environmental issue happens and blocks development
Show
Not applicable.
Show
The stress that comes with the job
Show
repeated codes
Show
Debugging memory corruption issues
Show
Resolving external dependencies.
Show
Bugs
Show
Living with old existing poor design
Show
When code doesn't work because of some feature I do not know about
Show
Nothing
Show
Paperwork and manual tests.
Show
Having to maintain poorly written code.
Show
The associated paperwork
Show
I hate it when our customers have bad experiences with our products because products were deployed with bugs.
Show
Changing requirements, working with legacy processors, and obviously over-buggy code.
Show
I guess the final stages or maintenance...taking care of the more trivial things
Show
Bugs, and testing. In hardware, you can just change a capacitor to change that RC filter, without worrying about negative overflows and untested boundary conditions. In firmware...
Show
Debugging
Show
When the code does what you tell it to, but it isn't what you expect.
Show
Debug other people's code
Show
Requirements definition (people are always changing their minds)
Show
debugging
Show
Documentation.
Show
Spend too much time on debugging. Spend too much time on setting up test environment.
Show
supporting multiple platforms ;-)
Show
Red corporate tape.
Show
Having too many people working on the same code and maintaining different products with a lot of branches. Spends a lot of time in merges and resolving conflicts.
Show
That the requirements and priorities of the software changes quite often.
Show
Others code ;) On a serious note, I hate trying to convince the managers or the group that code review and unit tests is time well spent.
Show
documentation
Show
dealing with legacy code
Show
No particular dislikes
Show
Things that don't work
Show
documenting
Show
When the embedded C just doesn't work for no apparent reason
Show
Probably dealing with product managers and sales teams.
Show
I dont always know if the module is safe enough and is the hardware i am developing functioning properly.
Show
Becomes too routine sometimes.
Show
Going back to fix bugs.
Show
Difficult debugging, and in particular that it is literally impossible to estimate how long it takes.
Show
Working with code that is messy.
Show
when the newly created things turns out to be monsters :)
Show
restructuring and changing unorganized existing software
Show
That you're sitting inside, staring at a screen all day
Show
Writing tons of boiler plate code over and over again
Show
The paper work that is required with Medical Device software
Show
Currently: the verbosity of Java In general: writing lots of boilerplate code before doing anything productive
Show
Nothing, its beautiful ;)
Show
n/a
Show
Analysing bugs
Show
When non reproducible problems occur, which cause much troubleshooting or debugging...
Show
repeatedly manual testing.
Show
Unexpected changes (either hardware or software), just before a release.
Show
Tedious sometimes. need more automated tools. Unclear specs. I work as a lone cowboy with the rest of the company in. China. Every body should work as a team. This is an organizational issue I attempting to work on.Learn a
Show
Tedious sometimes. need more automated tools. Unclear specs. I work as a lone cowboy with the rest of the company on another continent. Every body should work as a team. This is an organizational issue I attempting to work on.
Show
ongoing changes, working with many people and we aren't aligned on how to get things done.
Show
Repetitive tasks
Show
I don't like when I get stuck with debugging or fixing bugs, especially intermittent bugs!
Show
Flaws in human interactions that are involved in code, such as incomplete/lack of requirements because people are too lazy to spend time preparing a document or to review them, etc.
Show
NA
Show
Debugging and refactoring legacy code.
Show
The repetitive testing
Show
It's hard.
Show
Process overhead. we have few processes that we have to go through to submit the code. there are lot of overheads which i dont like in software development
Show
debugging.
Show
Weird bugs in the code that are very hard to track down sometimes.
Show
Being stuck with other people's crappy design choices.
Show
Complexity can quickly spiral out of control. Hyper-nonlinear, tiny code changes can have massive impacts to the behavior of the code.
Show
Fighting against bureaucracy.
Show
Restrictions placed on dev environment by IT
Show
Not being able to crack the problem at hand and move forward. I detest being stuck, while developing software.
Show
searching for bugs, rewriting SW
Show
Tedious Syntax
Show
Annoying bugs
Show
The short time schedules and ambiguous requirements.
Show
Often a difference between how I would like things to be done and reality. Planning accurately is very difficult!
Show
Stress
Show
Manually perform regression tests
Show
Bugs
Show
Difficult debugging
Show
Nothing
Show
Sometimes it does not work as I have planned.
Show
Having to write things in a rush, taking shortcuts
Show
When tools are not appropriate for the job at hand and thus frustrating to use.
Show
To solve the same problem again and again.
Show
being stuck
Show
.
Show
C++ programmers (or more precisely those who taught them to create the bad code they write)
Show
Fluid requirements.
Show
when I know how to solve a problem but am not allowed to or not given the tools to do so; when too much is done manually that should be automated
Show
Having to work with bad code
Show
Having to deal with nuances of languages, environments, configurations, etc.
Show
bickering
Show
Lack of variety
Show
Boilerplate code
Show
if not fit in above.
Show
Not understanding certain things.
Show
Moving targets.
Show
Maintaining old, undocumented, critical code.
Show
Not understanding why a fix to the code made it work.
Show
I don't enjoy when things become overly complex and when debugging becomes the main task.
Show
From the product side of things, it's the same ole story, I can't have it created for me fast enough :)
Show
N/A
Show
I'm a little tired of embedded. Specifically, I'm a little tired of cross compiling everything and the resource constraints.
Show
Legacy FW, covering a multitude or projects, so must always keep doing things the same way to avoid breaking targets that we can't test locally.
Show
Unclear documentation
Show
1. constantly changing priorities and requirements. 2. Interruptions 3. Big
Show
Difficult development environments.
Show
Nothing really.
Show
When tools are flaky or slow.
Show
Going to meetings and arguing about what the code should do. Making changes to products from 1 or 2 years ago (especially adding new features to old products, which is worse than fixing bugs in old products)
Show
Deadlines, inevitable scope-creep
Show
Can be mundane
Show
Code tends to get complicated over time.
Show
Mature, ugly code that everyone is afraid to refactor
Show
Large organizations spend a lot more time communicating than doing things. I don't enjoy the communication so as much.
Show
Anything that is not productive and slows me down.
Show
time to debug and testing is more than actual coding because of legacy code.
Show
having to learn some one else's complex code
Show
Can't think of anything now.
Show
Setting up development environments, especially getting all the dependencies working.
Show
Getting stuck because of a stupid bug.
Show
the business aspect
Show
Incomplete or inconsistent user manuals for hardware
Show
Sometimes it can be very frustrating/stressful/tedious. It's hard sitting in front of a computer for so long!
Show
Defects
Show
Figuring out the right dev environment
Show
Documentation
Show
Can be tedioius
Show
Deadlines!
Show
Sometimes boring/stressed
Show
debugging other developer's code
Show
Sometimes solutions are obscure and feedback can be few and far between with small to nonexistent positive reinforcement. In short, it can be very tedious sometimes if you work on stuff for a long time with little positive progress
Show
Resolving inter-team communication issues.
Show
old crappy code
Show
n/a
Show
Trying to reproduce a bug and not being able to
Show
physically sitting around most of the time and reading through very old code.
Show
When requirements are amorphous.
Show
I don't like working on poorly designed and written codebases.
Show
I don't like interpreting code without comments or unhelpfully named variables. I don't like writing tests.
Show
Dealing with code that comes from previous "questionable" decisions and design (or lack thereof).
Show
Dealing with code that is as old as me
Show
Poor development environments (long build times, poor debugging tools, etc.)
Show
all the initial setup to get to point where you start writing code.
Show
Looking at undocumented code I didn't write and trying to understand how it works.
Show
When the problem is too easy.
Show
-
Show
Head-ache debugging. Someone else "messing" up my particularly neat code.
Show
Watching the user get frustrated.
Show
Not sure. I like developing software.
Show
debugging
Show
Running into issues beyond my knowledge or having harsh deadlines.
Show
Testing
Show
Atthis company, I don't like customizing a code base I know nothing about, and have no knowledgeable resources to bounce idea's off of. We don't know the overall design/ application of design patterns, ect...
Show
Poorly written code. I see too much of it. Clean code makes everyone's life much easier.
Show
When political obstacles get in the way.
Show
Debugging bugs
Show
tedious
Show
Having bugs on the field.
Show
Being bothered
Show
hard to debug intermittent errors keeping you up at night.
Show
Digitally Signing Drivers for Windows
Show
The only thing worse then programming is not to program.
Show
Beeing slowed down by crappy tools.
Show
Bad tools
Show
Dealing with legacy code that wasn't written well.
Show
Don't get to be out in the sunshine
Show
Over-reacking processes and software that has little structure.
Show
Long Build Time, not having coding standards. People that think they know it all...
Show
?
Show
When same code fails multiple times on multiple paths
Show
Not enough time spent on it.
Show
working with developers who don't collaborate/communicate, don't test their code; working with developers who care more about code than about the impact of that code on the product they're developing code for
Show
Sitting at a desk for extended periods of time.
Show
some aspects of agile
Show
nothing
Show
Difficulty in getting good specs & reqs.Management & schedules. Reteaching that software is not always that simple. Documentation. Proving that it's not always software - sometimes electrical issues/hardware.
Show
nothing
Show
Process overhead
Show
The agile process and company process sometimes get in the way of being able to do productive work, like fixing bugs, and replace it with tedious work like typing up SCRs, PBIs, etc.
Show
excess documentation
Show
That there seems to be a never ending wave of new technologies that do the same thing just a little little differently, but offer little value over prior art.
Show
configuration and administrative type problems, for example not having rights, having to figure out the exact version of some 3rd party software to use
Show
I don't like when it takes forever to test something I don't like long build times Fixing bugs that should have already been fixed.
Show
It can be frustrating.
Show
I do not always enjoy acquiring requirements and editing code based on changed requirements.
Show
dealing with third party software problems
Show
IDE's and low level setup of the registers.
Show
Trying to give estimates for how long something will take.
Show
explaining computational complexity, tell-don't-ask, and other software paradigms to non-software folks. Also the limitations of cross-compiling are annoying.
Show
Regression testing.
Show
Coming up with and documenting test plans isn't much fun. I also become extremely grumpy when all the other groups make unscheduled, undocumented and unannounced changes to my test machine when I'm trying to qualify brand new code functionality.
Show
Schedules that don't allow for things to be done right! Politics.
Show
Dependency on hardware.
Show
it is my job
Show
Too much to learn Easy to get lost in the details
Show
The "invisibility" of software which is less recognized by people outside of the embedded community. Also, in embedded software (which requires a target hardware for testing), it is difficult to run automated tests for TDD purposes.
Show
Searching for the cause of bugs.
Show
Exhaustive testing is time consuming
Show
Asking estimates, hearing about bugs from customers
Show
see it not working by someone else
Show
Having to debug/edit someone else's code which doesn't follow any standard or is of poor quality.
Show
Debugging the tools
Show
Good question, maybe too many formalism
Show
unstable or limited tools
Show
I don't like having to work with third-party code because it usually means that any issue found will take ages to be fixed. It's also always harder to debug because it has no consistency with the company code.
Show
.
Show
Some time it is hard to finish something to the perfect outcome.
Show
When the requirements change after a significant part of the design or implementation is complete.
Show
---
Show
- Ecounter many mistakes after compiling the code. In particular, ecounter mistakes, that require a significant amount of time to debug.
Show
Read the code written without care.
Show
Producing documentation to check off that it was produced. Much of what external standards and the FDA require us to produce, if done correctly, will help us write better, more maintainable, software. This is rarely done well or valued.
Show
Struggling to figure out what a method does. Worrying about the unknown rationale for why a method was implemented, and concerned that I might break that.
Show
There's not much I don't like about developing SW. Probably the amount of time spent on DV testing and documentation.
Show
Having to load the code on the machine to test it, we don't have a simulator.
Show
Separate reporting structures are used hide behind scheduling and system issues.
Show
Only having VectorCast to do unit test (which means I don't do unit test). UGH!
Show
---
Show
Remaking systems do new things because someone didn't tell me the correct requirements up front
Show
People forcing unit testing on me
Show
Pressure to get things working quickly
Show
I do not enjoy using code which I do not fully understand.
Show
The bugs, all the bugs.
Show
Can be frustrating to implement new tools that are suppose to help the coder develop efficient code.
Show
It seems that sometimes things are deliberately difficult when it seems possible to be done in a simpler way.
Show
Trying to understand or debug someone else's labyrinthine code, then not being allowed to rewrite it.
Show
When it doesn't work
Show
Fighting my tools, non-standard and confusing environments, poorly architected legacy systems that are a pain to extend or debug without massive amounts of overhaul, occasionally having to write software documentation in Microsoft Word.
Show
Sometimes it can be tedious or repetitive.
Show
I hate fighting tools. Fixing something in one tool shouldn't lead to a break with another, but sometimes it does.
Show
Manual Testing and writing unit tests for classes/methods that are not written with unit testing in mind.
Show
creating large amounts of documentation beyond the code itself
Show
Documentation for safety critical software can be time consuming.
Show
Not always knowing how best to solve a problem with the most clean and direct code.
Show
Fighting with the tools
Show
Having to use Stack Overflow and dealing with arrogant, pompous, opinionated individuals; many of whom do not fully answer the question and do not exhibit patience towards those learning.
Show
Sitting inside all day has some serious disadvantages.
Show
Maintaining legacy code.
Show
Having to deal with pathologically bad products that I cannot change.
Show
debugging
Show
- Gnarly toolchains & infrastructure - Other peoples' commits breaking my code
Show
Trying to remember specific syntax when switching between many languages, trying to remember all the various libraries available to use.
Show
Test code generation is not automatic. Testing is only as good as one intended. How to test code in an unexpected way?
Show
The delays of a slow build/startup/test cycle, how long it takes for code to get reviewed.
Show
Time lost to slow builds and ineffective processses
Show
Waiting for a build to finish. Taking ownership of legacy code with no tests. Wasting time debugging. Developing the wrong thing.
Show
Sunk cost fallacies
Show
Documentation! and maintaining code that is a mess and untested.
Show
It's very hard to prove that you're doing exactly what you say you're doing. Doing so is time consuming. Legacy code.
Show
Chasing erratic bugs that consume large amounts of time to reproduce.
Show
Accurate requirements gathering from our typical clients (small company, mechanical engineering types) has been incredibly painful, historically. Managing dependencies is also never fun.
Show
The overwhelming amount of communication and process involved as team size grows
Show
There are too many tools available and not much good information. Good non-beginners content is hard to find.
Show
(Head) Managers how don't know what's the problems of hardware, software, software development,and that we are humans. Those, who don't want to know that it will take time to develop/make good products but will save money afterwards
Show
Hard to get third party stuff to work. Configuration problems. Figuring out legacy code.
Show
Poor quality everywhere, and seeming lack of concern over it. Teams complain they "don't have time" to do it any better. Teams responding to my suggested improvements with "we know we should be doing that", yet they never adjust.
Show
Solving un-challenging, yet tedious problems.
Show
Just how bad we are as an industry at developing software. Seeing Complex, organic, unmaintainable code get written, and not having the ammunition to fight it.
Show
2
Show
Failure to anticipate a use case that requires a significant redesign. Ideally sw is flexible enough, but sometimes difficult to anticipate the ways in which the sw will need to be flexible
Show
Reading badly written, badly designed or uncommented code. In a professional environment, code should be written so it is clear the programmer cared about what was being done.
Show
Every well-written software eventually "Peter principles" itself -- because it works, people keep adding to it until it becomes badly-written software.
Show
Broken code
Show
Setting up the development environment.
Show
Debugging
Show
Continuously retesting for regressions (i.e. prior bugs that come back out.)
Show
Being stuck with hard to understand legacy code bases.
Show
Testing and writing test plans.
Show
Changing requirements
Show
Testing
Show
Uncertainty if I'm breaking things while debugging/developing new features.
Show
The administration afterwards.
Show
Of course when it fails to perform what it suppose to do.. :)..
Show
Depending on third party software/firmware (compiler libraries, CubeMX from STM, Harmony from Microchip, etc.)...
Show
-
Show
Repeating work
Show
the power of software provides an ease to expand your code with many paths and layers of functionality on top of each other. Keeping the overview and understanding how to improve your code becomes more complex. Supporting tools are not easy to find
Show
Nothing.
Show
tbd, I probably like documentation the least,
Show
Reading other people's messy and undocumented code
Show
Bad variable naming, lon comments within the code. The code naming and short functions should tell much about the code with minimum comments
Show
Unexplained failures
Show
Sometimes is difficult to estimate the tasks and activities, specially when dealing with debugging. This can translate into frustration and extra time.
Show
Can be exasperating
Show
Deadlines, estimates, Agile. Poorly documented code, processes, tools, tests. Buggy tools that slow development. Lacking tools / debug features that would ease debug/test of code. Overbearing static analysis rules. Code coverage for its own sake.
Show
- Undocumented and poorly commented legacy code - Tools that don't work as supposed to out of the box - poorly named anything (files/folders/variables/tools) - Powershell (AKA PowerSh**t)
Show
- Undocumented and poorly commented legacy code - Tools that don't work as supposed to out of the box - poorly named anything (files/folders/variables/tools) - Powershell (AKA PowerSh**t)
Show
fighting the tools
Show
Lack of clearly defined requirements.
Show
Sometimes it may be difficult to get information on parts of code outside of your project. (Blockers rather), In addition, sometimes the build system generates erroneous warnings/errors.
Show
It can get a bit frustrating when it takes a long time in finding the root cause of a problem.
Show
It's easy to miss out on the bigger picture of the project when looking to much into the detail.
Show
Not enough time - no time to experiment, innovate. Not enough inclusion in the path forward.
Show
debugging
Show
Spending hours looking for a problem in the wrong place because my initial assumptions about what to look for were wrong.
Show
Determining what a customer really needs vs what they think they want. Arguing with management about priorities, especially around tooling, refactoring etc.
Show
Intentionally left blank.
Show
The dauntingness that I sometimes feel around trying to wedge something in to legacy code.
Show
Painting yourself into a corner w/bad design decisions.
Show
Software can be used to multiply the stupidity of the human brain.
Show
overhead.
Show
Documentation Some documentation provides value for developers (both now, and in future) but other documentation exists only to meet a process checkbox
Show
Stuff
Show
Documentation, mindless writing of functions based on requirements without visibility of its end-user purpose or opportunity for creative input
Show
testing.
Show
n/a
Show
Having to work with poorly documented APIs and tools.
Show
The process.
Show
The most difficult part of developing software is that we are not usually allocated enough time to develop it.
Show
creative activity
Show
Unreasonable schedules.
Show
The ever changing landscape, very difficult to keep up.
Show
Bureaucratic bean-counters who apply metrics without understanding.
Show
How easy it is to get something wrong. Difficult to re-use code
Show
Bureaucracy. People who don't know what they're doing messing things up for the rest of us. Can be a grindstone sometimes
Show
Waiting for ... build, test, reviews, approval to ship
Show
Frustrating bugs that take a long time to track down.
Show
Nothing comes to mind.
Show
Finding out that my solution isn't what the user needs/wants, fighting with development tools, repetitive boilerplate tasks.
Show
Unclear requirements. Legacy spaghetti code (followed by un-peeling the onion).
Show
none
Show
I don't like how long it takes to push code into the repo, depends on reviews
Show
The changing of names
Show
Design complex, overlap...
Show
Debugging
Show
Testing
Show
Sometimes I feel that we have to spend a lot of time to dev features which actually is not helpful
Show
Doing firmware development mostly in C, sometimes it takes more code than other languages to do the same thing.
Show
Sometimes it affected to my life
Show
When the system is too complicated then bug is easily happen and hard to find
Show
Not sure.
Show
Debug and fix issue of another developer.
Show
Nope.
Show
Software Bug.
Show
complecate
Show
nothing
Show
The endless number of ways you can build something.
Show
Battling rapidly changing stacks when supporting a long term product.
Show
Reinventing the wheel.
Show
Working on poorly documented/commented software written by someone no longer at the company.
Show
I do occasionally get frustrated with poorly documented and unreliable code.
Show
trying to decide requirements up front
Show
N/A
Show
na
Show
Chasing bugs that can't be reproduced. Fixing a bug only to discover that I've broken something else that seemed entirely unrelated.
Show
Too many opinions on how code should look, what functions/variables should be called and the 'proper' formatting.
Show
Generally people outside of development group (management?) underestimate how much it takes to develop software.
Show
fighting tool chain issues
Show
Cutting corners to "save time" to meet an arbitrary schedule.
Show
A reasearch & development is a long and tedious process in which a very high value is sometimes assigned to a a very small goal which after achieving turns out to be very small thing in the whole picture.
Show
getting test harnesses made
Show
can be monotonous
Show
Would like more exercise.
Show
Debugging
Show
Bug fixing. Bug fixing. Bug fixing. .... Oh, and bug fixing.
Show
Many teams are disorganized and mismanaged, with the developers working in radically different ways.
Show
Flexibility is a double edged sword. It is easy to do quick modifications to make a software design do something it was not intended to, introducing unintended consequences.
Show
The parts of development that are not programming - Managing releases - Sprint planning - Parsing external requirements
Show
It often takes longer than you think it should
Show
Unclear requirements. Focus on (narrow) features rather than quality/efficiency/ maintainability of code, working to deadlines.
Show
software Bugs :) Unclear requirements, changing priorities
Show
When the framework becomes unorganised
Show
-
Show
The testing part gets tedious - but then it is essential!
Show
Moving target requirements.
Show
often, we work with legacy code, adding functionality, then in many cases, developing boils down to "what to copy, where to paste". then you're not really making stuff.
Show
Long feedback loops. Problems debugging.
Show
Dependency frustration and being blocked by other teams.
Show
Bad tools or processes slowing down the development.
Show
nothing
Show
Complicated code files when it could have been much simpler and maintainable.
Show
extended documentations
Show
Fighting bad tools forced to use.
Show
It is stressfull. Bugs reach our customers. I often get caught up in doing deliveries and repetative tasks.
Show
Testbed Setups and finding and gathering the materials for the setup.
Show
Poor tools that make solving the problem harder.
Show
Debugging stuff.
Show
I don't like reading code that is convoluted or uses too many abbreviations
Show
All the things around developing software. The un-seriousness from the sector that things go so fast and its so easy. I come to know that this is an engineering skill like any other discipline.
Show
watching people sling code and then let someone else test and debug for them, or debug once everything is integrated
Show
The tight deadlines with a focus on just getting things done rather than getting them done the right way to produce high quality software.
Show
Debugging tools to find for on target problems don’t have user friendly interfaces.
Show
That one bug that happens once in a blue moon but then there's nothing better than solving it which I like.
Show
Not much.
Show
Commenting
Show
The tools (especially for embedded).
Show
Testing!
Show
Top down orders that are bad technical decisions.
Show
making issues
Show
I hate slow reactions.
Show
.
Show
Complicated Components Redundant code Mixed code between abstract and concrete Hard to read
Show
-
Show
Can not find solution and Requirements
Show
Writing what I did. Scheduling development. Estimating schedule.
Show
Testing time was boaring a little. But I know it's really important.
Show
I should make all things perfect in limited time with few chances. I should maintain and implement another one's codes and designs.
Show
Testing
Show
..
Show
writing lots of document
Show
I don't like debugging to find my bug
Show
Finding bugs late in a project and all what comes with it
Show
The cycles of hype for the next big thing
Show
The difficulty in debugging for certain cases.
Show
It can be a obnoxious to determine the cause of a bug.
Show
Debugging other people's uniquely written code
Show
It's desk work
Show
So many different ways to solve a problem, so many tools to use, and so many languages that can be implemented. I often find I lose focus out of curiousity and a desire to learn everything at once which can be VERY time consuming.
Show
Organization of large projects, modifying or fixing code written by others
Show
Don't do it much anymore.
Show
Looking at other peoples code with less experience.
Show
Maintenance (which seems to be forgotten about by management).
Show
Its a love/hate with the frustration that can come with embedded system development. The frustration is annoying and tedious, but once I overcome something the dopamine hit is incredible.
Show
New shiny languages/frameworks.
Show
Not shipping to users.
Show
Layers and layers of abstraction... I know it's a necessary evil but it makes finding problems hard. TDD should help with this too since you should be able to "trust" the underlying layers.
Show
The worst thing is searching bugs for hours or days - just to find out that the fix takes one minute.
Show
The managerial aspects suck. Also many-a-times organizational processes are inefficient.
Show
Bug
Show
change in requirements impacts working functionality
Show
design of system, class diagram, documentation
Show
I don't like debugging of the software.
Show
Performing lot of documentation with development.
Show
Testing efforts takes more time to check quality of code.
Show
Stringent Timeline
Show
Writing unit tests after the fact. Double-checking, I would prefer to work on new things.
Show
Nothing special, compared to developing hardware.
Show
Dealing with tooling issues or other problems not directly related to the development process
Show
debugging hard-to-reach code
Show
Some products/programming areas are boring--I'd be bored programming marketing websites for a living, for example. But honestly, I haven't been professionally programming that long, so new and fresh is good compared to the old career so far.
Show
Debugging
Show
Dealing with code which is lacking documentation, is unmaintained, and has no tests.
Show
Cryptic bugs that are hidden and hard to observe and root cause.
Show
Testing complex interactions, fixing bugs written by other people. Code and workflows that break because they don't have tests.
Show
Making suggestions to other developers who have more experience than I do (for example in PRs).
Show
Conflicting priorities, poor code.
Show
the fact that if not written well, it can be broken easily
Show
takes too long
Show
There is nothing much to not like.
Show
* Tracing through other people's code to figure out what it does and why they did it that way * Errors that are difficult to debug, difficult to reproduce, and seemingly unrelated to anything I did
Show
Buggy API's
Show
Industry growing too fast to track everything
Show
Spending what feels like way too much time debugging when something isn't working properly
Show
Sudden slam at the end for testing. Being accountable for code not directly written by you.
Show
Too much emphasis on inconsequential things.
Show

Make this into a word cloud

Select text below (triple click), copy, then try one of these tag cloud generators
jasondavies word cloud generator - colorful
tagcrowd - lets you show counts