Ok, folks, I'm starting to get concerned that I'm either losing all estimation of my skills, or going full-bore diva.
I'm currently part of a small team (2 devs, one PM), and I'm finding it increasingly frustrating that I seem to be the only one on the team who has any idea of how to develop a software system. If anything needs doing, I seem to be the only one who has any idea how. If there is a bug in code, my suggestions as to cause or how to proceed are ignored, then turn out to be correct. Members of another associated team make suggestions that for the most part are either already in place (sometimes obviously), or are totally irrelevant.
The other dev is very good at doing one thing at a time at best, and while they do create test harnesses for the code, does not seem to grasp the need to live testing *and* actually take the step to do it. I have to push for the live tests. If a stumbling block appears, all progress halts and it's a "what do I do now?"
I appear to be the only one looking at the system as a whole, and the only one taking action to do the things that need to be done. Several times we have had the production build fail due to some issue with the other dev's code or build process, and I get to diagnose and fix that.
And I'm not even bitching about the housekeeping issues that I'm handling, which, due to the draconian security policies, are almost entirely manual, because we are not trusted with admin access to the systems.
Thursday, July 12, 2018
Monday, June 25, 2018
Use what's already there, dammit
Venting post today.
Cow-orker and I are trying to debug performance in a multi-threaded application. I already added threads initially, so there was an example in the code to base anything new on. Of key significance is the casting of some references to arguments.
Yet cow-orker adds a new set of threads, and not only does not use that for the new code, but removes it from the part that it was already in.
So the code compiles under the old compiler mode, but fails when we get to the official build machine.
And the correct example was in the code to begin with.
Cow-orker and I are trying to debug performance in a multi-threaded application. I already added threads initially, so there was an example in the code to base anything new on. Of key significance is the casting of some references to arguments.
Yet cow-orker adds a new set of threads, and not only does not use that for the new code, but removes it from the part that it was already in.
So the code compiles under the old compiler mode, but fails when we get to the official build machine.
And the correct example was in the code to begin with.
Monday, May 21, 2018
More Practical advice - Producer-Consumer threads
Two in one day! What's the world coming to?
Ok, a common paradigm is a producer-consumer threaded application, using a queue to pass the message to be processed. I recently coded one, and we were discussing how to manage the number of threads in the future, when we would want the application to dynamically allocate threads to match load.
Now, adding threads to increase capacity is simple - you just need to create the thread with the appropriate parameters (input queue, output sink, etc), save off the info so you can reap the thread at termination, and Bob's your uncle.
But removing threads is more complicated, because you don't want to kill a thread in the middle of processing a message. So you need a means to tell a thread to die when it's done with the current message.
What I had come up with for shutting down all the threads at program end was pretty simple - the Producer emits a message with a specific format that when read by a thread, tells the thread to exit its main loop and return. What was moderately cool was that I had the thread re-emit the message into the queue, so that the next thread to read it would also stop, and would re-emit the message again, until all threads stopped.
The today I realized that if I added a simple counter onto the message format, I could use that as a way to reap a specific number of threads without any new mechanism. The Consumer thread sees that flag message, exits its main loop, and then checks the counter value for 0. If it's not 0, it decrements it by 1, and re-emits the message with the new counter value. So start the message with a counter of 3, and 3 threads see it, stop, and re-emit it once each. The last one sees the counter is 0, and does not re-emit it.
This can be used to kill all the threads but setting the counter to -1, which will never be 0, so all the threads will see, process, and re-emit the flag message (unless you have so many thread that the value wraps, but that's an entirely different problem)
Ok, a common paradigm is a producer-consumer threaded application, using a queue to pass the message to be processed. I recently coded one, and we were discussing how to manage the number of threads in the future, when we would want the application to dynamically allocate threads to match load.
Now, adding threads to increase capacity is simple - you just need to create the thread with the appropriate parameters (input queue, output sink, etc), save off the info so you can reap the thread at termination, and Bob's your uncle.
But removing threads is more complicated, because you don't want to kill a thread in the middle of processing a message. So you need a means to tell a thread to die when it's done with the current message.
What I had come up with for shutting down all the threads at program end was pretty simple - the Producer emits a message with a specific format that when read by a thread, tells the thread to exit its main loop and return. What was moderately cool was that I had the thread re-emit the message into the queue, so that the next thread to read it would also stop, and would re-emit the message again, until all threads stopped.
The today I realized that if I added a simple counter onto the message format, I could use that as a way to reap a specific number of threads without any new mechanism. The Consumer thread sees that flag message, exits its main loop, and then checks the counter value for 0. If it's not 0, it decrements it by 1, and re-emits the message with the new counter value. So start the message with a counter of 3, and 3 threads see it, stop, and re-emit it once each. The last one sees the counter is 0, and does not re-emit it.
This can be used to kill all the threads but setting the counter to -1, which will never be 0, so all the threads will see, process, and re-emit the flag message (unless you have so many thread that the value wraps, but that's an entirely different problem)
Practical advice re CSV files
Morning, everyone!
I'm sure everyone has had a situation where they were generating data for another system, and needed a text format, and decided that comma-separated values (CSV) would work nicely. Well, here's a little advice: if you have any reason to expect a) human-driven input for fields, or b) reformatting of fields by some programatic means, then chose to use a pipe '|' as the separator instead.
The reason is that there is little use for that character in normal human text usage, so it will not get used within a field, the way commas often are in things like addresses, or names. And as I found out recently, some encryption software is perfectly happy producing cyphertext with commas embedded
I'm sure everyone has had a situation where they were generating data for another system, and needed a text format, and decided that comma-separated values (CSV) would work nicely. Well, here's a little advice: if you have any reason to expect a) human-driven input for fields, or b) reformatting of fields by some programatic means, then chose to use a pipe '|' as the separator instead.
The reason is that there is little use for that character in normal human text usage, so it will not get used within a field, the way commas often are in things like addresses, or names. And as I found out recently, some encryption software is perfectly happy producing cyphertext with commas embedded
Thursday, July 20, 2017
Losr in Corporate Hell
I just got out of a meeting where I was gobsmacked at the insistence by some architects that no development could be done unless the specific IP addresses of the machines in the system were set in a design document.
Think about that.
No design or development could be done unless the specific machines were known, despite the interchangability of any machine.
IP addresses are standardized, so the only thing needed to be known is the number of machines.
As I said, gobsmacked.
Think about that.
No design or development could be done unless the specific machines were known, despite the interchangability of any machine.
IP addresses are standardized, so the only thing needed to be known is the number of machines.
As I said, gobsmacked.
Saturday, May 13, 2017
Muzzling diversity
I've got a new corporate master now, and one of the big "perks" is working in an open office plan.
There are plenty of blog posts, articles, studies, etc that show such offices are crap for software development.
However, I realized something this week. They also serve to minimize dissent in the company.
If you are surrounded by people who can watch your every move, you are likely to self-censor your speech, because you have to get along with the cow-orkers every day, so setting yourself up as someone who disagrees with your colleagues is career-limiting behavior.
If you had an office or a halfway decent cubicle (6-ft partitions, minimum) you could have soft conversations about topics that your neighbors did not agree with.
Open offices lead to groupthink. Just say no
There are plenty of blog posts, articles, studies, etc that show such offices are crap for software development.
However, I realized something this week. They also serve to minimize dissent in the company.
If you are surrounded by people who can watch your every move, you are likely to self-censor your speech, because you have to get along with the cow-orkers every day, so setting yourself up as someone who disagrees with your colleagues is career-limiting behavior.
If you had an office or a halfway decent cubicle (6-ft partitions, minimum) you could have soft conversations about topics that your neighbors did not agree with.
Open offices lead to groupthink. Just say no
Monday, November 21, 2016
Yet Another Bad Catchphrase
"...It's in our DNA"
Gaaahh. I *HATE* when corporations use that phrase.
It's not in your DNA, even metaphorically. If it were, you would not have to keep apologizing for security breaches, or for crappy customer service, etc., etc., etc.
It's just some uneducated marketing hack who wants it to sound like they can't fail.
Nearly as bad is "laser-focused". 'Cause the whole point of a laser is that it is not focused, it's collimated. If you focused it, it would no longer be a laser, and no longer any use.
Gaaahh. I *HATE* when corporations use that phrase.
It's not in your DNA, even metaphorically. If it were, you would not have to keep apologizing for security breaches, or for crappy customer service, etc., etc., etc.
It's just some uneducated marketing hack who wants it to sound like they can't fail.
Nearly as bad is "laser-focused". 'Cause the whole point of a laser is that it is not focused, it's collimated. If you focused it, it would no longer be a laser, and no longer any use.
Subscribe to:
Posts (Atom)