Thank you (seriously) for demonstrating the part where I said, "but they'd rather tell you why you're wrong rather than really listen to why you're frustrated."
> ...as well as any other missing AD features...
This isn't exactly a feature, it's a core part of AD permissions. Samba 4 was developed for the purpose of taking on server roles in an AD environment.
> We are not your servants, we are people. Give value, get value. Open source is not your custom-fit panacea.
OK, I hear that a lot. And it's a fair criticism. Now, here's the other half of it: support people are not your janitors. Quit expecting us to spend hours digging through arcane documentation, followed by further hours troubleshooting things that you left half-finished, and then turn around and tell us to write it our own damn selves. Because, seriously, there just aren't enough hours in the day. I'd love to contribute more to open source, but first I have to get enough revenue in my business to support that, and before I can do that, I have to figure out how to fix my clients' technical issues without raping their pocketbooks. The harder my job gets, the less likely I am to contribute.
For example, I might be writing a Jooma migration tool right now to fix the stupid 1.5->1.7 issues, and I'd be happy to release it and even support it for as long as people need it, but first I have to figure out what the hell is wrong with the wireless drivers in Linux on the new laptop...
> We're dipping into two different pools of shitware for examples of bad software now.
Yeah, that was the point: examples of bad software cross all disciplines, all companies, all environments. If it was just one company that consistently produced crap software, it would be easy to say that there's probably something broken at that company. But when there are so many companies, and so many freelancers, and so many open source developers producing crap software -- there's probably some issue with software development itself.
> That or you should take up buddhism, seriously.
Eh, I appreciate that, really, but I don't want to stop caring. I want it to be better.
> support people are not your janitors. Quit expecting us to spend hours digging through arcane documentation, followed by further hours troubleshooting things that you left half-finished, and then turn around and tell us to write it our own damn selves. Because, seriously, there just aren't enough hours in the day.
Unless I'm missing something, if software were perfect then there wouldn't be a need for support people?
Yeah, and I think that would be OK. I'm not certain about it, but I think that a lot of the time and energy that goes into support could go into development instead, and most people would be happier. For example, clients that are paying me to fix things might pay me instead to make new things for them that would better fit their needs.
I'm not under any illusion that it would work that way for everyone. But, I can't think of a single support-level person (whether consultant, phone, on-site, or otherwise) that's been doing it for more than a few years that's really happy with it. It can be exceptionally frustrating to be the go-between between users and fluky systems. So, at the very least, it would eliminate a necessary evil that makes a lot of people unhappy.
It might also result in fewer jobs to go around. But I don't think so.
>It might also result in fewer jobs to go around. But I don't think so.
It would result in more wealth and efficiency, not more jobs. Capitalism says nothing about jobs, only wealth.
We don't really (in western society) have a mechanism for transferring wealth beyond trade, labor, and government fiat. In the absence of busywork created by government fiat, we're going to have a hard time socially speaking midwifing an increasingly efficient world where redundant jobs get replaced with technology and processes.
This will continue the trend of increasing wealth stratification as whomever has control over the means of production will be subject to the will of others less and less, and be able to keep more of their profits.
Incidentally, this means it'll be fantastic to be a programmer, and terrible to be a laborer.
If a novel solution isn't found, the best many could hope for is a service job or medieval-style patronage of arts as production and maintenance of product pipelines requires fewer humans.
You're missing that software which works perfectly still wont do what you want magically. Just because it works on a terminal server doesn't mean it will select and install itself on your cluster when you want it.
Just because it generates reports promptly without crashing every time doesn't mean it will know which reports to generate or which data to pull from, or how to include your new office statistics.
Just because your phone synchronises email when abroad without messing up doesn't mean it knows which email addresses to forward to which people.
Support people would then be primarily involved in using technology to help businesses do things, instead of primarily using technology workaround other technology's problems.
You brought up some great points there but couldn't those be generally classified as training? When I think of support I think of people who help the customer to analyze problems and fix them. If support people are spending time holding the customer's hand then I'd say it isn't fair to be tasked with support and training.
> support people are not your janitors. Quit expecting us to spend hours digging through arcane documentation, followed by further hours troubleshooting things that you left half-finished
I am amazed once again at some people's ability to take free stuff and complain that it isn't making them money fast enough.
Just take a few seconds to think about the value we all get out of the deep and broad Free Software stacks. Finding bugs and fixing docs is a part of that process. You're not entitled to any of it, but you're welcome to participate and partake of the fruits.
The problem is that writing the code yourself is nice, while tracing/solving bugs in the code of others and fixing docs sucks. Too many free software authors do the nice work and rely on others to do the dirty work. They write code, release it and claim victory, while their code is only barely usable. The problem is that something barely usable is better than something nonexistent, so it gets used and we are stuck with a suboptimal solution. In this respect, free software development constantly gets stuck in a local maximum.
You have to weigh the value of immediacy against permanently enshrined qualities and perform your own cost-benefit analysis.
This is called critical thinking, they introduce this around age 12 in most western societies. You don't have to pick a religion and stick with it, you can just make a judgment call on a case-by-case basis.
> Quit expecting us to spend hours digging through arcane documentation, followed by further hours troubleshooting things that you left half-finished
I am amazed once again at some people's ability to take free stuff and complain that it isn't making them money fast enough.
That complaint applies equally to commercial software.
CEO arrives in a foreign airport, calls us up because his Blackberry now shows email headers instead of email, including email in his inbox which previously had all the content. The carrier tells me everything is setup fine for roaming and he needs to reset his Blackberry by taking the battery and SIM out, and then booting it with no SIM, then putting it back together properly. And if that doesn't work, he needs a new phone. And we couldn't talk him through it because that's his phone, and we couldn't email instructions, and anyway it was evening in an airport and he was in no mood for it.
This is a commercial device, praised for its business email handling, dealing with a well established, decades old protocol, from a large international carrier. Talk about a problem which just shouldn't happen, with a nonsensical solution.
And it's just one anecdotal example of every day workaround-finding. Wobbly software Jenga towers everywhere, and reboot-into-a-known-state is rule number 1.
>Eh, I appreciate that, really, but I don't want to stop caring. I want it to be better.
Corpses write no code. shrugs
> If it was just one company that consistently produced crap software, it would be easy to say that there's probably something broken at that company.
Anything below the top, say, 2-5% of software is guaranteed to be shit because all the programmers below the top 2-5% are shit. There is no grand movement or methodology to be had here.
It's a people problem.
>For example, I might be writing a Jooma migration tool right now to fix the stupid 1.5->1.7 issues, and I'd be happy to release it and even support it for as long as people need it, but first I have to figure out what the hell is wrong with the wireless drivers in Linux on the new laptop...
This is why I use Linux for workstations where it seems more comfortable, and my Mac for my mobile machine as it's more tolerant of network/display disruption. I'm not trying to troll or be a Mac fanboy here, I prefer working in Linux as I am simply more productive and it's my production OS. But, a laptop that is on the move plays to the strengths of OS X sufficiently that I am travelling right now and using my Mac instead of my Linux laptop.
You're going to have to accept that if you use the wrong software for the wrong problems, you're going to keep getting poked in the eye. You're using bad hammers and complaining about how bad hammers are.
There's a distinction to be made, an important one.
>Now, here's the other half of it: support people are not your janitors.
Open source projects don't have "support people", they have contributors and devs that volunteer their time. I worked for a MOTU and volunteered in the #ubuntu channel on FreeNode for years. I've done thousands of man-hours of support. I know exactly how bad software is, and how bad the situation is.
I'm on your side here, but until you start solving the problems one at a time, nothing changes.
My apartment gets cleaned one trash bag at a time.
>The harder my job gets, the less likely I am to contribute.
Something's gotta give. Stuff like Joomla registers as shitware in the circles I go in.
Complaining about things like Joomla, PHP, Drupal, Outlook, etc. doesn't really register with me.
Might as well buy a Kia and complain about how terrible the state of automobiles are. The author had much stronger points than you have. You work with some terrible stuff, period.
Anything below the top, say, 2-5% of software is guaranteed to be shit because all the programmers below the top 2-5% are shit. There is no grand movement or methodology to be had here.
It's a people problem.
Disagree. I don't think 95-98% of programmers are idiots. However, a lot of programmers (even some very smart ones) are terrible architects and have no sense of the big picture. Moreover, a lot of projects start out well but turn to shit through neglect and departure from the original architecture.
95-98% of software architecture is deplorable, but that's not because our industry is has 20+ idiots for every decently smart person. It's a lot more subtle than that. A big part of the problem is that most of professional programming is so disconnected and often alienating that a lot of programmers never learn architecture and its importance; the only way to really learn it is to support your own creation and experience first-hand the consequences of your original decisions. A lot of programmers never have that experience.
In sum, I think the general shittiness of the software industry and of architecture has a lot more to do with the fact that few programmers never have the experiences that will make them any good, than it does with a lack of talent. It takes 10,000 hours of deliberate practice to become good at something, but most of what most programmers do for work is not "deliberate practice"; it's repetitive drudge work that they often don't have the creative control to automate.
If you have 10,000 hours of practice in a particular software package or platform, congratulations, you are an expert at something that was obsolete five years ago. This is something that makes software development both a frustrating field and an interesting one. I always feel like I'm learning, but never feel I've really mastered anything.
I'm glad you brought up the point about software architecture because it's something I constantly find myself explaining: the difference between good architecture that survives many many generations and forms of code re-use vs. code monkey output that is fit only for that individual programmer's or his client's one-time use. This is an especially important point to bring up when you encounter business people who wonder why we can't just outsource everything. Cheaply-outsourced code is too often the drudge code monkey output we would find deplorable.
>Disagree. I don't think 95-98% of programmers are idiots.
I didn't say that.
> It takes 10,000 hours of deliberate practice to become good at something,
People need to stop re-hashing this. 10,000 hours of deliberate practice is likely but not necessarily going to make you an excellent programmer. I know plenty of programmers in their 40s and older who have that much time in or more that are frankly, garbage.
Investing time is necessary, but insufficient, and there is no one grand unified number that defines all professions for what is necessary to become excellent for every individual.
I know a 60-something whose code output terrifies me and he has a great deal more than 10,000 hours invested in programming.
OTOH, one of the programmers I most deeply respect is a 50-year old woman.
It's hit or miss. In my experience, passion counts more than anything.
>but that's not because our industry is has 20+ idiots for every decently smart person.
Work at a major insurance/something-not-directly-related-to-software company. That's an optimistic ratio.
Wait a minute, are you talking about people who spent 10,000 hours really trying to get better at their craft, and not just doing their work? It's like natural languages, where you can be immersed 20 years in a country and talk no better than you did 2 months after your arrival.
You're No-True-Scotsman'ing a subject/concept that was dead on arrival.
Stop pretending the 10,000 hours thing is a "real thing" or somehow fact.
It's not. Fucking stop it. It's the fantasy of a bad writer who makes up shit based on pure anecdote.
And to use your own bullshit against you, he never said it was deliberate practice in the book, he explicitly used the example of the Beatles, whose "10,000 hours" was them jamming in public and fiddling around privately, not hammering at chord progressions.
The 10,000 hours meme is bullshit. Stop propagating it.
The 10,000 hours meme (if it is that, it seems more of an observation to me) is not to be taken literal.
If you take it literal, then yes, it is nonsense, it is not that until the 9999th hour you are going to be bad at something and then suddenly, boom magic.
What it means - and what I've found to be very true - is that to get better at something you need to put in time and you need to practice your trade.
Nobody is born a 'great programmer', sure there are some differences in talent but I've seen guys go from bad to mediocre to good to excellent just by applying their trade and learning their lessons. Some of the kids I taught a decade ago that were struggling with basic concepts now run circles around me. That's proof enough to me that there is some truth in the 10,000 hour rule.
You can disagree with the writer all you want but in practice he does seem to have a point.
And for all your aggressive use of language you so far do not seem to have one. If you want to show that something is not true you have to provide counterexamples, not simply jump up and down using foul language telling people to stop.
People need to stop re-hashing this. 10,000 hours of deliberate practice is likely but not necessarily going to make you an excellent programmer. I know plenty of programmers in their 40s and older who have that much time in or more that are frankly, garbage.
Sure. And I could spend 10,000 hours playing basketball and I'd never become good at it. I don't have the genes. The point about "10,000 hours" is not that anyone can become good. It's that this is the amount of time that it takes for a person with sufficient talent (which is uncommon but not outstandingly rare, as it might seem) to become great at something.
Also, 10,000 hours of inadequate or badly-structured practice is useless. Otherwise, five years of work would be enough, and for most people, it's not. Most of the things that software developers do for money don't make them better programmers and therefore don't count.
It's hit or miss. In my experience, passion counts more than anything.
I agree. Passion, creativity, and courage are all important. It takes all three to figure out how to divert 10,000 hours away from what you're "supposed to do" and toward what will actually teach you something.
The point about 10,000 hours is that anyone can become good.
The point of Outliers, the Gladwell book, is to dismiss the idea that talent exists at all. "A person with sufficient talent", as you say, is a person who started onto decent amounts of practise at a young age, such that by the time the world notices them at age 8, 10 or 14, they're already surprisingly good and can make good use of professional coaching.
He used The Beatles travelling to Germany and having to perform for severl hours every night for months as the turning point between them being a band and them being a good band.
He didn't say they were "jamming and fucking around", or anything of the sort. He also didn't say "chord progressions is the only practise that counts", to reply to your other comment.
He also also didn't say "10,000 hours is a fact, 9,999 hours won't do", it's an anecdote fitting rule of thumb to tell a story.
But if you can find plenty of people who are world class at what they do, and haven't done anything close to 10,000 hours of doing it, have at it.
> ...as well as any other missing AD features...
This isn't exactly a feature, it's a core part of AD permissions. Samba 4 was developed for the purpose of taking on server roles in an AD environment.
> We are not your servants, we are people. Give value, get value. Open source is not your custom-fit panacea.
OK, I hear that a lot. And it's a fair criticism. Now, here's the other half of it: support people are not your janitors. Quit expecting us to spend hours digging through arcane documentation, followed by further hours troubleshooting things that you left half-finished, and then turn around and tell us to write it our own damn selves. Because, seriously, there just aren't enough hours in the day. I'd love to contribute more to open source, but first I have to get enough revenue in my business to support that, and before I can do that, I have to figure out how to fix my clients' technical issues without raping their pocketbooks. The harder my job gets, the less likely I am to contribute.
For example, I might be writing a Jooma migration tool right now to fix the stupid 1.5->1.7 issues, and I'd be happy to release it and even support it for as long as people need it, but first I have to figure out what the hell is wrong with the wireless drivers in Linux on the new laptop...
> We're dipping into two different pools of shitware for examples of bad software now.
Yeah, that was the point: examples of bad software cross all disciplines, all companies, all environments. If it was just one company that consistently produced crap software, it would be easy to say that there's probably something broken at that company. But when there are so many companies, and so many freelancers, and so many open source developers producing crap software -- there's probably some issue with software development itself.
> That or you should take up buddhism, seriously.
Eh, I appreciate that, really, but I don't want to stop caring. I want it to be better.