Bullshit! GS survived because they have Paulson as the treasury secretary. [...] but when the target became GS the government stepped in and banned short-selling (among a lot of other things)
Do you have any evidence for this? Goldman Sachs was the most highly regarded of the investment banks well before Paulson. And plenty of financial companies were smart enough to stay relatively clean from this, in that they managed their risks a lot better.
A more reasonably narrative to me is the one in in the financial press. They saved Bear because it was sudden, but then let Lehman go because they were worried about moral hazard. Then they saved AIG because of the systemic risk. And then, realizing they were up to their ass in alligators, then went to congress for the bailout authority to calm everybody down.
Based on what Buffet has said it sounds like the government tapped him and begged him to get in the market to instill some confidence.
That sounds more plausible, but I'd also like to see your source for that.
Still, that's exactly what the Treasury and the Fed should be doing about now. A lot of people are scared just because other people are scared, and not because they know much of anything.
That Buffett was encouraged to invest doesn't mean that he doesn't think it was a good idea. It's not like they can push him around. Sure, he was betting on the bailout, but everybody was betting one way or another on a bailout, which is why you saw the 777 point drop when it failed the first time.
The speaker? Some guy named Henry Paulson, the then-CEO of Goldman Sachs. I wonder what happened to him."
I'll just point out that Goldman has done reasonably well in all this, and that's probably because they did have good risk models. Warren Buffett recently invested in them, and he's one of the sharpest value investors out there.
Paulson's statement was broadly correct: what matters is the risk, not purely the leverage, and a fixed ratio for everybody did indeed give a less efficient use of capital.
Where things fell down wasn't the theory, it was the practice. The SEC, which has been a sharp and disciplined regulator for ages, apparently went out to lunch during the Bush administration, and specifically never followed up on this.
For a nice take on the SEC's abdication check out the "This American Life" episode "Enforcers". Not only does it have a great piece on the people tricking Nigerian scammers for fun, but the bit on the lameness of the SEC is very well done.
It's fairly common for companies to have large loans secured by a deposit of stock.
Could you show some references on that? I've seen loans with warrants, or loans secured with the stock of other companies, but I've never heard of a loan secured with the company's own publicly traded stock.
The company won't be able to raise capital, it won't meet loan requirements, and it will have no choice but to declare bankruptcy.
Please point me at some mainstream business press articles describing this happening.
As every fool knows, an increase in supply causes the price to drop. [...] Naked short sales completely destroy the relationship between supply and demand.
That's true only for sufficiently large quantities of naked shorting. Otherwise, it's a minor accounting issue. Do you have evidence that this is an actual problem? Or could it be just a theoretical one?
Personally, I'd be surprised if it's a big deal. If you're trading, your trades are going through a clearing firm. I haven't been involved the industry in more than a decade, but clearing firms always kept a very careful eye on outstanding obligations to make sure that you wouldn't blow up, as it's the clearing firm that has to clean up the mess. Somebody doing a huge volume of naked shorting is terribly vulnerable to a short squeeze, and those are very, very expensive.
. Pretty soon the share price has crashed, the company faces bankruptcy, but the perpetrators can easily cover their position at bottom dollar making millions.
Why would you be bankrupt if your stock value drops? Bankruptcy sure can impact your stock price, but it shouldn't go the other way around, as that's an imbalance between assets and liabilities.
Your argument seems to hinge upon the notion that without shorting stocks would be overpriced, and that thanks to shorting they are not. I refer you to every financial bubble in the last century as proof that stocks are quite capable of becoming overpriced despite the best efforts of shorting to keep them 'fair'.
You misunderstand him. Shorting stocks reduces the level of pricing error. Nothing can eliminate it. Shorting can't really help an asset bubble, as shorting a stock is generally a short-term, individual move, and bubbles are by definition long-term system problem.
then they would be easily replaced by direct investment with individual companies by individual and institutional investors with an actual interest in the productivity and profitability of the companies in question.
And your evidence for this is what? As a direct investor in a few companies, and as somebody who works a lot with venture-funded startups, it sounds entirely implausible to me.
even if the system were slightly less efficient, the difference would simply be paid for out of the pockets of wealthy investors who currently clean up to the tune of $500 billion or more each year. Companies and their employees in the working and middle class would almost certainly be unaffected, or actually be better off in the final analysis.
There you're entirely wrong.
If your proposed system is less efficient (and I think it would be much more than "slightly"), then I see two obvious effects. First, there is less capital available. Second, that capital is less liquid.
Less capital available means fewer people who want loans to expand their businesses get them, meaning lower economic growth. And those who do get those loans have to pay a higher price for them. That means a greater proportion of the value created goes to the people with the capital, the opposite effect you'd expect.
The lower liquidity gets you other problems. First, if people can't easily get their money out, they'll be less likely to put it in, further driving down growth and raising the cost of capital. Second, you can't really reward most employees with stock, as then they can't sell, or at best can sell to a very limited group. Third, investors who need cash won't be able to get it just by selling shares on the open market, so they'll be more likely to press the company to pay dividends, keeping them cash-poor and limiting opportunity for growth.
No, it's really synchronous. That's how they can afford to do it cheaply. It works like this:
Suppose you want to download a video. For every packet of the video you download, you need to upload one. Now naturally, you can't upload somebody else's copyrighted content. So you have to upload original video content that somebody else wants to watch.
The main sponsors of the rollout are porn companies, because that's the only kind of marketable content most people can create. Some camwhores will probably do all right, too. And if you live in an interesting neighborhood, you can put up some webcams to meet the synchronous data requirement.
Most people, though, won't be able to generate enough content, so they'll have to pay extra to get the synchronous requirement waved. It's sort of like how cellphone companies sell you a cheap plan, knowing they'll screw you on extras.
You know, I wrote you most of a response, and then I realized you were just being, for whatever reason, intentionally obtuse.
Apple is obviously being a lot more proprietary and control-freaky than Google is. And just as obviously, Google is going out of their way to attract a much wider base of developers.
I agree that for some people, dealing with the Apple shenanigans makes a lot of sense. Godspeed to all those people. But denying that the shenanigans exist or matter is idiocy, and doesn't leave you with much credibility, at least not for me.
All those tales of lone hackers coding all week on coffee, Jolt cola, cold pizza, pot stickers, and hot and sour soup are romantic and inspiring. They're stories about great people getting stuff done against the odds, though.
That's a great point. And it's important to remember that stories like that only matter when external circumstances necessitate heroics. In my career, about 98% of the heroics I've seen are unnecessary bullshit that could have been avoided with a little forethought. And easily 90% are in response to problems that the "heroes" helped create.
If you save somebody from a burning building, you're a hero. If you keep saving people from the same burning buildings where you keep storing gasoline cans near furnaces, then you're a dangerous lunatic.
One of the best ways to do this is to release early and often, and then pay attention to what happens. Study usage statistics. Observe people using your stuff. Ask people what they think, and set your natural pride and defensiveness aside to really listen.
Always remember that your work isn't to write code; it's to make the computer serve others. The more frequently you get feedback, the faster you can get to that end.
I want to make one point. *any* code is unmanageable if you don't comment
I disagree strongly. I think the important thing is to make your code easy to understand. Comments should be a last resort.
As an analogy, consider your MP3 player. Suppose that every time they struggled with a UI decision, they just decided to put something in a manual or on a sticker on the back. It would be an abomination. The right approach is to make it so that as much as possible, instructions aren't necessary.
When I'm coding, I'll first try to put information in names, like variable and method names. Next I'll try to extract methods or objects, so as to minimize complexity. Then I'll worry about interface and object names. And I put a lot of information in readable unit tests, as that's a kind of documentation that the computer can verify still is valid. Documentation is always a last resort.
I have to deal with a lot of other people's code, and I'll always take beautifully polished code with no docs over mediocre code with lots of docs.
There is no excuse however for Java's longer method names.
ProTip: Nobody types those method names out anymore. Enter the mid-90s and get an IDE with autocomplete.
Yes, vi and EMACS are awesome monuments to 1970s technology, and I also love them. But I'd no more use them for professional coding than I would wear a 1970s polyester leisure suit to a funeral. The tools have moved on, and so should you. I use IntelliJ's IDEA, but Eclipse is an acceptable second best, and it's free.
Funny, I always thought of Apple as a walled off isolationistic company. Where have you been?
I think it depends on what part of their history you look at. The Apple I and II were all about computing for the people, tearing down the walls of IBM's Temple of Data Processing. And they have traded on that image quite a bit, as with their classic 1984 Mac ad.
They've also had waves of openness historically. Some of their machines, like the original Mac, were totally sealed boxes. But some were very open from a hardware perspective. Their documentation has always been very public, and their human interface guidelines were a great example to the wider world. They even had their own Unix variant as early as '88, A/UX. And of course, at one point they opened up enough that they were licensing Mac clones.
Jobs's other company, NeXT, also went through waves of openness. They started pretty closed, but eventually had what is now MacOS running on commodity Intel hardware. And for a while they sold cross-platform app development tools, so you could create Objective-C, Inteface Builder apps for both the NeXT OS and Windows NT. It was great stuff.
As far as I can tell, the pattern is that Jobs's first instinct is to control everything (to a degree far greater than Gates ever cared about). Then, when Jobs gets into hot water, or when it's convenient for him, he opens things up and sings a song of openness and opposition to The Man that is in line with Apple's artsy, iconoclastic marketing image.
"Apple makes you use Apple stuff." Boo-hoo. Does that surprise anyone
It both surprises and disappoints me. When the iPhone came out with their new location-aware APIs, I was very excited. I had some things I wanted to build. But a decent Mac development box was at least $2k, and then I'd have to sign a $2k contract to get ahold of an iPhone. Then I'd have to sign yet more absurd contracts to get the apps to users, and if they didn't like my app for any reason, they could say no, and now they won't even let people bitch about it. It's ridiculous.
With Google, on the other hand, I can use hardware and tools I already have and like. T-Mobile has already said they'll sell a contractless version of the phone, so I'm not on the hook for two years of monthly bills just to play with it. And there will soon be other phones on other networks, so I'll have more options.
Steve Jobs makes some nice stuff, but he doesn't shit rainbows, and especially since he's screwed over developers in the past, I resent him acting like a god-king whom we all must trust and obey, even if all we want to do is knock out a couple fun apps.
I can see why this bothers people, but the ease of releasing new software really has changed something. I've got friends who release new features once or twice a week. And users on the web are pretty tolerant of using something with an initially low level of features as long as it's good for something and there is steady improvement.
This means that if we're going to use the old terms, then we either have to change "released" or "beta". Using "beta" to mean "still not where we want it" seems reasonable to me, so that people get their expectations set properly.
Re:You had me right up to "Agile."
on
Clean Code
·
· Score: 1
For some reason, whenever I see that word in reference to programming, I want to run screaming in the opposite direction. Does that make me a bad person?
I'd say it means you've had managers.
There's no denying "Agile" is a fad, and a lot of people are doing fake-Agile, where they adopt some buzzwords and then carry on doing shitty work.
Luckily for me, I got interested in it before it was popular, so I don't have the same natural aversion. Personally, I've found a lot of value in the approach. For me, it has totally ended arguments about what's in scope, what the spec is, and whether or not a change is allowed. I no longer work to arbitrary dates, and I produce code I'm generally proud of. I've got some issues with it, and especially with the fad, but overall, I'm pretty happy with agile approaches.
Re:Is it professional to cheat your boss?
on
Clean Code
·
· Score: 4, Interesting
I totally agree with Bob Martin here.
Suppose I go into the doctor and say, "I'm tired and not getting enough done. Please give me a bucket of amphetamines." The doctor will say no, as that would be likely to cause harm, followed by death. Instead, they'll try to figure out what's really going on, and help me appropriately. That's what professionals do.
If a boss comes to me and tells me that for the new banking software they'd like me to skip testing, exception handling, and error logging, I'll say no. Instead, I'll ask them what their real goal is, and suggest ways they can achieve that.
Over and over I see developers offering to write unmaintainable garbage, only to get in hot water in a year's time because productivity is in the toilet. It's not even fun the first time, but people keep on doing it. They should stop.
Re:Depends on function
on
Clean Code
·
· Score: 4, Insightful
related code" [sic] are NOT opposites. In fact, I have seen a huge number of situations where I sped something up by cleaning out the code.
I know what you mean, but the guy has a point. I have also often sped things up by removing "performance improvements" that some dolt had added because he thought he was being clever.
My view, which I guess you'd agree with, is that it's best to start with clean, simple code. Usually, that's plenty fast. If performance tests prove that you have a problem, and a profiler shows you the source of the problem, only then should you sacrifice clarity for speed. And you should only do just enough to meet your performance goals.
But every now and again, high WTF/minute is a sign of absolute genius. Like a lot of really cool Haskell code. Or wicked perl.
I think that depends on why you're coding. If you're writing code in the spirit that people write poetry, that's fab. Or if you're dealing with a performance-critical section that can't work any other way, then sure, that's fine.
But for most code (and more and more all the time), maintenance cost vastly overwhelms other factors. Real geniuses get the job done in a way that will last over the long haul.
I think a better way to look at this is that at the time you couldn't think of a better way. Often I've come back to a problem later and found some better abstraction. Or asked a colleague who has a nice trick to sort things out.
On some days, I think the the main job of a programmer is to hide the ugliness as well as possible. The code bases that really scare me are the ones where people have admitted defeat and let the ugliness seep everywhere.
Re:Is the problem one of craft or mentality?
on
Clean Code
·
· Score: 5, Insightful
Put another way, the kind of engineer that would actually benefit from a book like this, has probably already read a book like this.
I think you've created a false dichotomy.
I haven't read this book yet (although Bob Martin's other stuff is great), but back at the dawn of time, I was working with a team that was all relatively young. When McConnell's "Code Complete" came out, we all went through it pretty excitedly.
Although we had the right spirit, and we each could have named some of the things in the book, none of us could have articulated all of them. And there were a lot of subtleties that we had never thought of.
So I'd agree that jerks won't read this and nice graybeards don't need to, there are plenty of people who are perfectly nice that haven't perfected their craft yet. They can use this book.
Maybe the bubble has generated people who think they don't need to know anything but still be valuable?
One of the best things about Bubble 1.0 bursting was the number of "HTML Programmers" with 6 months experience who were forced to go out and get jobs that they actually liked, understood, and were good at. Sure, those jobs didn't pay as well, but real jobs never pay as much as fantasy-land jobs.
It was really a relief to me, as there was a point where I was having a hard time not sending snarky replies to the painfully clueless.
Slashdot Mirror
Bullshit! GS survived because they have Paulson as the treasury secretary. [...] but when the target became GS the government stepped in and banned short-selling (among a lot of other things)
Do you have any evidence for this? Goldman Sachs was the most highly regarded of the investment banks well before Paulson. And plenty of financial companies were smart enough to stay relatively clean from this, in that they managed their risks a lot better.
A more reasonably narrative to me is the one in in the financial press. They saved Bear because it was sudden, but then let Lehman go because they were worried about moral hazard. Then they saved AIG because of the systemic risk. And then, realizing they were up to their ass in alligators, then went to congress for the bailout authority to calm everybody down.
Based on what Buffet has said it sounds like the government tapped him and begged him to get in the market to instill some confidence.
That sounds more plausible, but I'd also like to see your source for that.
Still, that's exactly what the Treasury and the Fed should be doing about now. A lot of people are scared just because other people are scared, and not because they know much of anything.
That Buffett was encouraged to invest doesn't mean that he doesn't think it was a good idea. It's not like they can push him around. Sure, he was betting on the bailout, but everybody was betting one way or another on a bailout, which is why you saw the 777 point drop when it failed the first time.
The speaker? Some guy named Henry Paulson, the then-CEO of Goldman Sachs. I wonder what happened to him."
I'll just point out that Goldman has done reasonably well in all this, and that's probably because they did have good risk models. Warren Buffett recently invested in them, and he's one of the sharpest value investors out there.
Paulson's statement was broadly correct: what matters is the risk, not purely the leverage, and a fixed ratio for everybody did indeed give a less efficient use of capital.
Where things fell down wasn't the theory, it was the practice. The SEC, which has been a sharp and disciplined regulator for ages, apparently went out to lunch during the Bush administration, and specifically never followed up on this.
For a nice take on the SEC's abdication check out the "This American Life" episode "Enforcers". Not only does it have a great piece on the people tricking Nigerian scammers for fun, but the bit on the lameness of the SEC is very well done.
It's fairly common for companies to have large loans secured by a deposit of stock.
Could you show some references on that? I've seen loans with warrants, or loans secured with the stock of other companies, but I've never heard of a loan secured with the company's own publicly traded stock.
The company won't be able to raise capital, it won't meet loan requirements, and it will have no choice but to declare bankruptcy.
Please point me at some mainstream business press articles describing this happening.
Companies issue dividends when they have excess capital, not when their capital is being vaporized.
Are you sure you know what you're talking about?
Companies issue dividends when they have excess cash, not capital. And their stock price going down leaves them with the exact same amount of capital.
As every fool knows, an increase in supply causes the price to drop. [...] Naked short sales completely destroy the relationship between supply and demand.
That's true only for sufficiently large quantities of naked shorting. Otherwise, it's a minor accounting issue. Do you have evidence that this is an actual problem? Or could it be just a theoretical one?
Personally, I'd be surprised if it's a big deal. If you're trading, your trades are going through a clearing firm. I haven't been involved the industry in more than a decade, but clearing firms always kept a very careful eye on outstanding obligations to make sure that you wouldn't blow up, as it's the clearing firm that has to clean up the mess. Somebody doing a huge volume of naked shorting is terribly vulnerable to a short squeeze, and those are very, very expensive.
. Pretty soon the share price has crashed, the company faces bankruptcy, but the perpetrators can easily cover their position at bottom dollar making millions.
Why would you be bankrupt if your stock value drops? Bankruptcy sure can impact your stock price, but it shouldn't go the other way around, as that's an imbalance between assets and liabilities.
Your argument seems to hinge upon the notion that without shorting stocks would be overpriced, and that thanks to shorting they are not. I refer you to every financial bubble in the last century as proof that stocks are quite capable of becoming overpriced despite the best efforts of shorting to keep them 'fair'.
You misunderstand him. Shorting stocks reduces the level of pricing error. Nothing can eliminate it. Shorting can't really help an asset bubble, as shorting a stock is generally a short-term, individual move, and bubbles are by definition long-term system problem.
then they would be easily replaced by direct investment with individual companies by individual and institutional investors with an actual interest in the productivity and profitability of the companies in question.
And your evidence for this is what? As a direct investor in a few companies, and as somebody who works a lot with venture-funded startups, it sounds entirely implausible to me.
even if the system were slightly less efficient, the difference would simply be paid for out of the pockets of wealthy investors who currently clean up to the tune of $500 billion or more each year. Companies and their employees in the working and middle class would almost certainly be unaffected, or actually be better off in the final analysis.
There you're entirely wrong.
If your proposed system is less efficient (and I think it would be much more than "slightly"), then I see two obvious effects. First, there is less capital available. Second, that capital is less liquid.
Less capital available means fewer people who want loans to expand their businesses get them, meaning lower economic growth. And those who do get those loans have to pay a higher price for them. That means a greater proportion of the value created goes to the people with the capital, the opposite effect you'd expect.
The lower liquidity gets you other problems. First, if people can't easily get their money out, they'll be less likely to put it in, further driving down growth and raising the cost of capital. Second, you can't really reward most employees with stock, as then they can't sell, or at best can sell to a very limited group. Third, investors who need cash won't be able to get it just by selling shares on the open market, so they'll be more likely to press the company to pay dividends, keeping them cash-poor and limiting opportunity for growth.
No, it's really synchronous. That's how they can afford to do it cheaply. It works like this:
Suppose you want to download a video. For every packet of the video you download, you need to upload one. Now naturally, you can't upload somebody else's copyrighted content. So you have to upload original video content that somebody else wants to watch.
The main sponsors of the rollout are porn companies, because that's the only kind of marketable content most people can create. Some camwhores will probably do all right, too. And if you live in an interesting neighborhood, you can put up some webcams to meet the synchronous data requirement.
Most people, though, won't be able to generate enough content, so they'll have to pay extra to get the synchronous requirement waved. It's sort of like how cellphone companies sell you a cheap plan, knowing they'll screw you on extras.
You know, I wrote you most of a response, and then I realized you were just being, for whatever reason, intentionally obtuse.
Apple is obviously being a lot more proprietary and control-freaky than Google is. And just as obviously, Google is going out of their way to attract a much wider base of developers.
I agree that for some people, dealing with the Apple shenanigans makes a lot of sense. Godspeed to all those people. But denying that the shenanigans exist or matter is idiocy, and doesn't leave you with much credibility, at least not for me.
Try to right program code comments as much as possible as long as memory permits it (if you do have a memory cap).
Are there actually people who have had a problem this decade with this? Sure, when I had 4k of RAM, this was an issue for me, but now?
All those tales of lone hackers coding all week on coffee, Jolt cola, cold pizza, pot stickers, and hot and sour soup are romantic and inspiring. They're stories about great people getting stuff done against the odds, though.
That's a great point. And it's important to remember that stories like that only matter when external circumstances necessitate heroics. In my career, about 98% of the heroics I've seen are unnecessary bullshit that could have been avoided with a little forethought. And easily 90% are in response to problems that the "heroes" helped create.
If you save somebody from a burning building, you're a hero. If you keep saving people from the same burning buildings where you keep storing gasoline cans near furnaces, then you're a dangerous lunatic.
Excellent points. One amplification:
Listen to your end users.
One of the best ways to do this is to release early and often, and then pay attention to what happens. Study usage statistics. Observe people using your stuff. Ask people what they think, and set your natural pride and defensiveness aside to really listen.
Always remember that your work isn't to write code; it's to make the computer serve others. The more frequently you get feedback, the faster you can get to that end.
I want to make one point. *any* code is unmanageable if you don't comment
I disagree strongly. I think the important thing is to make your code easy to understand. Comments should be a last resort.
As an analogy, consider your MP3 player. Suppose that every time they struggled with a UI decision, they just decided to put something in a manual or on a sticker on the back. It would be an abomination. The right approach is to make it so that as much as possible, instructions aren't necessary.
When I'm coding, I'll first try to put information in names, like variable and method names. Next I'll try to extract methods or objects, so as to minimize complexity. Then I'll worry about interface and object names. And I put a lot of information in readable unit tests, as that's a kind of documentation that the computer can verify still is valid. Documentation is always a last resort.
I have to deal with a lot of other people's code, and I'll always take beautifully polished code with no docs over mediocre code with lots of docs.
There is no excuse however for Java's longer method names.
ProTip: Nobody types those method names out anymore. Enter the mid-90s and get an IDE with autocomplete.
Yes, vi and EMACS are awesome monuments to 1970s technology, and I also love them. But I'd no more use them for professional coding than I would wear a 1970s polyester leisure suit to a funeral. The tools have moved on, and so should you. I use IntelliJ's IDEA, but Eclipse is an acceptable second best, and it's free.
Funny, I always thought of Apple as a walled off isolationistic company. Where have you been?
I think it depends on what part of their history you look at. The Apple I and II were all about computing for the people, tearing down the walls of IBM's Temple of Data Processing. And they have traded on that image quite a bit, as with their classic 1984 Mac ad.
They've also had waves of openness historically. Some of their machines, like the original Mac, were totally sealed boxes. But some were very open from a hardware perspective. Their documentation has always been very public, and their human interface guidelines were a great example to the wider world. They even had their own Unix variant as early as '88, A/UX. And of course, at one point they opened up enough that they were licensing Mac clones.
Jobs's other company, NeXT, also went through waves of openness. They started pretty closed, but eventually had what is now MacOS running on commodity Intel hardware. And for a while they sold cross-platform app development tools, so you could create Objective-C, Inteface Builder apps for both the NeXT OS and Windows NT. It was great stuff.
As far as I can tell, the pattern is that Jobs's first instinct is to control everything (to a degree far greater than Gates ever cared about). Then, when Jobs gets into hot water, or when it's convenient for him, he opens things up and sings a song of openness and opposition to The Man that is in line with Apple's artsy, iconoclastic marketing image.
"Apple makes you use Apple stuff." Boo-hoo. Does that surprise anyone
It both surprises and disappoints me. When the iPhone came out with their new location-aware APIs, I was very excited. I had some things I wanted to build. But a decent Mac development box was at least $2k, and then I'd have to sign a $2k contract to get ahold of an iPhone. Then I'd have to sign yet more absurd contracts to get the apps to users, and if they didn't like my app for any reason, they could say no, and now they won't even let people bitch about it. It's ridiculous.
With Google, on the other hand, I can use hardware and tools I already have and like. T-Mobile has already said they'll sell a contractless version of the phone, so I'm not on the hook for two years of monthly bills just to play with it. And there will soon be other phones on other networks, so I'll have more options.
Steve Jobs makes some nice stuff, but he doesn't shit rainbows, and especially since he's screwed over developers in the past, I resent him acting like a god-king whom we all must trust and obey, even if all we want to do is knock out a couple fun apps.
I can see why this bothers people, but the ease of releasing new software really has changed something. I've got friends who release new features once or twice a week. And users on the web are pretty tolerant of using something with an initially low level of features as long as it's good for something and there is steady improvement.
This means that if we're going to use the old terms, then we either have to change "released" or "beta". Using "beta" to mean "still not where we want it" seems reasonable to me, so that people get their expectations set properly.
For some reason, whenever I see that word in reference to programming, I want to run screaming in the opposite direction. Does that make me a bad person?
I'd say it means you've had managers.
There's no denying "Agile" is a fad, and a lot of people are doing fake-Agile, where they adopt some buzzwords and then carry on doing shitty work.
Luckily for me, I got interested in it before it was popular, so I don't have the same natural aversion. Personally, I've found a lot of value in the approach. For me, it has totally ended arguments about what's in scope, what the spec is, and whether or not a change is allowed. I no longer work to arbitrary dates, and I produce code I'm generally proud of. I've got some issues with it, and especially with the fad, but overall, I'm pretty happy with agile approaches.
I totally agree with Bob Martin here.
Suppose I go into the doctor and say, "I'm tired and not getting enough done. Please give me a bucket of amphetamines." The doctor will say no, as that would be likely to cause harm, followed by death. Instead, they'll try to figure out what's really going on, and help me appropriately. That's what professionals do.
If a boss comes to me and tells me that for the new banking software they'd like me to skip testing, exception handling, and error logging, I'll say no. Instead, I'll ask them what their real goal is, and suggest ways they can achieve that.
Over and over I see developers offering to write unmaintainable garbage, only to get in hot water in a year's time because productivity is in the toilet. It's not even fun the first time, but people keep on doing it. They should stop.
related code" [sic] are NOT opposites. In fact, I have seen a huge number of situations where I sped something up by cleaning out the code.
I know what you mean, but the guy has a point. I have also often sped things up by removing "performance improvements" that some dolt had added because he thought he was being clever.
My view, which I guess you'd agree with, is that it's best to start with clean, simple code. Usually, that's plenty fast. If performance tests prove that you have a problem, and a profiler shows you the source of the problem, only then should you sacrifice clarity for speed. And you should only do just enough to meet your performance goals.
But every now and again, high WTF/minute is a sign of absolute genius. Like a lot of really cool Haskell code. Or wicked perl.
I think that depends on why you're coding. If you're writing code in the spirit that people write poetry, that's fab. Or if you're dealing with a performance-critical section that can't work any other way, then sure, that's fine.
But for most code (and more and more all the time), maintenance cost vastly overwhelms other factors. Real geniuses get the job done in a way that will last over the long haul.
I think a better way to look at this is that at the time you couldn't think of a better way. Often I've come back to a problem later and found some better abstraction. Or asked a colleague who has a nice trick to sort things out.
On some days, I think the the main job of a programmer is to hide the ugliness as well as possible. The code bases that really scare me are the ones where people have admitted defeat and let the ugliness seep everywhere.
Put another way, the kind of engineer that would actually benefit from a book like this, has probably already read a book like this.
I think you've created a false dichotomy.
I haven't read this book yet (although Bob Martin's other stuff is great), but back at the dawn of time, I was working with a team that was all relatively young. When McConnell's "Code Complete" came out, we all went through it pretty excitedly.
Although we had the right spirit, and we each could have named some of the things in the book, none of us could have articulated all of them. And there were a lot of subtleties that we had never thought of.
So I'd agree that jerks won't read this and nice graybeards don't need to, there are plenty of people who are perfectly nice that haven't perfected their craft yet. They can use this book.
Good meta-meta... I... joke.
Maybe the bubble has generated people who think they don't need to know anything but still be valuable?
One of the best things about Bubble 1.0 bursting was the number of "HTML Programmers" with 6 months experience who were forced to go out and get jobs that they actually liked, understood, and were good at. Sure, those jobs didn't pay as well, but real jobs never pay as much as fantasy-land jobs.
It was really a relief to me, as there was a point where I was having a hard time not sending snarky replies to the painfully clueless.