Hacker News Reader

I remember when it was, when it seemed like most things just worked, even though they didn't look pretty.

I remember spending hours moving around jumpers to set DMA and IRQ. Only to find out that the only free IRQ was #9 and bloody Packard Bells sometimes didn't have a frikkin' 9 because that batch of boards was $2 cheaper that month...

I remember when it wasn't pretty and it took ridiculous efforts to make it work even a little. Now I mostly jam a USB thing in the side and it goes. There has been much improvement.

I'm actually a little psyched by it all. This just happens to be a really hard problem that arrived at humanity's doorstep before we were really evolved enough to make much of it. It might mean we're ahead of the game, and it almost certainly means that the best is still yet to come.

I was thinking about this last night, the evolution problem - whether the only effective strategy would be to synthetically reintroduce tribal-era scarcity so we could all find our balance again, or would moving to a genuine post-scarcity world be something humankind could handle, or do we need to find some way to hack our minds to accept this new availability model in the same way that alcohol or cocaine short-circuit our reward pathways?

w.r.t. OP, should lines of code be restricted to manageable amounts by some kind of international regulatory fiat, or can they just abstract the problem away into utterly comprehensive libraries of functions, or do coders just need to man up and take it?

I think maybe we just need to grow into it. This takes time, and probably generations. The first generation that has truly never been without a globally interconnected computer as part of their life is about to come of age. Lets see what they can do.

There was a time when there were no humans who knew how to drive a car.

Yeah and at that time say there were dudes running around on the rigging of big 4-mast galleons like it was no big deal, and if you dropped one of them on a busy road they would be as horrified as I would be if someone dropped me in their place and told me to splice the mainbrace or whatever...

Hardware improved. I believe the guy's talking about software.

I believe he's talking about the whole lot of it. Software and hardware . I think USBs suffer their own issues (see http://wiki.gbatemp.net/wiki/USB_Devices_Compatibility_List as a simple example (hint see the ""If the Device does not work" section)).

This fits the OPs notion that no one really understand the crap underneath it all.

Which software was it exactly that was so great and just worked? MS-DOS? Windows 3.1? Windows Me? Some specifics would be nice, because across the board it seems everything is MUCH better now. It used to be that you would buy a computer game and 75% of the time it would not work out of the box.

"I really don't like this industry much anymore. I guess that makes me a bad hacker or something."

This is the 'little death.' Allow me to relate an anecdote.

I grew up loving computers, loving everything about them, how they were built, how they were programmed, how they did what they did. I started out just as the 'personal computer' revolution was getting started, it was glorious, Altair, IMSAI, SOL20, Heathkit. Lots of folks with their own take on what the PC should be. I have spent hours and hours and hours writing my own BIOS code, hacking ZCPR3, making an emacs clone work on CP/M, falling in love with the Amiga and suffering the incurable disease of incompetent management. By the time the late 90's rolled around I was starting to burn out. A lot of stupid things which didn't have to be that way, Microsoft always trying to make their version of something just a bit incompatible and only buildable with their tools. Etc. I was writing some code on a windows box and hating it. I yearned for a simple 'make foo'.

Then I met a 'kid' who was building stuff on Windows and he had the same wonder I had when I was that age, except he didn't complain about visual studio crap because he had been introduced to computers with this as the way to do it. Where I saw re-implementations of the wheel, done poorly, he didn't see anything, they were just the tools you had to use to get to the end point.

I realized with a start that I had lost my sense of 'wonder.' That childlike state where you ignore the fact that something is uncomfortable or irritating because you have so much amazement over the thing itself. And the truth is that if you use crappy tools for a while your muscle memory will figure out how to minimize the irritation. I looked around and saw that people I knew, people who were bright lights of leadership back in the day, were now stuck in an endless cycle of curmudgeonly rant because they too had lost their sense of wonder. I decided to start picking my battles more carefully. (which you can do in a hobby, not so much at work)

I found an editor that I could use everywhere (Visual Slick Edit, now VIM) so that I could have the same editing experience on all my platforms. I spent some time to understand the build system (make, gcc, java, python, etc) to get to a point where not only could I create my own environment I could keep it running across platforms, and began to develop my own set of APIs which I could link through into the underlying platform. The goal was reduce the friction between getting stuff done, and the tools to get things done. I recognized the reward comes in the running of the code and getting it to work as I wanted.

Then I can mostly ignore the crappy stuff. I can joke about how putting a character on screen used to be to monitor the transmitter buffer empty (TBE) flag on the serial port and then write the ASCII character when that flag was 'true', to something which spends thousands of cycles checking to see if this time I want my characters to go right to left, or which code points or font I should use to display them, or how they should be alpha blended into the background of what is on a screen somewhere. And when I come across something that is horribly, horribly broken like using WebCam's in Linux, I try to develop a durable API for talking to video which isn't cumbersome to use, or has feature stubs I'll be unlikely to use. I try to stay amazed that I can capture digitally on a piece of $20 hardware that which used to cost thousands, and in so doing keep my sense of wonder about what is possible.

So, of all the replies in this thread, this one spoke to me the most. I think you're right. Thank you for describing it so well.

I started out a little after you did, with BASIC on a Commodore Vic-20 and Commodore 64, then Logo, then HyperTalk, and so on. I used to have fun decompiling programs and poking them with MacsBug to make them dance for me, and I used to have fun writing my own toy operating system and generally just screwing around. And, for the most part, my tools were simple and reliable.

So that's what I compare everything now against, and it all seems less reliable and more complicated. MacsBug was a thing of wonder and beauty compared to the "debuggers" I have to deal with most often now -- Firebug and GDBp. And I've started working recently on building my own tools, which is sort of fun again, so maybe I'm sort of headed on the right track.

But anyway, thanks for describing it like you did.

I am the child, instilled with a sense of wonder about, well, everything. I got kind of a late start, didn't run into computers until I was starting High School, until my parents gave me an old Pentium II that they had lying around. I'm 19 now, so that would have been 2005-2006-ish. A horribly underpowered machine. I was infatuated. I installed WinXP on it for the first time, I laid awake at night listening to the hard drive wail... an 8GB hard drive. It barely fit XP on it. Over the next few years I did everything I could think of with that box to make it run just a little bit better. I scavenged my house's parts drawer, googling serial numbers on the silicon to see just what this board did, and whether it would make my relic run faster. A few months later, I upgraded my computer for the first time... A Pentium III! A 20 GB hard drive! My world had opened up. I had to have my old data and parts, so I became familiar with the internals of the computer. Eventually I ran out of things to do in windows. I tried the linux thing I had heard about, burned myself a liveCD of ubuntu, gutsy gibbon. Wifi didn't work on the cheap usb dongle I was using, so it was back to windows to me. But I had gotten a taste. A taste of the terminal, and of an operating system that actually let me tinker with things. When ubuntu fixed the wireless driver for that dongle, and I was ready to install it again (after a failed fedora install or 2). After that it was just one software foray after another. Something broke, and I adventured deeper into the file system to fix it. I started to learn how to program. I learned about Arch Linux. I got a Dual Core computer (!!). The rest is history.

I still learn all I can, but my focus has shifted a little. I'm learning to program properly, to make new tools instead of understanding existing ones. I'm learning C and python and haskell and lisp (and looking for more!) and loving every minute of it.

I find it a little bit disheartening, however, the lack of curiosity that my peers display, even my fellow CS majors. To me, the computer is a vastly complex system, just waiting to be explored, and thanks to open source software, I can! But a lot of my peers don't see things that way. I would hazard a guess that part of that reason is that the environment presented to them is not particularly interesting, particularly in a windows or mac environment, where a lot of the details are abstracted as far away as possible. For me the spark of curiosity was ignited when I had a relic of a machine that I needed to make run faster. I tried to squeeze the most out of that computer, and it taught me enough to whet my appetite. I feel like our youth, my peers have been and are being short changed by technology today. I'm not sure what there is to be done about it, but I know that it isn't right.

I can't speak for your peers, but for me, deadlines and emergencies have probably taken a lot of the fun out of it. It's one thing when you're trying to debug some driver issue on your own system and you're doing it as a hobby so whether it gets done today or next month is no big deal, versus, say, crossing yourself and muttering a prayer and rolling out an update following weeks of testing, only to have it conflict with something you didn't anticipate and the entire network goes down in flames while your phone melts.

Or, for a slightly less doomsday scenario, just a relatively simple problem affecting one person, but they're still trusting you to figure it out, and they're expecting you to do it sooner than later.

There's a point at which the fun really starts to go out of that. I've always been a bit of an adrenaline junkie, I've always worked well under pressure, but nowadays my favorite thing is quiet time in the sunshine digging about in the garden. (Oh god, that makes me sound old.)

Maybe this will never happen to you. I hope not! But I've been thinking a lot about what Chuck said, and about my frustrations with technology, and I think that maybe this has a lot to do with it.

You should have realized this years ago, and made your peace with it. I think I made my peace at about 23, after over 10 years of programming and wading through this crap (and this process was frankly like coming out of a mild depression). I'll reiterate what I said in the previous discussion about Ryan's rant:

"Just about everybody knows that all our software is imperfect crap on top of imperfect crap, from top to bottom. Everybody, when met with a new codebase above a certain size, thinks they could do better if they started over and did it "properly this time". Everybody can look at a simple thing like a submit form in a web browser, and sigh at the inefficiencies in the whole stack of getting what they type at the keyboard onto the wire in TCP frames, the massive amount of work and edifices of enormous complexity putting together the tooling and build systems and source control and global coordination of teams and the whole lot of it, soup to nuts, into a working system to do the most trivial of work.

"But this is not a new or interesting realization by any means. It's not hard to point almost anywhere in the system and think up better ways of doing it. Pointing it out without some prescription for fixing it is idle; and suggesting that it will be fixed by wholesale replacement by another complex system is, IMO, fantasy."

(Things probably only seemed like they worked in the old days because you hadn't realized what was going on in the sausage factory; or it was an almost useless piece of hardware whose software did almost nothing, owing to its simplicity.)

Every now and then I decide I don't like being a programmer anymore. And then I remember its the only thing I'm good at.

That's what hobbies are for - i.e. exploring other interests can make you more well-rounded, and occasionally give you marketable skills.

That's how programming started for a lot of us. Start playing with transistors, then discover 555s, 741s and discrete logic. Eventually discover micro controllers and start coding in assembly and the C. 10 years down, find yourself managing a large team of developers and you absolutely hate it :)

Continuing:

And so you start using your programming skills to travel the world while working, see some amazing places, but discover to your dismay that things aren't any better no matter where you go.

But you continue writing your own stuff, releasing open source programs here and there, and then somewhere along the way you move into freelancing, which removes the protective layer between you and unreasonable customers.

Tiring of that, you move into iPhone apps and discover that you suck at marketing.

And then one day you find yourself living in San Francisco, founding a startup with a bunch of awesome partners, working insane hours, and having a BLAST trying to solve hard problems.

There is much joy and wonder in this world; you just need to look harder.

I can so relate to that...

But then I think of other actual jobs that exist nowadays, and I conclude being a software dev might be the least worse.

Software is eating the world, after all.

Indeed, bugs are creatures of great appetite!

I often feel the same way. Also don't forget "the grass is always greener" syndrome.

Every morning when I get in my car for the morning commute my Android device automatically connects to it via Bluetooth. From the steering wheel I press play and my personal music collection on Google Music's cloud starts streaming through the internet, to the 4G cell network, to my device in a car traveling 70mph, to the car via Bluetooth, and I hear the music through my car speakers.

"Everything is amazing and nobody is happy" - Louis CK

This is also why IT admins become fascists over the long haul. Turns out nothing is compatible with anything, especially turn-key software. Turns out that no vendors care to test with any other vendors. Turns out that everything is in some state of brokeness and the only sane solution is to limit complexity and variety and focus on x amount of technologies that we have time to test and make work.

This is why you get a PC without admin rights, set to autoupdate, with our default image, our security policies, and our unpopular defaults (IE9 in my case) but with an option for chrome for those who request it.

I have no idea how home users get by. I hear about their problems and its sounds like a nightmare of poorly written default (your average home laptop is a minefield of OEM junk and a malware magnet). I suspect this is why Apple is doing so well. They abstract away the complexity and actually make their products compatible with their OS and other offerings! Toss in the fact that OSX isn't as targetted by malware, and I can see the allure. On the corporate side, linux is the same deal. We all are comfortable with the command line tools we learned in high school/college/whenever and they haven't changed. Its like an old friend. Sure, it may not generally "just work" but its easier to tinker and fix than a closed system.

Well, I'm a software developer and I can relate to what you're saying. I certainly don't try to defend poor software, and often I find myself frustrated with the current state of software. But, the reality of the situation is, you can't change the whole world all at once! Do what you can, plan to change the world and operate step by step. In the meantime, make your money, earn your living and deal with the current state of affairs while you're improving the world in your spare time! :D

You remember when most things "just worked"? When exactly was that?

I remember when you would buy a new mouse and sometimes it just wouldn't work and then you actually had to take it back to the store because you had something slightly different about your computer and there wasn't a released driver yet.

I remember when Blue Screen of Death was more than just a joke, and it was an actual thing that happened on a fairly regular basis.

You know how everyone thinks IE6 is teh devil? I remember when it came out and was awesome and it actually killed off the competitors for good with all its sweet features.

That's the world I grew up in, and the current state of things is MUCH better.

> I remember when it seemed like I could just open something up and start hacking on it without having to hold tens of thousands of lines of code in my head, spread over dozens of files.

Here's me telling you what's wrong instead of listening: what you're missing here is that we're doing vastly more than we were back then. If you want a pixelized bunch of text that does a simplistic task or two I'm sure you could do now in even less lines and more readable than you could back then.

But no one wants that from us anymore. You can't make a living doing that. You, yourself were complaining about Samba not implementing a specific feature. I bet their code is already too big to meet your "software is fun" metric.

This may be another flame war, but I don't use IDEs specifically to prevent me from writing the kind of code that I don't want to work on.

You must have used some pretty shitty IDEs then. I use IDEs for the productivity boost, owing to code completion, fast lookups, folding, integrated documentation, syntax highlighting, integrated build system, interactive graphical debugging, integrated source control, project based search, GUI tools, etc.

Of course, all IDEs have their design flaws (like any other piece of software), but the benefits are compelling.

I use IDEs too — sometimes — but there's a dark side to each of the things you're describing above. Here's the devil's-advocate argument.

If code completion is speeding you up, it means you're writing code with a lot of redundancy in it. But the slow part of programming isn't typing the code in in the first place; it's reading it later. If the stuff you're putting in your source code is redundant boilerplate that code completion can put in there for you, then it's going to make it hard to read the code later, when you need to find the part that you actually typed, because it has a bug in it, or because you need to change it.

If fast lookups (I assume you mean meta-point, quickly jumping to the definition of an identifier from a mention of the identifier?) are speeding you up, well, maybe you're getting into a codebase you don't understand very well, because you're just starting to work on it. (Although these days grep is pretty fast.) Or maybe your codebase is an overcomplicated nightmare with too many layers of indirection, costing you comprehensibility even despite the wonders of meta-point.

If folding speeds you up a lot, maybe your code is way too deeply nested, or you have a lot of irrelevant stuff mixed in with the stuff you're trying to read.

If integrated documentation speeds you up a lot, maybe you're programming to an API that's too big to memorize, which means you're going to make errors when you call it and then not be able to see them when you read the code.

Syntax highlighting is nice, but it matters most when your code is poorly laid out and unclear, and then it doesn't make your code easy to understand.

If you're spending so much time in your debugger that it matters a lot to you whether the debugger is an "integrated graphical debugger" or not, you're wasting a lot of time. Debuggers are indispensable when you're exploring a codebase you don't understand at all. (Although, in that case, the best one is probably IDA Pro, not part of an IDE.) But on code you write yourself, use unit tests and code reviews to minimize the number of bugs you have to debug, and in many cases, logging is a much more efficient way to track down bugs than a debugger, because you can see a whole run at once, instead of a single point in the execution. As an extra-special bonus, logging lets you track down bugs from production that you can't figure out how to reproduce on your own box.

If IDE GUI tools are saving you time, any time at all, your GUI library sucks and you should use a better one. Also, you're probably making shitty GUIs, the clicky equivalent of the IRS 1040-EZ, joyless bureaucratic crap, because GUI tools don't help you when you're trying to construct things like kseg or Inkscape or the GIMP. HTML and CSS, or for that matter Tk, allow you to produce those soul-destroying forms with less effort than some crappy drag-and-drop IDE. That's why HTML has replaced Visual Basic in modern use.

As for project-based search, I keep each project in a directory of its own, and then I can use grep -r or ack to search the project.

As for integrated source control, I probably spend about five minutes per hour interacting with my source control system, except when it completely breaks (in which case IDE integration is generally pretty useless).

If your integrated build system is saving you time, then you have way too much complexity in your build scripts, which are a part of your code that don't add any functionality to your product.

In short, the lovely features you're describing are real productivity boosts — but each only exists to compensate for an even bigger productivity killer, and then they only rescue you partway.

⁂

Do I believe that? Well, halfway. I use M-/ in Emacs (code completion) pretty often. I use integrated documentation because there are some APIs where I never can quite remember the arguments, including sometimes things I've used for decades. I use meta-point in Emacs under some circumstances; it's pretty much a necessity for some codebases. (And I use it often when I'm exploring unfamiliar code.) I always turn on syntax highlighting in any editor, because whether or not it improves my productivity, it's pleasant. I don't use folding, but it's not uncommon that I wish for a hotkey to fold all the comments in a piece of code. I have F5 bound to 'recompile in Emacs for the times when I'm playing around rather than implementing something well-defined. I use GDB's Emacs integration. Also, I use the fuck out of Firebug.

Basically I think it's stupid to do stuff manually that could be automated. Compilation is a good example: by using a compiler, I automate endless hours of fiddling with register assignments. But I think that eliminating work is even better than automating it.

๛

The alternative used to be: report a bug. Put it in bugzilla.

I've reported thousands of bugs. Maybe 30-50% of them used to be fixed. Nowadays I'd be pushing it to say 5%.

But do you still report bugs?

I've gone to report GNOME or Ubuntu bugs, only to find that the problem already has a bug report from 5 years ago. The bugs are still open and unfixed, with a poor sap adding a "me too" comment every few months.

There is a YC startup in there somewhere :) Kickstarter for bugfix contributions.

I still report bugs, but nowhere near as many.

Before there was a feeling of progress: report a bug, see it fixed. Now it's report a bug and silence.

As a programmer I find this offensive, we work all day trying to make software good (enough). As I see it the problem is with users, they think they should get programs, like firefox, for free. Most programs you use on a daily basis are now larger than anything a single person can build in a lifetime, and it should be free ? No business constraints and lack of money is what is keeping software down. Nobody is paying anyone to 'reinvent the wheel' to be better.

>allowed_users

You can pay someone to implement this, as well as any other missing AD features, then open source it so no-one has to implement it again.

The original devs that did much of the reverse-engineering work on Samba have since moved on to much more rewarding work. That work will essentially never be done again, nor be improved upon until financial incentives are introduced. Much of the work on Samba since has been bug fixes and pushing your food around on your plate.

We are not your servants, we are people. Give value, get value. Open source is not your custom-fit panacea.

>"So build your own version."..."Why are you reinventing the wheel? That's already been done."

Probably two different groups of the people, the latter group is likely harried contributors to a project you're asking for help from who doesn't have the benefit of the context for the work you're doing. It's a common thing in mailing lists and IRC.

>So Western Digital's backup software interferes with Outlook in funny ways?

We're dipping into two different pools of shitware for examples of bad software now.

>So everybody's decided to abandon sane software versioning altogether and make the support end of things even more nuts?

It's gotten more standard in some respects, thanks to SemVer. I can't speak for companies that have decided to treat it like a high score, much like the Linux distributions of the late 90s and early 00s.

>Software used to be fun.

Still fun for me, after ~15 years of coding, 5 of them professionally. Sounds like you're just grumpy and unwilling to invest in swatting any of the gnats flying in your face.

That or you should take up buddhism, seriously. I'm an atheist but there's some benefit to learning when you should and should not care about things.

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.

>The problem is that something barely usable is better than something nonexistent

No necessarily. I think sometimes the existence of something, even if only barely usable, blocks the creation of something else that might be better.

OTOH, perfect can at times be the enemy of good.

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.

Works great for me, fyi.

> 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.

> It takes 10,000 hours of deliberate practice to become good at something,

No, it takes that long to master something, it takes much less time to simply become good.

>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.

The 10,000 hours meme is something a bad author made up to fit his pile of anecdotes.

It's not a fact, it's a number he pulled out of his ass.

He never made it about deliberate practice, he used the Beatles jamming and fucking around for 10,000 hours as an example.

Stop talking about 10,000 hours IT'S BULLSHIT. You might was replace-string it with "SIX-SIGMA CERTIFICATION", it means nothing!

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.

>> Still fun for me, after ~15 years of coding, 5 of them professionally.

Lots of us did coding as a hobby for 10 years before gettting out into the professional world. With 5 years under your belt, you're still a junior programmer and the world's your oyster. Let us know how much fun it is 15-20 years or more from now. (And when you do have to care about things more important than programming: family, health, aging parents, job security, etc., etc.)