I ran across this post last week. An admirable sentiment, perhaps, but one that, in my opinion, is unwarranted. Many, many software developers never approach the user interface side of the work, and they have no need for graphic design exposure.
I see articles like this, and wonder if the managerial types are trying to keep the developers from feeling like they already possess a valuable and necessary skill. In a manner akin to those "open ads" for a job that list a very specific set of qualifications, clearly intended to fit the already-chosen candidate, often one whose options are limited by immigrant status, or whose salary is low due to being overseas, this begins to feel like a way to tell the existing developers "You're no longer good enough, we don't have to hire you unless you're a polyglot Renaissance man"
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, May 07, 2007
Friday, March 23, 2007
More validation of my opinions
Not that I need much.....
It was written for "artistic" types, but applies to software types
Points 3,4,9 and 10 resonate most, pity too many developers feel differently about OOP
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
It was written for "artistic" types, but applies to software types
Points 3,4,9 and 10 resonate most, pity too many developers feel differently about OOP
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, March 21, 2007
Like I said......
Someone else has seen the "Back where I used to work, we did things different" syndrome
Clinton Forbes
So remember folks, don't treat your new cow orkers like idiots, or they will hate you for it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Clinton Forbes
So remember folks, don't treat your new cow orkers like idiots, or they will hate you for it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Friday, March 02, 2007
Turnabout's Fair Play
Today, driving home, I had a mild epiphany.
You have no doubt heard the manager-speak where they call a problem "an opportunity", one of the more hated turns of phrase I know of.
Well, I just thought that what's sauce for the goose is sauce for the gander...
When managers discuss bugs, refer to them opportunities. You know, a chance to improve the codebase.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
You have no doubt heard the manager-speak where they call a problem "an opportunity", one of the more hated turns of phrase I know of.
Well, I just thought that what's sauce for the goose is sauce for the gander...
When managers discuss bugs, refer to them opportunities. You know, a chance to improve the codebase.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, February 17, 2007
Another Stupid Cliche - The Ninja Rants Again
It always happens, in every job. Some well-meaning managerial type has a chat with you about dealing with external issues, and that phrase comes up:
"You have to own the problem."
This always happens when the discussion is about someone outside your area has a problem and they want your help. They can't be bothered to provide all the necessary info, even if they are well-aware of what is needed, and they can't be bothered to follow-up on the issue, so you have to "own the problem" and spoon-feed them the answers, and god help you if you don't.
I always wonder why I am the one who has to "own the problem", and not the person who brings the problem to me? And why I am expected to be able to solve the problem against all odds without any increase in my authority, budget, or rank? It's particularly galling when you discover that the problem does not lie in your area of expertise, but are expected to pursue the problem to the next expert, instead of informing the one who came ot you, and letting them carry it to the next expert. Why aren't they "owning the problem"?
One of my theories about this is that managers don't want to appear as if their staff cannot solve problems, so they expect their staff to be the ones to "solve" the problem by carrying it to the end. It garners much praise from the upper managers, because they don't have to actually manage the problem. It might be an effect of continual delegation - the upper managers might rightly delegate a problem to an underling, but that underling still has enough authority to encompass the entire solution. This rule falls apart when you reach the lower levels of management, because the solution may not fall under the authority of that delegate, and that causes difficulties - the delegate now cannot command obedience to get the answer. And so the lowest level of management follows the trend, and expects the contributor level to magically influence others at their own or higher levels to help solve a problem that they have less then immediate data about.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
"You have to own the problem."
This always happens when the discussion is about someone outside your area has a problem and they want your help. They can't be bothered to provide all the necessary info, even if they are well-aware of what is needed, and they can't be bothered to follow-up on the issue, so you have to "own the problem" and spoon-feed them the answers, and god help you if you don't.
I always wonder why I am the one who has to "own the problem", and not the person who brings the problem to me? And why I am expected to be able to solve the problem against all odds without any increase in my authority, budget, or rank? It's particularly galling when you discover that the problem does not lie in your area of expertise, but are expected to pursue the problem to the next expert, instead of informing the one who came ot you, and letting them carry it to the next expert. Why aren't they "owning the problem"?
One of my theories about this is that managers don't want to appear as if their staff cannot solve problems, so they expect their staff to be the ones to "solve" the problem by carrying it to the end. It garners much praise from the upper managers, because they don't have to actually manage the problem. It might be an effect of continual delegation - the upper managers might rightly delegate a problem to an underling, but that underling still has enough authority to encompass the entire solution. This rule falls apart when you reach the lower levels of management, because the solution may not fall under the authority of that delegate, and that causes difficulties - the delegate now cannot command obedience to get the answer. And so the lowest level of management follows the trend, and expects the contributor level to magically influence others at their own or higher levels to help solve a problem that they have less then immediate data about.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, January 21, 2007
Software is like an ogre....
...it has layers
(sorry for the Shrek reference....)
Most developers are at least somewhat aware of this, since we all see the usual network protocol stack diagrams with 3-7 layers, and the MVC design pattern/paradigm, and so on.
What I am starting to think is that this pattern is not being used enough. We have our GUI layers, our database layers, and our business logic layers, but we tend to have a single program running as the layer.
After a recent push with work to have a VP's pet project done, I had the chance to build a "server" that was calling several standalone executables to perform specific tasks. What I got from this was that it followed the UNIX way better - I had smaller, easier-to-debug pieces that could be re-used on other projects without having to alter basic code. The big use would be for test harnesses - by having standalone executables, the test crew can write shell scripts to drive their tests, which relieves the development team from having to provide all the integration test code.
Now, this does not work in places where serious speed or efficiency is needed. But many programs are driven by user input, or easily-paced timers, and the benefit of the encapsulation can pay off later.
Also, many developers will point out that libraries can perform similar functions. They can, but alternate use requires they be linked in to the calling program, which can be problematic for testers, who typically have a) less software writing experience, and b) less support structure to write code in.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
(sorry for the Shrek reference....)
Most developers are at least somewhat aware of this, since we all see the usual network protocol stack diagrams with 3-7 layers, and the MVC design pattern/paradigm, and so on.
What I am starting to think is that this pattern is not being used enough. We have our GUI layers, our database layers, and our business logic layers, but we tend to have a single program running as the layer.
After a recent push with work to have a VP's pet project done, I had the chance to build a "server" that was calling several standalone executables to perform specific tasks. What I got from this was that it followed the UNIX way better - I had smaller, easier-to-debug pieces that could be re-used on other projects without having to alter basic code. The big use would be for test harnesses - by having standalone executables, the test crew can write shell scripts to drive their tests, which relieves the development team from having to provide all the integration test code.
Now, this does not work in places where serious speed or efficiency is needed. But many programs are driven by user input, or easily-paced timers, and the benefit of the encapsulation can pay off later.
Also, many developers will point out that libraries can perform similar functions. They can, but alternate use requires they be linked in to the calling program, which can be problematic for testers, who typically have a) less software writing experience, and b) less support structure to write code in.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, January 06, 2007
Being TOO Careful
A program at work gave me a bit of trouble these past two work weeks (the holiday break interrupted the debugging).
It's a process manager for the product, allowing the user to start and stop the various parts of the system, and it also monitors the processes to restart them if they fail. Basically, all the same stuff initd does under Unix, but for the specific system applications.
Now, for some reason, it does not keep its list of child processes in memory, but uses the 'ps' function to get them, filtering the output to eliminate things using the executable name in other ways. However, it expects the executable to be the first thin in the command line section of the output.
That's it - no provision for an interpreted script at all. And my most recent work is a rapid-prototype server in Python. So it can't be controlled from the manager. And it's buried in old, barely managed code, so I'm reluctant to dive into that swamp without managerial mandate.
(To be fair, this is one of the oldest parts of the system, written over a decade ago, so it was probably not a high probability that interpreted languages would be used in the system at that time. But it still was a real pain to have this float out of the miasma of reported bugs coming from the 3 sets of testing staff.)
Fortunately, Python's embedding feature saved me here; I was able to throw together a quick C++ wrapper that would call the Python script, waiting for it to exit. So now I get the monitor to start and stop it cleanly, but keep the useful parts in Python.
There is a plan to move the code more to C++, but the need to do several things that we have no C++ libraries for will keep some Python in the mix.
[Later]
Mea Culpa, Readers! I forgot to relate the moral of this story, in all my bitching and moaning.
The Lesson: When filtering results, the Software Ninja makes sure the filtering code is a) separated into an independent function, and b) make the filtering criteria very clear, so that the next developer to work on the code can change the filtering if necessary, and will understand what is being filtered out.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
It's a process manager for the product, allowing the user to start and stop the various parts of the system, and it also monitors the processes to restart them if they fail. Basically, all the same stuff initd does under Unix, but for the specific system applications.
Now, for some reason, it does not keep its list of child processes in memory, but uses the 'ps' function to get them, filtering the output to eliminate things using the executable name in other ways. However, it expects the executable to be the first thin in the command line section of the output.
That's it - no provision for an interpreted script at all. And my most recent work is a rapid-prototype server in Python. So it can't be controlled from the manager. And it's buried in old, barely managed code, so I'm reluctant to dive into that swamp without managerial mandate.
(To be fair, this is one of the oldest parts of the system, written over a decade ago, so it was probably not a high probability that interpreted languages would be used in the system at that time. But it still was a real pain to have this float out of the miasma of reported bugs coming from the 3 sets of testing staff.)
Fortunately, Python's embedding feature saved me here; I was able to throw together a quick C++ wrapper that would call the Python script, waiting for it to exit. So now I get the monitor to start and stop it cleanly, but keep the useful parts in Python.
There is a plan to move the code more to C++, but the need to do several things that we have no C++ libraries for will keep some Python in the mix.
[Later]
Mea Culpa, Readers! I forgot to relate the moral of this story, in all my bitching and moaning.
The Lesson: When filtering results, the Software Ninja makes sure the filtering code is a) separated into an independent function, and b) make the filtering criteria very clear, so that the next developer to work on the code can change the filtering if necessary, and will understand what is being filtered out.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Subscribe to:
Comments (Atom)