I ran across this post recently, and I was dumbfounded. That any university-educated programmer would complain about Knuth's relevance. I'll agree that reading Knuth is not a walk in the park, but the foundation he brought to programming cannot be ignored. If the writer of the post were self-educated, I could see this being understandable, but he's not.
I'll admit that formal methods are a pain to do - my brief stint at grad school covered such topics as formal proofs of correctness - which I never fully grasped, and the fast pace of commercial software development rarely allows the time to use the formal ideas, but if you can't at least grasp the utility of them, you really need to consider if you have the proper attitude to develop software as a professional.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, May 26, 2008
Thursday, May 22, 2008
Employee Turnover
This is an interesting take on turnover
The Ninja question is: Where are you on the curve?
Personally, I'm starting to feel way out on the right....
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The Ninja question is: Where are you on the curve?
Personally, I'm starting to feel way out on the right....
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, May 21, 2008
Working Hard, or Hardly Worth It?
Heroics again.
IRL, I'm fighting a bundle of management-set schedules that have no relation to reality. However, I am remaining steadfast in my determination to not work overtime. Since I was not consulted as to effort when these deadlines were set, I hold that I am not responsible for the work.
Now, many will take the stance that I am being unprofessional by not working my best towards this deadline. I point to the studies that show that prolonged excess working hours lead to shoddy work. Anecdotal evidence like this also support the stance.
So when I am dragged into an unrealistic schedule, I hold to regular work hours.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
IRL, I'm fighting a bundle of management-set schedules that have no relation to reality. However, I am remaining steadfast in my determination to not work overtime. Since I was not consulted as to effort when these deadlines were set, I hold that I am not responsible for the work.
Now, many will take the stance that I am being unprofessional by not working my best towards this deadline. I point to the studies that show that prolonged excess working hours lead to shoddy work. Anecdotal evidence like this also support the stance.
So when I am dragged into an unrealistic schedule, I hold to regular work hours.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, May 19, 2008
Workaholics, or Drama Queens?
One job back, I worked for a small company that instituted an "Employee of the Month" award to help boost morale. The only 2-time winner during the existence of this award was a nice guy, and a good programmer, but he won the award for being at the office long hours and fixing problems. But those problems were ones that should have been found before they got that far. This company was rewarding heroics instead of quality. It's a common problem for software companies - the people who get rewarded are those being heroes, while those that do things right the first time get no recognition. And that's just wrong, and this explains, in one of the links.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Tuesday, May 13, 2008
Software Zealots
I'm setting a record for most posts to this blog in a week.....
One of the biggest team problems you'll run across is the zealotry for the One True Way. Editor wars, code format wars, process wars, ad nauseum.
I read this recently, and it encapsulates the entire view - everyone who holds a strong opinion about software details. But the key takeaway point is that it's almost never a good idea to rewrite something if the only reason is that "I don't like it the way it is"
Case in point, I was given responsibility over a process that needed a significant new feature. By and large, the code was moderately inbred, 10 years of tweaks and fixes. I made two significant refactorings before adding the feature - I changed the polarity of the flag variables - they used 0 to mean set (do X) and 1 to mean unset (don't do X), and changing them to be 1 for set and 0 for unset brought this process in line with the rest of the system; and I replaced 4-5 chunks of repeated code with an extracted method - so that I could clone it for the new feature, which did all the normal stuff, but with additional data to process.
The rest of the code I left alone, not even changing the brace style to suit my common style, because it was safer to not change working code.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
One of the biggest team problems you'll run across is the zealotry for the One True Way. Editor wars, code format wars, process wars, ad nauseum.
I read this recently, and it encapsulates the entire view - everyone who holds a strong opinion about software details. But the key takeaway point is that it's almost never a good idea to rewrite something if the only reason is that "I don't like it the way it is"
Case in point, I was given responsibility over a process that needed a significant new feature. By and large, the code was moderately inbred, 10 years of tweaks and fixes. I made two significant refactorings before adding the feature - I changed the polarity of the flag variables - they used 0 to mean set (do X) and 1 to mean unset (don't do X), and changing them to be 1 for set and 0 for unset brought this process in line with the rest of the system; and I replaced 4-5 chunks of repeated code with an extracted method - so that I could clone it for the new feature, which did all the normal stuff, but with additional data to process.
The rest of the code I left alone, not even changing the brace style to suit my common style, because it was safer to not change working code.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Recognizing Competence
Amazingly, someone is more pessimistic than I am about getting through to management!
It is true that many (most) managers who are not developers have little means to distinguish between good and bad developers. And to make it harder for them, the criteria that some of the responses to the link claim will help managers tell the difference are flawed - it's not always the competent developers who complain about conditions.
From the Ninja Historical Documents, I refer to one of my former colleagues. He was very vocal about all the problems our group had - schedules, technical defects, missing requirements. However, we discovered after he left that he was not nearly as good as he thought he was - a number of key pieces of our libraries that he had coded were not at all functional. So the mere appearance of competence is not enough; the managers will not have the technical chops to tell if any given developer can walk the walk.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
It is true that many (most) managers who are not developers have little means to distinguish between good and bad developers. And to make it harder for them, the criteria that some of the responses to the link claim will help managers tell the difference are flawed - it's not always the competent developers who complain about conditions.
From the Ninja Historical Documents, I refer to one of my former colleagues. He was very vocal about all the problems our group had - schedules, technical defects, missing requirements. However, we discovered after he left that he was not nearly as good as he thought he was - a number of key pieces of our libraries that he had coded were not at all functional. So the mere appearance of competence is not enough; the managers will not have the technical chops to tell if any given developer can walk the walk.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Backshoring
So with all the jobs going over to India, what are we to make of this post?
Sounds like programmers are not all interchangeable, and it takes local people who know how the product is to be used, in order to develop good software!
I think that my earlier comments on this subject are valid.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sounds like programmers are not all interchangeable, and it takes local people who know how the product is to be used, in order to develop good software!
I think that my earlier comments on this subject are valid.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Subscribe to:
Comments (Atom)