Many careers have been made by fighting fires caused by one's shoddy engineering. At a previous job, a top developer was hailed for his abilities to work 48 hours straight to fix problems. Those problems were on his code, which was very poorly written in the first place. He was the firefighter, but also the arsonist.
If emergencies are not very rare, time is better spent preventing said emergencies than just fighting them.
2 hours of meetings per day, minimum? I've worked at places where that's the bare minimum for programmers! 30 hours of meetings a week seems closer to the average.
So, those experienced programmers are knitting while they are waiting for fair compensation? No, they are coding somewhere else. And if you raise salaries, guess what? That company gets to hire people, while another has open positions. It's not really an issue of not paying enough, when you look at it on aggregate.
If you want to look for a problem, it's that hiring young devs out of school is a lottery. You'll find some amazing ones, which will quickly deserve great salaries, and many crappy ones that are not really providing a good ROI even at entry level salaries. I'm sure you've seen developers that hindered more than they helped, even without taking their salary into account. So why hire someone out of school, when you can just have positions open to people with enough years of experience you can make a better guess on whether they are any good? Not that experience guarantees skill, but it's far easier to judge a 5 year resume than a 0 year resume, especially in a small enough market that you are well aware of the typical skill levels at each competitor.
But that's not how programming works. At least, not programming that is even remotely effective. Most development out there isn't really about coming up with cool ways for a computer to do a complex task, but defining what the task should be in the first place. After the workflow is defined, the actual programming is rather mundane. In those environments, a good percentage of your time is talking to people: From gathering requirements to just tasking out a large pile of work into smaller, more manageable pieces.
If anything, the main trait that was shared by all the worst programmers I've seen in my career is that they were poor communicators. And yet, when it comes to actual work environments, most programmers I've known are male, while females drift towards other software jobs, like business analysts, DBAs, testers, tech support and such. A shame, really.
Depending on the kind of development you are on, maybe. There's plenty of people moving to shinier things though, mainly due to Java's excessive verbosity and lack of support of functional features. For insance, you see Fortune 500 companies placing ads for Scala developers. And people don't move to Scala because they have nostalgia for the C++ era's compile times. There's plenty of growth out there by other second tier languages who people choose to increase speed of development. And there's of course C#, which actually attempts to evolve at a decent rate.
So while Java is still a very used language in industry, you won't see any language getting any uptake today if they replicate Java's love for boilerplate.
We could also talk about the tools that are often used with Java that just promote the mindless verbosity. We all remember how terrible EJB 1.0 and 2.0 were. But then we got Spring and Hibernate, which are only slightly better than the disease. You can choose between monstruous XML formats with no real type checking, leading to a whole lot of runtime errors, or annotations that are slightly less verbose, and yet are just as prone to runtime errors. You end up needing such high test coverage to double check for those 'helpful' technologies that you might as well have been using a purely dynamic language in the first place: It's not as if the compiler protects you from careless mistakes in annotations or XML files. To offset this, we need an IDE and some complex configuration, raising the bar for building even the simplest application. No wonder people found Rails so refreshing when it first came out.
They don't always make it: Many do not make it at all. Survivor bias and all that.
JavaScript thrived because the alternatives were arguably far worse. Java applets were terrible. ActiveX a platform specific disaster. Flash is heavy. JavaScript allowed you to do the very minor things most web developers wanted at the time without having to turn your website into a plugin that disregarded base web technologies.
Yes, the language design is pretty silly. The function declaration syntax is silly. It tries to look like a member of the Algol tree, but its internals behave more like Lisp. The automatic type conversion system is the source of many jokes. But it still beat it competition at the time, because it was built into the browser, it talked directly to the page's DOM, and the competition did not. Today we'd have little trouble designing a better language than JavaScript for what we currently do with it, but our best bet to get something like that working is to build a language that compiles to JavaScript and then hoping browsers start building VMs for that language directly, skipping the JavaScript step. Still, not bloody likely.
There's plenty of weird, inventive games out there... They just happen to be mostly indie, so they are released for the PC Master Race.
Big developers are the ones sitting on their asses, and that has more to do with the fact that modern graphics are expensive as hell than anything else. Hard to sink 50-200 million on a game that you don't expect to have a very broad appeal
It's hard to look at European employment figures as an aggregate, because the economic situation in say, Germany and Spain has nothing to do with each other, and even though people could theoretically move from one country to the other and work, language and cultural barriers make it far harder for a Spaniard to work in Germany than for someone from Mississippi to move to Washington.
And no, southern Europe has no problem with tech workers: They have plenty of unemployed tech workers already. Their problem is that employment quality has all to do with your friends, and very little with your actual skill set. Anyone that is any good over there is doing their own thing in the app store, as corporate jobs just don't pay.
So if Europe has a tech problem is one of worker mobility.
Code should be easy to read, and it should be easy to find what you want. Therefore, while it might resemble a book, it will not look at all like literature.
The best code out there deals with extremely complex problems, and turns them into something so simple, anyone that approaches the problem by reading the code must think that the problem was trivial. So trivial that most simple enhancements pretty much write themselves. Only after maintaining a codebase like that for a while, or seeing the same developer do this over an over again, your typical reader realizes how much skill was put into making the extraordinary look ordinary. If anything, this is the opposite of literature.
Apparently Nintendo has been opening up to indies quite a bit: For instance, the requirement for an actual commercial address is gone. However, you'd have to be mad to make the WiiU your main platform, if just because as an indie, you will not get enough exposure to warrant the gamble. That's why everyone and their mother tries to develop for PC: If you get on Steam, you will get plenty of visibility.
8 for gas? even if you claim gas is 4 bucks a gallon (which it isn't in most of the US today), that's still 2 gallons of gas to go out. Say you drive a pretty inefficient car, 20 mpg. That gets you to a destination that is 20 miles away and back. Here in middle America, I count 16 multiplexes that are closer than that.
So, are you going to a movie theater that is 2 counties away or do you drive an H2?
Like every other question about software development, we should always start with The Mythical Man Month. In this case, the relevant chapter is There Is No Silver Bullet.
Now, the interesting thing about that chapter is that, while it was right, it was the least right of all the good predictions Brooks made. No technology is a silver bullet, but many produce noticeable improvements that, when put together, can give us an order of magnitude in productivity over older tech. It's not as if OO has been abandoned. Case tools were replaced by the far more sensible powerful IDE. GUI builders are not used a lot nowadays, but we get many of their gains by having dev environments with tighter feedback loops. And there's of course the mother of all improvements, which is the creation of large, powerful libraries. How many of the things that people did for business applications 15 years ago are, today, just replaced by libraries?
Not that this denies your final thesis though: Hire bright programmers with people skills, and do your best to keep them. No technology will allow bad developers to make a good application.
The platform still has some glaring holes for languages other than Java. For instance, the call stack is still represented in a C style stack, with a depth that is insufficient for functional programming. In Scala, for instance, we have people explicitly using trampolines and such to avoid running out of stack.
Very likely, yes. Do you want to go back to a world before penicilin?
Weeds will keep evolving to beat whatever you throw at them: If they didn't, they would be extinct. If anything, we should invest more in genetic research, so taht we can have a bigger advantage over weeds and diseases. Feel free to regulate their application of said technology though, just like we could regulate antibiotic use on farm animals.
There are uses for storing credit card numbers longer than the transaction: Plenty of very big online retailers do it. Now, the issue is that if you do store said numbers, you better take it very seriously: What I've seen done is encryption keys that are rotated often, and who are stored encrypted in the database. That 'key to the keys' was never actually stored in the DB: It only existed in memory, and generated using a shared secret scheme, so no single person had access to said key.
When we tried to penetrate the security ourselves, our best attack vector for the stored cards required a developer that knew the software well and had managed to compromise sysadmin accounts on production servers. It was actually far easier to crack the transactions as they happened, and those don't really rely on whether you store your card data at all: Your card processor still needs to see the card data at some point.
You assume the system works. In the real world, the keys cannot be just in a computer that is not connected to the network, because otherwise nothing would get decrypted outside of said computer.
The moment you try to get those keys to be useful, you are making copies, which will reside in less secure environments, and you are connecting something to said machine, which suddenly gives you an attack vector.
A system that has very secure keys, like something that meets PCI-DSS key management standards, is always extremely inconvenient to start up and use. What the article wishes for is actually impossible given our current technology.
Don't look at the bugs individually, but at the distribution of bugs in the application. Bugs do not have an equal chance of appearing anywhere in a codebase, so their distribution is not random. There is much you can learn about the quality of your system and your development process depending on where the bugs are found, and this knowledge is actionable. Maybe your team needs to take unit tests more seriously. Maybe your developers have no idea of what are realistic scenarios. Maybe you are building on a technology that is just misused for the task at hand.
Either way, you should be making educated guesses on where the bugs will be, and then measure where the bugs are actually found, both during development an in production.
How does a thermostat bring all of those features to the home, without first changing your entire HVAC installation? What most of us have in the home is a single HVAC unit, or at most two, with no parts that would allow any of the fun things you can do in a modern building. You need both an army of sensors and movable parts. If you build a home thermostat around those features, expect to not sell any, because it'd come only with new houses made for people that have quite a bit of money and much to say about the home's construction. It's not as if it's going to be a selling point for a company that builds a new random subdivision.
Next up, you'll be disappointed in the nexus 5 because it missed the opportunity of bringing the playboy party experience to the cellphone.
Well., many of those games come with their own editors already: You can make Portal levels with the same tools Valve used to make the game in the first place. The problem with those games is that making new levels is far harder than it was with the old stuff. Just compare making a level for Doom, Quake and any modern shooter. 8 year olds could make Doom levels easily: The map was actually 2d, so it was pretty easy. A level for Quake was way harder, because not only you are sculpting in 3d, but you have to care about a bunch of little details that you never had to care about in Doom. Visleafs anyone? Switch to a more modern game, and it's even harder, especially when it comes to art assets. Textures aren't just flat pictures anymore. Then you add animation, and it takes weeks to build a character for a game for a team of professionals: It's not something you can dabble in for a couple of hours a week.
Yes, and there's this thing called FDIC insurance that makes sure that if my bank gets hacked, my balance remains the same. Same thing if the bank suddenly disappears. The same features that crypto currency proponents tout as ways to avoid the supposed evil of central banks are precisely what makes this kind of attacks easier to get away with, and therefore much more likely.
A world with banks working on crypto currencies requires real life contracts and huge amounts of non-crypto collateral.
If I have a 50k deposit in a bank account, and said account disappears, our good friends in the FDIC will make sure I still get my money. It also becomes pretty difficult to close your bank, keeping all the money, without getting hunted down. If someone robs my bank, I lose zero dollars.
Good luck getting anything that resembles those protections in a crypto currency. You'd actually be safer having multiple offline copies in different locations.
There's lobbies for everything. There's this large company whose name starts with an M whose bottom line is helped a whole lot by increasing demand for corn, and both subsidies and the mandate to use ethanol in gas both help in that respect. So what you get here is a conflict between different lobbyists.
The only ones that truly lose are those without a lobby.
This is already checked for, and already gamed: We get wonderful things like socially trading citations, and making sure your grad students only work on things very similar to your core work, to make sure they cite your work, and keep citing it in the future.
But who wouldn't want to go back to a world before the invention of banking?
Imagine a world running on bitcoin. How long until a bank issues its own form of cryptocurrency that only it can mine, and then starts to use it on loans, as a form of fractional reserve banking?
Slashdot Mirror
Many careers have been made by fighting fires caused by one's shoddy engineering. At a previous job, a top developer was hailed for his abilities to work 48 hours straight to fix problems. Those problems were on his code, which was very poorly written in the first place. He was the firefighter, but also the arsonist.
If emergencies are not very rare, time is better spent preventing said emergencies than just fighting them.
2 hours of meetings per day, minimum? I've worked at places where that's the bare minimum for programmers! 30 hours of meetings a week seems closer to the average.
So, those experienced programmers are knitting while they are waiting for fair compensation? No, they are coding somewhere else. And if you raise salaries, guess what? That company gets to hire people, while another has open positions. It's not really an issue of not paying enough, when you look at it on aggregate.
If you want to look for a problem, it's that hiring young devs out of school is a lottery. You'll find some amazing ones, which will quickly deserve great salaries, and many crappy ones that are not really providing a good ROI even at entry level salaries. I'm sure you've seen developers that hindered more than they helped, even without taking their salary into account. So why hire someone out of school, when you can just have positions open to people with enough years of experience you can make a better guess on whether they are any good? Not that experience guarantees skill, but it's far easier to judge a 5 year resume than a 0 year resume, especially in a small enough market that you are well aware of the typical skill levels at each competitor.
But that's not how programming works. At least, not programming that is even remotely effective. Most development out there isn't really about coming up with cool ways for a computer to do a complex task, but defining what the task should be in the first place. After the workflow is defined, the actual programming is rather mundane. In those environments, a good percentage of your time is talking to people: From gathering requirements to just tasking out a large pile of work into smaller, more manageable pieces.
If anything, the main trait that was shared by all the worst programmers I've seen in my career is that they were poor communicators. And yet, when it comes to actual work environments, most programmers I've known are male, while females drift towards other software jobs, like business analysts, DBAs, testers, tech support and such. A shame, really.
Depending on the kind of development you are on, maybe. There's plenty of people moving to shinier things though, mainly due to Java's excessive verbosity and lack of support of functional features. For insance, you see Fortune 500 companies placing ads for Scala developers. And people don't move to Scala because they have nostalgia for the C++ era's compile times. There's plenty of growth out there by other second tier languages who people choose to increase speed of development. And there's of course C#, which actually attempts to evolve at a decent rate.
So while Java is still a very used language in industry, you won't see any language getting any uptake today if they replicate Java's love for boilerplate.
We could also talk about the tools that are often used with Java that just promote the mindless verbosity. We all remember how terrible EJB 1.0 and 2.0 were. But then we got Spring and Hibernate, which are only slightly better than the disease. You can choose between monstruous XML formats with no real type checking, leading to a whole lot of runtime errors, or annotations that are slightly less verbose, and yet are just as prone to runtime errors. You end up needing such high test coverage to double check for those 'helpful' technologies that you might as well have been using a purely dynamic language in the first place: It's not as if the compiler protects you from careless mistakes in annotations or XML files. To offset this, we need an IDE and some complex configuration, raising the bar for building even the simplest application. No wonder people found Rails so refreshing when it first came out.
They don't always make it: Many do not make it at all. Survivor bias and all that.
JavaScript thrived because the alternatives were arguably far worse. Java applets were terrible. ActiveX a platform specific disaster. Flash is heavy. JavaScript allowed you to do the very minor things most web developers wanted at the time without having to turn your website into a plugin that disregarded base web technologies.
Yes, the language design is pretty silly. The function declaration syntax is silly. It tries to look like a member of the Algol tree, but its internals behave more like Lisp. The automatic type conversion system is the source of many jokes. But it still beat it competition at the time, because it was built into the browser, it talked directly to the page's DOM, and the competition did not. Today we'd have little trouble designing a better language than JavaScript for what we currently do with it, but our best bet to get something like that working is to build a language that compiles to JavaScript and then hoping browsers start building VMs for that language directly, skipping the JavaScript step. Still, not bloody likely.
There's plenty of weird, inventive games out there... They just happen to be mostly indie, so they are released for the PC Master Race.
Big developers are the ones sitting on their asses, and that has more to do with the fact that modern graphics are expensive as hell than anything else. Hard to sink 50-200 million on a game that you don't expect to have a very broad appeal
It's hard to look at European employment figures as an aggregate, because the economic situation in say, Germany and Spain has nothing to do with each other, and even though people could theoretically move from one country to the other and work, language and cultural barriers make it far harder for a Spaniard to work in Germany than for someone from Mississippi to move to Washington.
And no, southern Europe has no problem with tech workers: They have plenty of unemployed tech workers already. Their problem is that employment quality has all to do with your friends, and very little with your actual skill set. Anyone that is any good over there is doing their own thing in the app store, as corporate jobs just don't pay.
So if Europe has a tech problem is one of worker mobility.
Code should be easy to read, and it should be easy to find what you want. Therefore, while it might resemble a book, it will not look at all like literature.
The best code out there deals with extremely complex problems, and turns them into something so simple, anyone that approaches the problem by reading the code must think that the problem was trivial. So trivial that most simple enhancements pretty much write themselves. Only after maintaining a codebase like that for a while, or seeing the same developer do this over an over again, your typical reader realizes how much skill was put into making the extraordinary look ordinary. If anything, this is the opposite of literature.
Apparently Nintendo has been opening up to indies quite a bit: For instance, the requirement for an actual commercial address is gone. However, you'd have to be mad to make the WiiU your main platform, if just because as an indie, you will not get enough exposure to warrant the gamble. That's why everyone and their mother tries to develop for PC: If you get on Steam, you will get plenty of visibility.
8 for gas? even if you claim gas is 4 bucks a gallon (which it isn't in most of the US today), that's still 2 gallons of gas to go out. Say you drive a pretty inefficient car, 20 mpg. That gets you to a destination that is 20 miles away and back. Here in middle America, I count 16 multiplexes that are closer than that.
So, are you going to a movie theater that is 2 counties away or do you drive an H2?
Like every other question about software development, we should always start with The Mythical Man Month. In this case, the relevant chapter is There Is No Silver Bullet.
Now, the interesting thing about that chapter is that, while it was right, it was the least right of all the good predictions Brooks made. No technology is a silver bullet, but many produce noticeable improvements that, when put together, can give us an order of magnitude in productivity over older tech. It's not as if OO has been abandoned. Case tools were replaced by the far more sensible powerful IDE. GUI builders are not used a lot nowadays, but we get many of their gains by having dev environments with tighter feedback loops. And there's of course the mother of all improvements, which is the creation of large, powerful libraries. How many of the things that people did for business applications 15 years ago are, today, just replaced by libraries?
Not that this denies your final thesis though: Hire bright programmers with people skills, and do your best to keep them. No technology will allow bad developers to make a good application.
The platform still has some glaring holes for languages other than Java. For instance, the call stack is still represented in a C style stack, with a depth that is insufficient for functional programming. In Scala, for instance, we have people explicitly using trampolines and such to avoid running out of stack.
Very likely, yes. Do you want to go back to a world before penicilin?
Weeds will keep evolving to beat whatever you throw at them: If they didn't, they would be extinct. If anything, we should invest more in genetic research, so taht we can have a bigger advantage over weeds and diseases. Feel free to regulate their application of said technology though, just like we could regulate antibiotic use on farm animals.
There are uses for storing credit card numbers longer than the transaction: Plenty of very big online retailers do it. Now, the issue is that if you do store said numbers, you better take it very seriously: What I've seen done is encryption keys that are rotated often, and who are stored encrypted in the database. That 'key to the keys' was never actually stored in the DB: It only existed in memory, and generated using a shared secret scheme, so no single person had access to said key.
When we tried to penetrate the security ourselves, our best attack vector for the stored cards required a developer that knew the software well and had managed to compromise sysadmin accounts on production servers. It was actually far easier to crack the transactions as they happened, and those don't really rely on whether you store your card data at all: Your card processor still needs to see the card data at some point.
You assume the system works. In the real world, the keys cannot be just in a computer that is not connected to the network, because otherwise nothing would get decrypted outside of said computer.
The moment you try to get those keys to be useful, you are making copies, which will reside in less secure environments, and you are connecting something to said machine, which suddenly gives you an attack vector.
A system that has very secure keys, like something that meets PCI-DSS key management standards, is always extremely inconvenient to start up and use. What the article wishes for is actually impossible given our current technology.
Don't look at the bugs individually, but at the distribution of bugs in the application. Bugs do not have an equal chance of appearing anywhere in a codebase, so their distribution is not random. There is much you can learn about the quality of your system and your development process depending on where the bugs are found, and this knowledge is actionable. Maybe your team needs to take unit tests more seriously. Maybe your developers have no idea of what are realistic scenarios. Maybe you are building on a technology that is just misused for the task at hand.
Either way, you should be making educated guesses on where the bugs will be, and then measure where the bugs are actually found, both during development an in production.
How does a thermostat bring all of those features to the home, without first changing your entire HVAC installation? What most of us have in the home is a single HVAC unit, or at most two, with no parts that would allow any of the fun things you can do in a modern building. You need both an army of sensors and movable parts. If you build a home thermostat around those features, expect to not sell any, because it'd come only with new houses made for people that have quite a bit of money and much to say about the home's construction. It's not as if it's going to be a selling point for a company that builds a new random subdivision.
Next up, you'll be disappointed in the nexus 5 because it missed the opportunity of bringing the playboy party experience to the cellphone.
Well., many of those games come with their own editors already: You can make Portal levels with the same tools Valve used to make the game in the first place. The problem with those games is that making new levels is far harder than it was with the old stuff. Just compare making a level for Doom, Quake and any modern shooter. 8 year olds could make Doom levels easily: The map was actually 2d, so it was pretty easy. A level for Quake was way harder, because not only you are sculpting in 3d, but you have to care about a bunch of little details that you never had to care about in Doom. Visleafs anyone? Switch to a more modern game, and it's even harder, especially when it comes to art assets. Textures aren't just flat pictures anymore. Then you add animation, and it takes weeks to build a character for a game for a team of professionals: It's not something you can dabble in for a couple of hours a week.
Yes, and there's this thing called FDIC insurance that makes sure that if my bank gets hacked, my balance remains the same. Same thing if the bank suddenly disappears. The same features that crypto currency proponents tout as ways to avoid the supposed evil of central banks are precisely what makes this kind of attacks easier to get away with, and therefore much more likely.
A world with banks working on crypto currencies requires real life contracts and huge amounts of non-crypto collateral.
If I have a 50k deposit in a bank account, and said account disappears, our good friends in the FDIC will make sure I still get my money. It also becomes pretty difficult to close your bank, keeping all the money, without getting hunted down. If someone robs my bank, I lose zero dollars.
Good luck getting anything that resembles those protections in a crypto currency. You'd actually be safer having multiple offline copies in different locations.
There's lobbies for everything. There's this large company whose name starts with an M whose bottom line is helped a whole lot by increasing demand for corn, and both subsidies and the mandate to use ethanol in gas both help in that respect. So what you get here is a conflict between different lobbyists.
The only ones that truly lose are those without a lobby.
Of course there's enough people: There are plenty of private sector companies that are full of them. Good luck getting funding.
This is already checked for, and already gamed: We get wonderful things like socially trading citations, and making sure your grad students only work on things very similar to your core work, to make sure they cite your work, and keep citing it in the future.
But who wouldn't want to go back to a world before the invention of banking?
Imagine a world running on bitcoin. How long until a bank issues its own form of cryptocurrency that only it can mine, and then starts to use it on loans, as a form of fractional reserve banking?