I went into management. Programming ceased to be engaging. it was easier to argue for code cleanup a couple times a year as a team lead than as a programmer because we had two people saying it would be beneficial.
Yeah, I learned the hard way that sometimes it's better to become a manager, even if you don't want to, because otherwise bad managers will make decisions for you.
Well, I don't disagree with your main point, that some code is not worth the effort of writing comprehensive unit tests.
However, it's worth pointing out that in this case, Uncle Bob suggests writing a stub function right before the command goes to the machine.
I have no understanding of your code base though, so I'm not telling you what to do; I have confidence in your coding ability.
Lisp is really great I won't deny, and macros are without a doubt better than C++ style generic programming, but writing hygienic macros in Lisp is still a pain. We'll say almost readable syntax.
And Smalltalk is without a doubt worth looking into. The best way IMO is to check out Squeak and play with it (there's a tutorial).
And lets not forget Logic Programming. Did I miss any?
Stack based programming, table oriented programming, probably more lol
Personally, I think Smalltalk does a nice job of finding the balance between the various methodologies.
Unit tests or no, you're still going to get lousy code from lousy programmers, and good code from good programmers (I think that is the point you were trying to make).
I contend that one can always learn to think more clearly, and if one is constantly doing so then one's code will constantly be less clear than one is capable of writing.
You are right, but there's a point where you are 'good enough'. Let me give an analogy:
Traffic going onto the freeway can be bad, and if it gets too bad, then suddenly there is a slowdown, or even traffic jam. If the traffic is clear, then you can go the speed limit. The traffic can become more clear, but there is a point where it's "good enough."
Of course, you should ask, "When is it 'clear enough' in software development?" I think Jim Shore has the answer. When your code is clean enough that you can operate in the sort of 'no bug' environment he describes, then there is still room for improvement, but you write good code at that point.
The Peter principal says that all 'professional' programmers will be asked to do things more and more complicated.
Donald Knuth discussed this, and said that you keep doing harder and hard things, things you've never done before, and that is why you can't write perfect code.
The upside is, your skills keep getting better, and that's what keeps programming fun.
In practice, you'll probably just end up writing yet more web services.
One of the checks I do is to have a non-programmer just READ my code. If they can make any sense of it (Think variable and function names) then I continue.
If you inherit someone else's mess, and your team is really good (because if your team is not good, your first priority needs to be training them, otherwise they'll just write even more bad code), then the answer is to encapsulate the ugliness and move on.
If you are working in a section of code, spend a little time clean it up, since you'll have to test it anyway. Make sure you understand the implications of every line you change (yeah, that's slow). Over time, the sections you work with a lot will become very clean, and you'll be able to work with the code easily and quickly.
A constant need to refactor is a sign that something is wrong.
Let me offer a counter point: abstracting, wrapping, deferring, and hiding those black boxes can often lead you to building abstractions and interfaces which promise more than the underlying code can deliver, or which are outright not compatible with it.
If you run screaming from your real code so you can add a layer of code which allows you to pretend like you know what code you have, sooner or later you do something monumentally STUPID.
You are right, and the GP is also right.
The reality is, people who write bad code will write bad code, no matter what 'strategy' they use (and those people will typically use the wrong strategy, too).
When programmers aren't asking themselves, "how can I write readable code?" then you can be sure their code won't be readable, even when they follow all the guidelines.
Also, if the programmers on your team are writing bad code, you either need to teach them to do better or leave the company because it doesn't matter how brilliant you are, you can't clean faster than the other programmers make a mess.
When your question gets closed on Stack Overflow, then try to ask it on Slashdot?
Frankly, if your code is constantly getting out of control and becoming unreadable, you are not doing professional work, you are doing amateur work (and yes, I know that there are plenty of paid professionals who do amateur work. We've seen stories from Trend Micro programmers here recently on Slashdot).
It's not a set of rules to follow. If there were a mindless algorithm to follow, then a computer could do it. Instead, when you are about to write code, always ask yourself, "How can I write this in a way that future programmers can understand it?"
We've seen a lot of failure-mode problems lately, to me this points to a lack of quality assurance testing.
If you want high-quality software, you need to start with teaching even junior developers how to do it. Otherwise QA will just be overwhelmed, and management will release without getting rid of all the bugs.
We have all these development methodologies like agile, XP, scrum, waterfall, that are focused on what managers should do, and what kind of meeting you should have, etc, but we need to focus on making the individual programmers better. Then you won't need managers.
"We use Debian. Do you know anything about Debian?", he asked.
I replied "did you see that Debian security alert about an hour ago?"
"Yeah, this one right here?" he said as he opened the email.
Looking at the first line of the email, he saw it said "Ray Morris discovered a vulnerability..."
Suddenly he seemed less concerned about my knowledge of Debian.:)
It's also worth pointing out that "responsible disclosure" time is only a problem with closed source software.
With open source software, you can release a patch with the disclosure. Yet another reason to favor open source over closed.
If a company is (arguably) already treating security reasonably seriously, then spreading details on how to hurt their customers does not achieve anything.
That kind of assumes there aren't malicious people already exploiting the bug.
Sometimes it's better to let people know so they can defend themselves: either by closing a port, changing a configuration, turning off a service, fixing the bugs themselves and recompiling, or switching to another software system.
Of course, corporations don't like the last two options, but being able to recompile is a very real benefit of open source software.
scale out to pan-galactic levels, include a cryptographic signature and be directly transliterable across every language, including Klingon, ancient Egyptian hieroglyphics and the language of a tribe in the Amazon basin that only uses clicks and whistles and writes only by stacking the skulls of its enemies.
Slashdot Mirror
I went into management. Programming ceased to be engaging. it was easier to argue for code cleanup a couple times a year as a team lead than as a programmer because we had two people saying it would be beneficial.
Yeah, I learned the hard way that sometimes it's better to become a manager, even if you don't want to, because otherwise bad managers will make decisions for you.
Well, I don't disagree with your main point, that some code is not worth the effort of writing comprehensive unit tests.
However, it's worth pointing out that in this case, Uncle Bob suggests writing a stub function right before the command goes to the machine.
I have no understanding of your code base though, so I'm not telling you what to do; I have confidence in your coding ability.
Yeah, to be honest, in my experience, technical debt largely increases as developer competence decreases.
Yeah, I think that's true.
Lisp is really great I won't deny, and macros are without a doubt better than C++ style generic programming, but writing hygienic macros in Lisp is still a pain. We'll say almost readable syntax.
And Smalltalk is without a doubt worth looking into. The best way IMO is to check out Squeak and play with it (there's a tutorial).
Some of the good techniques in some domains are really awful ideas in other domains.
As a Python programmer, I used to disagree with you, but lately I've found my C++ code is much more flexible since I added some braces.
That's a good point, too. You kind of have to draw a line in your mind, "This is affected by the change......That is not affected by the change."
And lets not forget Logic Programming. Did I miss any?
Stack based programming, table oriented programming, probably more lol
Personally, I think Smalltalk does a nice job of finding the balance between the various methodologies.
Unit tests or no, you're still going to get lousy code from lousy programmers, and good code from good programmers (I think that is the point you were trying to make).
I contend that one can always learn to think more clearly, and if one is constantly doing so then one's code will constantly be less clear than one is capable of writing.
You are right, but there's a point where you are 'good enough'. Let me give an analogy:
Traffic going onto the freeway can be bad, and if it gets too bad, then suddenly there is a slowdown, or even traffic jam. If the traffic is clear, then you can go the speed limit. The traffic can become more clear, but there is a point where it's "good enough."
Of course, you should ask, "When is it 'clear enough' in software development?" I think Jim Shore has the answer. When your code is clean enough that you can operate in the sort of 'no bug' environment he describes, then there is still room for improvement, but you write good code at that point.
The Peter principal says that all 'professional' programmers will be asked to do things more and more complicated.
Donald Knuth discussed this, and said that you keep doing harder and hard things, things you've never done before, and that is why you can't write perfect code.
The upside is, your skills keep getting better, and that's what keeps programming fun.
In practice, you'll probably just end up writing yet more web services.
One of the checks I do is to have a non-programmer just READ my code. If they can make any sense of it (Think variable and function names) then I continue.
That's a really good idea.
but during non-peak times (like the week between Christmas and New Years) when stuff is slow
Best week of the year because no one is there, and you can work on whatever you want.
If you inherit someone else's mess, and your team is really good (because if your team is not good, your first priority needs to be training them, otherwise they'll just write even more bad code), then the answer is to encapsulate the ugliness and move on.
If you are working in a section of code, spend a little time clean it up, since you'll have to test it anyway. Make sure you understand the implications of every line you change (yeah, that's slow). Over time, the sections you work with a lot will become very clean, and you'll be able to work with the code easily and quickly.
A constant need to refactor is a sign that something is wrong.
This line of thinking implies that one never improves
No. Please read the part where I wrote, "Learn to think clearly."
Let me offer a counter point: abstracting, wrapping, deferring, and hiding those black boxes can often lead you to building abstractions and interfaces which promise more than the underlying code can deliver, or which are outright not compatible with it. If you run screaming from your real code so you can add a layer of code which allows you to pretend like you know what code you have, sooner or later you do something monumentally STUPID.
You are right, and the GP is also right. The reality is, people who write bad code will write bad code, no matter what 'strategy' they use (and those people will typically use the wrong strategy, too).
When programmers aren't asking themselves, "how can I write readable code?" then you can be sure their code won't be readable, even when they follow all the guidelines.
Also, if the programmers on your team are writing bad code, you either need to teach them to do better or leave the company because it doesn't matter how brilliant you are, you can't clean faster than the other programmers make a mess.
I think the code is a representation of the person. People who think clearly write clear code. Learn to think clearly.
When your question gets closed on Stack Overflow, then try to ask it on Slashdot?
Frankly, if your code is constantly getting out of control and becoming unreadable, you are not doing professional work, you are doing amateur work (and yes, I know that there are plenty of paid professionals who do amateur work. We've seen stories from Trend Micro programmers here recently on Slashdot).
It's not a set of rules to follow. If there were a mindless algorithm to follow, then a computer could do it. Instead, when you are about to write code, always ask yourself, "How can I write this in a way that future programmers can understand it?"
We've seen a lot of failure-mode problems lately, to me this points to a lack of quality assurance testing.
If you want high-quality software, you need to start with teaching even junior developers how to do it. Otherwise QA will just be overwhelmed, and management will release without getting rid of all the bugs.
We have all these development methodologies like agile, XP, scrum, waterfall, that are focused on what managers should do, and what kind of meeting you should have, etc, but we need to focus on making the individual programmers better. Then you won't need managers.
Microsoft already allows this capability, you need to search better. Here are the instructions, although I prefer these.
Step 4: Now my boxes are actually getting exploited, and they mostly weren't before.
You hope.
I assume you're referring to this exchange?
"We use Debian. Do you know anything about Debian?", he asked. ..." :)
I replied "did you see that Debian security alert about an hour ago?"
"Yeah, this one right here?" he said as he opened the email.
Looking at the first line of the email, he saw it said "Ray Morris discovered a vulnerability
Suddenly he seemed less concerned about my knowledge of Debian.
That is awesome. You are awesome.
It's also worth pointing out that "responsible disclosure" time is only a problem with closed source software.
With open source software, you can release a patch with the disclosure. Yet another reason to favor open source over closed.
If a company is (arguably) already treating security reasonably seriously, then spreading details on how to hurt their customers does not achieve anything.
That kind of assumes there aren't malicious people already exploiting the bug.
Sometimes it's better to let people know so they can defend themselves: either by closing a port, changing a configuration, turning off a service, fixing the bugs themselves and recompiling, or switching to another software system.
Of course, corporations don't like the last two options, but being able to recompile is a very real benefit of open source software.
scale out to pan-galactic levels, include a cryptographic signature and be directly transliterable across every language, including Klingon, ancient Egyptian hieroglyphics and the language of a tribe in the Amazon basin that only uses clicks and whistles and writes only by stacking the skulls of its enemies.
Huh.....that actually does sound kind of good.