What's your least favorite part of coding?
-
Sorry I have to somewhat contradict you, but I don't think your question has a proper answer between professionals. My view is that we do the work, and the whole work or we get out of this profession or we call ourselves hobbyists. What would you say of a surgeon who says "I enjoy cutting, but stitching not so much"? The oft repeated lament "I hate documenting/commenting" is driving me nuts: what good is your work if you cannot explain to someone how to use it or if you explain it badly? Saying that you don't want to cover with tests all significant cases is like someone performing a CAT scan and stopping in the middle: probably the other half is also OK. Speaking for myself, I like my profession and try to do it the best I can. I strive to document my code (although English is not my mother tongue), write unit tests and, in general, do all the drudgery tasks associated with programming. The fun is doing the whole lot.
Mircea
I wasn't necessarily speaking professionally. In fact, in my OP, that code is something I developed on my time.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
Documentation, as I am no good at writing clear instructions. Testing comes a close second, as I get bored after a few iterations.
-
The fun part of IoT and embedded is a lot of times you're working very close to the metal, and you can't rely on things like an operating system and graphics drivers - you have to write them yourself (or find code that's already written in some cases). I have a graphics library I wrote which I've been using for about 2 years both professionally and as a hobby. I've extended it in that time to support Unicode, TrueType, SVG, PNG and JPG. I liked writing all that code. I hated documenting it[^]. I'm working on documentation for my user interface library that builds on top of it right now and it's a slog. Testing it is at least as bad. I can't decide which I hate most. Probably testing, considering I enjoy writing at least. I've got some unit tests for my major library, but I haven't written it to cover the absolutely vast surface area of my test matrix. Design is typically fun for me, but I feel like every third time I think I'm clever it bites me. Lately the above user interface library has been kicking me in the teeth, requiring me to make breaking changes over several iterations of the code. I'm not thrilled about it, but it's better than testing.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
Why it just happened yesterday... :laugh: I spent 5 hours trying to fix a 'bug' where setting a chart series point to IsEmpty was not reversible and led to completely bizarre results. (works the first time, not the second) Found that IsEmpty for that object was the same as Double.NaN. Try using that and .NET complains that it can't handle NaN! :confused: (again, works the first time, not the second) This morning, try it again and it works perfectly! :wtf: I love/hate it when problems just fix themselves! :laugh: Hmmm...the only difference was VS2019 yesterday vs. VS2017 today??? :confused: Edit: It still doesn't work! I just didn't test correctly! More research indicates that it's a known issue albeit an apparently rare one. At least they provided a workaround...only it doesn't seem to work either. (clearing the points and adding dynamically) Back to the drawing board! :sigh: Really though, my least favorite part has got to be communicating with colleagues. It's all too normal anymore for me to be stuck on a 1-2 hour phone call when I'd rather be fixing things! :sigh: Also, there's communicating with family during working hours, which also happens way too often these days. :sigh: It's hard to be antisocial when every 10 minutes there's a phone call, text message, notification, email, etc. though I still try! :laugh:
"Go forth into the source" - Neal Morse "Hope is contagious"
-
Diagnosing customer issues when the bug report is of the following order: "It's broke."
Software Zen:
delete this; -
The fun part of IoT and embedded is a lot of times you're working very close to the metal, and you can't rely on things like an operating system and graphics drivers - you have to write them yourself (or find code that's already written in some cases). I have a graphics library I wrote which I've been using for about 2 years both professionally and as a hobby. I've extended it in that time to support Unicode, TrueType, SVG, PNG and JPG. I liked writing all that code. I hated documenting it[^]. I'm working on documentation for my user interface library that builds on top of it right now and it's a slog. Testing it is at least as bad. I can't decide which I hate most. Probably testing, considering I enjoy writing at least. I've got some unit tests for my major library, but I haven't written it to cover the absolutely vast surface area of my test matrix. Design is typically fun for me, but I feel like every third time I think I'm clever it bites me. Lately the above user interface library has been kicking me in the teeth, requiring me to make breaking changes over several iterations of the code. I'm not thrilled about it, but it's better than testing.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
Anything with dependencies you can't resolve yourself. Trying to communicate with a peace of hardware and asking for documentation on how to connect to a standard protocol: "we will get that to you next week". WTF. That thing cost 1 million euro, and we have a good handful of those. Besides that, CI/CD pipeline. Is as such simple enough, but always end up tedious and eating a bunch of time.
-
The fun part of IoT and embedded is a lot of times you're working very close to the metal, and you can't rely on things like an operating system and graphics drivers - you have to write them yourself (or find code that's already written in some cases). I have a graphics library I wrote which I've been using for about 2 years both professionally and as a hobby. I've extended it in that time to support Unicode, TrueType, SVG, PNG and JPG. I liked writing all that code. I hated documenting it[^]. I'm working on documentation for my user interface library that builds on top of it right now and it's a slog. Testing it is at least as bad. I can't decide which I hate most. Probably testing, considering I enjoy writing at least. I've got some unit tests for my major library, but I haven't written it to cover the absolutely vast surface area of my test matrix. Design is typically fun for me, but I feel like every third time I think I'm clever it bites me. Lately the above user interface library has been kicking me in the teeth, requiring me to make breaking changes over several iterations of the code. I'm not thrilled about it, but it's better than testing.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
If the "user" won't help with testing, I start losing enthusiasm fast. That said, I have lots of "eyes" into my software's internals.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
The fun part of IoT and embedded is a lot of times you're working very close to the metal, and you can't rely on things like an operating system and graphics drivers - you have to write them yourself (or find code that's already written in some cases). I have a graphics library I wrote which I've been using for about 2 years both professionally and as a hobby. I've extended it in that time to support Unicode, TrueType, SVG, PNG and JPG. I liked writing all that code. I hated documenting it[^]. I'm working on documentation for my user interface library that builds on top of it right now and it's a slog. Testing it is at least as bad. I can't decide which I hate most. Probably testing, considering I enjoy writing at least. I've got some unit tests for my major library, but I haven't written it to cover the absolutely vast surface area of my test matrix. Design is typically fun for me, but I feel like every third time I think I'm clever it bites me. Lately the above user interface library has been kicking me in the teeth, requiring me to make breaking changes over several iterations of the code. I'm not thrilled about it, but it's better than testing.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
Quote:
What's your least favorite part of coding?
Coding. Yeah, I'm burnt out at the moment; have been for 6 months or so. Ugh. Extensive overuse of tight deadlines usually causes this for me.
-
Quote:
What's your least favorite part of coding?
Coding. Yeah, I'm burnt out at the moment; have been for 6 months or so. Ugh. Extensive overuse of tight deadlines usually causes this for me.
I hear that. I got burnt out due to lack of challenge and lack of creativity, coupled with long hours. I can handle eating and breathing code but not always on another person's agenda, and not if it's the same stuff over and over again. How many different ways can you design an e-commerce app? It makes it somehow worse when other people are actually excited about it. I left the field for years. I got scouted off codeproject actually. That's what dragged me back in. I'm enjoying IoT and embedded because it reminds me of the same type of problems I faced coding in the 1980s and early '90s. The idea is to get little things to do big things, and solve problems on a limited medium. It brings the challenge and creativity back for me, like getting TrueType running on a system with 192kB of RAM or less.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
Definitely documentation, I'm terrible at it!
I don't think before I open my mouth, I like to be as surprised a everyone else. PartsBin an Electronics Part Organizer - Release Version 1.1.0 JaxCoder.com Latest Article: SimpleWizardUpdate
I hate documenting my code, but I enjoy writing technical articles. I've tried using codeproject articles to document my code, but in the end I found they were at best supplementary. Now I've taken to using markdown and generating a wiki web from it using Gatsby. Markdown is at least easy to format, and I can do it all in VS Code, putting the markdown in a /docs folder under the project. I even have a server script that repulls my doc updates from git and pushes them to the web. Markdown, once you know it - and if you use a preview extension with it, is a nice way to document. It's now used all over the place, including Github, and it's also easy to read even if you don't have a markdown display app. I know it isn't the silver bullet you and I are hoping for, but I like it a lot better than trying to fill in the blanks with something like doxygen.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
If the "user" won't help with testing, I start losing enthusiasm fast. That said, I have lots of "eyes" into my software's internals.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Yeah. I have two people I know are using my graphics library seriously, one guy who is using it has been an invaluable resource, not only uncovering bugs, but tracking down where they are in my code and even suggesting fixes. I offered a collaborative role on the project with him, that's how much he impressed me, but he's of course otherwise occupied. Still, I'm glad to have him using my stuff!
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
Anything with dependencies you can't resolve yourself. Trying to communicate with a peace of hardware and asking for documentation on how to connect to a standard protocol: "we will get that to you next week". WTF. That thing cost 1 million euro, and we have a good handful of those. Besides that, CI/CD pipeline. Is as such simple enough, but always end up tedious and eating a bunch of time.
Sometimes I like that challenge. Other times it can be frustrating.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
Writing documentation and troubleshooting very intermittent problems, in web apps.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave KreskowiakDave Kreskowiak wrote:
troubleshooting very intermittent problems, in web apps.
That is like everything about my nightmares 1. Troubleshooting 2. Intermittent problems 3. Web applications My horror trifecta :laugh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
I hate documenting my code, but I enjoy writing technical articles. I've tried using codeproject articles to document my code, but in the end I found they were at best supplementary. Now I've taken to using markdown and generating a wiki web from it using Gatsby. Markdown is at least easy to format, and I can do it all in VS Code, putting the markdown in a /docs folder under the project. I even have a server script that repulls my doc updates from git and pushes them to the web. Markdown, once you know it - and if you use a preview extension with it, is a nice way to document. It's now used all over the place, including Github, and it's also easy to read even if you don't have a markdown display app. I know it isn't the silver bullet you and I are hoping for, but I like it a lot better than trying to fill in the blanks with something like doxygen.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
I just started using VS2022 for a serious project and I was amazed when I went to add my source to git, it automagically pushed my code to github and set up the ?site?. So I broke down and learned enough markdown to create a readme page and it wasn't to bad. Technology is progressing but not to the stage where I can tell the IDE what I want and it produce it, document it and push it to github and recommend a good place to eat. Is that really too much to ask? :)
I don't think before I open my mouth, I like to be as surprised a everyone else. PartsBin an Electronics Part Organizer - Release Version 1.1.0 JaxCoder.com Latest Article: SimpleWizardUpdate
-
Actually I like these issues and solve them then with ETW Tracing (most of the time). E.g. AV Scanners can cause funny issues which can make software fail in interesting ways. [^]
-
The fun part of IoT and embedded is a lot of times you're working very close to the metal, and you can't rely on things like an operating system and graphics drivers - you have to write them yourself (or find code that's already written in some cases). I have a graphics library I wrote which I've been using for about 2 years both professionally and as a hobby. I've extended it in that time to support Unicode, TrueType, SVG, PNG and JPG. I liked writing all that code. I hated documenting it[^]. I'm working on documentation for my user interface library that builds on top of it right now and it's a slog. Testing it is at least as bad. I can't decide which I hate most. Probably testing, considering I enjoy writing at least. I've got some unit tests for my major library, but I haven't written it to cover the absolutely vast surface area of my test matrix. Design is typically fun for me, but I feel like every third time I think I'm clever it bites me. Lately the above user interface library has been kicking me in the teeth, requiring me to make breaking changes over several iterations of the code. I'm not thrilled about it, but it's better than testing.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
The bit where you write beautiful, elegant code that solves are well-defined, common problem in an easy way with seamless integration and your users take one look at it and point at the huge flaw you didn't see.
cheers Chris Maunder
-
The bit where you write beautiful, elegant code that solves are well-defined, common problem in an easy way with seamless integration and your users take one look at it and point at the huge flaw you didn't see.
cheers Chris Maunder
Blasphemy! Such users are non-existent. Russion bots! And they LIE!!!!
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
I just started using VS2022 for a serious project and I was amazed when I went to add my source to git, it automagically pushed my code to github and set up the ?site?. So I broke down and learned enough markdown to create a readme page and it wasn't to bad. Technology is progressing but not to the stage where I can tell the IDE what I want and it produce it, document it and push it to github and recommend a good place to eat. Is that really too much to ask? :)
I don't think before I open my mouth, I like to be as surprised a everyone else. PartsBin an Electronics Part Organizer - Release Version 1.1.0 JaxCoder.com Latest Article: SimpleWizardUpdate
I'm still waiting for the flying car the science fiction authors promised us. Or wait, I'm too young for that. It looks like we're getting that cyberpunk dystopia they mentioned instead. :~
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
Sorry I have to somewhat contradict you, but I don't think your question has a proper answer between professionals. My view is that we do the work, and the whole work or we get out of this profession or we call ourselves hobbyists. What would you say of a surgeon who says "I enjoy cutting, but stitching not so much"? The oft repeated lament "I hate documenting/commenting" is driving me nuts: what good is your work if you cannot explain to someone how to use it or if you explain it badly? Saying that you don't want to cover with tests all significant cases is like someone performing a CAT scan and stopping in the middle: probably the other half is also OK. Speaking for myself, I like my profession and try to do it the best I can. I strive to document my code (although English is not my mother tongue), write unit tests and, in general, do all the drudgery tasks associated with programming. The fun is doing the whole lot.
Mircea
In an ideal world, I should get a specification which fully documents what something is needed to do. I write it and send it back having tested as far as I can, then the business does extensive tests and the bugs get corrected before it gets released. So we should only need to code and test to the requirements and then the specification is the documentation. As I said, "In an ideal world, ...". :)
-
The fun part of IoT and embedded is a lot of times you're working very close to the metal, and you can't rely on things like an operating system and graphics drivers - you have to write them yourself (or find code that's already written in some cases). I have a graphics library I wrote which I've been using for about 2 years both professionally and as a hobby. I've extended it in that time to support Unicode, TrueType, SVG, PNG and JPG. I liked writing all that code. I hated documenting it[^]. I'm working on documentation for my user interface library that builds on top of it right now and it's a slog. Testing it is at least as bad. I can't decide which I hate most. Probably testing, considering I enjoy writing at least. I've got some unit tests for my major library, but I haven't written it to cover the absolutely vast surface area of my test matrix. Design is typically fun for me, but I feel like every third time I think I'm clever it bites me. Lately the above user interface library has been kicking me in the teeth, requiring me to make breaking changes over several iterations of the code. I'm not thrilled about it, but it's better than testing.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
Having to track down and fix a poorly reported bug in code written years ago by someone who's long since moved on and who coded using unusual patterns for no obvious benefit.
-
In an ideal world, I should get a specification which fully documents what something is needed to do. I write it and send it back having tested as far as I can, then the business does extensive tests and the bugs get corrected before it gets released. So we should only need to code and test to the requirements and then the specification is the documentation. As I said, "In an ideal world, ...". :)
StarNamer@work wrote:
...and then the specification is the documentation. As I said, "In an ideal world, ..."
Well, I have issues with that on two counts: - the specification only provides the "black box" description of the code, what gets in and what gets out. It doesn't say how to do it. It is up to you, the programmer to choose/devise the best algorithm, data structures to be used, limitations and compromises you had to make and so on; in brief, the nitty-gritty of the implementation. - as you say, the world is not ideal and specifications are not complete so you have to make decisions during the implementation on how to solve those blank spots in the specification. You do it either by going back to the user, or by making informed choices but in the end all that accumulated knowledge has to be put somewhere by someone and I'd argue that you are in the best position to amend that specification and transform it into a manual. Of course things can be different if you are part of a humongous organization and you are just a little cog doing your little bit for an enormous project. In that case there are probably many other people doing documentation, testing, integration, etc. and you just have to do (well) your bit of coding. However the OP was talking of design and contrasting it with documentation and testing, often seen as "lowly" activities. My point was that, in smaller projects, where you have certain freedom to design and implement stuff, there are no "lowly" tasks and everything has to be regarded as equally important. I could go on, but I already feel that I'm ranting. Sorry... :)
Mircea
