I agree with your point regarding training vs education. However very little development is green fields. New developers should receive product training in your domain specific field. You do have to introduce people to the existing product and the thinking that went into solving a specific problem. Otherwise you wont leverage the value you already have, and your code-base will quickly evolve into a fragmented set of different solutions. Programmers need to know the fundamentals and the inherent ability to think and come up with new ideas (education and skill), but they should also learn and take advantage of things other built before them (product training).
This would get all my mod points (if i had any). Project managers who only care about, and only manage the project on project milestones are my pet hate....but I have a lot of respect your other category.
I don't think project managers need to be technical, but it does often help if they have some background or can easily pick up technical concepts....because the communication between different stakeholders isn't always at a high level feature / functionality level. Different parties can be fussy about low level details and projects can get blocked on technical issues which the project manager needs to have some understanding of. I've worked with some excellent project managers, and they have been invaluable at handling tough clients and challenging projects and making sure everyone is happy. They did this primarily through good communication and management by having empathy and respect for everyone.
Technical team leads are another story. If you have a small technical team who has a non-technical lead who's only job is line management and administration for that team....its very likely you have too much process and politics, and your organization structure is likely too deep. Management at that level should have a technical background and they should have some technical responsibility and authority over the work being done...even be doing some of it themselves.
Powershell isn't meant to do everything...if you judge it by that, it is a fail. But it is extensible. We use it at work from a build server to package up our some fairly big and complicated builds and automatically deploy it to a remote server, as well as the final product deployments too. Powershell does 90% of the work, but we've had to extend it in a few places to do some of the low level stuff. Its easily configurable, concise, but more importantly its maintainable by any decent windows admin or developer.
That is true for any project where you just keep building something bottom-up and just adding more code at the UI layer, or whatever layer your entry points are. I've seen enormous source code files in many languages / platforms. You've got to think beyond that and apply a little more structure yourself i.e. separation of concerns. Don't just slip into the easiest path whatever IDE, interface builder, or framework slides you down.
Unit tests are great...but don't fall into the trap thinking that if you cover your code with them, it will find all your bugs, or protect you from changes introducing new ones.
Unit tests are usually very granular and designed to test specific scenarios. It also forces your code to be very modular in order to isolate the things to test. These are not bad attributes, but what many programmers forget is an application is the sum of its parts, and things most often break in the integration of all those pieces...not just isolated individual pieces you wrote the unit tests for.
Unit tests are just one part of the toolkit. Other tools and practices are good too. Writing clean code, logging, peer review etc. Even with perfect unit tests, the debugger is still indispensable for actually tracing into the code when you find a problem and understanding whats going on.
Most software is over-designed with features and options. 95% of users (not techies) are much happier having a simpler interface that easier to learn and use.
It is *very* difficult to hide complexity in software...most techies and designers usually avoid the problem by just adding options, abstraction layers, and complexity (this includes things like file systems, disk formats, encryption, and power saving options). Providing something functional yet simple that will still appeal the the majority is not easy.
Apple usually gets this right (not always), which is why they generally make great consumer devices. It does not appeal to technologists or the enterprise though, because they usually want more options, extensibility, or customization.
This trend happens in everything. A Model T ford exposed its implantation to a far greater extent to the driver. But most people these days just get in a car with very little of its deeper implementation or working exposed. Most people dont drive cars that they customize (although "commercial" or "trade" versions are usually still available for those that do). Apple devices are consumer devices. Dont expect from them all the same things you get from Linux or Windows.
Iran's current government is abysmal...but as a *nation* it has suffered a lot from foreign interference, including from the US, UK, and USSR. The main ones being an invasion during World War 2, an imposition of a dictator a decade later, and supporting Saddam Hussein in the Iraq/Iran war that caused millions of deaths. Yes, their current regime has behaved badly, and continues to do so, but so has the western world. On the balance of things, not looking at the smaller examples only, they have suffered more as a people and country.
And a little googling will show that Iran *did* offer aid after Katrina, but the US rejected it, as it did most foreign aid offers. Not a criticism though, its often for valid reasons. Aid hardly ever comes without strings attached...from anyone.
Buses are safer per miles traveled too, but people still drive cars....you cant just use safety stats. Nuclear is a sexy technology, and everything in me as a geek screams for me to support it. However its not an economically better option, and even less so if you factor in all the external costs; including nuclear waste, WMD proliferation fears etc. Fukushima might not have killed anyone, but what is the economic cost of the loss of all the productive land that has had to be evacuated? Countries like Britain only ever built Nuclear reactors because it produced the Uranium for their Nuclear weapons industry, and to reduce power of the coal miner unions....not because it was cheaper, even by the very optimistic calculations of the people that wanted it.
I always see the same arguments by pro-nuclear proponents here. I divide them into two threads...(1) Dont judge us by previous reactors designs....newer designs are safer...fair enough, but their still super expensive and can still fail catastrophically in a worst case scenario...and (2) My magic bullet will fix everything e.g. thorium, fast breeder.....sorry, none of these options exist commercially yet, are feasible, or meet all critical concerns.
Im not anti-nuclear...it has current applications like big bombs or powering very expensive warships... but ive yet to see a good economic power producing argument for them that includes all the external costs. I don't close my mind to new ideas e.g. a travelling wave reactor.....just make a good case for it first.
Part of the problem is you. Bosses can be jerks, but a lot of that is determined by how you let them treat you. As a coder, you shouldn't be an interchangeable part...you have skills and knowledge specific to organization. Use it....do a good job, but also be confident and stand up for yourself. Your not a easily replaceable factory line worker.
Next, work on your social skills. Be diplomatic with everyone you deal with. This means understanding where they come from (even if their jerks), and trying to make them happy. Often this means just listening, and framing your responses in their language. Its funny how easy it is to introduce people to new ideas if you come from their position but add something new.
Be proud of your work, and communicate it. This doesn't mean crowing or anything "in your face". Document it, comment your code, make it nice so that others understand it. It will form trust and respect from other workmates.
Finally, don't get stuck in a rut. Even if your day to day job is boring, be open to new ideas. Read, learn, experiment, and code on the side. Try to find something you enjoy, and find a way to relate it to your work. This doesn't mean introducing every new technology or pattern fad to your current project, but if its something you can do on the side, or something you can discuss with your team, its all good.
If you do these things, add them to your CV...even if you have no intention of moving jobs, its just something you can take pride in. Its easy to get down about work, but in software development, there is so much scope to do things that make our work more enjoyable. Even if your current job continues to be a pain, these are all things that will help you find something new. If you don't change, then your situation wont either.
I'm not disagreeing completely with you here...but judging popular protests by the fact that they don't "suggest something better" in not fair. A mass protest movement is never going to have a single better alternative to offer...there are simply too many people with contrary views. That doesn't make their grievance with the status quo unjust, and it doesn't mean that the government / system cant be reformed improved in ways to make it better for the majority. Most of them don't want to bring the system down...most still want their iPhones, they still want to use Facebook, and drink Coke....they just want improvements for everyone.
Just because hippies were dirty and smelly and high on pot, and had some loony ideas, didn't make Nixon a good president...
Re:What he took away is more precious than given
on
Steve Jobs Dead At 56
·
· Score: 1
That has nothing to do with iOS or Android being a walled garden... iOS just has a better design; its applications are sandboxed from the underlying OS or need explicit permission to do the things that malware on Android easily gets away with.
I think people exaggerate the walled garden argument for the iPhone. Yes, Apple imposes some draconian conditions sometimes, but its still a pretty open platform. Most of the apps i use, and the content i have brought on my phone, have not been provided by Apple. I believe most of what the people here associate with a walled garden and criticize Apple about, are really decisions Apple made to make its devices more appealing to consumers e.g. iTunes pricing, simple content purchasing, and simplicity...
Want a more open device...dont buy an iPhone...most likely you will still be using a lot of technology and ideas pioneered by Apple e.g. Webkit, touch interfaces...but most likely, it wont be as great a consumer device.
Steve was a complex and amazing person....i dont mean to lessen all the contributions of all the people that worked with him, but he was the one that led and drove them into producing the most polished and consumer friendly devices that are with us today. He was a true leader and visionary...
There is nothing wrong with having a native client for specialized graphic intensive applications....but why cant the web browser also perform some of these more general tasks? No-one is suggesting you implement a Graphics API in Javascript, but a web browser is more then capable of hosting some fairly advanced graphical visualizations or games by building on top of lower level components like Canvas or WebGL.
Most "game engines" are based on similar architectures....highly performant engine components written in native C++, but game logic and user interface scripted in a higher level languages (LUA, QuakeC etc).
Native is always better for no-compromise performance and for taking full advantage of the platform, but web browsers have their place too.
Its not Active Desktop. This is a new shell and a new user interface paradigm, built on top of a completely new cross-platform API (WinRT). Metro applications run in seperate processes, sandboxed, and they never touch the win32 API. Furthermore, applications are installed from a trusted source (the windows app store). Its not a dodgy web page asking you to install an ActiveX control.
Microsoft are actually doing a lot of things right this time IMHO. Metro isnt for productivity applications or games, but its pretty good for tablets, status or information displays, or casual stuff. Dont like it, dont use it. Its not replacing the desktop. Excel, Blender, OpenOffice wont ever use it. Its just another shell, thats all.
My only gripe is they Metro applications can be written in HTML+js, but using extensions. This is so it appeals to a wide developer base. However, their not trying embrace and embed the wider web, so in this regard, its better then Android or iOS which use much more proprietary tools to write their applications.
There is a bit in truth in both of those statements. Google may be shutting down a lot of its "experiments", but they had all served their purpose and their benefits have been incorporated into existing products. Innovation doesn't mean green lighting every "neat idea"...they should all serve a purpose, but if you don't allow your employees to spend some time to innovate and try new things, your never going to improve your products.
Some of the worst places ive worked at is where they punished you for thinking outside the box or doing something different, even if they had real potential to provide a lot of benefits.
I actually agree. I wasnt impressed when my local ISP outsourced their email to them. However, their recent mail upgrade is pretty awesome. It has nice web UI, and works well with desktop mail clients too e.g. archives everything you sent through SMTP.
Good software engineering practices like code reviews, source control, bug tracking, unit testing, etc. are generally no different. If applied correctly, they should reduce the overall time to release a product.
I actually agree with you here...but to use your analogy against you...*which practices?* I'm sure medicine is full of examples of practices that were thought to be beneficial, but that later went out of fashion. Software engineering is the same. Tell me in what context a practice is good, how it should be applied, and what benefits it gives, what pitfalls should be avoided, and proof for these claims.
A lot of the "practices" we do in software development is driven by trends e.g. the latest technology or the latest methodology, or politics e.g. excessive reviews, meetings, procedures etc.
Not the price up front, but through rewards in the game. Slashdot's karma works in a similar way. Everyone can post, its equal in that sense, but people with more karma get more recognition. Multi-player games could have the same mechanism. Playing nicely with others could do things like making it easier to join another multi-player server, and would earn you in-game rewards more easily. Designing such a system that rewards positive behavior would be fiendishly difficult though. Also, a global ranking might not work....i might like playing with this person, but someone else might not....i might like playing with this person in this game, but not in another...
Now, I don't think MS gets, even now, how that works. Calling stored procedures in MS-SQL from any VisualStudio framework is a royal pain in the ass. They tout DRY but I can't think why you have to jump through loops to get stored procedures to work in their frameworks; I have many complex queries in SQL to list records, why would I want to repeat the same SQL statements in an MVC app and in a WinForms app against the same database? The surest way to achieve DRY is to use stored procedures and let each app handle only the presentation of the data.
This isnt an MS specific thing...its true for many ORM frameworks. In the MS world, most ORM frameworks sit on top of ADO.NET, but their abstraction is so much, that a lot of database features become hard to access. However, using ADO.NET directly, calling Stored Procedures, or using other database features (e.g. full-text search) is fairly easy to do.
My own personal preference (and im not saying it suits everyone or everything), is not to use a "heavy" ORM framework or abstraction layer to "hide" the database or its features and functionality. I use the old ADO.NET typed datasets to cache data in memory, helper classes to automate the simple CRUD operations based on the meta information in the dataset, and the more complicated data operations (multiple joins, searches, complicated updates) happen in database views or stored procedures. For me, its a good compromise between both worlds (ORM vs direct database access).
This article is not looking very accurate right now. Hindsight is 20/20, but there has been a lot of inaccurate pro-nuclear reporting and commentary too, especially here, to the point of being partisan and political. Many wont acknowledge it has real dangers and other pitfalls. Despite the best possible planning and design, worst-case-scenarios do happen (you would think anyone in IT knows that), and very sadly, we just saw the result.
You say you don't understand why the iPod ever got to the top, but you list the #1 reason why they did...they made it idiot proof. Most people are not geeks and don't enjoy exploring every piece of functionality or configuration option. Most people arnt idiots either, but they don't have the patience to explore every arcane bit of new technology. Apple just made it work and made the majority of people happy (except geeks).
I completely agree with this. Its not about quantity of lines-of-code or words-per-minute, its about being able to hold an idea as you execute it. Ive seen developers using a laptop keyboard and a trackpad losing focus as they try and implement something and they stuggle with the keyboard and moving the mouse pointer. Someone who has the right tools and knows how to use them well can focus on the higher-order problems more easily. Its the same in any profession.
Just a general question...whats the chance of Mozilla ditching gecko and using webkit? Firefox's strength isnt the rendering engine, its all the add-ons. Chrome is very elegant, but i dont see myself using it, because im addicted to things like firebug...
Slashdot Mirror
I agree with your point regarding training vs education. However very little development is green fields. New developers should receive product training in your domain specific field. You do have to introduce people to the existing product and the thinking that went into solving a specific problem. Otherwise you wont leverage the value you already have, and your code-base will quickly evolve into a fragmented set of different solutions. Programmers need to know the fundamentals and the inherent ability to think and come up with new ideas (education and skill), but they should also learn and take advantage of things other built before them (product training).
This would get all my mod points (if i had any). Project managers who only care about, and only manage the project on project milestones are my pet hate....but I have a lot of respect your other category.
I don't think project managers need to be technical, but it does often help if they have some background or can easily pick up technical concepts. ...because the communication between different stakeholders isn't always at a high level feature / functionality level. Different parties can be fussy about low level details and projects can get blocked on technical issues which the project manager needs to have some understanding of. I've worked with some excellent project managers, and they have been invaluable at handling tough clients and challenging projects and making sure everyone is happy. They did this primarily through good communication and management by having empathy and respect for everyone.
Technical team leads are another story. If you have a small technical team who has a non-technical lead who's only job is line management and administration for that team....its very likely you have too much process and politics, and your organization structure is likely too deep. Management at that level should have a technical background and they should have some technical responsibility and authority over the work being done...even be doing some of it themselves.
Powershell isn't meant to do everything...if you judge it by that, it is a fail. But it is extensible. We use it at work from a build server to package up our some fairly big and complicated builds and automatically deploy it to a remote server, as well as the final product deployments too. Powershell does 90% of the work, but we've had to extend it in a few places to do some of the low level stuff. Its easily configurable, concise, but more importantly its maintainable by any decent windows admin or developer.
That is true for any project where you just keep building something bottom-up and just adding more code at the UI layer, or whatever layer your entry points are. I've seen enormous source code files in many languages / platforms. You've got to think beyond that and apply a little more structure yourself i.e. separation of concerns. Don't just slip into the easiest path whatever IDE, interface builder, or framework slides you down.
Sorry if i sounded critical, and thanks for the feedback.
Unit tests are great...but don't fall into the trap thinking that if you cover your code with them, it will find all your bugs, or protect you from changes introducing new ones.
Unit tests are usually very granular and designed to test specific scenarios. It also forces your code to be very modular in order to isolate the things to test. These are not bad attributes, but what many programmers forget is an application is the sum of its parts, and things most often break in the integration of all those pieces...not just isolated individual pieces you wrote the unit tests for.
Unit tests are just one part of the toolkit. Other tools and practices are good too. Writing clean code, logging, peer review etc. Even with perfect unit tests, the debugger is still indispensable for actually tracing into the code when you find a problem and understanding whats going on.
Most software is over-designed with features and options. 95% of users (not techies) are much happier having a simpler interface that easier to learn and use.
It is *very* difficult to hide complexity in software...most techies and designers usually avoid the problem by just adding options, abstraction layers, and complexity (this includes things like file systems, disk formats, encryption, and power saving options). Providing something functional yet simple that will still appeal the the majority is not easy.
Apple usually gets this right (not always), which is why they generally make great consumer devices. It does not appeal to technologists or the enterprise though, because they usually want more options, extensibility, or customization.
This trend happens in everything. A Model T ford exposed its implantation to a far greater extent to the driver. But most people these days just get in a car with very little of its deeper implementation or working exposed. Most people dont drive cars that they customize (although "commercial" or "trade" versions are usually still available for those that do). Apple devices are consumer devices. Dont expect from them all the same things you get from Linux or Windows.
Iran's current government is abysmal...but as a *nation* it has suffered a lot from foreign interference, including from the US, UK, and USSR. The main ones being an invasion during World War 2, an imposition of a dictator a decade later, and supporting Saddam Hussein in the Iraq/Iran war that caused millions of deaths. Yes, their current regime has behaved badly, and continues to do so, but so has the western world. On the balance of things, not looking at the smaller examples only, they have suffered more as a people and country.
And a little googling will show that Iran *did* offer aid after Katrina, but the US rejected it, as it did most foreign aid offers. Not a criticism though, its often for valid reasons. Aid hardly ever comes without strings attached...from anyone.
Buses are safer per miles traveled too, but people still drive cars....you cant just use safety stats. Nuclear is a sexy technology, and everything in me as a geek screams for me to support it. However its not an economically better option, and even less so if you factor in all the external costs; including nuclear waste, WMD proliferation fears etc. Fukushima might not have killed anyone, but what is the economic cost of the loss of all the productive land that has had to be evacuated? Countries like Britain only ever built Nuclear reactors because it produced the Uranium for their Nuclear weapons industry, and to reduce power of the coal miner unions....not because it was cheaper, even by the very optimistic calculations of the people that wanted it.
I always see the same arguments by pro-nuclear proponents here. I divide them into two threads...(1) Dont judge us by previous reactors designs....newer designs are safer...fair enough, but their still super expensive and can still fail catastrophically in a worst case scenario...and (2) My magic bullet will fix everything e.g. thorium, fast breeder.....sorry, none of these options exist commercially yet, are feasible, or meet all critical concerns.
Im not anti-nuclear...it has current applications like big bombs or powering very expensive warships... but ive yet to see a good economic power producing argument for them that includes all the external costs. I don't close my mind to new ideas e.g. a travelling wave reactor.....just make a good case for it first.
Part of the problem is you. Bosses can be jerks, but a lot of that is determined by how you let them treat you. As a coder, you shouldn't be an interchangeable part...you have skills and knowledge specific to organization. Use it....do a good job, but also be confident and stand up for yourself. Your not a easily replaceable factory line worker.
Next, work on your social skills. Be diplomatic with everyone you deal with. This means understanding where they come from (even if their jerks), and trying to make them happy. Often this means just listening, and framing your responses in their language. Its funny how easy it is to introduce people to new ideas if you come from their position but add something new.
Be proud of your work, and communicate it. This doesn't mean crowing or anything "in your face". Document it, comment your code, make it nice so that others understand it. It will form trust and respect from other workmates.
Finally, don't get stuck in a rut. Even if your day to day job is boring, be open to new ideas. Read, learn, experiment, and code on the side. Try to find something you enjoy, and find a way to relate it to your work. This doesn't mean introducing every new technology or pattern fad to your current project, but if its something you can do on the side, or something you can discuss with your team, its all good.
If you do these things, add them to your CV...even if you have no intention of moving jobs, its just something you can take pride in. Its easy to get down about work, but in software development, there is so much scope to do things that make our work more enjoyable. Even if your current job continues to be a pain, these are all things that will help you find something new. If you don't change, then your situation wont either.
I'm not disagreeing completely with you here...but judging popular protests by the fact that they don't "suggest something better" in not fair. A mass protest movement is never going to have a single better alternative to offer...there are simply too many people with contrary views. That doesn't make their grievance with the status quo unjust, and it doesn't mean that the government / system cant be reformed improved in ways to make it better for the majority. Most of them don't want to bring the system down...most still want their iPhones, they still want to use Facebook, and drink Coke....they just want improvements for everyone.
Just because hippies were dirty and smelly and high on pot, and had some loony ideas, didn't make Nixon a good president...
That has nothing to do with iOS or Android being a walled garden... iOS just has a better design; its applications are sandboxed from the underlying OS or need explicit permission to do the things that malware on Android easily gets away with.
I think people exaggerate the walled garden argument for the iPhone. Yes, Apple imposes some draconian conditions sometimes, but its still a pretty open platform. Most of the apps i use, and the content i have brought on my phone, have not been provided by Apple. I believe most of what the people here associate with a walled garden and criticize Apple about, are really decisions Apple made to make its devices more appealing to consumers e.g. iTunes pricing, simple content purchasing, and simplicity...
Want a more open device...dont buy an iPhone...most likely you will still be using a lot of technology and ideas pioneered by Apple e.g. Webkit, touch interfaces...but most likely, it wont be as great a consumer device.
Steve was a complex and amazing person....i dont mean to lessen all the contributions of all the people that worked with him, but he was the one that led and drove them into producing the most polished and consumer friendly devices that are with us today. He was a true leader and visionary...
There is nothing wrong with having a native client for specialized graphic intensive applications....but why cant the web browser also perform some of these more general tasks? No-one is suggesting you implement a Graphics API in Javascript, but a web browser is more then capable of hosting some fairly advanced graphical visualizations or games by building on top of lower level components like Canvas or WebGL.
Most "game engines" are based on similar architectures....highly performant engine components written in native C++, but game logic and user interface scripted in a higher level languages (LUA, QuakeC etc).
Native is always better for no-compromise performance and for taking full advantage of the platform, but web browsers have their place too.
Its not Active Desktop. This is a new shell and a new user interface paradigm, built on top of a completely new cross-platform API (WinRT). Metro applications run in seperate processes, sandboxed, and they never touch the win32 API. Furthermore, applications are installed from a trusted source (the windows app store). Its not a dodgy web page asking you to install an ActiveX control.
Microsoft are actually doing a lot of things right this time IMHO. Metro isnt for productivity applications or games, but its pretty good for tablets, status or information displays, or casual stuff. Dont like it, dont use it. Its not replacing the desktop. Excel, Blender, OpenOffice wont ever use it. Its just another shell, thats all.
My only gripe is they Metro applications can be written in HTML+js, but using extensions. This is so it appeals to a wide developer base. However, their not trying embrace and embed the wider web, so in this regard, its better then Android or iOS which use much more proprietary tools to write their applications.
There is a bit in truth in both of those statements. Google may be shutting down a lot of its "experiments", but they had all served their purpose and their benefits have been incorporated into existing products. Innovation doesn't mean green lighting every "neat idea"...they should all serve a purpose, but if you don't allow your employees to spend some time to innovate and try new things, your never going to improve your products. Some of the worst places ive worked at is where they punished you for thinking outside the box or doing something different, even if they had real potential to provide a lot of benefits.
I actually agree. I wasnt impressed when my local ISP outsourced their email to them. However, their recent mail upgrade is pretty awesome. It has nice web UI, and works well with desktop mail clients too e.g. archives everything you sent through SMTP.
Good software engineering practices like code reviews, source control, bug tracking, unit testing, etc. are generally no different. If applied correctly, they should reduce the overall time to release a product.
I actually agree with you here...but to use your analogy against you...*which practices?* I'm sure medicine is full of examples of practices that were thought to be beneficial, but that later went out of fashion. Software engineering is the same. Tell me in what context a practice is good, how it should be applied, and what benefits it gives, what pitfalls should be avoided, and proof for these claims. A lot of the "practices" we do in software development is driven by trends e.g. the latest technology or the latest methodology, or politics e.g. excessive reviews, meetings, procedures etc.
Not the price up front, but through rewards in the game. Slashdot's karma works in a similar way. Everyone can post, its equal in that sense, but people with more karma get more recognition. Multi-player games could have the same mechanism. Playing nicely with others could do things like making it easier to join another multi-player server, and would earn you in-game rewards more easily. Designing such a system that rewards positive behavior would be fiendishly difficult though. Also, a global ranking might not work....i might like playing with this person, but someone else might not....i might like playing with this person in this game, but not in another...
Now, I don't think MS gets, even now, how that works. Calling stored procedures in MS-SQL from any VisualStudio framework is a royal pain in the ass. They tout DRY but I can't think why you have to jump through loops to get stored procedures to work in their frameworks; I have many complex queries in SQL to list records, why would I want to repeat the same SQL statements in an MVC app and in a WinForms app against the same database? The surest way to achieve DRY is to use stored procedures and let each app handle only the presentation of the data.
This isnt an MS specific thing...its true for many ORM frameworks. In the MS world, most ORM frameworks sit on top of ADO.NET, but their abstraction is so much, that a lot of database features become hard to access. However, using ADO.NET directly, calling Stored Procedures, or using other database features (e.g. full-text search) is fairly easy to do.
My own personal preference (and im not saying it suits everyone or everything), is not to use a "heavy" ORM framework or abstraction layer to "hide" the database or its features and functionality. I use the old ADO.NET typed datasets to cache data in memory, helper classes to automate the simple CRUD operations based on the meta information in the dataset, and the more complicated data operations (multiple joins, searches, complicated updates) happen in database views or stored procedures. For me, its a good compromise between both worlds (ORM vs direct database access).
This article is not looking very accurate right now. Hindsight is 20/20, but there has been a lot of inaccurate pro-nuclear reporting and commentary too, especially here, to the point of being partisan and political. Many wont acknowledge it has real dangers and other pitfalls. Despite the best possible planning and design, worst-case-scenarios do happen (you would think anyone in IT knows that), and very sadly, we just saw the result.
You say you don't understand why the iPod ever got to the top, but you list the #1 reason why they did...they made it idiot proof. Most people are not geeks and don't enjoy exploring every piece of functionality or configuration option. Most people arnt idiots either, but they don't have the patience to explore every arcane bit of new technology. Apple just made it work and made the majority of people happy (except geeks).
I completely agree with this. Its not about quantity of lines-of-code or words-per-minute, its about being able to hold an idea as you execute it. Ive seen developers using a laptop keyboard and a trackpad losing focus as they try and implement something and they stuggle with the keyboard and moving the mouse pointer. Someone who has the right tools and knows how to use them well can focus on the higher-order problems more easily. Its the same in any profession.
Just a general question...whats the chance of Mozilla ditching gecko and using webkit? Firefox's strength isnt the rendering engine, its all the add-ons. Chrome is very elegant, but i dont see myself using it, because im addicted to things like firebug...