What's your least favorite part of coding?
-
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
My worst part of coding is when I'm constantly asked to defend the code when it turns out that the data is the cause of the problem.
-
lmoelleb wrote:
I did not change anything
That statement is always a lie.
Software Zen:
delete this; -
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.
Nelek wrote:
McAfee is installed at work
We have it here as well. We use Inno Setup for our product installers. One day I was working on an install script and compiled it. I got a popup message from McAfee claiming a real-time scanning violation. Inno Setup closed up. I restarted it, and the source for my install script was gone, as were a number of the files included in the install. McAfee had terminated the Inno Setup compile process and deleted all of the files (including source code) that process had opened. I only lost an hour's work, but still. My problem report to IT was... flammable.
Software Zen:
delete this; -
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
Sorry, but it doesn't matter if it is "professionally" or "your own". I know it is a very popular view these days, but I learned to document first, before even writing a single line of code. And that includes having (insisting! when it comes from an outside request) the specifications for a project. And then, and only then, start "coding", according to the existing specs and docs. And if you do this, properly, without using shortcuts, this will drastically cut down on any debugging/testing/troubleshooting afterwards. If you don't do this, you are just a code monkey, hacking away at a keyboard and you will always run into problems, no matter what the project is. And that "running into problems" is the real part that takes away any fun and satisfaction on this kind of job. It is NOT the documentation. And no, the documentation is NOT in the code, not by a long shot...
-
Sorry, but it doesn't matter if it is "professionally" or "your own". I know it is a very popular view these days, but I learned to document first, before even writing a single line of code. And that includes having (insisting! when it comes from an outside request) the specifications for a project. And then, and only then, start "coding", according to the existing specs and docs. And if you do this, properly, without using shortcuts, this will drastically cut down on any debugging/testing/troubleshooting afterwards. If you don't do this, you are just a code monkey, hacking away at a keyboard and you will always run into problems, no matter what the project is. And that "running into problems" is the real part that takes away any fun and satisfaction on this kind of job. It is NOT the documentation. And no, the documentation is NOT in the code, not by a long shot...
None of that has anything to do with liking it or not. I spend plenty of time on documentation.[^] It doesn't mean I enjoy it, and I don't mind saying so. I should add: Furthermore, everyone's got their own opinion on how things must be done, will argue it 'til they're blue in the face, and everyone that does things differently is a "code monkey". I'm too old for that nonsense. When I start reading it, my eyes glaze over. I developed a process and order that works for *me* and allows me to produce solid, maintainable work. And it does work. I'm paid quite well, and my clients are happy with what I produce. At the end of the day, that's what matters, not how I got there.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
Nelek wrote:
McAfee is installed at work
We have it here as well. We use Inno Setup for our product installers. One day I was working on an install script and compiled it. I got a popup message from McAfee claiming a real-time scanning violation. Inno Setup closed up. I restarted it, and the source for my install script was gone, as were a number of the files included in the install. McAfee had terminated the Inno Setup compile process and deleted all of the files (including source code) that process had opened. I only lost an hour's work, but still. My problem report to IT was... flammable.
Software Zen:
delete this;Gary Wheeler wrote:
My problem report to IT was... flammable.
Yeah... been there done that too... We had a new password policy in a firm I worked too, where 90% of the workers were with mid to long term projects mostly on the way. Suddenly we had to change password every 6 weeks. I wrote an email to our IT that got escalated to the CTO and I got a very CTO-answer explaining me how wrong I was and how insecure was our previous policy. A guy got a project ended, went 4 weeks in vacation and when he came back his first day was to go to the company, grab som equipment and go to the airport for a project somewhere in the US west coast (almost 30 hours until he reached the hotel). He slept and on the first work day, connected the VPN in the hotel, checked the emails and went to the customer... Once there, the laptop wouldn't let him log in. He called me to explain the problem and I was like "oh, oh" (but rubbing my hands in my interior). I went to the company and started a discussion with the IT about it. I supposed it had to do with the password policy. With vacations and the trip he went over the 6 weeks, the first log in the US was with an offline valid user, once he connected the VPN the windows got the message "password expired" and after the reboot... bye bye. Once they confirmed on their own, what I was telling them from the very beginning the good dialog started. - He can change it with the Ctrl+Alt+Supr menu * No he can't, because he can't log in - Then he should use the password recovery option in the website of the company * No he can't, because it only works in VPN and he can't log in in windows - But he can use the VPN in other computer * No he can't, our VPN certificate is in encoded in C: and he can't log in in windows - OK, I have reseted the validity of his user, that should solve the problem * No, it won't, because the change is only valid once you connect to the VPN (and we already spoke about it) ... Rinse and repeat with two additional "support levels", the final solution was to send another laptop per messenger. That was Thursday, Laptop was expected to come on monday. The guy had not expected "holidays" and could do tourism, the company got a really angry call from our customers and had to discount the not worked days, we got a new password policy for 6 months instead of 6 weeks and I got the most satisfactory "I told you" in my whole life. :laugh: :rolleyes:
M.D.V. ;) If something has a solut
-
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
Trying to explain to Dunning-Kruger management types why their brilliant idea would cause a disaster. Favorite quote from a CEO: "it's all objects, right? Can't you just change it anyway you want?"
-
Mircea Neacsu wrote:
travelling to 50+ countries on 6 continents
I'd absolutely hate that part of the job X| I hate visiting customers, save for two are even closer than my own office (6 and 7 km vs. 14 km). I don't like working from home all the time either though, need to get out and socialize once in a while :)
Mircea Neacsu wrote:
There is some difference in purpose and scale
That's my point exactly. In your original post you said: "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." However, at my scale, it adds more work and complexity than it takes away. Just like almost everything, whether you need documentation and unit tests "depends" on your use case. Not having proper build and release pipelines is leaving the job half-done though :laugh:
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
There's a marked difference between not enjoying something and not doing it. Mind the gap. :)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
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
-
I don't like it, but I feel like it's good for the soul to be reminded periodically of how little I actually know. :laugh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
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
What I now do probably falls under your classification as:
Mircea Neacsu wrote:
part of a humongous organization and you are just a little cog doing your little bit for an enormous project
Most of our business users are quite happy specifying UI changes, notifying legal requirements and otherwise just treating the whole distributed setup as a "black box". The IT team keeps track of how everything really works! I'd question describing my role as "a little cog" since it's more a case that I get the issues no-one else has managed to solve. I do more support and fixing than actual development these days but have probably worked on all areas of our main in-house application. However, the "humongous organization" is probably correct as the company was blocked from an acquisition a few years ago as it would have had too much market share in the UK; my boss used to describe it at trade fairs as "the largest UK company you've never heard of"!
-
What I now do probably falls under your classification as:
Mircea Neacsu wrote:
part of a humongous organization and you are just a little cog doing your little bit for an enormous project
Most of our business users are quite happy specifying UI changes, notifying legal requirements and otherwise just treating the whole distributed setup as a "black box". The IT team keeps track of how everything really works! I'd question describing my role as "a little cog" since it's more a case that I get the issues no-one else has managed to solve. I do more support and fixing than actual development these days but have probably worked on all areas of our main in-house application. However, the "humongous organization" is probably correct as the company was blocked from an acquisition a few years ago as it would have had too much market share in the UK; my boss used to describe it at trade fairs as "the largest UK company you've never heard of"!
StarNamer@work wrote:
I'd question describing my role as "a little cog"
I didn't mean that disparagingly. Little cogs doing their work well in a humongous organization put the man on the moon. In my book, they are all heroes. And, yes, some of them were programmers[^].
Mircea
-
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
Explaining to other programmers that because the code they are working on was first coded 20 years ago there is no possible way that those programmers could have designed it to work with what is needed now. And in the same way they should not try to guess what will be needed 20 years from now by adding stuff that has nothing to do with what is needed now.
-
I don't like it, but I feel like it's good for the soul to be reminded periodically of how little I actually know. :laugh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
Take heart - the more you learn, the more you realise how little you know. So the corollary must be that the more you realise how little you know, the more you must have learned.
-
Mine is not technical. Overall, I am pleased with the tools and helps I have in VS2022. My least favorite part of coding is interference in my coding by non-technical project managers. Such as (and I paraphrase for brevity): “That will take too long to do it right.” “Are we there yet?” “I read somewhere you should be using language Y instead of language X. Go back and rewrite all the code in language X.” “We don’t need exception handling and logging. Just do it without all that.” “Why is it taking so long?” “Let’s add more programmers so we get this done sooner.” (said about halfway or after the midpoint of the project) “We need more meetings.” And, of course, the reader could add more. P.S. I have over 20 years as a project manager with the technical knowledge, skills, and abilities. This is about the non-technical project managers who don’t have the necessary knowledge and experience on how software engineering projects differ from other projects they learned about in their coursework. I thank God everyday for those non-technical project managers that understand they need to learn the difference and are teachable. They make fantastic project managers.
The basic lesson they should've been taught is that a little learning is a dangerous thing. Or putting it another way, the more you learn the more you see how little you know.... I'm currently bingeing on the very perceptive BBC comedies "Twenty Twelve" and "W1A", where several of the characters illustrate the above very well. Chief airhead and "Head of Brand" Siobhan Sharpe portrays this kind of PIA hilariously.
-
Explaining to other programmers that because the code they are working on was first coded 20 years ago there is no possible way that those programmers could have designed it to work with what is needed now. And in the same way they should not try to guess what will be needed 20 years from now by adding stuff that has nothing to do with what is needed now.
I remember learning to code in 1978. My instructor said I was using too much storage using 4 digit years. Most code wouldn't be running by 2000. In 2000 I was doing the job I hated most debugging code written 22+ years before where the programmer chose to save space and made it necessary to rewrite code to use 4 digit years.
-
I remember learning to code in 1978. My instructor said I was using too much storage using 4 digit years. Most code wouldn't be running by 2000. In 2000 I was doing the job I hated most debugging code written 22+ years before where the programmer chose to save space and made it necessary to rewrite code to use 4 digit years.
