Richard Davies wrote: The UK has a good crop of technology pioneers in cloud computing - for example ElasticHosts, FlexiScale, Flexiant, OnApp - and also some strong government initiatives such as G-Cloud.
We will have to see whether this kind of technical leadership converts into swift mass-market adoption or not.
While at lunch with colleagues recently I overheard four very able Java developers swapping horror stories of the kit they'd cut their teeth on as junior programmers. One had used a Sinclair ZX-81 with 1K of RAM and a black and white TV and a tape recorder in lieu of a hard drive. Things were so bad with the memory that the screen buffer was used to store program data. That story was trumped by tales of a Commodore 64 where after it was discovered that the built-in hard drive had its own processor, it was used to offload program work to create true symmetric multiprocessing on a box that was never designed for this.
Both stories came from wizened old developers convinced they'd won the mantle of "hardship programming in my youth." Ironically the college kid in the group played the five-ace hand with tales of taking a games console and stripping it down to a Unix box and then running it as his home server. Apart from feeling I was observing a 21st century version of Monty Python's "Four Yorkshiremen" sketch (www.phespirit.info/montypython/four_yorkshiremen.htm), I felt slightly worried by the allegories being drawn and implied by the dialog.
Without necessarily intending it, two messages were being conveyed. One was that you had to have struggled with basic tools and underpowered hardware to get a job done as a necessary rite of passage on the path to becoming a true programmer, and the second was the syllogism that if you continue to use sticks and stones to program you are somehow a superior programmer than someone who doesn't.
I encounter quite a lot of the latter attitude in my day job where I develop tools whose purpose is to help people write Java GUIs. When talking to users, some of them enjoy the obvious benefits of being able to preview their screen as they write it and handle components by selecting and manipulating them in WYSIWYG touchy-feely viewers. Others will rightly point out that the complexity of their GUI is beyond what the builder can cope with and that's a good reason not use it. Others seem almost threatened by what is basically a fairly entrenched idea of a tool creating code for you and they'll come up with every excuse possible why they shouldn't use it. Arguments vary from the code not conforming to their particular style, which, apart from often degenerating into an academic argument about how fields should be named or methods structured, also shows a certain intransigence against being able to adapt to a new style. It exhibits a belligerent and generally frowned upon trait in programmers to be inflexible when dealing with code authored by others without feeling the compunction to rewrite it.
The favored vestige of the non-IDE folks is often to drop down to a text editor such as vi or Emacs and gain some kind of Luddite satisfaction from editing raw files and firing off build scripts. I used to admire people who enjoyed coding with such tools similar to the way you might enjoy listening to classical music played on period instruments. After a while, however, it just starts to sound flat and hollow and in denial of all that has been learned since. The problem is being able to recognize the genuine aficionado of someone who is using his favorite antique editing experience because it genuinely makes him productive and able to focus on his job without helpful wizards and code assist, versus the one who is trying to copy the master and thereby fake credibility that masquerades his inability to focus on his job.
At a recent presentation I was giving on an IDE feature that makes it easier to write code, I had to deal with a heckler who told me how superior vi was and how we couldn't deal with his particular key bindings. The irony was that he wasn't from the wizened penguin bumper-sticker brigade who are the stereotypes of such attitudes - he was a fresh-faced, recent college grad and had brought his bellicose attitude almost as a badge of honor to parade.
Let's take cars, for example - my attitude is that when they break I take them to the mechanic; what's fun isn't so much tinkering with the engine myself and gaining some kind of machismo pride in doing so, it's the journeys I take in it and what I do when I arrive. Likewise with writing software - the purpose is to create a good user experience for someone else who wants to solve a particular problem in a more efficient way. I once had to explain to a customer why we were late shipping a particular software release and he replied that we were just polishing the inside of a tin can and he didn't care. He was right - we were upgrading operating system releases and migrating to a new language version mid-release cycle. However, there was no business value to it and we'd just taken our eye off the target and onto our navels.
Is the problem with software and tooling one of a master craftsman with his favorite chisel and simply that people are reluctant to change something that makes them most productive, or is it just that people have a built-in desire to belong to a herd and gain social acceptance from their tribal peers from where they can collectively mock progress and other languages and technology changes as being for the folks on the other team? Is the super-league of programmers occupied by folks who take apart game boxes and have wireless networks in their kitchen, or is it by those who would rather play some fun games on the box it was designed for and then enjoy a nice meal in the kitchen afterward?
About Joe Winchester Joe Winchester, Editor-in-Chief of Java Developer's Journal, was formerly JDJ's longtime Desktop Technologies Editor and is a software developer working on development tools for IBM in Hursley, UK.
Reader Feedback: Page 1 of 2
#20
Infernoz commented on 26 Jan 2005
Firstly you have picked some of the worst tools, VB is an an archaic hybrid, NetBeans hasn't grown up and Visual Studio and its low level tools are so top heavy and complex it needs loads of Wizards to get anything useful done i.e. not good comparisons with Java tools.
Yes IDEs have their quirks, as does all software, even different version of the same software e.g. MS Office, but the effort to learn the goods ones is often worth it, because you can work much faster with an IDE than in a text editor. As with most complex software you often don't have to learn the whole product at once i.e. only learn the stuff you need.
#19
Michael Powe commented on 19 Jan 2005
I disagree with some of the comments about IDEs vs editors. Usage of an IDE (e.g., NetBeans) breaks the task into two very separate components: you have to learn the language _and_ you have to learn the IDE. Learning NetBeans or Visual Studio can be every bit as daunting and time-consuming a task as learning the language itself. Pick up any book on learning VB, for example, and you will find most of the text covers using the IDE, not writing code. What's more, learning NetBeans does not mean you know how to use Eclipse or JBuilder efficiently, either. If your company switches IDEs, then you have to start over again and learn the new IDE.
I believe that much is gained from writing in an editor. What is gained is a greater on-the-ground familiarity with the language. Whether you use the (crappy) editor in Visual Studio or emacs, you need to be alert and focussed to accomplish your task. The result of that familiarity is going to be elegance and efficiency in your code, a better understanding of what it is doing and an enhanced ability to critique and debug it.
mp
#18
Larry A. Rowe commented on 29 Dec 2004
When the User who doesn't like you polishing the inside of your tin can is given his own IDE that will allow him to wish into being the software he wants then the person that owns that IDE owns him and the rest of us can go off and do other things for a living and for fun.
In the meantime Software Engineering still pays because for some strange entropic reason it still isn't autonomous or trivial.
And of course without a little can polishing we would all still be using Sinclairs.
Knowing when to use an IDE and when not to is similar to knowing when to go to a country doctor, but I figure his advice would be "When it starts hurting, then stop doing it!" :)
I myself prefer to use the tool of choice for a given task and shave with OCKHAM'S RAZOR whenever possible:
If a tool completely shields you from what it produces (the way a compiler shields you from the bytecode), then you run very little risk in using it. But if you'll be looking at or changing the output (ie, using a code generator or wizard), you had better understand the output.
Bottom line: if a tools helps you manage or create code that you understand, that's great -- you'll save a lot of time, and enjoy building more. But if the tool builds code you couldn't write on your own, code you don't understand, you're headed for trouble.
#16
Dan Clamage commented on 24 Dec 2004
One of the earliest IDE's I ever used was QuickC 1.0. It was a DOS-based, character-graphics UI. It streamlined the code-compile-test cycle. It had a built-in graphical debugger with breakpoints. It had context-sensitive help with a C manual for the language and runtime library (plus Microsoft's proprietary libraries). The text editor was pretty decent and supported multiple files within the main frame. It generated the make file for your project. Primitive by today's standards, but definitely helpful to beginner and more experienced C programmers. I was glad to have it available.
As a consultant, I often found myself in shops that provided nothing more than vi and a C compiler (or for Oracle development, sqlplusw and notepad). If that's all you have, then you have to be competent in that environment. So you build your own toolbelt of useful utilities, and take them along with you from gig to gig.
#15
Infernoz commented on 24 Dec 2004
So don't use the wizards to generate code, do it manually (in an IDE), IDE's still allow manual coding, but are often more helpful on the little useful bits than a text editor. As for cost, lots of the IDEs are free, and commercial IDEs have always had evaluation and/or licenced beginner/foundation (free) versions available.
One key benefit of good IDEs is that they integrate support for the JavaDocs (very useful, especially for beginners) e.g. you can highlight a class, property or method name in JBuilder *, press F1 and up pops the relevant JavaDocs page.
* Jbuilder even supports JavaDocs lookup for any external libaries associate with a project, provided the library directory/zip/jar contains the JavaDocs (or is told where to find them). I've used this feature a lot with Apache.org Java libraries e.g. Log4J, RegExp, ORO etc...., and the www.exolab.com castor XML libary. IMHO there are too many libaries to understand/memorise, so it's better to have fast efficent lookup.
#14
Ann Klein commented on 23 Dec 2004
(1)As a rank beginner I found it the generated code confusing. I wanted to learn to build a simple application from scratch. Once I understood the skeleton and the basic parts I am willing to switch to a fancy IDE. If you don't have some idea about what is under the covers you will be lost without your fancy IDE.
(2) When I was not on an official project, and before so much open source was available fancy IDE cost money and therefore were not available. I certainly did not have them at home. If I wanted to try out the new stuff I had to use the available tools. Tutorials that only told me where to click in their IDE did not teach me how to code.
#13
Infernoz commented on 23 Dec 2004
I've used both emacs and vi in the past when I had nothing better, but I quickly jumped when the more capable/powerful editor Cygnus-Ed became available on the Amiga (with AREXX automation support).
I now use Borland JBuilder (on Windows) because it works, has lots of genuinely time saving features (e.g. refactoring, drop-down method lists etc., serious build and library support, switchable JDK support etc....) and can easily be extended e.g. I have a custom project menu to run a Java class to build castor XML classes from specific XSD's. No stupid key combos to remember and all the complex stuff is automated, it just works.
I have had to go back to using make for some legacy DOS C work and damn is painful, ant is just a java XML version of this, IMHO extensible IDE project files are so much easier. I don't want some kludge on an ancient editors, which needs any kind of make like script, it's just nasty.
BTW I tried Eclipse, it had some interesting features, but just seemed glued together, not really an integrated experience, IMHO JBuilder does it better.
#12
Laslo Bednarik commented on 22 Dec 2004
I have worked with excellent developers of either type - some that wanted to have everything done in Emacs and some that were really fond of their chosen IDE. So I agree to let everybody choose the tools that make them most productive.
Regarding the pride in "having done it the hard way" - there is also some learning aspect to it. Yes, you can quickly assemble a GUI using some IDEs. But to really understand what the underlying API offers and to be able to think about a problem in the way of the used framework I would advice everybody to handcraft a non-trivial GUI at least once.
For me the learning effect is much higher than clicking and dragging around elements.
After I know what I am working with I can still benefit from the GUI builder in future projects. And I am less likely to be lost when I hit the limits of the tool.
#11
A. Lloyd Flanagan commented on 22 Dec 2004
Well, it depends upon what your priorities are when coding. IDE's offer great visual building tools. However, their text editing is usually rudimentary at best -- just the basics.
With Emacs I have to code the visual interface from scratch. On the other hand, I can do in a couple of keystrokes editing tasks that would be very difficult to do in any IDE I've yet worked with.
Emacs also:
1. Is cross-platform.
2. Is open source -- there's no vendor to abandon it when the VCs pull their funding.
3. Knows about a LOT of different languages, and has custom modes that add powerful tools for that particular language to the editor -- seamlessly.
4. Is highly customizable.
What I want is an IDE that offers the above advantages. Emacs has its drawbacks, and I've been looking for a good replacement for some time. I haven't found it yet. However, I think Eclipse just might get there, at least if you've got lots of memory to burn.
#10
Mark Kaiser commented on 22 Dec 2004
To attempt to disqualify a writer's opinion and the questions he brings solely becauses he writes IDE's for a living is as limited and short sighted as either using only IDE's for coding or using only the text editors out there.
There are generally two types of people that I have worked with in development over the past seven years: Those whose primary purpose and excitement in their job is evangelizing (either about the newest IDE, or about how open-source is pure, or about the only way to code is through a simple editor, et. al), and those whose primary excitement is designing and developing an extensible, maintainable system regardless of those factors.
The fact is, elegant and maintainable systems can be developed with nearly any language, technology, editor or IDE. The ability to MacGyver a system in extreme situations is quite admirable; however, the gunslinger mentality that the idolization of those abilities promotes is generally destructive to software development teams and the building and maintenance of actual business applications. This is also the gist from what I took from Mr. Winchester's article. And I agree.
So, my attitude is this: use whatever tools make you, as a developer, the most productive -- if you use a hand-router better than you use a powered router because you feel like you make fewer mistakes and that this makes your overall productivity better, then go to it. And if you use the powered router, knowing that you'll have to incorporate mistake-fixing time into your equation, and THAT improves your productivity, then more power to you (pun intended). But don't cast aspersions on the other camp just because they are in the other camp.
Be open to using the tools that improve your development productivity and help your clients produce their business applications. Be a solutions provider, not a solutions evangelist.
My two pennies,
Mark Kaiser
#9
Bob G. commented on 22 Dec 2004
There are great programmers. There are programmers that want you to think they are great. Then there are those that write articles complaining about them. Over time, market factors will determine who is 'great' and who is outsourced. How they get themselves there is their concern - unless you write IDE's for a living.
Funny how this "IDEs are superior; people who use vi/Emacs are Luddites" position is always advanced by people with an IDE that they want other people to use. I've never heard of anyone who gave up Emacs for an IDE and then began evangelizing for it.
The simple truth is that real programmers (those with long-term experience) realize that IDEs are bad news for any number of reasons. Proprietary IDEs come and go, and woe unto you who have your project locked into their proprietary file formats when they go. (I could make a museum of old Java IDEs that died horrible deaths.) Most IDEs are exceptionally clumsy, getting in the way of a competent programmer who knows what to do and is trying to get it done, with clumsy interfaces, confusing UIs, etc. IDEs frequently don't work as advertised (a main reason why I don't bother with them anymore), crashing and having all sorts of errors.
Emacs will be around forever because (1) it is stable and works great, and (2) it can be adapted to whatever new language/fad/tool that comes along.
Every tool has a cost as well as a benifit. While I agree that using ancient tools is not necessarily good, using modern tools has a cost of it's own.
How many amoung use have used MS visual design tools and have spent hours moving fields around or scratching our head because it is acting in a way that makes no sense, or done something really strange because the design tool doesn't allow what we need to do. So the argument that the tools are implicitly better doesn't hold water in many cases and you often don't know which track is better (at least small apps) for an application until after it is behind schedule.
Additionally, the people that learned on the new tools are just as arrogant about the new tools.
Like it or not coding is in many ways a social activity and the best programmers require an arrogance to be any good, just like golfers or chess masters. The arrogance is gained by being good at something that is hard to do. The challenge to the developer community and the tool developers is evolve the tools, keep the arrogance and move the community forward.
#6
Dan Clamage commented on 21 Dec 2004
Hey back when I was still in school I took a PT job writing BASIC on the old IBM System/23 (the granddaddy of the PC). Painting the edit forms fields on screen was a trial-and-error chore. So I wrote a program that let me enter screen coordinates and field length from a command line, then drew the field for me. Once I had the screen painted the way I wanted, the program dumped all the field info to a file. This then became the skeleton of my form application. This relatively simple tool saved me hours of drudgework.
At another company, my boss asked me to write queries to exercise all the indexes for a table. We were trying to identify corrupt indexes. Each table had anywhere from 4 to 16 indexes. She wanted this done for 6 tables. So I thought to myself, I could spend the next 4 hours devising the SQL for one of the tables; or I could write a generator to create the SQL for me. While challenging, once developed, it took just seconds to generate all of the SQL needed. I dumped the query code to a script, kicked it off, and went home.
Infernoz wrote: Firstly you have picked some of the worst tools, VB is an an archaic hybrid, NetBeans hasn't grown up and Visual Studio and its low level tools are so top heavy and complex it needs loads of Wizards to get anything useful done i.e. not good comparisons with Java tools.
Yes IDEs have their quirks, as does all software, even different version of the same software e.g. MS Office, but the effort to learn the goods ones is often worth it, because you can work much faster with an IDE than in a text editor. As with most complex software you often don't have to learn the whole product at once i.e. only learn the stuff you need.
Michael Powe wrote: I disagree with some of the comments about IDEs vs editors. Usage of an IDE (e.g., NetBeans) breaks the task into two very separate components: you have to learn the language _and_ you have to learn the IDE. Learning NetBeans or Visual Studio can be every bit as daunting and time-consuming a task as learning the language itself. Pick up any book on learning VB, for example, and you will find most of the text covers using the IDE, not writing code. What's more, learning NetBeans does not mean you know how to use Eclipse or JBuilder efficiently, either. If your company switches IDEs, then you have to start over again and learn the new IDE.
I believe that much is gained from writing in an editor. What is gained is a greater on-the-ground familiarity with the language. Whether you use the (crappy) editor in Visual Studio or emacs, you need to be alert and focussed to accomplish...
Larry A. Rowe wrote: When the User who doesn't like you polishing the inside of your tin can is given his own IDE that will allow him to wish into being the software he wants then the person that owns that IDE owns him and the rest of us can go off and do other things for a living and for fun.
In the meantime Software Engineering still pays because for some strange entropic reason it still isn't autonomous or trivial.
And of course without a little can polishing we would all still be using Sinclairs.
Knowing when to use an IDE and when not to is similar to knowing when to go to a country doctor, but I figure his advice would be "When it starts hurting, then stop doing it!" :)
I myself prefer to use the tool of choice for a given task and shave with OCKHAM'S RAZOR whenever possible:
``Pluralitas non est ponenda sine neccesitate''
http://phyun5.ucr.edu/~wudka/Physics7/Notes_www/node10.html
Dan Bernier wrote: If a tool completely shields you from what it produces (the way a compiler shields you from the bytecode), then you run very little risk in using it. But if you'll be looking at or changing the output (ie, using a code generator or wizard), you had better understand the output.
Bottom line: if a tools helps you manage or create code that you understand, that's great -- you'll save a lot of time, and enjoy building more. But if the tool builds code you couldn't write on your own, code you don't understand, you're headed for trouble.
Dan Clamage wrote: One of the earliest IDE's I ever used was QuickC 1.0. It was a DOS-based, character-graphics UI. It streamlined the code-compile-test cycle. It had a built-in graphical debugger with breakpoints. It had context-sensitive help with a C manual for the language and runtime library (plus Microsoft's proprietary libraries). The text editor was pretty decent and supported multiple files within the main frame. It generated the make file for your project. Primitive by today's standards, but definitely helpful to beginner and more experienced C programmers. I was glad to have it available.
As a consultant, I often found myself in shops that provided nothing more than vi and a C compiler (or for Oracle development, sqlplusw and notepad). If that's all you have, then you have to be competent in that environment. So you build your own toolbelt of useful utilities, and take them along with you from...
Infernoz wrote: So don't use the wizards to generate code, do it manually (in an IDE), IDE's still allow manual coding, but are often more helpful on the little useful bits than a text editor. As for cost, lots of the IDEs are free, and commercial IDEs have always had evaluation and/or licenced beginner/foundation (free) versions available.
One key benefit of good IDEs is that they integrate support for the JavaDocs (very useful, especially for beginners) e.g. you can highlight a class, property or method name in JBuilder *, press F1 and up pops the relevant JavaDocs page.
* Jbuilder even supports JavaDocs lookup for any external libaries associate with a project, provided the library directory/zip/jar contains the JavaDocs (or is told where to find them). I've used this feature a lot with Apache.org Java libraries e.g. Log4J, RegExp, ORO etc...., and the www.exolab.com castor XML libary. IMH...
Ann Klein wrote: (1)As a rank beginner I found it the generated code confusing. I wanted to learn to build a simple application from scratch. Once I understood the skeleton and the basic parts I am willing to switch to a fancy IDE. If you don't have some idea about what is under the covers you will be lost without your fancy IDE.
(2) When I was not on an official project, and before so much open source was available fancy IDE cost money and therefore were not available. I certainly did not have them at home. If I wanted to try out the new stuff I had to use the available tools. Tutorials that only told me where to click in their IDE did not teach me how to code.
Infernoz wrote: I've used both emacs and vi in the past when I had nothing better, but I quickly jumped when the more capable/powerful editor Cygnus-Ed became available on the Amiga (with AREXX automation support).
I now use Borland JBuilder (on Windows) because it works, has lots of genuinely time saving features (e.g. refactoring, drop-down method lists etc., serious build and library support, switchable JDK support etc....) and can easily be extended e.g. I have a custom project menu to run a Java class to build castor XML classes from specific XSD's. No stupid key combos to remember and all the complex stuff is automated, it just works.
I have had to go back to using make for some legacy DOS C work and damn is painful, ant is just a java XML version of this, IMHO extensible IDE project files are so much easier. I don't want some kludge on an ancient editors, which needs any kind of make like...
Laslo Bednarik wrote: I have worked with excellent developers of either type - some that wanted to have everything done in Emacs and some that were really fond of their chosen IDE. So I agree to let everybody choose the tools that make them most productive.
Regarding the pride in "having done it the hard way" - there is also some learning aspect to it. Yes, you can quickly assemble a GUI using some IDEs. But to really understand what the underlying API offers and to be able to think about a problem in the way of the used framework I would advice everybody to handcraft a non-trivial GUI at least once.
For me the learning effect is much higher than clicking and dragging around elements.
After I know what I am working with I can still benefit from the GUI builder in future projects. And I am less likely to be lost when I hit the limits of the tool.
A. Lloyd Flanagan wrote: Well, it depends upon what your priorities are when coding. IDE's offer great visual building tools. However, their text editing is usually rudimentary at best -- just the basics.
With Emacs I have to code the visual interface from scratch. On the other hand, I can do in a couple of keystrokes editing tasks that would be very difficult to do in any IDE I've yet worked with.
Emacs also:
1. Is cross-platform.
2. Is open source -- there's no vendor to abandon it when the VCs pull their funding.
3. Knows about a LOT of different languages, and has custom modes that add powerful tools for that particular language to the editor -- seamlessly.
4. Is highly customizable.
What I want is an IDE that offers the above advantages. Emacs has its drawbacks, and I've been looking for a good replacement for some time. I haven't found it yet. However, I think Eclipse just might get...
Mark Kaiser wrote: To attempt to disqualify a writer's opinion and the questions he brings solely becauses he writes IDE's for a living is as limited and short sighted as either using only IDE's for coding or using only the text editors out there.
There are generally two types of people that I have worked with in development over the past seven years: Those whose primary purpose and excitement in their job is evangelizing (either about the newest IDE, or about how open-source is pure, or about the only way to code is through a simple editor, et. al), and those whose primary excitement is designing and developing an extensible, maintainable system regardless of those factors.
The fact is, elegant and maintainable systems can be developed with nearly any language, technology, editor or IDE. The ability to MacGyver a system in extreme situations is quite admirable; however, the gunslinger men...
Bob G. wrote: There are great programmers. There are programmers that want you to think they are great. Then there are those that write articles complaining about them. Over time, market factors will determine who is 'great' and who is outsourced. How they get themselves there is their concern - unless you write IDE's for a living.
Scott McMahan wrote: Funny how this "IDEs are superior; people who use vi/Emacs are Luddites" position is always advanced by people with an IDE that they want other people to use. I've never heard of anyone who gave up Emacs for an IDE and then began evangelizing for it.
The simple truth is that real programmers (those with long-term experience) realize that IDEs are bad news for any number of reasons. Proprietary IDEs come and go, and woe unto you who have your project locked into their proprietary file formats when they go. (I could make a museum of old Java IDEs that died horrible deaths.) Most IDEs are exceptionally clumsy, getting in the way of a competent programmer who knows what to do and is trying to get it done, with clumsy interfaces, confusing UIs, etc. IDEs frequently don't work as advertised (a main reason why I don't bother with them anymore), crashing and having all sorts of errors.
Em...
Edgar Dollin wrote: Every tool has a cost as well as a benifit. While I agree that using ancient tools is not necessarily good, using modern tools has a cost of it's own.
How many amoung use have used MS visual design tools and have spent hours moving fields around or scratching our head because it is acting in a way that makes no sense, or done something really strange because the design tool doesn't allow what we need to do. So the argument that the tools are implicitly better doesn't hold water in many cases and you often don't know which track is better (at least small apps) for an application until after it is behind schedule.
Additionally, the people that learned on the new tools are just as arrogant about the new tools.
Like it or not coding is in many ways a social activity and the best programmers require an arrogance to be any good, just like golfers or chess masters. The arrogance is...
Dan Clamage wrote: Hey back when I was still in school I took a PT job writing BASIC on the old IBM System/23 (the granddaddy of the PC). Painting the edit forms fields on screen was a trial-and-error chore. So I wrote a program that let me enter screen coordinates and field length from a command line, then drew the field for me. Once I had the screen painted the way I wanted, the program dumped all the field info to a file. This then became the skeleton of my form application. This relatively simple tool saved me hours of drudgework.
At another company, my boss asked me to write queries to exercise all the indexes for a table. We were trying to identify corrupt indexes. Each table had anywhere from 4 to 16 indexes. She wanted this done for 6 tables. So I thought to myself, I could spend the next 4 hours devising the SQL for one of the tables; or I could write a generator to create the SQL for me. While...
Joe Maia wrote: Having been in the software development business for over 26 years, I've seen many viewpoints - from the hard-core bit-heads who think programming in anything other than assembly language is somehow "cheating" and is not worthy of "real" programmers ... to the "design" jock who thinks touching code is for junior programmer hacks and who spends all their time drawing UML diagrams.
To each his own, I suppose.
I count myself in the group described by Dmitry above. The best developers are those who know how to choose the proper tools for the job at hand, and who know how to develop flexible, maintainable, well-documented, user-friendly, products.
The bit-jockies and gadget-twiddlers who pride themselves for completely revamping a piece of hardware or for producing a bit of code that will run in the smallest space possible, generate more problems than they solve unless they also fol...
Richard Johnson wrote: Great article - I've faced all of the attitudes you describe.
I think it's a simple balancing act.. Show someone that the effort saved by a tool outweighs that expended in learning it, and they'll soon start using it. The problem is overcoming the hurdle of convincing someone that their upfront investment in learning will pay off. I also think a lot of developers would benefit from having done it 'the hard way' first.
Joe Moraca wrote: Another way to read the conversation is "pushing the limits" and working on the edge of current technology is what drives many people
Norman Azadian wrote: Using your car analogy; you say: "... it's the journeys I take in it and what I do when I arrive." Some of us would definitely find the journey vastly improved with a Ferrari. Some of us actually like to get our hands dirty (and learn something) by fixing the car ourselves. I submit that the person who enjoys the Ferrari, the person who fixes his own car, is someone who knows, understands, and appreciates cars. You just use a car as a tool to get you from A to B. When you get stranded out on a lonely road, with no telephone coverage, you'll be wishing for someone who knows and cares about cars, someone who takes "some kind of machismo pride" in being able to fend for himself.
Perhaps a better analogy would be assembly code. Hardly anybody writes it these days unless she has to, but it wasn't always that way.
NHA
Dmitry Leskov wrote: To me, the "superleague" of programmers as you call it consists of people who can choose the right tool for the job and use it effectively, being it refactoring a 50,000 classes app in IntelliJ IDEA on their workstation or binary patching a malfunct proprietary driver on a customer's Unix box on the other side of the world via a telnet session.
Swisscom, the Swiss telecom, is going into the cloud business.
Its subsidiary Swisscom IT Services AG has signed up with Red Hat as a Certified Cloud Provider and launched a public cloud Infrastructure-as-a-Service (IaaS) cloud targeting enterprise-class customers primarily in ...
Apache Deltacloud, the Red Hat-contributed ReSTful API that abstracts differences between clouds so services on any cloud can be managed – provided of course there’s a driver – has graduated from the Apache Foundation’s incubator and is now a full-fledged Top-Level Project (TLP)....
In a surprise move on Tuesday, January 10, Oracle wheeled out its Big Data Appliance.
That’s the one it said in October would be ready sometime in the first half. Only nobody believed it meant early in the first half. Heck, it’s not even clear anybody thought Oracle could make ...
Rackspace Hosting, the service leader in cloud computing, on Thursday announced its acquisition of SharePoint911, an industry leader in SharePoint consulting, training, and "JumpStart" services within SharePoint. The unification of both companies provides capabilities to deliver ...
CloudLinux, Inc., on Thursday released CafeFS 3, a virtualized file system for shared hosters that cages each customer within its own virtualized file system.
CageFS becomes part of CloudLinux OS at no additional charge. CloudLinux OS, the only commercially-supported Linux OS m...
About Newsfeeds / Video Feeds
.gif)
Swisscom, the Swiss telecom, is going into the cloud business.
Its subsidiary Swisscom IT Services AG has signed up with Red Hat as a Certified Cloud Provider and launched a public cloud Infrastructure-as-a-Service (IaaS) cloud targeting enterprise-class customers primarily in ...
Apache Deltacloud, the Red Hat-contributed ReSTful API that abstracts differences between clouds so services on any cloud can be managed – provided of course there’s a driver – has graduated from the Apache Foundation’s incubator and is now a full-fledged Top-Level Project (TLP)....
In a surprise move on Tuesday, January 10, Oracle wheeled out its Big Data Appliance.
That’s the one it said in October would be ready sometime in the first half. Only nobody believed it meant early in the first half. Heck, it’s not even clear anybody thought Oracle could make ...
Rackspace Hosting, the service leader in cloud computing, on Thursday announced its acquisition of SharePoint911, an industry leader in SharePoint consulting, training, and "JumpStart" services within SharePoint. The unification of both companies provides capabilities to deliver ...
CloudLinux, Inc., on Thursday released CafeFS 3, a virtualized file system for shared hosters that cages each customer within its own virtualized file system.
CageFS becomes part of CloudLinux OS at no additional charge. CloudLinux OS, the only commercially-supported Linux OS m...
