Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Does Visual Studio make you stupid?

Does Visual Studio make you stupid?

Rate This
  • Comments 43

I know everyone's talking about this, but it IS a good question...

Charles Petzold recently gave this speech to the NYC .NET users group.

I've got to say, having seen Daniel's experiences with Visual Basic, I can certainly see where Charles is coming from.  Due partly to the ease of use of VB, and (honestly) a lack of desire to dig deeper into the subject, Daniel's really quite ignorant of how these "computer" thingies work.  He can use them just fine, but he has no understanding of what's happening.

More importantly, he doesn't understand how to string functions/procedures together to build a coherent whole - if it can't be implemented with a button or image, it doesn't exist...

 

Anyway, what do you think?

 

  • Some countries require the ability to fix at least some kinds of mechanical problems in cars before issuing a driver's licence. In some of those same countries it's standard practice to run red lights, run down pedestrians in crosswalks, etc.

    If someone can "drive" VB enough to have fun for themselves but also learn (or be in a sandbox) to avoid hurting anyone else, well fine, let them. Let mechanics be mechanics.
  • I would argue that there's a certain evolution of knowledge in any field, and that in order to advance in overall complexity, that you must simplify/consolidate/hide the lower-level tasks. This lets you focus on innovation because less energy is spent simply making something work.

    Take photography, for example. 99+% of people don't have their own dark rooms, and have no idea how to develop film or make their own prints. Digital photography has even taken the film out of the picture (pun).

    Sure, there are some die-hards out there who still do everything end-to-end because they enjoy it. But, for the most part, people are happy snapping pictures on their Canon Powershot and emailing them off to Grandma. Are modern photographers worst at their art because they don't know how to do all of the low-level work that photographers of 50-100 years ago performed?

    I for one welcome the Intellisense-Code-Generating overlords. They allow me to put my ideas into code much more quickly than when I had to do everything from scratch.
  • His rants on Visual Studio sounds like the a "Real Programmers use Fortran" phase that all programmers with a lot of experience seem to go through. Years ago, when punch cards were on their way out, there probably was someone complaining how programming had become just conversations with a text editor, and how it rots your brain because you can start banging out code without thinking about your algorithms carefully, etc....etc. Wash, rinse, and repeat. Yawn.
  • Using Visual Studio 2005 makes me about as stupid as when I transitioned from programming in assembly to C. I got rusty on the various instructions, registers, etc. and started to get actual work done. I sure didn't feel very stupid at the time, now that I think about it.

    I don't buy the Petzold's argument at all. It's just a tradeoff between productivity and detailed control via abstraction. I don't know what is so hard to understand about that, since this has happened in this industry 'n' times already.
  • I don't think the photography argument holds up though - most people who snap photos on their Powershots and email them to Grandma wouldn't claim to be "photographers". I think if you talk to a photographer-by-trade, you'll find that they at least have an understanding of how aperture settings, shutter speeds, and development techniques can lead to very different outcomes. Sure, they may leave the darkroom work to someone else so they can get more pictures taken (and maybe as a result their darkroom skills have become a little rusty), but they're not completely clueless as to what takes place in there.

    A good software developer should work the same way - in order to get your project completed, most of the time you want to work at a high-enough level of abstraction that you can actually be productive. But if you haven't got a clue what's going on at a lower level because you've relied entirely on Visual Studio keeping the guts hidden from you, that sounds like a recipe for disaster.

    If you understand what VS is doing for you, and why it's doing what it's doing, great, let it save you some time. But if you're just letting it do it because "that's how Visual Studio works", then it's making you dumber.
  • I thought it was decadent when I bought a macroassembler so I didn't have to look up opcodes in the 6510 reference manual. But, I've never again wasted an hour recalculating branch offsets to fit in an extra instruction.
  • While intellisense is an intelligence multiplier, “closed” code generation forces me to deal with black boxes all the time, which spoils my intellect. It is one of those things that should be available in source code, or maybe redesigned to be template based.
  • I'm of two minds on this. I think several of his points are valid. At the same time, I look at the tremendous productivity I have made as a developer. Things that would have taken months to develop now take weeks. Performance-wise and maintainablity-wise, I think things are better now.

    Of course, this doesn't mean that I blindly accept the fluff that VS.NET has to offer. Over time and with experience, you see where the fluff is just fluff and where you really need to dig deeper and do things differently. Especially if you are developing a software product, as opposed to a simple quick-and-dirty project.

    Very interesting none-the-less.
  • Of course it makes you stupid! And allows you to be otherly-smart. (Which is what everyone else is saying, too.)

    Then again, going against what I'm sure most other 'softies would believe, I claim that the world needs average-skilled productive devs more than it does 133t ones. Nothing personal against the gurus, but I don't see a sustainable business model for us if we're interested in making it MORE difficult to write code so that only the highly-trained, experienced graybeards know how to do it.

    I saw a link to Petzold's speech on /. and followed the link, but skipped the commentary because this is exactly the kind of thing that crowd seems to love. After all, it's an excuse to do some sparring for alpha geek territory. Garbage!

    3rd party devs aside, IMHO if Daniel gets interested enough in coding he'll start to dig deeper because that's where some of the really fun (meaning difficult) challenges lie. I wouldn't think that currently lacking depth of knowledge is anything to worry about. He's probably busy solving the problems that are interesting to *him* and that's the kind of empowerment I think Microsoft ought to be focused on. (Note: modding games is also a very common way for kids to get into coding today and I think that's cool, too.)

    Crap. I read like a glossy brochure. I'd best lay off the Kool Aid for a while.
  • In my opinion good programming has nothing to do with the language or the tools you use to build a program / system. It has everything to do with mindset and your ability to work professionally, turn problems into solutions in an efficient way (both logically, technically and time wise).

    I could build a solution in Assembly, C(++), C#, VB, VB.NET, HTML, Pascal and I could do that with a simple text editor, with a DOS copy con line or an elaborate IDE.

    I prefer the latter, as do my clients, since it usually cuts time and makes everything much more manageable.

    So I do think it is necessary to at least know how a computer works and the platforms you are programming on (Windows and .NET for example). Now you don't have to be an expert, but it is good to know how multithreading works under Windows for example. And how this doesn't work under COM with Visual Basic if you are developing in that language.

    Rob
    visuar@iname.com
  • I dubt it makes people stupid, but the VB-ifying (dumbing-down) of it sure makes new users ignorant and some (many?) existing professional (C/C++ only?) developers more than frustrated (*).

    I believe one part of the problem is VS gives you basically two choices. Either use all the (ohhh, new, shiny!) whistles-and-bells and be treated as a child - having code generated for you and do exactly what Microsoft thinks you should do in exactly the way Microsoft thinks you should do it (no matter how illogical or stupid) - or turn off all that shite and go "hard-core old-school".

    I suspect this is in part due to trying too hard to please the previous VB "developers" in the "test groups" from the large companies MS check with, that mostly or even only use it for in-house work. Perhaps it could be good to again start paying attention to the ones that makes Windows a viable platform - the developers that makes Windows software for the public?

    (*) The frustration I've experience is of the kind making you more than once both hear and voice the opinion that "If I had the bastard/moron even allowing this shit, I'd use a baseball bat and a pound of salt in more imaginative ways than you can dream of. Without KY!"
  • Well, by a similar token, then, doesn't using the BCL itself also promote laziness?

    I mean, developers can now decode UTF-8 documents without knowing how UTF-8 works at the byte level. Developers can Base64-encode a byte array without knowing how Base64 works. With a couple of lines of code, a developer can retrieve a file from a web server without knowing anything about the HTTP protocol, let alone how TCP/IP works.

    Get even lower than that. A lot of people out there do not know how to do math anymore (beyond arithmetic). And do they need to? Just pull out a computer, fire up Excel, and let it do the work for you. I'm sure that at one time, the academic world was up in arms about how computers make people lazy because they aren't able to use logarithms or whatever.

    But this is what innovation is all about--it's not just finding cool new ways to do things. But rather, it's about allowing me to forget all of my previous skills so that I can concentrate on developing new skills.
  • Someone else hit it right on the head with the photography analogy. Just because I can take a picture and email it to grandma, I don't claim that I am a photographer. In programming, people who build simple HTML pages think they are programmers.

    VS.NET any other productivity aids do no make old programmers stupid, they make stupid new programmers.

    In the case of RAD tools for UI, products such as Delphi and VS.NET have allowed programmers to create complex (and usually bad) UI beyond their ability to create and support the code required to bring that UI to life. When we looked at moving our tools development from Borland C++ Builder to VC7/MFC, one of the arguments against doing such a thing was that the UI building tools in VC7/MFC were primitive compared to Borland C++ Builder. My counter argument was that the amount of time we spend working on UI is very small compared to the amount of time working on the UI and non-UI support code. Does this mean our new UI's are of less quality? In reality our UIs are of better quality because the UIs tend to be simpler, more in line with standard Windows UI and have the quality support code needed to bring the tools to life.

    If I had my way, I would train new programmers without many of the productivity tools we currently have available.

    P.S. The idea that we don't need "gurus" anymore is just silly. The difference between a well crafted program done by "gurus" and a functional program done by code monkeys can be very substantial. But sometimes the hard part is getting the "guru" to stop playing and release the software before it is a masterpiece.
  • UTF-8? Base64?

    The problem isn't about knowing how to decode UTF-8 and other such formats. The problem is knowing what UTF-8 is, the relationships between UTF-8 and other encoding systems and the impact of one encoding scheme compared to another. We have encoding schemes such as UTF-8 because they meet specific needs that other encoding schemes did not. However, UTF-8 has limitations that makes it harder to use than other encoding schemes in different applications.

    When the software is made available to the programmer without the programmer being required to understand what he is working with, then you get case after case of inappropriate usage.

    This is why I am still trying to get someone like Michael K. to talk about internationalization where I work. I know just enough about the subject to know that we currently have no clue what we are doing. The problem is that the high availability of conversion software has made it easy to get the software to work without knowing if what we are doing is the right thing to do.
  • What I think is going on here is us folks that grew up having to understand the stack order in C vs. Pascal calls. So we see these new folks, quite happy not knowing the plumbing, and wonder if they can possibly do things bug-free enough. Our industry is maturing; I am sure there are engineers that wonder how one can do a bridge without drawing SOMETHING in pencil. My opinion is that 80% of the time they don't have to know the plumbing. And when they do, they will come to us an ask. We need them, and they need us. As in nature, a symbiotic relationship.
Page 1 of 3 (43 items) 123