What's your least favorite part of coding?
-
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
-
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
Ditto Mircea, I agree. In my grad school computer lab, we had the proverbial toilet paper picture with "The job's not finished until the paperwork is done!", on the wall next to our Data General Eclipse mini-computer. Our mentor/professor meant it as we got graded from A-to-Z in preparation for the professional world of computer programming.
"A little time, a little trouble, your better day" Badfinger
-
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
When it must work, is right, is simple but doesn't. I have been struggling most of Sunday where 2 old iframes src=(path to mvc view) work fine but the new one, just like the others is producing a 404. I can go to the folder in dos and copy the view iis can't find to somewhere and that is ok, and it's in the same folder as the others. I have stared at the code and stared at the code. These days put me in a foul mood.
-
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
honey the codewitch wrote:
It's now used all over the place, including Github,
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
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. [^]
Hell yeah. McAfee is installed at work and we have had really weirdo things happening... everytime we do get a "not so logical" thing, the first we do is to deactivate it for an hour (the only thing we can do due to server policies) or check the second most common cause... the windows updates.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
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
Chris Maunder wrote:
and your users take one look at it and point at the huge flaw you didn't see.
Or when a user that is working less than 2 weeks there blocks the execution in such a way that you need to step in with the laptop and manually reset something, after 4 years of non stop stable as a rock working record... :doh: :sigh: X|
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
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 debug old code and work out what the hell was thinking the idiot that wrote that code just to find out after a while, that I was that idiot.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
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
Testing is the worst. Documentation is the worst too. After that, I go into a bit of a decline. (With apologies to Douglas Adams)
Paul Sanders. If I had more time, I would have written a shorter letter - Blaise Pascal. Some of my best work is in the undo buffer.
-
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
Mircea Neacsu wrote:
I don't think your question has a proper answer between professionals
So you like everything about your job? Including the meetings with management? Very few people like everything about their job. In fact, not many people really like their job at all. As for the rest of your post, I come across very little code that's properly documented, my own code included. I don't find it all that important and neither does my customer and it's never been an issue. Same goes for automated tests. The greatest bottleneck in my code is a piece that requires extensive UI and integration testing (of which a part can't even be tested because third party). It's faster and easier to just manually run the code a few times and get that code in order so there's fewer chances of it breaking. Having said that, I hate writing documentation because the moment you write it the software will have evolved and the documentation is outdated and no one will ever read it anyway and for that reason I never trust documentation. I also really dislike writing tests. The only tests I've seen never broke until they did because functionality changed. Never have I prevented a bug with tests. I use tests when writing complicated and easy to test logic, like parsers (but I rarely write those and when I do they're simple parsers).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Quote:
Documentation, as I am no good at writing clear instructions
Now appart from Q/A where you simply reply with a link, I have a strong feeling, that you are writing very good instructions :thumbsup:
-
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
Recoding because some product manager has changed his/her mind and shoehorned some feature modification into the spec, which trashes the design and requires a major rewrite. I hate doing things twice. I'm sure I'm not alone in 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
Recoding because some product manager has changed his/her mind and shoehorned some feature modification into the spec, which trashes the design and requires a major rewrite. I hate doing things twice. I'm sure I'm not alone in this.
-
Mircea Neacsu wrote:
I don't think your question has a proper answer between professionals
So you like everything about your job? Including the meetings with management? Very few people like everything about their job. In fact, not many people really like their job at all. As for the rest of your post, I come across very little code that's properly documented, my own code included. I don't find it all that important and neither does my customer and it's never been an issue. Same goes for automated tests. The greatest bottleneck in my code is a piece that requires extensive UI and integration testing (of which a part can't even be tested because third party). It's faster and easier to just manually run the code a few times and get that code in order so there's fewer chances of it breaking. Having said that, I hate writing documentation because the moment you write it the software will have evolved and the documentation is outdated and no one will ever read it anyway and for that reason I never trust documentation. I also really dislike writing tests. The only tests I've seen never broke until they did because functionality changed. Never have I prevented a bug with tests. I use tests when writing complicated and easy to test logic, like parsers (but I rarely write those and when I do they're simple parsers).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Sander Rossel wrote:
So you like everything about your job? Including the meetings with management?
Yes, I lived an enchanted life :) My boss for 20+ years was the owner of the company, an intelligent, nice person who called meetings only when needed and kept them short and to the object. Otherwise, I had my share of delayed flights, lost luggage, running into the occasional idiot, in short the usual unpleasantness of life, but that's not something I could blame on my profession.
Sander Rossel wrote:
In fact, not many people really like their job at all.
I know. In fact I see it as one of the best paths to a miserable life. Hopefully, most programmers who hang out in their spare time at a coding site, do enjoy their profession. Otherwise I'm very, very sorry for them. Now about documentation:
Sander Rossel wrote:
I don't find it all that important and neither does my customer and it's never been an issue.
Really? I imagine you provide your customer with some type of manual or instructions. As for documenting the internals of your program, if other colleagues need to look at your code, I'm not sure they enjoy the experience. If you are a team of one, it might not be that important in your younger years or if you are writing throw-away code that is used only once and never revisited. If you are writing reusable code, docs matter.
Sander Rossel wrote:
I also really dislike writing tests. The only tests I've seen never broke until they did because functionality changed. Never have I prevented a bug with tests.
I don't know what type of code you are writing. It might be your case, but in my world tests do matter. I do complicated math stuff and I want to make sure it works for all acceptable inputs. Some of the code I wrote has been in use for 10-15 years and that's because of a combination of being well-documented and properly tested.
Mircea
-
Sometimes I like that challenge. Other times it can be frustrating.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
It can be a challenge when you have access to something you can examine. In this specific case, all we have access to is a 404 response if we do not guess the URL and port. Another problem with 1 million euro gizmos, they do not give us any to play with in a test environment.
-
Sander Rossel wrote:
So you like everything about your job? Including the meetings with management?
Yes, I lived an enchanted life :) My boss for 20+ years was the owner of the company, an intelligent, nice person who called meetings only when needed and kept them short and to the object. Otherwise, I had my share of delayed flights, lost luggage, running into the occasional idiot, in short the usual unpleasantness of life, but that's not something I could blame on my profession.
Sander Rossel wrote:
In fact, not many people really like their job at all.
I know. In fact I see it as one of the best paths to a miserable life. Hopefully, most programmers who hang out in their spare time at a coding site, do enjoy their profession. Otherwise I'm very, very sorry for them. Now about documentation:
Sander Rossel wrote:
I don't find it all that important and neither does my customer and it's never been an issue.
Really? I imagine you provide your customer with some type of manual or instructions. As for documenting the internals of your program, if other colleagues need to look at your code, I'm not sure they enjoy the experience. If you are a team of one, it might not be that important in your younger years or if you are writing throw-away code that is used only once and never revisited. If you are writing reusable code, docs matter.
Sander Rossel wrote:
I also really dislike writing tests. The only tests I've seen never broke until they did because functionality changed. Never have I prevented a bug with tests.
I don't know what type of code you are writing. It might be your case, but in my world tests do matter. I do complicated math stuff and I want to make sure it works for all acceptable inputs. Some of the code I wrote has been in use for 10-15 years and that's because of a combination of being well-documented and properly tested.
Mircea
Mircea Neacsu wrote:
but that's not something I could blame on my profession
Part of the job, I guess.
Mircea Neacsu wrote:
Hopefully, most programmers who hang out in their spare time at a coding site, do enjoy their profession.
I do :)
Mircea Neacsu wrote:
Really? I imagine you provide your customer with some type of manual or instructions.
None whatsoever. My code is custom made for every customer so they know exactly what they're getting. I get an occassional call like "Sander, if I press this button will it do x or y?", but that happens maybe once a year. Mostly because all buttons are pressed on a weekly basis so people know what they do. I've written plenty of manuals in the past and I think none of them were ever read. Even with a manual, it's easier for my customer to call me than it is to find and read the documentation. At one time the customer even requested a help menu, accessible from an "info-button" at the top right of the form. We documented the entire form and added the button. The only one who pressed it was me when they called "what does this do?" :laugh: One time a customer told me "I didn't know what to expect, but I opened it and I just knew where to go because the software is so intuitive."
Mircea Neacsu wrote:
if other colleagues need to look at your code, I'm not sure they enjoy the experience.
I recently got a new junior employee and he had little trouble working through my code. It's not that hard either, you POST a form and end up in the OnPost method and you can figure it out from there. A few if-statements, a for-loop, some validations, save something to the database... Nothing too complicated. I have the advantage that most of my code has a GUI, which means most of the funtionality has a visible component, which also makes debugging a bit easier (there's always a clear entry point, like a button click). Some of my code is a hassle to work with, but I wouldn't even know how to begin to describe it. Just set a breakpoint and walk through the code line by line, I guess. That's really the only sure way to know what code does. Reversed, I never read documentation either. If I have to read lots of documentation just to understand what's going on, it's probably bad code and the documentation would be just as bad. On that note, writing go
-
Mircea Neacsu wrote:
but that's not something I could blame on my profession
Part of the job, I guess.
Mircea Neacsu wrote:
Hopefully, most programmers who hang out in their spare time at a coding site, do enjoy their profession.
I do :)
Mircea Neacsu wrote:
Really? I imagine you provide your customer with some type of manual or instructions.
None whatsoever. My code is custom made for every customer so they know exactly what they're getting. I get an occassional call like "Sander, if I press this button will it do x or y?", but that happens maybe once a year. Mostly because all buttons are pressed on a weekly basis so people know what they do. I've written plenty of manuals in the past and I think none of them were ever read. Even with a manual, it's easier for my customer to call me than it is to find and read the documentation. At one time the customer even requested a help menu, accessible from an "info-button" at the top right of the form. We documented the entire form and added the button. The only one who pressed it was me when they called "what does this do?" :laugh: One time a customer told me "I didn't know what to expect, but I opened it and I just knew where to go because the software is so intuitive."
Mircea Neacsu wrote:
if other colleagues need to look at your code, I'm not sure they enjoy the experience.
I recently got a new junior employee and he had little trouble working through my code. It's not that hard either, you POST a form and end up in the OnPost method and you can figure it out from there. A few if-statements, a for-loop, some validations, save something to the database... Nothing too complicated. I have the advantage that most of my code has a GUI, which means most of the funtionality has a visible component, which also makes debugging a bit easier (there's always a clear entry point, like a button click). Some of my code is a hassle to work with, but I wouldn't even know how to begin to describe it. Just set a breakpoint and walk through the code line by line, I guess. That's really the only sure way to know what code does. Reversed, I never read documentation either. If I have to read lots of documentation just to understand what's going on, it's probably bad code and the documentation would be just as bad. On that note, writing go
Sander Rossel wrote:
Part of the job, I guess.
Price to be paid for travelling to 50+ countries on 6 continents with all travel expenses paid :laugh:
Sander Rossel wrote:
Mostly LOB applications. I really don't need to test that a button click results in some entity being validated and saved to the database. I manually tested it and it works.
There is some difference in purpose and scale. In my case, the same software was/is used for data acquisition and visualization by over 5000 customers who connected 200+ types of devices. Besides, operating costs for some of the customers were so big that a single day lost was more than the cost of our software. If it wouldn't have worked, they would have thrown it overboard and I wouldn't have had the chance of a comfy retirement. :D
Mircea
