IDEs sweet but beguiling

  • Comments posted to this topic are about the item IDEs sweet but beguiling

    Best wishes,
    Phil Factor

  • This is a really good article, Phil. It actually echoes what Bill Gates predicted back in the '80s when he said that, soon, there would be no programmers, just users. To a large extent, he's correct and it's all due to the "ease of programming offered by IDEs and GUIs". Even with all I do with T-SQL in SSMS, it's still not really programming. And, things like SSIS have made it so that people don't even need to understand the data to do something with it.

    Because the tools are so successful at enabling the unqualified, many people have labeled themselves as "experts" in fields they don't actually know much about. Of course, that's a huge problem. It has enabled people to try to do things they have no understanding of and, yes, I do mean "try" because the results are frequently disastrous in the areas of security, accuracy, performance, and scalability. It's kind of like a person using a "robot-guided surgical tool" and labeling themselves as a "doctor". They might know how to operate the machine to do a couple of different things but they may not have a clue as to when a certain operation should be performed or even if it should be performed. Heh... for example, men don't need hysterectomies and hemorrhoid repair should never be confused with a tonsillectomy but the machine will try to do whatever you tell it.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Great article Phil, great comment Jeff. Windows is a windowing environment and I love my IDE. However, I agree wholeheartedly that this labor saving tool designed for systems professionals enables people to get into trouble. They enable complex actions by people who don't have enough knowledge to understand the implications. In an open source world, the partial solution is for all of us, everyone, to embrace and advocate professionalism. Most specifically, we should help people in IT operations gain the knowledge to analyze the risk of what they are doing.

    Throughout this comment, I kept having to avoid saying that it is "IT professionals" who get into such trouble. Not so. Those of us who are this do not need my advice.

  • Nice editorial, Phil. You're certainly right in that a good IDE makes life easier. It helps people perform better investigation and make better decisions. Of course, it also enables people to do things they don't understand and get themselves into trouble much easier than in days past.

    I loved your phrase "Professor Google". How many times have we seen people copy and paste code from the internet and not understand it? It works so people put it into production and then have trouble when they have to support it. It's great for learning, but it's another aspect of the profession that lets people get themselves into trouble.

    No matter how good the IDE gets, I think the bottom line is that there's just no substitute for understanding the technology.

  • Not too sure I agree with what's being said here. You're taking a set of tools that empower you to do something at greater ease, with more accessibility and with consolidation and saying it's a trick or potentially a bad habit.

    It's easy to poke holes in the tools and methodologies we adapt with those tools. But the thing is, regardless of the trouble they can cause someone inexperienced, you got to think of the greatness they can instill in the right hands?

    I kind of relate my thoughts to a similar thought I had today when seeing an ad for the GoPro. I couldn't help but wonder what took a company so long to give the public something as cool as the GoPro that was likely only available to certain professionals at an extremely high price.

    Giving the public a high-quality weather resistant rugged mobile camera they can pretty much wear anywhere to record their own extreme sports, adventures and so forth allowed a lot of people to create some very powerful media that 10 years ago may not have been possible.

    Yet to sit on that ivory tower as a film producer and smug at the fact a 15-year old kid can make a Hollywood-isk film with a camera phone and a first generation GoPro without the 20-years of film experience is really setting us back rather than pushing us forward as an industry. :ermm:

  • I have some sympathy for both sides on this one. There are circumstances when you want people to have served the long apprenticeships and spent the requisite time stroking chins and thinking, learning the intimate details and knowing what all the risks are. There are other times when this may not be entirely necessary, and clever and sensible people, perhaps without such grounding, can take a chance on getting something done, realising it may not be perfect. Unfortunately such grounding does take a while and everyone needs to start somewhere.

    The other part of the perspective is that people who don't know everything can on occasion improve upon prior methods simply by not have been totally inculcated into a particular mode of behaviour. I've spent a lot of time programming but still learn plenty from those who have not spent half that time. Guiding and structuring a whole project, hopefully I can do this effectively, but the building blocks I use can certainly be spruced up plenty by fresh thinking.

  • I'm going to disagree with the general view here. How are people to get real world experience in the workplace without being allowed to have a go and learn from theirs and other colleague's mistakes along the way? I see a lot of posts in previous topics where people say they would likely cringe if they saw code from early in their careers, yet the same people are now experts having benefitted from that learning process.

    The view here is akin to telling a child they're not allowed to learn to ride a bike until they're an expert at riding a bike.

  • TheFault (2/29/2016)


    I'm going to disagree with the general view here. How are people to get real world experience in the workplace without being allowed to have a go and learn from theirs and other colleague's mistakes along the way? I see a lot of posts in previous topics where people say they would likely cringe if they saw code from early in their careers, yet the same people are now experts having benefitted from that learning process.

    The view here is akin to telling a child they're not allowed to learn to ride a bike until they're an expert at riding a bike.

    They should be allowed to play and learn, but not in production. They should also have code reviews and instruction. I had mentors when I was learning and they were absolutely invaluable.

    Even with "Professor Google" being available, it doesn't replace a mentor. In today's world of "coin-operated answer" machines, where someone posts a question and gets an answer, does a copy/paste and moves along, the part that's missing is an understanding of why the answer works and what's going on under the hood. That code then becomes the basis of every other solution that's similar, whether it works well or not.

  • A perfect example of this are data modeling tools, which are excellent for logical modeling, but much less useful when it comes to physical modeling and generating DLL scripts.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Jeff Moden (2/27/2016)


    This is a really good article, Phil. It actually echoes what Bill Gates predicted back in the '80s when he said that, soon, there would be no programmers, just users. To a large extent, he's correct and it's all due to the "ease of programming offered by IDEs and GUIs". Even with all I do with T-SQL in SSMS, it's still not really programming. And, things like SSIS have made it so that people don't even need to understand the data to do something with it.

    Whats "real programming" then?

  • To me, this sounds like conflation of two different issues. Most of the negatives being mentioned seem to center around them empowering less competent users to do things they otherwise shouldn't be able to do. To me, that's more of an institutional and process issue than anything related to IDEs.

    Ideally, an organization wouldn't allow a beginner to be point on an important project, but it happens, especially in smaller organizations where expertise and mentorship may not be available. I can't really blame people who get forced into such a situation.

    The only ones that really vex me are the people who think they're advanced when they're not. For example, I previously worked with someone who self-described as a "vba expert" when really all he knew how to do was run Excel's macro recorder and link the resulting macro to a button. He was like that with pretty much everything. Ironically, he got assigned on a project that had to use SQL Server. I wasn't even on the project, but came into a meeting on something else that he was also in and he just unloaded with stuff like "that program [SQL Server] is a joke."

    It's really rather humorous to watch the cognitive dissonance and anger that result when someone's self-perception as an expert is challenged.

  • Ed Wagner (2/29/2016)


    TheFault (2/29/2016)


    I'm going to disagree with the general view here. How are people to get real world experience in the workplace without being allowed to have a go and learn from theirs and other colleague's mistakes along the way? I see a lot of posts in previous topics where people say they would likely cringe if they saw code from early in their careers, yet the same people are now experts having benefitted from that learning process.

    The view here is akin to telling a child they're not allowed to learn to ride a bike until they're an expert at riding a bike.

    They should be allowed to play and learn, but not in production. They should also have code reviews and instruction. I had mentors when I was learning and they were absolutely invaluable.

    Even with "Professor Google" being available, it doesn't replace a mentor. In today's world of "coin-operated answer" machines, where someone posts a question and gets an answer, does a copy/paste and moves along, the part that's missing is an understanding of why the answer works and what's going on under the hood. That code then becomes the basis of every other solution that's similar, whether it works well or not.

    Sorry, I'm missing the connection here :-P. How does learning at work translate to screwing up production? In most organizations, there is a huge wall between production and dev. Most of us are able to tackle real-world problems with things that have worked in the past, others have to learn new approaches to solve the same problem. They both happen in dev and go through the same pipeline of review, testing and other final checks before being production ready.

    To say you know the solution to every problem is false. To say that production is 100% bug free is also false. The tools we have enable us to both work and learn better on the job or off.

  • In my opinion IDEs are like power tools (as in drills etc.) as they allow people to do things a lot quicker and with less effort. If you have coded without an IDE then it is like using handheld tools.

    Whatever tools used you shouldn't let an eager DIYer build a skyscraper. Nor would you expect a professional builder to still use tools technologically millennia old. A professional who has used handheld tools MAY, just may, know his craft a bit more. No guarantees though.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Gary Varga (2/29/2016)


    In my opinion IDEs are like power tools (as in drills etc.) as they allow people to do things a lot quicker and with less effort. If you have coded without an IDE then it is like using handheld tools.

    Whatever tools used you shouldn't let an eager DIYer build a skyscraper. Nor would you expect a professional builder to still use tools technologically millennia old. A professional who has used handheld tools MAY, just may, know his craft a bit more. No guarantees though.

    Nice analogy. I know it's true for me. Learning without any IDE definitely taught me to see thing differently. I still prefer to write it instead of clicking my way through a GUI.

  • I'm a little confused here as well. I learned to program in text editors, which were really notepad for various platforms. They provided nothing more than open, save, and indent.

    However those tools didn't enable me to build test harnesses or ensure code reviews, or build monitoring. isql, and isql/w for SQL Server, were similar. These tools work, but they don't really help you do anything better.

    The items mentioned, that separate the professionals from the hacks, aren't because of IDEs or the lack of them. These are habits and understanding. These come from the fact you view your work as a craft, and not as a job. You seek to be efficient, not only as you build systems, but to support them.

    I'd argue that many of our quite famous and extremely talented C, Lisp, Fortran, etc. programmers would cringe at the idea of not being able to use a debugger.

    IDEs truly help us manage the complexity of applications, without having to worry about every little keystroke. They are incredibly helpful. I'd argue DMVs are essential to better working with SQL Server, and SSIS is an incredible tool for migrating that strangely structured and poorly formatted data into rows and columns. The fact that these items are used by the poorly skilled has nothing to do with the tools.

    Without these tools, we'd still have complex, poorly written software. It would take a bit longer, in that the hunt and peckers, and the slow readers would take longer, but do you think for a second that a poor programmer using VS or SSMS would be a better programmer in isql or notepad?

    In terms of the power tool analogy, it's not bad, but not great. Power tools certainly allow you to do work quicker, and make mistakes quicker. You can ruin material quicker. However poor skills in putting materials together would still be poor skills with hand tools.

Viewing 15 posts - 1 through 15 (of 32 total)

You must be logged in to reply to this topic. Login to reply